[ncc-services-wg] Reverse DNS Restructuring Project

In article <20031008145711.C7178 at iprg.nokia.com>,
David Kessens <david at iprg.nokia.com> wrote:
> [...]
> > However, we currently use the domain objects to maintain reverse
> > delegations. Those domain objects do end up in the database while
> > simultaneously updating zone files. So if everybody would use the
> > proper interface to update domain objects than we would have full
> > consistency. So when implementing the proposal we loose the
> > ambiguity in the update path, we get consistent WHOIS and ZONE data.
> > Besides we gain access, and use of new authorization mechanism that
> > become available to the database (e.g. X509).
> 
> Yes, that is certainly useful. However, we would also get full
> consistency if we got rid of both 'domain:' and 'rev-srv:' attributes
> and use a simple specialized interface to do reverse delegations. The
> DNS is already a fully public database. There is no need to keep the
> data in yet another backend database or publish it in more than one
> place.

I beg to differ.  The redundancy in the database is needed for us 
operators.  If you were right, we could drop all the IRR databases, 
sice the bgp table is a fully public database.  That's fine as long as 
no errors happen, but error do happen so we need some out-of-band
method to know how it should look like and whom to cantact if it
doesn't.  

A quick example:  let's assume that the nameservers for iprg.nokia.com 
and nokia.com are all lame delegations.  Who'e the right contact to
fix this?  Since they are all lame, I can't retrieve the RNAME in the 
SOA.  I guess I could get the RNAME of .com, but contacting 
nstld at verisign-grs.com would certainly not solve the problem.

> I think the focus should be on the people who use the interface: we
> need to choose the most simple and easy way for the user to get the
> job done. The goal is not to make a complicated interface and declare
> victory because we have reached data consistency!

It's not getting more complicated.  You already have to submit a 
domain object to get a reverse delegation.  In fact it's getting
easyer since you don't have to remember that this object has go to
auto-inaddr at ripe.net.  It's an ripe database object, so
auto-dbm at ripe.net seems to be the natural choice.

> [...]
> To give another example:
> 
> - Somebody sends in: 3-10.193.in-addr.arpa
> - Next, requests a change to: 4.193.in-addr.arpa
> - Next, somebody requests a deletion of: 3-10.193.in-addr.arpa
> 
> Should the deletion fail since 3-10.193.in-addr.arpa is actually many
> different objects and one of them is not the same anymore so in fact
> there is really two sets of different objects ?!? 

Try again, this time with inetnums and rev-srv.  What's the meaning of
rev-srv on a /20 followed by a more specific /24 followed by the less
specific /20?  The problem space is exactly the same.  

Joerg