[ncc-services-wg] Reverse DNS Restructuring Project

Olaf,

On Mon, Oct 06, 2003 at 03:58:13PM +0200, Olaf M. Kolkman wrote:
> > 
> > On Wed, Oct 01, 2003 at 05:39:28PM +0200, ext Olaf M. Kolkman wrote:
> > >  
> > >   - 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.
> > 
> > Does this mean that the 'rev-srv:' attribute will be retired too ?!?
> 
> the "rev-srv:" attribute has been retired for the purpose of requesting
> reverse delegation.  E.g see:
> http://www.ripe.net/ripencc/faq/reverse/qa2.html#14:
> 
>   What are those "rev-srv" lines in an inetnum object for?
> 
> 
>   Previously, delegation requests could be made using either an
>   inetnum object or a domain object. We discovered several problems
>   with this, one being inconsistency of the two possible sources.
>   Requests are now only accepted via domain objects, so you must
>   register your reverse servers only in the domain object. If you're
>   changing a reverse delegation and find rev-srv lines in the
>   corresponding inetnum object in the RIPE DB, you must create a
>   domain object and you should delete the rev-srv lines from the
>   inetnum.

As you saw from my previous mail, if we decide to go the 'domain:'
object way, let's get rid of the 'rev-srv:' attribute at the same
time. I would like that to be part of the proposal.

This whole 'rev-srv:' versus 'domain:' confusion has already lasted
for such a long time that it is time to clear it up.

> (...)
> > This proposal also means that one has to submit for example 16 reverse
> > delegation objects to do a reverse delegation of a single /20.
> 
> To request delegation ranges you can use the "y-x.z.w.in-addr.arpa"
> notation.  This only works for "3rd" octets and there are problems
> when using this update method in combination with PGP (will be fixed
> during the migration to the WHOIS interface).  
> 
> Documentation on the range-update feature cannot be found on the web.
> It used to be part of the documentation, but fell through a crack at
> some point. We will be reviewing the documentation as part of the
> project but will fix this omission soon.
> 
> In the mean time, this is the relevant piece of documentation:
> 
>   http://www.ripe.net/reverse/howtoreverse.html#ranged-domain
> 
>  The range-update is also part of the LIR training curriculum:
> 
>   http://www.ripe.net/training/lir/material/slides/page97.htm

Ok, but as you mentioned this gives problems with PGP. This is in my
opinion a serious problem since this is the only real secure way to
enter data in the database. Security is even more important if we use
the data for actual operational purposes instead of informational
purposes in contrast to all other registry data (with the exception of
the routing registry part of the database). It is a real change from
current procedures to use something from the RIR database for real
operational purposes.

It is also a departure of our policy of not rewriting users data. I am
not sure whether that is a good thing. Rewriting and making a small
correction to users input is one thing, expanding from one object to
16 or even more different objects is quite another. Don't be surprised
if users are getting confused why they cannot find the range notation
objects that they thought they just entered in the database.

> > In fact, there is actually very little use for doing the whole thing
> > in the RIPE database in the first place. I haver never found any use
> > at all for looking up one of the in-addr.arpa objects in the database.
> > Maybe we should even think about retiring the 'domain:' objects and
> > 'rev-srv:' attributes altogether and offer a simple secure web or mail
> > user interface for submitting reverse delegations.
> 
> 
> We need an interface to 'transport' reverse zone information; now only
> nameserver attributes but in the future also DNSSec key
> attributes. 

This is a very good point. However, I am not sure whether it is a good
idea to overengineer a solution for a thing that we possibly might be
doing in the future. I can probably be convinced if there is actually
a concrete project plan that we can discuss for adding DNSsec.

> Our "philosophy" when drawing this proposal is to provide
> our customers with uniform interfaces to deal with the RIPE NCC. By
> having one data-store, that comes with authorization mechanisms and a
> well defined API we are able to develop multiple interfaces to it;
> currently we have a mail and a network interface to the WHOIS
> database, web-portal functionality is being extended.

I think myself that using the database is probably the right way to do
it but I am not really sure either. I do think that a bit more
discussion on this list will help to determine that this is really the
case.

Doing a reverse delegation is a relatively easy transaction and the
proposal that is currently on the table adds a tremendous amount of
extra complexity to the database and the request process. I am not
convinced that there are no alternate ways to make the life of the users
easier (that can or cannot include the database).

Doing the reverse delegation over a secure webinterface where one only
has to choose for which allocation the reverse delegation has to be
changed and entering a couple of servers comes to mind.

I am afraid, despite my fondness for the database, that it will only
get into the way of people doing their job. I have seen too many
companies deciding that they wanted to have a uniform way of dealing
with their company systems and they end up with this beautiful all
encompassing SAP (or whatever other vendors) system and people have to
become an expert in the system before being able to do relatively easy
transactions.

For example, simply using the 'rev-srv:' attributes and retiring the
'domain:' objects seems a lot easier for the user. Yes, there is the
disadvantage of different administative responsibilities inside larger
local registries that could make this more difficult in certain cases,
but this should balanced against the much greater ease of use. In
addition, there are solutions possible that can address this fairly
easily like adding a 'mnt-rev-srv:' attribute that allows the
'mntner:' to only change the 'rev-srv:' lines and nothing else. And
the good thing is that this is completely optional so it doesn't
interfere with people who want to do it the easy way.

David K.
---