At 16:53 +0100 3/2/10, Antoin Verschuren wrote:
The question is whether we need to follow this administrative path.
"We" do for some value of $we. If you are a registry, then you can develop one interface that all of your registrants have to use. But if you are not a registry you will deal with bunch and commonality will be a good thing.
Queries don't follow this administrative path. DNSSEC validation doesn't follow this administrative path. So why should DS_updates follow this administrative path ?
The answer is apparent when the perspective is from the point of view of a DNS operator. Some registries do not have an public interface to the process that populates the zone they manage. For the same of interoperability in operations, there is a need to establish a common mechanism.
E.g., we (speaking in the voice of our commercial DNS hosting department) have to deal with names registered in COM and in other ccTLDs. It would be nice to have a consistent interface amongst the registries.
And if we want to pull out the "what about the children" (http://en.wikipedia.org/wiki/For_the_children_(politics)) argument - the end customers get tied up having to get information from the DNS operator (or their DNS operations) at a regular interval and having to carry this to the registration system. If they have a small cache of names and there is no general solution, they will have to remember how to update each name.
Ok, but why should DS updates follow an administrative path. For traceability. For logging. For accountability. For forensics. For reasons that differentiate the activity of registration from the serving of DNS zones. DNS does not maintain history, logging of registration does.
NS updates (technical information) -at this moment- only follow this administrative path because of a lack of a different secure channel.
That is an incorrect characterization of the problem. Currently updates to name servers and glue addresses follow the administrative channel because such information is easy to "cut'n'paste" and it is relatively static. Customers of DNS operations are accustomed to being given a list of name servers and addresses which they carry to their registrar (if applicable) "portal". The data, in format, is on par with administrative contacts, billing contacts, technical contacts, etc. (which have much higher security requirements IMHO than DS records).
If there was a secure channel between child and parent (like with DNSSEC), then none of the administrative channels would need to process NS updates or other technical updates.
Security is not the main problem - basic transfer of the randomized-looking hash is the first step. Security has to be built-in, but it's the tail of the dog here.
Automate it. Over DNS.
I think it is very short-sighted to maintain this position. This statement assumes that the registration body involved is running DNS. I've learned that not all registration entities do this. One environment was described to me as "folks running a domain name selling point" (aka domain name reseller/retailer) with just a web page and a cell phone number. A customer of this kind of entity may run their own DNS infrastructure and need to get DNSSEC keys to the TLD the name is registered under.
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
