Reverse DNS

Problem: EMails to services such as AOL or Yahoo get returned.  These services check for the presence of a Reverse DNS setting, to prevent email from spammers.  Otherwise the DNS of the service provider, such as Covad or Natel is returned, resulting in a mismatch.

----- Original Message -----
From: "Postmaster" <postmaster@CICorp.com>
To: <rick@cicorp.com>
Sent: Friday, April 06, 2007 8:03 AM
Subject: [Norton AntiSpam] Undeliverable Mail

> Unknown host: WSHADDOCK@aol.com
>
> Original message follows.
>
> Received: from fs6 [67.55.221.6] by CICorp.com with ESMTP
> (SMTPD32-7.15) id A6C63E020C; Fri, 06 Apr 2007 08:02:14 -0400
> Message-ID: <016701c7784c$63b76740$06dd3743@fs6>
> From: "Rick Shaddock" <rick@cicorp.com>
> To: <WSHADDOCK@aol.com>
> Subject: DonaldHall.org
> Date: Fri, 6 Apr 2007 08:05:58 -0500
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_015F_01C77822.69100FF0
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> That is a great speech you gave, Dad. It was so much fun to go to Lake
> Loughborough for fishing.

Detection: DNSReport.com has a free service to detect problems with a web site's setup.

PASS Multiple MX records OK. You have multiple MX records. This means that if one is down or unreachable, the other(s) will be able to accept mail for you.
PASS Differing MX-A records OK. I did not detect differing IPs for your MX records (this would happen if your DNS servers return different IPs than the DNS servers that are authoritative for the hostname in your MX records).
PASS Duplicate MX records OK. You do not have any duplicate MX records (pointing to the same IP). Although technically valid, duplicate MX records can cause a lot of confusion, and waste resources.
FAIL Reverse DNS entries for MX records ERROR: The IP of one or more of your mail server(s) have no reverse DNS (PTR) entries/* (if you see "Timeout" below, it may mean that your DNS servers did not respond fast enough)*/. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. You can double-check using the 'Reverse DNS Lookup' tool at the DNSstuff site if you recently changed your reverse DNS entry (it contacts your servers in real time; the reverse DNS lookups in the DNS report use our local caching DNS server). The problem MX records are:
210.221.55.67.in-addr.arpa [No reverse DNS entry (rcode: 3 ancount: 0) (check it)]

Solution: Setting up Reverse DNS

Reverse DNS (rDNS) is quite simply the method of resolving an IP address into a domain name, just as the domain name system (DNS) resolves domain names into associated IP addresses.

This tutorial will guide you through setting up reverse DNS in DNS Made Easy.

Step1
First you will need to find out who owns your IP block (usually this is your ISP or hosting provider). You will need this as they will have to delegate your IP block to the DNS Made Easy name servers for reverse DNS resolution. If they will not delegate the IPs to DNS Made Easy then there is no reason to continue and you can ask them to set the reverse DNS for you.

Just as your Domain is delegated to use DNS Made Easy nameservers (by notifying your registrar) so must your IP block. Usually an ISP or hosting company will only do this if you have 256 IPs (a full class C) or more, but some companies have been known to make an exception.

Once your ISP or hosting company has agreed that they will assign the reverse DNS to DNS Made Easy ask them for the zone name that you will need to create.

A reverse DNS zone is slightly different than a normal domain name.

The zone (domain) "1.168.192.in-addr.arpa" would actually be the reverse DNS for the 192.168.1 class C. So this would handle the reverse DNS for IPs 192.168.1.1 to 192.168.1.256.

If your IP block is smaller than a class C then your zone (domain) might look like this "0/25.1.168.192.in-addr.arpa" or "0-25.1.168.192.in-addr.arpa". These would actually be the zone that would handle 128 IPs. This would actually be the zone for the IPs 192.168.1.1 to 192.168.1.128.

