You are here: Home > Data & Tools > DNS > Reverse DNS > How to Set Up Reverse Delegation
RIPE Database Search

By pressing the "Search" button you explicitly express your agreement with the RIPE Database Terms and Conditions.

How to Set Up Reverse Delegation

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 email to ripe-dbm _at_ ripe _dot_ 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.

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 email to auto-dbm _at_ ripe _dot_ net or by using webupdates.

 

For allocations, a "mnt-domains:" attribute can be added to the inetnum object by logging into the LIR Portal Allocation Editor. For assignments, 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 setup 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 may use 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 server.
In both cases, you have to allow zone transfers from the name server listed in the SOA resource record to the RIPE NCC address space (193.0.0.0/22 and 2001:610:240::/48 and 2001:67c:2e8::/48)

Step 4: Submitting the DOMAIN Object

Once you have set up your DNS servers 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  log in. 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 email

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.png

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.png

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.

3

For the "mnt-by:" attribute you use the mntner you have prepared in Step 1

Send your domain object to auto-dbm _at_ ripe _dot_ net.

Step 5: Verifying the Setup

Once you have submitted the domain object you will receive a notification from the RIPE Database. You should then be able to query for your object in the database . 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 Setup for more information.

Please contact ripe-dbm _at_ ripe _dot_ 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 map 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 multiple zones for one address block. We describe how to determine which domains are relevant to a given address block below.

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 more 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, if you have been assigned 10.155.16/21. you need 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 delegate domains on 'nibble' boundaries, so you will need to create two /36 zones.

For example, for 2001:abcd:e000::/35 you will have to create two reverse zones: 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

You may request classless delegation by creating a domain object of the form [first-last].X.Y.Z.in-addr.arpa. For example, if you have been allocated the address range 192.0.2.0 - 192.0.2.127, then you should create a domain object of the form 0-127.2.0.192.in-addr.arpa. The RIPE NCC DNS provisioning system will then generate the following records in the parent zone:

0.2.0.192.in-addr.arpa IN CNAME 0.0-127.2.0.192.in-addr.arpa
1.2.0.192.in-addr.arpa IN CNAME 1.0-127.2.0.192.in-addr.arpa
...
...
127.2.0.192.in-addr.arpa IN CNAME 127.0-127.2.0.192.in-addr.arpa

Please note that we do not support reverse delegation using slashes, as described in RFC 2317. We only support the form that uses dashes.

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 flags and return codes.

The (non-)availability of the aa flag indicates whether you received an answer from the "authoritative server" or not. If you have set up 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 Server

The 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 should do to verify if 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
2.png
rd; 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 formatted 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.png

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: NOERROR
2.png
, id: 3001 		    
;; flags: qr rd ra
3
; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 	    

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

;; ANSWER SECTION:
4.png

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 formatted output.

2.png

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.png

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.png
 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.png

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 setup 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 authoritative for 193.in-addr.arpa., AUTH03.NS.UU.NET. is selected for the next query. That server returns a delegation to the 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.