[ncc-services-wg] Reverse DNS Restructuring Project

Olaf,

On Wed, Oct 08, 2003 at 11:50:56AM +0200, Olaf M. Kolkman wrote:
> 
> 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.

very good.

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

That is exactly why I think the RIPE database might be a good place.

However, if we use 'rev-srv:' attributes instead of 'domain:' objects,
we can still use this model without the need to rewrite users data.

> As for using WHOIS directly to generate zone information, you hit the
> nail on the head, this is a real change.

And an important one. Not all database security mechanisms in use are
good enough for this new purpose. They might be good enough for
publishing data for informational purposes, they are not good enough
to make actual changes to configurations.

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

Rewriting users data is messy and should be avoided if there is other
alternatives available. There is all kind of possible problems that
one can come up with and you will find more when you start doing this
in practise.

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 ?!? 

This kind of things can be solved by applying (or implying) more rules
and this will result in making life more difficult for the casual
database user because one has to go first to a three week training
class before one is able to interact properly with the RIPE database.

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

And that is exactly my problem with it. I don't think that the
'minimal changes to the end-user' is the right requirement. The right
requirement is to make things as easy as possible for your customers.

Doing reverse delagations with 'rev-srv:' attributes seems a lot
easier to me (I prefer this option). There is no need to rewrite
objects. And one can reverse delegate whole blocks at once by doing
a single simple submission without a need to learn any complications
like 'range' notations for domain objects.

But as an alternative, I think not using the RIPE database at all can
possibly be even easier (and there is no need to have multiple backend
databases either, the DNS works just fine for that).

And there are pretty good arguments for this too: the database allows
one to submit objects that are lower in the delegation tree and they
will be ignored because there are already delegations in another part
of the tree. This points in the direction that neither 'inetnum:'
objects or 'domain:' objects are the right datamodel to this.

Again, this can solved by adding rules, but it adds complexity and in
the mean time, the user will be confused because the user didn't read
the 50 page database manual before requesting the reverse delegation.

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

Of course there is a lot of similarity because they are trying to
accomplish the same thing. But only one of the proposals is the
easiest and least complicated to use.
 
> 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. 

Yes, but did they have a choice ?!? They had to submit 'domain:'
objects to get their reverse delegations done. No wonder they are more
up to date (but still far from correct) than the 'rev-srv:'
attributes.

Again, the requirement is what works easiest for your customer, it is
not: 'let's keep doing it the old way because people are used to it'.

I think it is time for me now to take a step back and watch what other
people like as the best solution.

David K.
---