[ncc-services-wg] Reverse DNS Restructuring Project

David and others,


David wrote:
> 
> 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.

I agree "Clarity good, Confusion bad". I have not yet had the change
to study all implications of getting rid of the "rev-srv:". But we'll
look at this and get back on this issue; probably in the clean-up proposal
that is to follow or in a separate proposal.


David wrote:
> 
> 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.
> 

I may not have explicitly mentioned this but in the new system PGP
will work in combination with the "range" update. (Technical detail,
now the authorization checks are done after the objects have been
split and individually processed, in the future the authorization
check will be done first and then the objects are split to to further
checks). Note also that not only PGP will work with the proposed setup
but users will be able to use the consistent authorization model of
the RIPE DB.

As for using WHOIS directly to generate zone information, you hit the
nail on the head, this is a real change. 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).


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

I am not in the position to judge if this will be a problem. I hope
and think the mechanism of the range update is documented well enough
that users will know that the range update is "synthesizing multiple
updates".


Olaf wrote:
> > We need an interface to 'transport' reverse zone information; now only
> > nameserver attributes but in the future also DNSSec key
> > attributes. 

David replied:
> 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.

The proposal as such stands on its own. Ideas on DNSSEC deployment are
a motivation to go this way but are not the main driving force behind
it. Having said this, here are the requirements for DNSSec key-exchanges.

   - Initial key exchange needs to happen out of band.
   - The authorization mechanisms use during the key exchange will need
     to be as strong as the authorization used for the exchange of nameserver
     attributes.

   A less strict requirement:
   - There is a preference to maintain a database with key information.
	(A hash over the key ends up in the parent zone, during trouble
         shooting it may be handy to figure out what the key material was
         used to generate the hash).

All these requirements are fulfilled when we use the domain object to
store key information and adding DNSSEC capabilities to our
provisioning system will be a matter of weeks, allowing for rollout
soon after standards have been completed.

Note that we will still be able to deploy DNSSEC with a key-attribute
in a domain object and using auto-inaddr/Marvin (Marvin is the robot
in the back-end) however with the in-addr robot and the WHOIS database
not being tightly integrated we will get more and more
inconsistencies. The proposal is to make sure there is one update path
for domain objects that leads to consistent zone information; that is
independent of deployment of DNSSEC or not.



David wrote:
> 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.

Reading and open to suggestions see however the next point.

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

There might be other mechanisms. But our requirements for the current
proposal were minimal changes to the end-user and minimizing the
amount of different back-end databases we have to maintain. It is hard
to put hard numbers on these things but less complicated systems lead
to less costs.


> Doing the reverse delegation over a secure web interface 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.

As said above and in the previous mail, the DB group is developing
various interfaces to the WHOIS database. Piggy-backing on those
developments that kind of interface becomes real close.


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

It strikes me that this example as remarkable similarity to the
current proposal. Both use the DB for storage of reverse information
and both use a new attribute to delegate authorization for updating
specific information.

Most users have been using domain objects for years. I am not sure if
deprecating those in favor of reviving "rev-srv:" is something those
users are waiting for. 



-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC