Reverse DNS is about finding a name for an IP address. The system is quite simple, the IP address is converted to a name and a lookup done in the usual way. The record type for a reverse DNS lookup is a PTR record not an A record.
Because of the way DNS works, control is delegated at each level, so my.firebrick.co.uk is delegated so that the name servers for co.uk tell the name servers for firebrick.co.uk and so on. This is normally only at a couple of levels but it could be that at each level control of the domains below that level (i.e. with anything added to the start of the domain) are delegated to a new name server.
With IP addresses the control is delegated the other way, e.g. 217.x.x.x is delegated to RIPE, and 217.169.0.x is delegated to AAISP. To allow DNS to be used to turn IP addresses in to names, the reverse DNS name for an IP address is backwards. For example 217.169.0.1 is 1.0.169.217.in-addr.arpa . This means that 217.in-addr.arpa is delegated to RIPE and 0.169.217.in-addr.arpa is delegated to AAISP.
To delegate your IP addresses to you we have to find a way to delegate within the block of 256 addresses we have received from RIPE. Few customers have a complete block of 256 addresses. Those that do can simply be set up so that their own name servers are used in the delegation from RIPE. For anyone with less than 256 addresses we have to find a way to give you some of the addresses within a block - which DNS does not allow.
We have two main ways to solve this, and you can select which you prefer using the control pages. In both cases the task is to set up the name servers which you manage and which will give the answers for reverse DNS queries. The two Reverse DNS name server boxes on the control pages let you specify one or two name servers (by name, not by IP address) for you name server(s). Don't put a dot on the end of the name though.
Delegation by NS works by putting your name server in our DNS for each of your addresses. e.g. if you had 217.169.0.0-3 then we would put your name servers for each entry 0.0.169.217.in-addr.arpa , 1.0.169.217.in-addr.arpa,2.0.169.217.in-addr.arpa,3.0.169.217.in-addr.arpa . This would mean you can create 4 separate zone files each of which has to normal SOA records, etc, and a single PTR record with the name for that IP address. This is logically the correct way of doing it as the reverse DNS zone is delegated at each level of control right down to the IP address level. It is rather tedious to set up lots of zone files though, especially if you have, say, 128 addresses.
Delegation by CNAME is a way to delegate a block of addresses to you so that you only have one zone file to worry about. The way this works is that we put a CNAME record for each address indicating that the answer is found under a different name. We then delegate that different name to your name servers. There are several ways to do this, but we use the system of first-last.restofzone.in-addr.arpa. e.g. if you had 217.169.0.0-3 we would delegate a zone 0-3.0.169.217.in-addr.arpa to your name server(s) and add CNAME entries for each IP, e.g. 1.0.169.217.in-addr.arpa with CNAME to 1.0-3.0.169.217.in-adrr.arpa .
Auto reverse is a third option that works by filling in a PTR record for each IP4 address and a corresponding forward A record as well so that all of your IP addresses will have a valid reverse entry automatically. This is mainly for customers who are not interested in setting up any reverse entries but need something in place to avoid problems with some servers. If you also use A+reverse records in a domain then your IPs will have two PTR records, both valid.
Most ADSL customers will have a small block of IPs which they can delegate using CNAME if they want. However all ADSL lines also have a single IP address for the external (WAN) side of their ADSL router. This is always delegated as a single zone for the IP address.
Domain reverse is provided where you have a domain that we manage in our DNS, and want an IP we manage to refer to and from that name. To do this you can create an A+reverse record in your domain DNS entries (instead of simply an A record). This will automatically complete the corresponding reverse entry in our DNS mapping the IP address back to the name.This is usually the simplest way to handle reverse DNS when you also have a domain with us.
We provide constant monitoring for all ADSL lines. This is done by sending a tiny LCP echo (like a ping) every second to your router. The reply to this LCP echo shows us that your router is on-line and working, and we can tell if any packets are being lost as well as the round trip time (latency) of your circuit at that point in time. See our Constant Quality Monitoring page for more details.
Whenever you send or receive data (web pages, email, etc) the packets of data are buffered in the router at each end. The router sends the packets as fast as the line allows, but the queue of packets waiting means that any new packet is delayed slightly as it has to wait it's turn. This means using your line will increase latency. This is quite normal and means that the green/blue trace on your usage graph is a reflection of the level of usage of your line.
You can also sometimes see slight increases in latency during the day on some lines if the local BT exchange or part of the BT network is busy. As ADSL is a shared service this is quite normal and is one of the differences between Standard and Premium services, but there are bigger differences simply because of the way lines are routed via the BT network.
A big factor affecting latency is error correction and interleaving. These are turned on to allow a poor quality line to work better, but can be disabled if you wish (ask support) if latency is more important to you.
The graph shows a peak latency in green. Each point represents 100
seconds of sampling and the green trace the the biggest delay in that
100 seconds. There is also a lower blue trace which shows the average
latency for the 100 seconds.
As usage increases, initially you see green on top of the blue, but
with large file transfers, you will see the blue level increase.
Outgoing traffic has far more impact and can cause latency to go off the top of the graph (500ms).
Packet loss is a measure of how many LCP echos did not respond. Packet loss is normally expressed as a percentage. Whilst we are only measuring where our LCP echos are lost, they are an indication of the percentage of all packets that are being lost at that time. We work on 100 second samples, so counting the lost packets gives us a percentage.
Packet loss can happen for several reasons. The main one is that transferring a lot of data will actually fill the buffers on a router and it has no choice but to drop a packet. This is normal, and TCP (the protocol used for reliably transferring data on the internet) expects packet loss and uses it as an indication that it is trying to send data too fast. TCP will slow down when it sees a dropped packet and will adjust its speed to try and send at just the right speed. This can mean that when transferring a lot of data you will see some packet loss - a percent or two per TCP session. If you have lots of TCP sessions at once (e.g. multiple file transfers or point to point file sharing programs) then you could see quite high percentages of packet loss while sending or receiving data.
Packet loss because of usage of the line is easy to spot as it is associated with high latency. This sort of packet loss only happens if the routers buffers are full, and that means high latency as well as packet loss. On the graph this shows as blue and green being quite high with some red creeping up from the bottom.This is quite normal.
The other reason for packet loss would be a fault, and this is the main reason we track the packet loss. If we see packet loss, even only 1%, when the latency is low, then this means that there is probably a fault on the line or other equipment. You may think 1% packet loss would not be a problem, but what happens is that TCP thinks it is sending too fast even if it is sending very slowly, and so it slows down even more. With just a few percent of random packet loss you can find the internet almost unusably slow.
Please don't jump to conclusions though. If you think there is a problem with your line please contact tech support and we will look in to it. Having the usage graphs for everyone means we can quickly identify different types of fault and report to BT where necessary. We may even do this before you have spotted any problem yourself.
The other thing we can tell is that you are off line. Your line logs in when you connect and can log out as well. If however your line stops answering LCP echos for 10 seconds we will log you out.
Logged out is shown in a different colour (purple) on the graphs.
You can set up a mobile number and we will send an SMS if you line is unexpectedly off line, and then when it is on line again. You can set your line so these are only sent during the day. This is not sent if your router logged off cleanly rather than it being unexpected.
If your line goes on and off line a lot then the SMS will be progressively delayed. If your line comes back on during this delay you will not get an SMS at all. This helps reduce the annoyance (and cost) of sending a text evry time, but means if your line goes off very occasionaly you are told promptly.
You can also ask for an email when you go on/off line.
We have systems for tracking attacks. An attack is typically if you have offended someone, such as comments in an irc channel, or quite often if you have a virus infected machine attacking other people. We don't condone any sort of attack.
If your line is attacked it will be shut down automatically and the SMS you are sent advises it is because of an attack. Contact support for more details.