If you are still using the old theme you can view the correct Knowledge Base here: https://help.easydns.com/.
|Regular DNS can be pretty confusing sometimes, so as you’d imagine, it gets a bit more complicated when you reverse it. Let’s go over standard forward DNS first, just to clear things up. Feel free to skip this if you’re familiar with it all.
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:
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 18.104.22.168
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 22.214.171.124
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.
64.in-addr.arpa. 86400 IN NS u.arin.net.
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.