Reverse DNS Restructuring Project

Restructuring of the reverse DNS setup

The Reverse DNS Restructuring Project involves a number of changes:

• Modification of internal databases so that the RIPE Whois Database becomes the authoritative source for zone file generation.

• Change of interface for the creation and maintenance of delegation of reverse domains. <auto-inaddr@ripe.net> will be deprecated while the Whois Database interfaces will be available for reverse database management.

• The introduction of a new attribute, "mnt-domains:", in inetnum and inet6num objects to be able to delegate the authority to create new domain objects.

• The introduction of 'name' syntax checks for the ip6.arpa and in-addr.arpa domains, only allowing domain for names that make sense in the address hierarchy i.e. those that represent "reversed" addresses.

• A cleanup of inconsistent data so that the Whois Database reflects the data that is in the reverse zones.

• Once address space has been allocated the reverse delegations can be made. There is no longer the requirement that address space has to be assigned before a reverse delegation is made.

• The introduction of an attribute in the domain object used for storing public DNSSec keys.

Background and Motivation:

There are a number of issues that give rise to these changes.

• LIRs must currently use a separate interface for the maintenance of their domain objects. Having a single entry point for the maintenance of all objects in the Whois Database is more efficient for LIRs and the RIPE NCC.

• Deployment of DNSSec requires a method for the exchange of public keys. Using the Whois Database as the authoritative source for zone file creation enables the use of the Whois Database authorisation mechanisms including the LIR Portal, PGP keys and X.509 certificates, for DNSSec public key exchanges.

• Reverse zones are currently maintained though an e-mail robot, <auto-inaddr@ripe.net>, also referred to as 'Marvin'. When domain objects are submitted Marvin performs a number of DNS checks, updates the Whois Database with the submitted object and then updates the zone files. Once a domain object exists in the Whois Database it can be modified using the database interfaces. However changes to it will not end up in the zone file. This allows for the data in the Whois Database to be inconsistent with the data in the DNS. This leads to confusion and lameness problems in the DNS.

• The motivation for introducing the "mnt-domains:" attribute is because the maintenance of the DNS is often done by a different set of people to those that maintain inetnum objects. With the introduction of this new maintainer attribute and no longer having the restriction that address space is to be assigned before delegations are made, the setup of reverse space is easier and operational delays can be avoided.

• The motivation for the 'name syntax check' is because there are currently domain objects that clearly cannot exist in the address hierarchy (e.g. 666.193.in-addr.arpa).

• The Whois Database has several methods to interface with it, moving towards a system where the Whois Database is the authoritative source for reverse delegation information eases the development of web-based tools for zone maintenance. Besides, having uniform interfaces for all RIPE NCC services has benefits for the RIPE NCC and its customers.

Details:

Introduction of the "mnt-domains:" attribute for inetnum/inet6num (inet(6)num for short) objects.

An inet(6)num object can contain multiple instances of the "mnt-domains:" attribute. It is used for authorising the creation of domain objects for the reverse DNS namespace to which the inet(6)num relates i.e. the smallest less specific range. It protects the creation of domain objects and allows for fine grained control of who requests a delegation.

Once the domain object is created it is protected through the use of the "mnt-by:" attribute.

If there is no "mnt-domains:" attribute on a inet(6)num the authentication for the creation of a domain object is passed by the "mnt-lower:" attribute, when this is not available the "mnt-by:" attribute is used. This is a mechanism also used in RPSL and RPSS.

Reverse delegation interface

The <auto-inaddr@ripe.net> e-mail interface will be deprecated.

Reverse delegations can be maintained by submitting domain objects to the database. This allows for the use of existing database update interfaces in addition to the e-mail interface (<auto-dbm@ripe.net>).

The RIPE NCC will create DNS zone files for the reverse space from the information in the domain objects. During the creation of the zone files a filter is applied to ensure that:

• Reverse zone delegations are only created for address space allocated by the RIPE NCC (this takes into account ERX space).
• Once a delegation at a /16 boundary is made the more specific /24 domain objects are ignored.
• Delegations are only allowed on /16 and /24 boundaries (note that it remains possible to submit an object of the form 0-9.xxx.yyy.in-addr.arpa that will be expanded into 10 separate domain objects).

RFC 2317 type 'delegations' for PI space smaller than /24 not allocated by a LIR cannot be handled via this interface but will need to be requested via <inaddr@ripe.net>.

Introduction of an attribute for storing DNSSec public key information in domain objects.

When DNSSec is deployed not only the name servers that are authoritative for running a zone need to be registered but also the public key with which those reverse zones are signed. A mechanism is needed to authenticate the exchange of public keys. To avoid the deployment of DNSSec being prohibitively expensive the key exchange should be similar to the procedure used to exchange the information about the authoritative name servers.

The authentication methods used during the key exchange should be at least as strong as the authentication methods used for making the actual delegation. Using the Whois Database, in combination with the "mnt-domains:" attribute, the users of address blocks have control over the authentication methods.

We expect improved consistency and lower maintenance costs when, during the zone file generation, a single source of data for both DNSSec public keys and name server RRs can be used.

Database consistency and cleanup

Currently there is a set of zone files that is the authoritative source for the reverse tree. In addition there are domain objects in the database. Appendix 1 shows the number and nature of the inconsistencies.

The cleanup should not cause existing delegations to change i.e. the zone data has prevalence over Whois Database information in case of inconsistencies.

A somewhat more detailed cleanup plan will be presented to the DB-WG mailing list.

Tentative milestones:

Last Updated April 2004