[ncc-services-wg] Reverse DNS Restructuring Project

Joerg,

On Thu, Oct 09, 2003 at 01:56:29AM +0000, Joerg Schumacher wrote:
> > 
> > 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.

I happen to be an operator too :-). I very carefully talked about the
reverse delegation 'domain:' and 'rev-srv:' data only. I never said
that IRR databases should be dropped. When the DNS is unable to
provide you with a contact, the 'inetnum:' objects are still there and
it gives you quite a few contacts to talk to in case of problems. If
people feel that that is not enough, you could always introduce a
'reverse-contact:' attribute.

Note that my preferred solution is to use 'rev-srv:' attributes which
actually keeps all the reverse information in the database. I just
wanted to point out that there are other alternatives that could also
be considered.

When changing the systems anyways, it is always a good idea to take a
step back and look with an open mind whether the current process
actually accomplishes the goal in the most efficient way. Of course we
can make incremental improvements but sometimes a lot of the problems
with the current process go away by taking a different direction.

> 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.

This example is not about reverse domains. As said before, there are
still plenty of contacts to be found in the 'inetnum:' object in the
RIPE database and additional contact information could be added if
people wish so.

> > 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.

I agree. I think overall it is preferrable to use the
'auto-dbm at ripe.net' interface. But I do think that the process would
work a lot better if we used 'rev-srv:' attributes instead of
'domain:' objects.

At the same time, I think it is good to mention and study some other
alternatives in order to get a better understanding of the problem
that needs to be solved.

> > 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.  

No, the drawback that I was talking about was an example of how
rewriting of user data is eventually going to cause confusion because
it is not clear anymore whether the 'range' notation object that the
user submitted is the real object or the objects that eventually get
written in the database.

You talk about another drawback with objects lower in the tree that
get ignored and are confusing to the user. I actually already
mentioned that drawback in my previous mail and it is indeed the same
for 'rev-srv:' or 'domain:' based solutions but non-existant for
solutions that don't use the RIPE database. Some more intelligence in the
database software could probably help here too.

Thanks for your comments - I do think this discussion helps people to
better understand the disadvantages and advantages of the different
approaches.

David K.
---