The RDNS Project

RDNS Consistency Cleanup

This document provides a more detailed overview of the inconsistencies that you may have been warned about between January and March 2004.

Note: a number of messages concerning the cleanup of domain objects were sent in error. Please see our post to the DNS Working Group mailing list for details.

Context

The RIPE NCC is currently undertaking a project to clean inconsistencies between the data in our zone files and the Whois Database. This will allow us to use the Whois Database as the authoritive source for reverse zone files i.e. generate our zone files from the database records.

This project is part of a larger effort to streamline reverse DNS operations and make it easier for network range users to manipulate related domain objects.

During the project we will scan for inconsistencies and notify the contacts for the relevant domain objects that show problems. This will allow them to fix the inconsistency themselves. 1 March 2004 we will clean up any inconsistencies left (a message will be mailed to the Database working group mailinglist about two weeks prior to this).

The Inconsistencies

You have received a message about an inconsistency. The message contains an indication of what the RIPE NCC will do if you have not updated the relevant object yourself before 1 March 2004. We have tried to take a logical course of action that will result in a continuation of service as much as possible.

The inconsistencies are described at the end of this page. After the list of inconsistencies we will first explain what consistent data is and how you can, in general, fix inconsistent data.

• Inconsistency found: Syntax Errors
• Inconsistency found: No delegation in zone files
• Inconsistency found: "nserver:" is not a hostname
• Inconsistency found: "nserver:" without matching NS RR in zone file
• Inconsistency found: NS RRs in zone file without matching "nserver:"

What is consistent data?

In this context data is called consistent when 'our zone file' contains the same set of NS RRs (Nameserver Resource Records) as is stored in the set of "nserver:" attributes for the relevant domain object. We just used the term 'our zone file', it is the parent zone as loaded into ns.ripe.net.

To have a properly configured DNS setup the set of NS RRs at the parent (our zone file) should be a subset of the set of NS RRs at the child (your zone file). All the servers listed in the NS RRs at the parent should be authoritative for the zone. Our consistency test only looks at differences between what is in the Whois Database and in 'our zone files'; it does not test for a properly configured DNS setup. However, whenever you try to update a domain object a set of DNS tests is done.

We will use the 193.0.3/24 space as an example. Consistency, in the context we are checking, means that the set of "nserver:" attributes for this domain object is the same as the information in the DNS. You can check the content of the domain object by using whois -h whois.ripe.net 3.0.193.in-addr.arpa". The content of our zonefile can be determined directly from the DNS "dig @ns.ripe.net 3.0.193.in-addr.arpa NS"

The following higlighted entries should match.

The information from the Whois Database

whois  3.0.193.in-addr.arpa
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

domain:       3.0.193.in-addr.arpa
descr:        Reverse for RIPE NCC address space
admin-c:      AP110-RIPE
tech-c:       OPS4-RIPE
zone-c:       OPS4-RIPE
nserver:      ns.ripe.net
nserver:      sec1.apnic.net
nserver:      sec3.apnic.net
mnt-by:       RIPE-NCC-MNT
mnt-lower:    RIPE-NCC-MNT
changed:      inaddr@ripe.net 19990705
changed:      ripe-dbm@ripe.net 20020705
changed:      inaddr@ripe.net 20021205
source:       RIPE

[... other output removed ...]

Information from 'our zone files'

dig @ns.ripe.net 3.0.193.in-addr.arpa NS

; <<>> DiG 9.3.0s20021217 <<>> @ns.ripe.net 3.0.193.in-addr.arpa NS
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37012
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 5

;; QUESTION SECTION:
;3.0.193.in-addr.arpa.		IN	NS
;; ANSWER SECTION:
3.0.193.in-addr.arpa.	172800	IN	NS	sec3.apnic.net.
3.0.193.in-addr.arpa.	172800	IN	NS	ns.ripe.net.
3.0.193.in-addr.arpa.	172800	IN	NS	sec1.apnic.net.


