[db-wg] Domain Cleanup Proposal

Dear Colleagues,

A. Introduction

This proposal is part of the effort to streamline reverse DNS operations 
[1] and make it easier for network range users to manipulate related 
domain objects.

Local Internet Registries (LIRs) maintain their reverse delegations at the 
RIPE NCC through the use of domain objects. For several historical reasons 
there are a number of inconsistencies between the domain objects and the 
reverse delegation information in the DNS. Since we want to move to a 
system in which the Whois Database is the authoritative source for data 
that is published in the DNS (see [1]), there is a need to remove these 
inconsistencies.

In this proposal, we will address the inconsistencies between data 
represented through the domain objects in the Whois Database and the 
reverse delegation data in our zone-files. We will also propose solutions 
to fix these inconsistencies.

Note, this proposal is only relevant for domain objects that the RIPE NCC 
provides reverse delegation services for i.e. networks delegated to it by 
the Internet Address and Numbering Association (IANA) and networks 
transferred to the RIPE Database via the Early Registration Transfer (ERX) 
Project [2].

This proposal is NOT relevant to domains in the e164.arpa space.


B. Type of Inconsistencies

- Domain objects that have no delegation in the zone configurations:

  Reverse DNS-related updates to the RIPE database must be sent to
  <auto-inaddr at ripe.net>, otherwise zone configurations can not be 
  updated. There are objects in the RIPE Database created via methods 
  other than by sending an e-mail to <auto-inaddr at ripe.net>, causing 
  this type of inconsistency.

- Zone configuration entries that do not exist as domain objects in the
  RIPE Database:

  When zone files are updated manually, and not by sending an e-mail 
  to <auto-inaddr at ripe.net>, this type of inconsistency occurs.

- Conflicting entries in the RIPE Database and zone files:

  A mismatch between the "nserver:" attributes and the NS Resource 
  Records (RRs) in our zone files occurs as a mixture of the
  first two inconsistencies. The domain object has been added or
  modified at one point via <auto-inaddr at ripe.net>, but then either
  updated manually or by <auto-dbm at ripe.net>.

- Invalid domain objects in the RIPE Database:

  This type of inconsistency occurs in domain objects that can not 
  map to a valid DNS entry. As an example, 8080.80.in-addr.arpa is 
  an invalid entry. Only reverse address space mapping is taken into 
  account.

- Invalid "nserver:" attributes in the RIPE Database:

  "nserver:" attributes must contain hostnames rather than IP entries. 
  This type of inconsistency occurs when one of the "nserver:" 
  attributes does not contain a host name.

C. Preventive remedies - Enforcing domain updates to <auto-inaddr at ripe.net>

We are in the process of integrating <auto-inaddr at ripe.net> and 
<auto-dbm at ripe.net>, so that domain updates and other types of updates can 
be performed from the same source. Until then, in order to prevent further 
inconsistencies, updates sent to <auto-dbm at ripe.net> containing only 
reverse domain objects will automatically be forwarded to 
<auto-inaddr at ripe.net>. Updates that contain a mixture of domain and other 
types of objects will be returned to the user unprocessed, warning him/her 
to split the objects and resend.

A separate announcement has already been sent to related mailing lists 
about this change.

D. Clean-up of Inconsistencies

The goal of the clean-up is to streamline the contents of domain objects 
and zone configuration files so that we can create zone files from the 
Whois Database. If choices have to be made about which data is more 
accurate , the data in the DNS has prevalence over the data in the Whois 
Database.

The approach followed in the clean-up is to identify inconsistencies, 
notify the contact persons for the domain objects, provide them with a 
suggested fix and allow maintainers to fix their objects (details below). 
After about six weeks the RIPE NCC will send messages about 
inconsistencies still present in the system. Two weeks after this message 
has been sent, the RIPE NCC will apply the suggested fix to the domain 
objects automatically.

- Domain objects that do not exist in zone configurations:

  Contact persons(*) in the domain object will be notified that the 
  object will be deleted by the given deadline unless it is updated.

  This procedure will be followed even if the domain object contains
  valid delegation information. Resubmitting the object will ensure that
  a valid delegation is created in the DNS.

- Zone configuration entries that do not exist as domain objects in the
  RIPE Database:

  The contact persons(*) in the less specific inetnum object will be 
  notified that, at a given deadline, place holder records in the RIPE 
  Database will be created for these objects. These can be overridden 
  by the maintainer of the inetnum object.

  The notification contains a suggested domain object that can be
  modified and submitted before the deadline if the LIR does not want
  to have a domain object created automatically.

- Conflicting entries in the RIPE Database and zone files:

  Contact persons(*) in the domain object will be notified that the
  object will be updated to reflect the contents of the delegation NS
  RR in the reverse zone files by the given deadline. They will be 
  notified that they can fix these entries by updating them.

  The notification contains a suggested domain object that can be
  modified and submitted before the deadline if the LIR does not want 
  to have a domain object modified automatically.

  The clean-up is not meant to solve lame delegation data (e.g. when the NS
  RRs at the parent side are different from NS RRs at the child side of a 
  zone). Therefore the suggested domain object might not represent the 
  actual set of authoritative nameservers and fail during submission by the 
  maintainer.

- Invalid domain objects in the RIPE Database:

  Contact persons(*) in the domain object will be notified that the object
  will be deleted by the given deadline.

- Invalid "nserver:" attributes in the RIPE Database:

  Contact persons(*) in the domain object will be notified that the
  contents of the "nserver:" attributes will be replaced by the entries in
  zone files if there are any, otherwise the object will be deleted. One IP
  address may refer to many hostnames, therefore automatically replacing it 
  with its host entry may be erroneous.

*: Contact persons are defined by the NIC handles listed in the "admin-c:",
   "tech-c:", "zone-c:" and the "mnt-by:" attributes of the domain object.

E. Timeline

- 7/12/2003: Filtering domain updates to <auto-dbm at ripe.net>.
  Domain objects submitted to <auto-dbm at ripe.net> are redirected to the
  <auto-inaddr at ripe.net> interface. 

- 3/12/2003: An announcement will be sent to the Database WG and DNS WG
  mailing lists

- January 2004:Listing inconsistencies and sending notifications to contact
  persons.

- End of February 2004 (announced approximately two weeks before): Cleanup
  (creation of place holder records and synchronising conflicting entries)

This timeline allows for a two month period in which customers are informed 
and have the opportunity to fix inconsistencies. The end of February 
milestone is tentative and may extended during the cleanup if unexpected 
problems are encountered.


E. References

[1]: Original proposal http://www.ripe.net/reverse/proposal.html.
  Discussion on this proposal has taken place on the RIPE NCC Services WG
  mailing list and was summarised in:
  http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html


[2]: Early Registration Transfer [ERX] Project
  http://www.ripe.net/db/erx/erx-ip/




Regards,

--
Can Bican
Software Engineering Department

Olaf Kolkman
New Projects Group

RIPE NCC