Configuring Reverse DNS
The reverse DNS database of the Internet works with a hierarchical tree of servers, just like forward DNS. It is rooted in the Address and Routing Parameter Area (arpa) top-level domain of the Internet. One level below the arpa root are the delegated servers in-addr.arpa for IPv4 and ip6.arpa for IPv6.
Further down the tree, there are delegations for the /8 blocks that IANA allocated to the RIRs, the allocations that the RIRs gave to the address holders, all the way down to the individual IP addresses and names that you have configured for your Internet-enabled hosts. The process of reverse resolving an IP address uses the pointer DNS record type (PTR record).
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. This means that, as an address holder, you will have to configure two things. First, you have to configure your zone for reverse DNS. Second, you have to request reverse delegation of your zone. The second part is done by creating a domain object in the RIPE Database.
Before you can submit the domain object to the RIPE Database, you will first have to configure reverse DNS for your zone on at least two name servers. Upon submission, the RIPE Database will perform checks to see if your name servers are configured properly. If so, delegation will be propagated to the DNS by the RIPE NCC's name servers.
1.1 Mapping IP addresses into the DNS name hierarchy
For IPv4, the mapping of the reverse address space can only happen on "byte" boundaries, i.e. multiples of 8 bits. This means that you should take the four octets – the decimal numbers between the dots - of an IP address range, put them in reverse order and then map them into the in-addr.arpa domain.
For example, an address (A) record for mail.example.com points to the IP address 192.0.2.5. In pointer records of the reverse database, this IP address is stored as the domain name 126.96.36.199.in-addr.arpa. pointing back to its designated host name mail.example.com. The resulting PTR record would look like this:
188.8.131.52.in-addr.arpa. 3600 IN PTR mail.example.com.
Reverse DNS for IPv6 uses the hexadecimal notation on "nibble" boundaries, i.e. multiples of 4 bits. This means you should take the IPv6 address, expand all the zeros, put each hexadecimal number in reverse order and map them into the ip6.arpa domain.
For example, the pointer domain name corresponding to the IPv6 address 2001:db8::567:89ab is b.a.184.108.40.206.220.127.116.11.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa., which would result in this PTR record:
b.a.18.104.22.168.22.214.171.124.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR mail.example.com.
1.2 Dealing with multiple zones for one address block
Because the particular mapping delegation of reverse address space can only happen on byte boundaries for IPv4 and nibble boundaries for IPv6, you could be dealing with multiple zones for one address block.
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.
For example, if you have been allocated 10.155.16/22, you need to create four reverse zones:
If you have been allocated an IPv6 block that is not on a nibble boundary, you will need to go down to the next nibble and create multiple zones to cover the entire block.
For example, an allocation such as 2001:db8::/29 will result in eight reverse zones of /32 each:
Step 1: Set up authorisation
The creation and maintenance of domain objects must be handled by a designated maintainer. You can use an existing maintainer or create a specific one for the people who will be creating and managing domain objects. You should refer to this maintainer using the "mnt-domains:" attribute in the inetnum object for the address block that you hold. You will be able to add the "mnt-domains:" attribute in the RIPE Database, for example using webupdates. If you are an LIR, you may need to select your default maintainer first, before you can add this attribute.
Step 2: Configure your DNS servers
First, chop your address block into "chunks" that can be delegated. For example, if you have been allocated 10.155.16/22, you need to create four reverse zones:
Then proceed to configure your DNS servers. Here are some recommendations to help you pass all the tests:
- Make sure you set up at least two name servers that are authoritative for the zone
- Ensure that the servers are at least in different subnets, but preferably in different networks that are geographically distributed
- The resolvable names of these name servers should be in the NS resource records of the zone
- The SOA resource record (RR) 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.
Keep in mind that, for a /16 (v4) and /32 (v6), you can use ns.ripe.net as the secondary server. In both cases, you have to allow zone transfers from the name server listed in the SOA resource record's MNAME field to the RIPE NCC distribution servers. The IP addresses of the two servers are:
126.96.36.199 / 2001:67c:2e8:11::c100:13be
188.8.131.52 / 2001:67c:2d7c:66::53
If your servers are configured to send DNS notify messages and you would like ns.ripe.net to update promptly, please send them to the IP addresses listed here. Any notify messages sent directly to the addresses of ns.ripe.net will not be seen. Also, we do not support any non-standard configurations (such as port numbers other than 53, TSIG keys and so on).
When you are satisfied with your configuration, we recommend that you perform a test of your setup using the DNSCheck tool so you can find and resolve any problems.
Step 3: Submit your domain object
When you submit a domain object you are requesting reverse delegation, asking the RIPE NCC to enter NS records pointing to your name servers in RIPE NCC’s /8 parent zone. The domain object has the following mandatory attributes:
domain: <zone name>
admin-c: <nic-handle for administrative contact>
tech-c: <nic-handle for technical contact>
zone-c: <nic-handle for zone contact>
nserver: <primary nameserver>
nserver: <secondary nameserver>
mnt-by: <your maintainer>
In the "domain:" attribute, you specify the name of the reverse zone, e.g. "16.155.10.in-addr.arpa". As discussed, you will have to do this for each "chunk" you have created. So if you need reverse delegation for a /22 block, you will need to create four domain objects, one for each /24.
Enter all other attributes and submit your domain object to the RIPE Database. After verifying syntax and authorisation, we will perform a number of tests to see if you configured reverse DNS correctly. The tests return log level information, categorised as INFO, NOTICE, WARNING, ERROR and CRITICAL. We reject any update that has ERROR or CRITICAL for any test. In this case, resolve the problem and try submitting the domain object again.
If the update was succesful, you should then be able to query for your object in the RIPE Database. Still, it may take several hours 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.
To allow for the exchange of DNSSEC-related information, the domain object includes a "ds-rdata:" attribute.
In DNSSEC, the Delegation Signer (DS) resource record is created from a DNSKEY resource record by comparing it with the public key. The parent publishes the DS resource record. The "ds-rdata:" attribute contains the RDATA of the DS resource records related to the domain, as shown in the "domain:" attribute.
ds-rdata: 64431 5 1 278BF194C29A812B33935BB2517E17D1486210FA
The tools provided with BIND (version 9.3.0 and later) will generate a "ds set" during signing. You should copy the DS Rdata into the "ds-rdata:" attributes.
When we receive a domain object with DNSSEC-related information, we will carry out additional tests. These are the most important:
- There should be a matching DNSKEY available in the DNS for each "ds-rdata:" attribute that is submitted in the domain object
- There should be a valid RRSIG made with the DNSKEY matching the "ds-rdata:" attribute
- Although it is not mandatory, the DNSKEY should have the "SEP" flag set. If it is not, a warning will be produced, but the "ds-rdata:" content will still be copied to the zone
- Lastly, we check if the signature validity period is close to expiring and whether the Times To Live (TTLs) are a reasonable fraction of the signature validity period. The test requires the TTL to be at least two times smaller than the signature validity period
Keep in mind that these tests will only be done for "ds-rdata:" attributes using digest type 1 (SHA1). If the "ds-rdata:" attribute uses an unsupported digest type, you will see a warning message, but the "ds-rdata:" content will still be copied into the parent zone.
Here is an overview of the most common warnings and errors that the reverse delegation checker reports, along with the likely causes and suggested solutions.
|Error||Likely cause and suggested solution|
|*ERROR*: No SOA RR were found.||No Start of Authority records were found. This tends to indicate that the nominated name servers are not replying correctly for the zone in question. Usually, the fix for this involves reloading all of the name servers.|
|*WARNING*: some of the specified name servers appear to be in the same subnet. According to RFC 2182, they should be geographically separated.||If you supply two or more name servers that appear to be in the same physical location, this warning is a reminder that the zone may not be visible if your connection to the Internet fails. We highly recommend that you have multiple geographically distributed secondary name servers.|
|*ERROR*: NS RR for abc.b.c.d found on xyz.b.c.d but not in template.||The machine abc.b.c.d is reported to be a name server for this domain by the machine xyz.b.c.d, but you did not list abc.b.c.d when submitting the domain object.|
*ERROR*: nserver: a.b.c.d
The name server a.b.c.d has failed to respond because:
Correct your name server or firewall/router configuration and resubmit the domain object.
*ERROR*: cross-check of listed NS RR failed.
|The name servers on both zones should be the same.|
|*ERROR*: SOA on "machine1.b.c.d" does not match SOA on "machine2.b.c.d".||Some of the name servers supplied could not be contacted, or some of them failed to respond appropriately, i.e. there may not be a name server running on the hosts, or they may not know about the zone in question. This message is also generated when the list of name servers that you supply does not match the list of name servers that you set up. The comparison is done on a textual basis, meaning that supplying IP addresses will not work.|
I'm sure my zone is set up correctly, but the RIPE Database just won't accept my domain object!
|You can always contact us for help, but we suggest that you first read RFC 1912 - Common DNS Operational and Configuration Errors.|