Related Articles:
This guide explains the purpose of reverse DNS and how to configure it when necessary.
Reverse DNS resolves IP addresses to hostnames (1.2.3.4 to example.com), while forward DNS resolves hostnames to IPs (example.com to 1.2.3.4). Reverse DNS verification is a common anti-spam tool, as spammers often lack proper reverse DNS. Correctly configured reverse DNS resolves both forward and backward, like so:
$ dig example.com +short 1.2.3.4 $ dig 4.3.2.1.in-addr.arpa ptr +short example.com
Reverse DNS is served using the special TLD .arpa; IPv4 uses the domain in-addr.arpa, while IPv6 uses ipv6.arpa. Like forward DNS, IP addresses in these domains are read from right to left: for example, the reverse DNS for 1.2.3.4 is served from 4.3.2.1.in-addr.arpa. Lastly, while host (A) records resolve to IPs, PTR records resolve IPs in IN-ADDR.ARPA zones to hosts. The following sample dig output demonstrates a reverse lookup:
$ dig 4.3.2.1.in-addr.arpa ptr ; <<>> DiG 9.3.3 <<>> 4.3.2.1.in-addr.arpa ptr ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49642 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 ;; QUESTION SECTION: ;4.3.2.1.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.3.2.1.in-addr.arpa. 86400 IN PTR example.com. ;; AUTHORITY SECTION: 3.2.1.in-addr.arpa. 86400 IN NS ns1.example.com. 3.2.1.in-addr.arpa. 86400 IN NS ns2.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 600 IN A 1.2.3.1 ns2.example.com. 600 IN A 1.2.3.2 ;; Query time: 1 msec ;; SERVER: 1.2.3.5#53(1.2.3.5) ;; WHEN: Wed Jul 8 00:16:54 2009 ;; MSG SIZE rcvd: 273
When using dig, the -x flag performs a reverse lookup, e.g. dig -x 1.2.3.4.
Unless you are hosting your own mail server, reverse DNS is not necessary. If you do host your own mail, your messages may be rejected by providers such as AOL and Hotmail for two reasons:
Rather than upgrading to a costly static IP, you can prevent mail rejections using our MailHop Outbound service. Reverse DNS tests only check the current connecting server, not the message's origin; this will allow your messages to be pass inspection, as we use static IPs with correct reverse resolution. You can also use your ISP's SMTP servers, if available.
Please select the entry below which best describes your situation. In each section, we will be using the network address 1.2.3.4 and the server mail.yourdomain.com as examples.
Before you begin: By default, your Internet Service Provider controls the reverse DNS for your IP addresses. You will need to contact them to make any changes to these settings. If you have only a handful of IP addresses, or you believe your ISP will be uncooperative when asked to give up control of these records to a third party, you should simply ask them to make the necessary changes on their side. Since reverse DNS settings rarely change, you may be able to save yourself a great deal of hassle by having them create the PTR records for you.
Additionally, as stated above, you must have static IP addresses in order to have reverse DNS configured for them.
Most customers will only need reverse DNS for one or two IP addresses, since reverse DNS is mostly used for outgoing mail servers. In this case, it is easiest to simply have your ISP create the necessary records on their side.
If you are still interested in delegating these addresses to us, you can create the PTR records in your forward Custom DNS zone for your domain itself. Your ISP will need to create CNAME records on their side for your addresses. Please follow the steps below:
4.3.2.1.in-addr.arpa 86400 IN CNAME 4.rev.yourdomain.com 5.3.2.1.in-addr.arpa 86400 IN CNAME 5.rev.yourdomain.com
Classless delegation allows customers to create a new Custom DNS zone to control a full block of IP addresses. This requires both CNAME records and NS records, since the queries for your reverse zone will be delegated directly to our nameservers.
4.3.2.1.in-addr.arpa 86400 IN NS ns1.mydyndns.org 4.3.2.1.in-addr.arpa 86400 IN NS ns2.mydyndns.org 4.3.2.1.in-addr.arpa 86400 IN NS ns2.mydyndns.org 4.3.2.1.in-addr.arpa 86400 IN NS ns2.mydyndns.org 4.3.2.1.in-addr.arpa 86400 IN NS ns2.mydyndns.org
4.3.2.1.in-addr.arpa 86400 IN CNAME 4.4.3.2.1.in-addr.arpa 5.3.2.1.in-addr.arpa 86400 IN CNAME 5.4.3.2.1.in-addr.arpa 6.3.2.1.in-addr.arpa 86400 IN CNAME 6.4.3.2.1.in-addr.arpa ... 19.3.2.1.in-addr.arpa 86400 IN CNAME 19.4.3.2.1.in-addr.arpaYou can use our Classless IN-ADDR.ARPA calculator to print the full list of records, which makes it easy for customers to provide the correct information to their ISP.
This type of delegation is the easiest, as it requires your ISP to create relatively few records. (Please note that Custom DNS has a 75-record limit; if you need reverse DNS for more than 75 IP addresses in your block, please contact our support team for information.)
3.2.1.in-addr.arpa 86400 IN NS ns1.mydyndns.org 3.2.1.in-addr.arpa 86400 IN NS ns2.mydyndns.org 3.2.1.in-addr.arpa 86400 IN NS ns3.mydyndns.org 3.2.1.in-addr.arpa 86400 IN NS ns4.mydyndns.org 3.2.1.in-addr.arpa 86400 IN NS ns5.mydyndns.org
It can take some time for the changes you have made to take effect, as NS and PTR records usually have very high TTLs. Once the change completes, you can test the reverse DNS with a simple dig -x ipaddr to view the current resolution. Depending on your configuration, you may see a CNAME being resolved at your ISP prior to our nameservers providing the expected answer; this extra lookup has no effect on the outcome of reverse DNS verification tests.
If you do not see the expected data, or receive an error such as SERVFAIL, use dig -x ipaddr +trace to follow the delegation path and determine where the failure is occurring. Most often, you will see that your ISP has delegated your reverse DNS to the wrong nameservers (nsX.dyndns.org instead of nsX.mydyndns.org), the wrong destination zone, and so on. You should be able to contact your ISP to have them correct the issue; if you get stuck, please feel free to contact Support for further assistance.
For customers with blocks smaller than /24, this very simple calculator will generate a list of records to provide to your ISP. Please double-check the output to make sure it properly matches your actual IP address allocation.
© 1998-2010
Dynamic Network Services Inc. -
Legal Notices -
Privacy Policy -
Contacts