Step 2
Add your zone (domain) into the DNS Made Easy system. This is done just as you would by entering any domain into the DNS Made Easy system. NOTE: You will not want to use any Domain wizards as they will not really help you. You can just use the classic Domain setup.

At the end of adding your domain to the DNS Made Easy system you will be assigned a group of name servers. These are the name servers that you will want to tell your ISP or hosting company to delegate the reverse DNS to.

Step 3
Tell your ISP or your hosting provider the name servers that they will have to delegate your IPs to. This is important that they do this. This step is exactly the same idea when you tell your regsitrar to use DNS Made Easy nameservers for your doamin.

Step 4
You will then want to add PTR records as needed.

So if you had the zone (domain) "1.168.192.in-addr.arpa" and you created a PTR record with the following values:
Name: '32'
Value: 'systems.example.com.'


Then the end result would be that the reverse DNS for the IP 192.168.1.32 will be "systems.example.com.".


That's about it. Adding reverse DNS to your IPs is really easy with DNS Made Easy!

DNSReport.com

Location: United States [City: Fairfield, Iowa]

Preparation:
The reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 67.55.221.210 is found by looking up the PTR record for
210.221.55.67.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking h.root-servers.net for 210.221.55.67.in-addr.arpa PTR record:
h.root-servers.net says to go to figwort.arin.net. (zone: 67.in-addr.arpa.)
Asking figwort.arin.net. for 210.221.55.67.in-addr.arpa PTR record:
figwort.arin.net [192.42.93.32] says to go to NS1.NATEL.NET. (zone: 221.55.67.in-addr.arpa.)
Asking NS1.NATEL.NET. for 210.221.55.67.in-addr.arpa PTR record: Reports that no PTR records exist [from 207.177.74.108].

Answer:
No PTR records exist for 67.55.221.210. [Neg TTL=86400 seconds]

Details:
NS1.NATEL.NET. (an authoritative nameserver for 221.55.67.in-addr.arpa., which is in charge of the reverse DNS for 67.55.221.210)
says that there are no PTR records for 67.55.221.210.

To get reverse DNS set up for 67.55.221.210, you need to speak to your Internet provider. You could also
check with dns@natel.net., who is in charge of the 221.55.67.in-addr.arpa. zone.

Note that all Internet accessible hosts are expected to have a reverse DNS entry (per RFC1912 2.1),
and many mailservers (such as AOL) will likely block E-mail from mailservers with no reverse DNS entry.
To see the reverse DNS traversal, to make sure that all DNS servers are reporting the correct results, you can Click Here.

How This Applies to C I Corporation

Domain IP Reverse DNS
mail.CICorp.com 67.55.221.210 210.221.55.67
PTR Record Name: 10  
Date (PTR to): www.cicorp.com  
TTL 1800 seconds  

We can check this with DNSReport.com

DNS Made Easy

PTR Record (Pointer Record)

Pointer records are used to map a network interface (IP) to a host name. These are primarily used for reverse DNS.

Example Input for Domain Name: 1.168.192.in-addr.arpa
Name: 25
Data (PTR to): www.example.com.
TTL: 1800 seconds

Result:
This will create a reverse DNS entry for 192.168.1.25. The reverse DNS will be a pointer to 'www.example.com.'. This record will have a cache (TTL) of 30 minutes.

Of course 192.168.1.x is an internal network and would not be allowed in the DNS Made Easy system.




 

Here is the screen that DNS Made Easy provides for changing the PTR record to implement Reverse DNS.  This did not work, so we need to find out how to properly fill out the following screen.

Info from RIPE

http://www.ripe.net/reverse/reverse_howto.html

Reverse Delegation How To

The Five Steps to Set Up Reverse Delegation

[For classless delegations (blocks smaller than 256 addresses), click here].

This page tells you how to set up reverse delegation for address space that has been allocated or assigned to you. We assume that you understand how to set up zone files and how to administer a Domain Name System (DNS) server. This process will help you set up your DNS servers and tell you how to let the RIPE NCC know about them by creating a domain object.

