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