Reverse DNS

Computers identify themselves with numbers called IP addresses. so, for example, an IP address would look like this:

10.35.73.234

Actually, you won't see an IP address that starts with 10, because all the 10 addresses are reserved. Anyone can use them for their network, but you can't use them externally. I make considerable use of 10 addresses, and my firewall translates them to the addresses that you access.

But you don't type in numbers to access a computer, you use names, because people find it easier to remember names. Like blogger.com. So something has to translate the names to the numbers, and that's called DNS, Domain Name Services.

But for some purposes you need to be able to translate the other way round. Given an IP addreess, you want to know what name corresponds to that, and that's called Reverse Domain Name Services, rDNS.

If you want to send email to someone signed up with AOL's email service, you have to get rDNS working; ditto Comcast, and there might be others. If you don't have rDNS, then AOL won't deliver the email, on account of it's probably spam. But getting it working isn't easy.

First, I had to get my ISP to delegate the rDNS to me; their default is that they do it, but they don't do it quite right, they translate every IP address to something a bit silly. That's OK for AOL - AOL don't care what it translates to, as long as it's something.

Then I had to tell my name servers to do the rDNS. For that, I had to set up data files with the reverse translation. To do that, you have to give each IP address a name, so 10.35.73.234 would be 234.73.35.10.in-addr.arpa. Notice that the numbers are backwards, and you have to add the magic incantation "in-addr.arpa", and then you put in the file the name that this corresponds to.

Already you can see it's a nightmare.

Here's some help.

http://mxtoolbox.com/

http://www.debouncer.com/reverse-dns-check

http://postmaster.aol.com/cgi-bin/plugh/rdns.pl

Those will tell you when you have it wrong. But they can't tell you how to put it right. And it's worse - when you make a change, it takes a while, maybe an hour or more, for it to get noticed around the internet, so if you make a change, you can't really test it immediately.

Anyway.

I had it *almost* right, and I've had it *almost* right for some years. But the AOL tester was only working about half the time. Half the time it told me my rDNS was working, half the time it told me it wasn't. Not too big a deal, because my email to AOL were getting through. But it bothered me.

I finally worked out what was wrong. To use rDNS, you have to have name servers, of course. And to use DNS you have to use name servers. But how do you know where my name server is? How do you know the IP address of my name server, because if you don't, you can't ask my name server any questions.

The answer is, root name servers. Your computer asks the root name servers, which I imagine are big boxes in stainless steel cases, with armed guards all round. The root name servers don't know the answer, but they know which server you can ask. Except that server don't know the answer, but it knows a server that does. And the question gets delegated down until eventually, an answer is supplied, now you know the IP address of my name server, and now you can ask it for the IP address of any of my servers.

So, the IP address of my name servers wasn't in my data file. No point. You already know the IP address of my name server if you're asking it questions.

But it turns out that for rDNS, you *do* have to have the IP address of your name server, and if I'd thought about it, I'd have realised why.

When you try to resolve 10.35.73.234 to a name, you don't know where my name server is, and you can't ask the root name servers to find out for you. So my file that contains the IP addresses of all my servers, also has to have the IP address of my name servers.

I added that, and bingo! My rDNS now works perfectly.

And I now understand the internet a little bit more. Maybe.