If you have any questions or suggestions that will help us to improve this document, please send an e-mail to ripe-dbm@ripe.net.

Step1: Modifying the INETNUM Object

You will need to add a "mnt-domains:" attribute to your inetnum object

The "mnt-domains:" attribute refers to a mntner (or maintainer) object that contains information on who is able to create a domain object for reverse delegation. If there is no "mnt-domains:" attribute, the "mnt-lower:" attribute will be used for authorisation. See how authorisation of domain object creation works.

If you do not have a mntner object, you can create one through the LIR Portal. If you are not a Local Internet Registry (LIR), you can create mntner objects by sending an e-mail to auto-dbm@ripe.net or by using webupdates.

You can find details of how to create a mntner object and the authorisation model at: http://www.ripe.net/db/support/security/security.html

For allocations, a "mnt-domains:" attribute can be added to the inetnum object by logging into the LIR Portal Allocation Editor. For assigments, the "mnt-domains:" attribute can be added directly by updating an existing object.

Step 2: Preparing the Reverse Delegation

Because of how DNS works, you will need to chop your address block into "chunks" that can be delegated.
For an IPv4 address block, you will have to create one or multiple /24 or /16 type address blocks mapped into in-addr.arpa domains
For IPv6, you will have to map a /32 address block into the ip6.arpa domain

For more information about this, see From Address Space to DNS Names.

Step 3: Configuring Your DNS Servers

For each zone you have prepared, you will have to set up DNS service. An automated test complying with these recommendations is made against your zones. Problems encountered during the tests are given a number of points. Delegation will be refused if a DNS setup scores more than 20 points. You will receive a summary of any problems if delegation fails. You can perform a test of your set-up using the web delegation checker.

The following recommendations may help:

NS Servers
 
Make sure that you have at least two name servers that are authoritative for the zone. The resolvable names of these NS servers should be in the NS resource records of the zone. The name servers should be on different subnets.
SOA Resource Records The SOA Resource Record should have the same content, both serial number and other data, on all the nameservers. The SOA should contain a valid 'rname' (the contact address). The timing parameters should be reasonable. Please see the RIPE Document "Recommendations for DNS SOA Values" for more information.
 
Secondary Service by the RIPE NCC

For IPv4: If your zone is a /16 reverse zone, you will need to set up ns.ripe.net as a secondary server

For IPv6: If your zone is a /32 reverse zone, you may use ns.ripe.net as a secondary
In both cases, you have to allow AXFR queries from the RIPE NCC addresses (193.0.0/22 and 2001:610:240::/48) to the name server listed in the SOA resource record.

Step 4: Submitting the DOMAIN Object

Once you have set up your DNS to serve the reverse zones, you are ready to request reverse delegation by submitting a domain object. You can do this in two ways:

1. By using webupdates

  • First authorise yourself in the authorisation section. Then go to the add section
     
  • Select domain, by clicking on 'Create a New Object' and then click on 'Add Object'
  • Fill in all the available fields
  • Use the 'Add New Field' feature to add at least two "nserver:" attributes. Here, you supply the names of the name servers that are serving the zones as set up in Step 3 and that you have specified in the NS resource records of those zones
  • For the "mnt-by:" attribute use the mntner you prepared in Step 1
2: By e-mail
You need to create a domain object containing information about the zone you need reverse delegation for. For details on creation and authorisation please refer to the RIPE Database Reference Manual .
These are the basic steps:

Obtain a template using whois -t domain and fill in the details. 

