| |||||||||||||
DNSSECDNSSECPosted Feb 2, 2010 19:03 UTC (Tue) by Thue (subscriber, #14277)In reply to: DNSSEC by tialaramex Parent article: China Internet Network Information Center accepted as a Mozilla root CA
On the other hand, to me DNSSEC at the root seems to be a simple problem of load-balancing an embarrassingly parallel problem. Which really should not be that big of a problem to implement; just throw more servers at it behind the load balancers.
I have approximately zero insider knowledge as to what exactly is holding up the deployment of DNSSEC in the DNS root. But I have seen zero good explanations as to why it would not have been implemented long ago if it had any sort of priority. And DNSSEC should have very high priority, if nothing else then because of DNS poisoning.
(Log in to post comments)
DNSSEC Posted Feb 2, 2010 19:41 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Well, how long ago exactly is "long ago" ?
One hold up was that DNSSEC as originally conceived didn't offer privacy, because at that time DNS privacy was regarded as an esoteric thing to desire. If you're willing to admit that gazimble.example.com resolves to 10.1.2.3, why would you care that it's possible for someone to find that out without the advance knowledge of the existence of the name 'gazimble.example.com' ?
But by the time it was first considered good enough to be worth actually implementing things had changed - privacy was the default in many "public" registries as well as most private organisations. DNSSEC was unacceptable in its current form to those entities because it would mean giving up something they were used to having, and in some cases which they had guaranteed to others.
So, back to the drawing board to come up with a way for a DNSSEC server to assert that the name you've asked for isn't known, without having to
pre-cache a denial for every conceivable unknown name
Of course you could argue that this shouldn't have held things up for the root - nobody expects TLDs to have privacy, this was only ever a concern for subdomains. But it was felt that if nobody else was going to deploy there was certainly no reason to _begin_ with the root where problems would be most costly.
DNSSEC Posted Feb 2, 2010 20:12 UTC (Tue) by Thue (subscriber, #14277) [Link]
RFC 5155 defining NSEC3 was published in March 2008. If DNSSEC was high priority, and NSEC3 was not that big of a change over base DNSSEC, then I don't see why it should take more than 6 months to implement at the root level. As I argued previously, once a basic software implementation is in place then it is just a question of load balancing. Other organizations have deployed DNSSEC, so software support exists.
Yes, it is important to take the time to get it right at the root DNS. But this is snails pace. I can't reasonably see that the supposed problems fit the time it is taking, if enough resources were allocated to this important project.
It is possible that we are just dealing with a large slow bureaucracy. But I still don't have to like it :). And it should be blindingly obvious that having Verisign near the center of the effort to implement DNSSEC is a potential conflict of interest. For example, Wikipedia says that Verisign ran the NSEC3 DNSSEC Pilot (http://en.wikipedia.org/wiki/NSEC3#Response_and_NSEC3).
|
|||||||||||||