Regular DNS
The thing to remember about DNS is that it’s all about queries and replies.
When you go to view a website, here’s what happens:
- Your computer queries your local DNS resolver for where to go — and waits patiently for the resolver to do all the heavy work.
- The local DNS resolver queries the root servers for the registrar responsible for the information, gets a reply and goes on to the next step
- The DNS resolver now asks the registrar for the name(s) and address(es) of the server(s) responsible for knowing all the details about the domain name. These are called nameservers.
- The DNS resolver now queries the nameservers (which it knows to be authoritative because it started from the root) for the IP address of the server that hosts the web site you’ve clicked to view, and receives it.
- The local resolver sends that IP address back to your computer, which can now look it up on the internet in a format that makes sense to it, rather than to us.
Reverse DNS
Reverse DNS is a means of checking that a computer claiming to be a specific server isn’t actually faking it. When people send out spam, viruses, and so on, they don’t tend to use their real names and emails. To cut down on the amount of spam that comes in, many mail servers use reverse DNS to confirm that the server trying to deliver mail to them is genuine.
Communication on the net requires that every chunk of data be tagged with an IP address to tell where it comes from (so one can reply back). That means that you always know the unique address of a machine connecting to yours, even if you don’t know who it belongs to or where it may physically be.
IP addresses are assigned in large blocks of numbers by the International Association of Names and Addresses (IANA) to telcos and bandwidth providers who redistribute them in smaller chunks to Internet Service Providers, and so on down the line. These IPs have, just like domains, a series of authoritative DNS nameservers and responses that allow lookups to be made on their information. The only records they usually return are called PTR (pointer) records, which contain the name of the host record which is supposed to resolve to it.
Take one of our mail servers, for example, smtp.easydns.com :
A standard lookup on this host name will return the A record for it, as follows.
$ dig smtp.easydns.com
;; ANSWER SECTION: smtp.easydns.com. 237 IN A 64.68.200.52
A receiving mailserver might be satisfied just to believe it when this machine connects and identifies itself as smtp.easydns.com, but the server enabled to do reverse checking will take a confirmation step, and check to see what PTR record exists for that IP address first.
To do so, it checks the root servers to see who is authoritative for that IP.
We can do the same through manual lookups, and see the same results.
Here’s how one might do a reverse lookup on the IP address above
$ dig -x 64.68.200.52
;; ANSWER SECTION:
52.200.68.64.in-addr.arpa. 990 IN PTR smtp.easydns.com.
Using the ‘dig’ command, we can look up the PTR record for the IP and get the return of the the PTR record that tells us that the IP is officially configured to confirm smtp.easydns.com as the host that should be connecting from it.
The answer section looks a bit strange at first glance though.
Because DNS is (strictly speaking) designed for domain names, there’s a special type of domain called in-addr.arpa (this is a Top Level Domain, like .com, .net, etc..). This is only used for IP addresses. Just as with standard DNS, the hierarchy for an IP goes from right to left.
smtp.easydns.com, for example means that a lookup starts with the .com servers, then with the servers responsible for the easydns domain within .com, and then for the host (or subdomain) smtp within the easydns.com zone.
Similarly, to look for the DNS for an IP address, it first checks the in-addr.arpa servers for who is responsible for the 64 zone, then 68 within that zone, and so on. This is somewhat simplified from what actually happens, but for our purposes is accurate enough.
If we were to try and trace the line of authority for this IP, we would see something like this :
. 518398 IN NS c.root-servers.net.
. 518398 IN NS a.root-servers.net.
. 518398 IN NS k.root-servers.net.
64.in-addr.arpa. 86400 IN NS u.arin.net.
64.in-addr.arpa. 86400 IN NS dill.arin.net.
64.in-addr.arpa. 86400 IN NS x.arin.net.
64.in-addr.arpa. 86400 IN NS t.arin.net.
;; Received 182 bytes from 196.216.169.10#53
(c.in-addr-servers.arpa) in 274 ms
200.68.64.in-addr.arpa. 86400 IN NS ns1.easydns.com.
200.68.64.in-addr.arpa. 86400 IN NS ns2.easydns.com.
;; Received 90 bytes from 72.52.71.2#53(w.arin.net) in 24 ms
200.68.64.in-addr.arpa. 1200 IN SOA ns0.easydns.com.
root.easydns.com. 2011032200 3600 1200 1209600 1200
;; Received 99 bytes from 66.225.199.10#53(ns1.easydns.com) in 12 ms
This shows the root servers displaying who is responsible first for the in-addr.arpa domain, then who is responsible for the 64 range of IPs. Since easyDNS has a large block, we are responsible for the DNS for all those, and the buck, so to speak, stops there. The final line shows that a response was received back with an SOA (start of authority) reply for the IP, which means all is well.
Setting It All Up
Step by step instructions on setting up and configuring reverse DNS can be found here.
In brief, however:
When you (the end-user) get a static IP (or range of IPs) from an ISP, they are responsible for maintaining the DNS for the IP addresses in question. Generally they will maintain the PTR records or DNS for an IP themselves.
Some clients, however, prefer to maintain control themselves, or have ISPs who do not provide reverse PTR service. In those cases. they must have the ISP delegate responsibility for the DNS to another service (such as easyDNS). Once they do so, we would become responsible, and you (the easyDNS client) would be able to add, edit and remove PTR records for the domain. Before delegating to us, you must make sure you have added the netblock (that’s the full range of IPs for which we would become responsible), paid the invoice for the service, and then configured the PTR records, so that as soon as the IP is delegated, we will already be prepared to respond with the information when reverse checks are done.
For greater detail on how Reverse DNS works, we advise starting with the Wikipedia article on it, which will point to further resources.