In article <20031008145711.C7178@iprg.nokia.com>, David Kessens <david@iprg.nokia.com> wrote:
[...]
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 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. 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.
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.
[...] 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 ?!?
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. Joerg