|
|
 |
Reverse Delegation How
To
The
Five Steps to Set Up Reverse Delegation
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 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
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
-
-
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
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.
|
|
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.
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.
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. |
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.
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:
13 September 2007
|
|
 |
 |