- lesser delegations in the RIPE-operated zone files

Not really, since a delegation on a /16 boundary even now precludes any further delegation of "names" below that /16 out of the parenting /8. Ignoring the objects is just a consequence of how DNS works. -Peter

On 02.10 14:19, Daniel Roesen <dr@cluenet.de> wrote: ^^^^^^^

You're right of course. No coffee yet. *sigh*

No coffee -> dormant clue. [sorry, could not resist] Daniel Karrenberg

On Thu, 2 Oct 2003, Daniel Roesen wrote:

On Wed, Oct 01, 2003 at 05:39:28PM +0200, Olaf M. Kolkman wrote:

...

- Once a delegation at a /16 boundary is made the more specific /24 domain objects are ignored.

Hm. This has to consequences which I can see off-hand: - higher resolution delays as more indirection is involved

In abstract terms, this project merely changes the authoritative data source for the DNS-based data (delegations), moving it from the current zone files, to the RIPE Database. No additional DNS indirection is involved or created by this project. ( Note that the NCC currently secondaries /16-level zones on ns.ripe.net when /16-level delegations are requested, thus cutting out one level of indirection when queries hit ns.ripe.net . No change to this behaviour is introduced by this project )

And: you're saying that this is part of a filter between the database and the actual zone file generation. Wouldn't this introduce possible inconsistencies between DNS data and database data?

The end goal is that the authoritative DNS data is taken from the Database, such that barring the lag time (minimal) between a Database update, and publication of the same data in DNS, there are no inconsistencies between the two data sets. Kind regards, -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations/Security

Hi, On Fri, Oct 03, 2003 at 04:27:41PM -0700, David Kessens wrote:

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.

While I agree with the first half of your comments (do away with domain: and do it with the inetnum:) I disagree here. Users know how to access and modify the RIPE database - so please don't introduce yet another interface just for the reverse DNS. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56883 (56833) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

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

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

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@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@ripe.net. It's an ripe database object, so auto-dbm@ripe.net seems to be the natural choice.

I agree. I think overall it is preferrable to use the 'auto-dbm@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. ---

In article <20031006121932.A4658@iprg.nokia.com>, David Kessens <david@iprg.nokia.com> wrote:

[...] For example, simply using the 'rev-srv:' attributes and retiring the 'domain:' objects seems a lot easier for the user. [...]

The RIPE NCC delegates reverse domains on /24 and /16 boundaries only so they don't match inetnum objects very well. The 'rev-srv' might seem to be easier, but thats only true for /16 allocs. rev-srv on e.g. a /29 are meaningless and should go away. Same holds true for a rev-srv on a /24 within a /16. Regards, Joerg

Hi!

IMHO we have to camps:

1) the webinterface folks 2) the mailinterface folks

I think that RIPE NCC should support both camps. [...] Supporting two different interfaces to the same service doesn't come for free, but I think it's worth the trouble (and money).

From what I learned, supporting two different interfaces allows for very subtle bugs and annoyances, which ultimatly lead to effects like "you can do this only with that interface" or "If you do this with that interface, something different will happen compared to that other interface".

Having *one* way, and having this way consistently, is far easier to support. I vote for mail. -- MfG/Best regards, Kurt Jaeger 17 years to go ! LF.net GmbH fon +49 711 90074-23 pi@LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372