domain:        [mandatory]  [single]     [primary/look-up key]		1
descr:         [mandatory]  [multiple]   [ ]
admin-c:       [mandatory]  [multiple]   [inverse key]
tech-c:        [mandatory]  [multiple]   [inverse key]
zone-c:        [mandatory]  [multiple]   [inverse key]
nserver:       [optional]   [multiple]   [inverse key]			2
sub-dom:       [optional]   [multiple]   [inverse key]
dom-net:       [optional]   [multiple]   [ ]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]			3
mnt-by:        [optional]   [multiple]   [inverse key]
mnt-lower:     [optional]   [multiple]   [inverse key]
refer:         [optional]   [single]     [ ]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

 

1 Here you put the name of your domain.
2 Enter the names of your name servers which correspond to the name servers as used in Step 3; use multiple lines, one nserver: nameservername per line. Do not forget to include ns.ripe.net if you request reverse delegation for a IPv4/16 domain. Do not include ns.ripe.net in other cases.
3 For the "mnt-by:" attribute you use the mntner you have prepared in Step 1

Send your domain object to auto-dbm@ripe.net.

If you want to submit a number of domains that all run on the same name server you can use a range notation such as 10-16.168.192.in-addr.arpa for the "domain:" attribute. The database will then automatically create separate domain objects in that range. This applies to all whois database interfaces.

Step 5: Verifying the Setup

 

Once you have submitted the domain object you will receive a notification from the database. You should then be able to query for your object in the database (e.g whois -h whois.ripe.net 4.0.192.in-addr.arpa). After the object appears in the database it may take between 15 to 60 minutes before the delegation information is available in the DNS. The ultimate test is to query a recursive name server that is not authoritative for your zone for a record from your zone.

Refer to Using dig to Troubleshoot Your Set-Up for more information.

Please contact ripe-dbm@ripe.net if, six hours after the appearance of your domain object in the whois database, your delegation does not appear. Include the details such as name server addresses and the domain object in your request. Also include the full response, including headers, as received from the database.

 

Advanced and Less Advanced Topics

From Address Space to DNS Names

In order to do a DNS lookup for data that is associated with a certain IP address, you should map the IP addresses into the DNS name hierarchy. The algorithm is to reverse the elements in the IP address and to put these in specific DNS domains.

For IPv4 use the decimal notation of the four octets and maps these into the in-addr.arpa domain. For IPv6 use the hexadecimal notation and map the "nibbles" into the ip6.arpa domain.

Figure1.Mapping an IPv4 address into a DNS name

Mapping an IPv4 address into a DNS name

 

Figure2.Mapping an IPv6 address into a DNS name

Mapping an IPv6 address into a DNS name

Because the particular mapping delegation of reverse address space can only happen on "byte" or "nibble" boundaries, you could be dealing with multple zones for one address block. Below is described how to determine which domains are relevant to a given address block.

IPv4
One or more /24 type zones need to be created if your address space has a prefix length between /17 and /24. If your prefix length is between /16 and /9 you will have to request one or multiple delegations for /16 type zones. If you have an address block with a prefix of /25 or larger you will have to revert to Classless Delegations

For example we have been assigned 10.155.16/21. We therefore have to create eight reverse zones 16.155.10.in-addr.arpa, 17.155.10.in-addr.arpa, 18.155.10.in-addr.arpa, 19.155.10.in-addr.arpa, 20.155.10.in-addr.arpa, 21.155.10.in-addr.arpa, 22.155.10.in-addr.arpa and 23.155.10.in-addr.arpa.

IPv6
If you are allocated a /32 address block you can request a delegation for the /32 zone and you do not need to split the block into multiple zones.

If you have been allocated a /35 block you have to take the following into account. We can only delegated domains on 'nibble' boundaries therefore you will need to create 2 /36 zones.

For example for the 2001:abcd:e000::/35 you will have to create two reverse domains: 2001:abcd:e000::/36: e.d.c.b.a.1.0.0.2.ip6.arpa. and 2001:abcd:f000::/36:f.d.c.b.a.1.0.0.2.ip6.arpa.

Classless Delegations

 

If you have been assigned an address block smaller than a /24, classless delegation will need to be setup. Setting up classless delegations is described in RFC 2317

