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]		
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]			
sub-dom:       [optional]   [multiple]   [inverse key]
dom-net:       [optional]   [multiple]   [ ]
remarks:       [optional]   [multiple]   [ ]
notify:        [optional]   [multiple]   [inverse key]			
mnt-by:        [optional]   [multiple]   [inverse key]
mnt-lower:     [optional]   [multiple]   [inverse key]
refer:         [optional]   [single]     [ ]
changed:       [mandatory]  [multiple]   [ ]
source:        [mandatory]  [single]     [ ]

	Here you put the name of your domain.
	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.
	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

Figure2.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 ripe-dbm@ripe.net. 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  	
; <<>> 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 rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2     

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

;; ANSWER 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: 30 msec
;; SERVER: 192.0.2.195#53(ns-pri.example.net.)
;; WHEN: Thu Apr  8 12:44:52 2004
;; MSG SIZE  rcvd: 330

	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
	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.
	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  	
; <<>> DiG 9.3.0 <<>> 2.0.192.in-addr.arpa SOA
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3001 		    
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 	    

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

;; ANSWER SECTION:						            
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

	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.
	`NOERROR` indicates a successful query.
	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.
	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  
;; 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  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

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.

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.

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)]

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

Reverse DNS

DNSReport.com

How This Applies to C I Corporation

DNS Made Easy