[ncc-services-wg] Reverse DNS Restructuring Project

["Olaf M. Kolkman" <]

Dear Colleagues,

Below you find a proposal for restructuring of parts of the reverse DNS
services.

The proposal can also be found on
http://www.ripe.net/reverse/proposal.html

We would appreciate your feedback on this (ncc-services-wg) list.


-- Olaf Kolkman


Reverse DNS Restructuring Project.


Proposal:

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@localhost 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 who is 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
    authorization 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@localhost, 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 being 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 authorizing 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@localhost 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@localhost).

    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 in 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@localhost.

  - 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

  - A more detailed proposal for the "mnt-domains:" attribute and the
    cleanup. (October 2003)

  - Documentation and procedures. (October-November 2003)

  - Introduction of "mnt_domains:" and reverse delegation processing
    for auto-dmb@localhost while still allowing the use of
    auto-inaddr@localhost with the current authorization
    methods. (December 2003).

  - As soon as auto-dbm@localhost can handle reverse delegation
    requests, and the back-end systems have been modified not to
    introduce new inconsistencies the RIPE NCC will be sending out
    warnings about inconsistent data (as part of the cleanup
    process). There will be a 2 months interval to allow users to fix
    inconsistencies.

  - Deprecation of the auto-inaddr@localhost interface, allowing 
    only updates via auto-dbm@localhost.
    (Around February 2004, Details to be worked out). 

  - Around February 2004 (shortly after the previous step) the inconsistent
    data will be cleaned up.


$Id: RDNS-Proposal.txt,v 1.8 2003/09/30 07:21:45 olaf Exp olaf $