Classless Delegation for PA

 

The RIPE NCC does not provide classless delegation for Provider Aggregatable (PA) address space. You will have to contact the administrator of the /24 zone that encloses your address space to coordinate delegation.

Classless Delegation for PI

 

For Provider Independent (PI), or "portable" address space you will have to ensure that your inetnum object contains a "mnt-domains:" attribute. If you do not have a "mnt-domains:" attribute in your inetnum object you will need to contact the LIR who maintains the object with a request for the addition of a "mnt-domains:" attribute.

If your inetnum does contain a "mnt-domains:" attribute, please setup your zone using the [firstaddress]-[lastaddress].X.Y.Z.in-addr.arpa(e.g. 0-127.2.0.193.in-addr.arpa) convention and e-mail your domain object, with appropriate authorisation, to . The request for delegation will be processed manually during business hours.

Using dig to Troubleshoot Your Setup

 

There are numerous tools to test your setup. You can use nslookup, host and dig. dig is the 'rawest' of the three and provides a detailed look at what a server returned.

Here are a few examples using dig. The power of dig is that it lets you examine the content of the returned DNS packet. More specifically it allows you to examine the settings of the flag fields and return codes.

The (non-)availability of the aa flag indicates wether you required an answer from the "authoritative server" or not. If you have setup two name servers and you query them for the SOA record from that zone, then the aa flag should be set.

Query against an authoritative serve

Following is an example of a query against the authoritative server for the NS in 2.0.194.in-addr.arpa. This is the first check you would do to verify the name server setup is correct.
  > dig +multiline  @ns-pri.example.com  2.0.192.in-addr.arpa NS  	1
; <<>> DiG 9.3.0 <<>> @ns.ripe.net 2.0.193.in-addr.arpa NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14740
;; flags: qr aa 2rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2     

;; QUESTION SECTION:
;2.0.192.in-addr.arpa.		IN	NS

;; ANSWER SECTION:                                                       3
2.0.192.in-addr.arpa.172800 IN NS ns-sec.example.net.
2.0.192.in-addr.arpa.172800 IN NS ns-pri.example.net.

;; ADDITIONAL SECTION:
ns-pri.example.net.172800 IN A 192.0.2.195
ns-pri.example.net.172800 IN A 10.0.0.1


;; Query time: 30 msec
;; SERVER: 192.0.2.195#53(ns-pri.example.net.)
;; WHEN: Thu Apr  8 12:44:52 2004
;; MSG SIZE  rcvd: 330

 

1 This is the command that queries a local resolver for the NS resource records for 2.0.192.in-addr.arpa zone. We have used the +multiline to receive nicely formated output. The query is sent to ns-pri.example.com, one of the two name servers that is authoritative for 2.0.192.in-addr.arpa
2 When confirming that your servers are running correctly it is important that you check the existence of the aa flag. That, in combination with the NOERROR status code and the result in the ANSWER SECTION, is an indication that your authoritative servers have been set up correctly.
3 The ANSWER SECTION contains the two NS resource records you queried for.

Query Against a Recursive Name Server

 
> dig +multiline  @recursive.example.com  2.0.192.in-addr.arpa SOA  	1
; <<>> DiG 9.3.0 <<>> 2.0.192.in-addr.arpa SOA
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR2, id: 3001 		    
;; flags: qr rd ra3; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 	    

;; QUESTION SECTION:
;2.0.192.in-addr.arpa.INSOA

;; ANSWER SECTION:						            4
2.0.192.in-addr.arpa.172800 IN SOA ns.example.net. foo.example.net. (
				2004033102 ; serial
				86400      ; refresh (24 hours)
				7200       ; retry   (2 hours)
				1209600    ; expire  (2 weeks) 
				3600       ; minimum (2 hours) 
				)

;; AUTHORITY SECTION:
2.0.192.in-addr.arpa.172800 IN NS ns-sec.example.net.
2.0.192.in-addr.arpa.172800 IN NS ns-pri.example.net.

