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