;; ADDITIONAL SECTION:
ns.ripe.net.		172800	IN	A	193.0.0.193
ns.ripe.net.		172800	IN	AAAA	2001:610:240:0:53::193
sec1.apnic.net.		3600	IN	A	202.12.29.59
sec3.apnic.net.		3600	IN	A	202.12.28.140
sec3.apnic.net.		3600	IN	AAAA	2001:dc0:1:0:4777:140::

;; Query time: 1 msec
;; SERVER: 193.0.0.193#53(ns.ripe.net)
;; WHEN: Wed Dec 17 15:48:21 2003
;; MSG SIZE  rcvd: 211

How to fix inconsistent data

Please refer to the procedure described in the reverse section of our webpages. Essentially you will have to create a new domain object with the proper information. You have to make sure that your mail is properly authenticated and that your DNS infrastructure is properly set up. The reverse delegation robot that handles your requests will do some rudimentary tests.

Inconsistency found: Syntax Errors

This object contains syntax errors in the "domain:" attribute. Since it refers to no valid reverse DNS entry, it is invalid. This object will automatically be deleted after 1 March 2004.

Explanation

The domain object has a "domain:" attribute i.e. a name which does not exist in the reverse delegation tree. Examples of these are 1.foo.193.in-addr.arpa and 1.666.193.in-addr.arpa where the labels foo and 666 are not allowed in reverse domains.

The default action will be to delete these items since they are probably caused by mistakes, typos, etc.

We recomend that you delete these objects yourself.

Inconsistency found: No delegation in zone files

This object does not have a corresponding NS RR in our zone files. Since the operational information has not propagated, this object will automatically be deleted after 1 March 2004.

Explanation

This object was, at some point, uploaded to the database but a delegation was never made; there are no NS RRs in the parent zone. Since this object reflects information about non-existent domains we will delete it.

If the domain object does represent a valid domain and you want the delegation to be created you should resubmit it following the procedures described at www.ripe.net/reverse. The NS RRs, providing the delegation, will then be created in our zonefiles.

We choose to delete the object since we want to make sure that we do not create delegations that are not intended to be created.

We recommend that you delete these objects yourself.

Inconsistency found: "nserver:" is not a hostname

The following "nserver:" entries are not valid hostnames:

nserver: 192.168.1.61
nserver: sheriff.the.shot.1
nserver: none at all
.
.
.

These entries will be automatically removed from the domain object after 1 March 2004. If there are no "nserver:" attributes left in the domain object after removal, the domain object itself will also be removed.

Explanation

A name server must be specified by name because the NS RR datatype is a domain name (RFC1035 sect 3.3.11). The attributes listed are not valid domain names. This inconsistency check is implemented using a regular expression; we have not tested if the "nserver:" attributes actually contain names that can be resolved i.e. we have not tested for "lameness".

The default action is to automatically remove the "nserver:" attribute lines without a valid hostname. If all "nserver:" attributes are deleted, the domain object itself will be deleted.

We recommend that you delete or correct the offending "nserver:" attributes yourself.

Inconsistency found: "nserver:" without matching NS RR in zone file

The following "nserver:" entries do not exist in our zone files:

nserver: ns0.example.net
.
.
.

Since the operational information has not propagated these entries will be automatically be removed from the domain object after 1 March 2004. If there are no "nserver:" attributes left in the domain object after removal, the domain object itself will also be removed.

We recommend that you delete or correct the offending "nserver:" attributes yourself.

Note: a number of messages concerning the cleanup of domain objects were sent in error. Please see our post to the DNS Working Group mailing list for details.

Inconsistency found: NS RRs in zone file without matching "nserver:"

The following NS entries that are in our zone files do not exist in the domain object:

ns1.example.net
.
.

These objects will automatically be inserted into the domain object after 1 March 2004.

Explanation

Our zone files contain NS RRs that are not listed as a "nserver:" attribute in the domain object. We do not want to break the DNS delegation, therfore this inconsistency needs to be fixed by adding the relevant "nserver:" attribute.

We recommend that you add the relevant "nserver:" attributes to the domain object and submit that yourself.