;; ADDITIONAL SECTION:
ns-pri.example.net.172800 IN A 192.0.2.195
ns-pri.example.net.172800 IN A 10.0.0.1


;; Query time: 20 msec
;; SERVER: localresolver.example.com#53(192.0.2.11)
;; WHEN: Mon Apr  5 10:44:29 2004
;; MSG SIZE  rcvd: 219

 

1 This is the command that queries a local resolver for the SOA from the 2.0.192.in-addr.arpa zone. We have used the +multiline to receive a nicely formated output.
2 NOERROR indicates a successful query.
3 The absence of the aa (authoritative answer) flag and the combination of rd (recursion desired) and ra (recursion available) flags indicate that the server which you queried is not authoritative for the 2.0.192.in-addr.arpa. zone and your query has been resolved by recursing the root to the authoritative server.

We also found an answer (ANSWER: 1), as expected.
4 This line should reflect the SOA from your zonefile.

Negative Caching of a Non-Existent Delegation

 

If you try to find out if a zone has already been delegated you may encounter what is known as "negative caching". What happens is that that your recursive name server remembers the fact that a delegation does not exist. It may take a few hours before the "non-existence" of a zone has expired. If you try to establish if the delegation has been created and you have queried 'too early' this is what you see in later queries. Below is an example of a query for a /24 zone for which a delegation does not exist. 

> dig 20.0.193.in-addr.arpa  NS +multiline

; <<>> DiG 9.3.0 <<>> 20.0.193.in-addr.arpa NS +multiline
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37535  1
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;20.0.193.in-addr.arpa.	IN NS

;; AUTHORITY SECTION:
193.in-addr.arpa.	6449 2 IN	SOA ns.ripe.net. ops-193.ripe.net. (
				2004041201 ; serial
				43200      ; refresh (12 hours)
				7200       ; retry (2 hours)
				1209600    ; expire (2 weeks)
				7200       ; minimum (2 hours)
				)

;; Query time: 5 msec
;; SERVER: 10.0.0.198#53(10.0.0.198)
;; WHEN: Tue Apr 13 12:28:34 2004
;; MSG SIZE  rcvd: 94

 

1 The NXDOMAIN return code indicates that the domain queried for does not exist. In the AUTHORITY SECTION the SOA resource record is provided for the domain which "knows" about the non-existence of 20.0.193.in-addr.arpa.
2 The SOA resource record is "cached". The TTL field indicates how long the data remains in the cache. In this case the value is: 6449. If you query again for the same information shortly afterwards you will see that the TTL has decreased. Only after the TTL has reached "0" will the recursive name server check if the delegation exists.

Here is the same query shortly afterwards. 

dig 20.0.193.in-addr.arpa  NS +multiline

; <<>> DiG 9.4.0s20040114055632 <<>> 20.0.193.in-addr.arpa NS +multiline
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22434
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;20.0.193.in-addr.arpa.	IN NS

;; AUTHORITY SECTION:
193.in-addr.arpa.	5785 IN	SOA ns.ripe.net. ops-193.ripe.net. (
				2004041201 ; serial
				43200      ; refresh (12 hours)
				7200       ; retry (2 hours)
				1209600    ; expire (2 weeks)
				7200       ; minimum (2 hours)
				)

;; Query time: 4 msec
;; SERVER: 10.0.0.198#53(10.0.0.198)
;; WHEN: Tue Apr 13 12:39:37 2004
;; MSG SIZE  rcvd: 94

The TTL has decreased to 5785, It is still more than 1.5 hours before the information that the 20.0.193.in-addr.arpa zone does not exist expires from the cache.

 

Other Useful dig Flags

 
+nssearch
 

With the +nssearch flag set, dig attempts to find the authoritative name servers for the zone containing the name being looked up and display the SOA record that each name server has for the zone.

Below is an example where we look for the authoritative servers for 1.0.193.in-addr.arpa: 

dig 1.0.193.in-addr.arpa   +nssearch
SOA ns.ripe.net. ops.ripe.net. 2004040201 43200 7200 1209600 7200 from server ajax.nikhef.nl in 15 ms.
SOA ns.ripe.net. ops.ripe.net. 2004040201 43200 7200 1209600 7200 from server ns-pri.ripe.net in 10 ms.
SOA ns.ripe.net. ops.ripe.net. 2004040201 43200 7200 1209600 7200 from server sec3.apnic.net in 253 ms.
SOA ns.ripe.net. ops.ripe.net. 2004040201 43200 7200 1209600 7200 from server sec1.apnic.net in 321 ms.

Your set-up is probably broken if the command times out or no SOA RRs are returned.

+trace
 

With the +trace flag set dig will follow the delegation tree from the root down and show all the steps in the recursion.

Below is an example where we show the recursion for a reverse lookup of 193.0.0.1. 

 dig +trace 1.0.0.193.in-addr.arpa PTR

; <<>> DiG 9.3.0 <<>> +trace 1.0.0.193.in-addr.arpa PTR
;; global options:  printcmd
.			94088	IN	NS	i.root-servers.net.
.			94088	IN	NS	j.root-servers.net.
.			94088	IN	NS	k.root-servers.net.
.			94088	IN	NS	l.root-servers.net.
.			94088	IN	NS	m.root-servers.net.
.			94088	IN	NS	a.root-servers.net.
.			94088	IN	NS	b.root-servers.net.
.			94088	IN	NS	c.root-servers.net.
.			94088	IN	NS	d.root-servers.net.
.			94088	IN	NS	e.root-servers.net.
.			94088	IN	NS	f.root-servers.net.
.			94088	IN	NS	g.root-servers.net.
.			94088	IN	NS	h.root-servers.net.
;; Received 260 bytes from 193.0.0.198#53(127.0.0.1) in 2 ms

193.in-addr.arpa.	86400	IN	NS	AUTH03.NS.UU.NET.
193.in-addr.arpa.	86400	IN	NS	NS-PRI.RIPE.NET.
193.in-addr.arpa.	86400	IN	NS	TINNIE.ARIN.NET.
193.in-addr.arpa.	86400	IN	NS	NS2.NIC.FR.
193.in-addr.arpa.	86400	IN	NS	SEC1.APNIC.NET.
193.in-addr.arpa.	86400	IN	NS	SEC3.APNIC.NET.
193.in-addr.arpa.	86400	IN	NS	SUNIC.SUNET.SE.
;; Received 218 bytes from 192.36.148.17#53(i.root-servers.net) in 15 ms

0.0.193.in-addr.arpa.	432000	IN	NS	ns.ripe.net.
0.0.193.in-addr.arpa.	432000	IN	NS	sec1.apnic.net.
0.0.193.in-addr.arpa.	432000	IN	NS	sec3.apnic.net.
;; Received 153 bytes from 198.6.1.83#53(AUTH03.NS.UU.NET) in 91 ms

1.0.0.193.in-addr.arpa.	172800	IN	PTR	rrc00.ripe.net.
;; Received 68 bytes from 202.12.29.59#53(sec1.apnic.net) in 326 ms

Using the "root-hints" from the nearest recursive server at 127.0.0.1 dig chooses to select i.root-servers.net for the first query. i.root-servers.net returns a delegation to the 193.in-addr.arpa. zone. From the set of name servers autoritative for 193.in-addr.arpa., AUTH03.NS.UU.NET. is selected for the next query. That server returns a delegation tothe 0.0.193.in-addr.arpa. zone, for which three name servers are authoritative, out of these sec1.apnic.net is queried for the answer.

Repeatedly issuing the same dig with the +trace flag will show different paths for the recursion.

 

This page has been updated: 20 June 2007