Root DNS Zone Now DNSSEC Signed

← Back to Stories (view on slashdot.org)

Root DNS Zone Now DNSSEC Signed

Posted by timothy on Friday July 16, 2010 @02:40PM from the signing-of-the-times dept.

r00tyroot writes with news that slipped by yesterday, quoting from the Internet Systems Consortium's release: "ISC joined other key participants of the Internet technical community in celebrating the achievement of a significant milestone for the Domain Name System today as the root zone was digitally signed for the first time. This marked the deployment of the DNS Security Extensions (DNSSEC) at the top level of the DNS hierarchy and ushers the way forward for further roll-out of DNSSEC in the top level domains and DNS Service Providers."

94 comments

Min score:

Reason:

Sort:

Great! by Anonymous Coward · 2010-07-16 14:52 · Score: 1, Insightful

Can those of us who run our own dns servers flip a switch and start using this now?
1. Re:Great! by BitZtream · 2010-07-17 04:39 · Score: 1
  
  Technically, you could have flipped the switch and started taking advantage of others using DNSSEC, though at a lower, nearly useless trust level, years ago.
  This just ups the trust level to something actually useful.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
2. Re:Great! by Athanasius · 2010-07-17 07:14 · Score: 2, Insightful
  
  That depends on if the registry for your TLD supports DNSSEC. There has to be a chain of trust all the way down from the root nameservers to yours. .ORG does support DNSSEC now.
  I'm currently trying to find a registrar that definitely has DNSSEC support in their web management interface for .ORG domains. GoDaddy looks like a good bet on this point, but I'd also like IPv6 glue support (i.e. so I can create a new A record with an IPv6 address and then also set that as an NS record and have that data in the .ORG nameservers as glue for my domain).
3. Re:Great! by penguin359 · 2010-07-17 08:56 · Score: 1
  
  GoDaddy has both DNSSEC and AAAA glue for IPv6 for the .ORG domains. pir.org has a list of registrars supporting DNSSEC for .ORG.
4. Re:Great! by Athanasius · 2010-07-17 09:09 · Score: 1
  
  I should have mentioned I started with the pir.org list. Most of the registrars listed there have awful websites that fail to mention anything about either service.
  Also many of them seem to be 'mere' resellers using the same software package for the website. They even have identical FAQ and Support pages!
  Thanks for confirming godaddy have full support for both features. Unless I hear something bad about them that puts me off, or something awesome about another registrar, I think I'll be transferring to them when there's about a month left to expiry.
5. Re:Great! by penguin359 · 2010-07-17 13:54 · Score: 2, Interesting
  
  Actually, you can't transfer a domain when it's close (~30 days I think) to expiring to avoid it expiring mid-tranfer. You shouldn't not loose any time off of the original registration. It should just extend it so it's probably better to transfer now. Check on the rules for that from both registrars.
6. Re:Great! by Athanasius · 2010-07-17 20:24 · Score: 1
  
  All I'd been reading so far was no transfers for X days after a new registration or expiry. But I'll check and make sure, thanks.
  I'll also mention that name.com also support both DNSSEC and IPv6 Glue now. They've only done so for a week and haven't yet updated their FAQs. I'd even read the TheRegister article about this just last week!
7. Re:Great! by Lennie · 2010-07-18 08:53 · Score: 2, Informative
  
  But .org does not have a full trust-chain setup from the root yet.
  Only these have a full chain right now:
  bg br cat cz na tm uk
  org and gov, se and others may be signed, but the root does not have 'ds'-records yet for those tld's.
  
  --
  New things are always on the horizon
subdomin? by Anonymous Coward · 2010-07-16 15:11 · Score: 0

So now I just have to ask verisign for the subdomain certification, mitm pwn the root right
Software development like the good old days... by Anonymous Coward · 2010-07-16 15:23 · Score: 5, Insightful

“ISC has been intimately involved with the development of DNSSEC for more than fourteen years..." "Today's milestone marked the final step in a seven month process of evaluation and incremental deployment, assuring operational readiness of systems, software, and processes necessary for any significant change to the DNS root."
Just like the good old days. Not like the Rapid Application Development that pushes crap out the door that goes obsolete before all the bugs are fixed. I miss those days.
1. Re:Software development like the good old days... by ergrthjuyt · 2010-07-16 16:36 · Score: 1, Insightful
  
  Rapid application development has its place. The point is to iterate quickly and have short milestones, it doesn't have anything to do with "shove stuff out the door and stop maintaining it."
  
  That said, the majority of software projects, in my experience, would be much better off adopting a more waterfall-like development model rather than that agile crap or whatever the latest buzzword is. Obviously a system designed that affects the entire fricken internet is one such example.
2. Re:Software development like the good old days... by mcrbids · 2010-07-16 19:58 · Score: 3, Insightful
  
  Things have changed, a bit. The once radical idea of domain names have become so infrastructural that the failure of the DNS system would cause a DOS attack on the global economy. Basically, there probably isn't a single system that is more critical to the global economy than DNS except perhaps the IMF.
  So, 7 months to roll out... pretty aggressive, if you ask me! I can't imagine the pressure that people in these positions actually have to endure...
  
  --
  I have no problem with your religion until you decide it's reason to deprive others of the truth.
3. Re:Software development like the good old days... by moonbender · 2010-07-16 23:04 · Score: 2, Interesting
  
  I wonder whether you're right.
  What kind of services rely on DNS? Web and email communication, obviously, but would voice communication either via cell phones or landlines break down? I suppose much of the voice traffic is routed over the same physical backbone as the Internet, but does it share the same server infrastructure including DNS? What about bank transactions? Are companies smart enough to handle internal communication (even if it touches the net) in a way that would work without DNS? Or would my toilet refuse working without DNS?
  Also: considering the distributed, caching nature of DNS, how long would it take for a problem in the root zone to affect people? (Wasn't there a root zone incident a short while back?) Would that give people enough time to revert a botched rollout?
  
  --
  Switch back to Slashdot's D1 system.
4. Re:Software development like the good old days... by phyrexianshaw.ca · 2010-07-17 00:56 · Score: 4, Insightful
  
  though your toilet may continue to work without DNS being there, the company that keeps your water flowing would likely slow to a crawl if they were unable to e-mail/call the partners they do business with.
  
  Voip servers, when calling other voip servers, will make DNS lookups to get IP's to establish such calls, though anything that's done over the PSTN just goes through the phone companies version of DNS, the CO.
  
  E-mail would fall apart inside the TTL of the cache entries. web browsing would quickly deteriorate, most debit machines that I've installed are hand coded with Static IP's, though most ABM's were DNS names. (because the service cost for ABM's is much higher than just leading the business owner/tech through changing IP's on a terminal over the phone)
  
  However, as the DNS system follows the CO ideology, the ISP's all along the way would have the simple ability to just switch away from the CO stored root zone, and only provide certain names resolvability. this would allow ISP's the ability to offer "services like Google! something not all providers are able to say!" as a promo, attracting people that don't know better.
  
  in my city, the vast majority of DNS names for city locations/devices are internal names anyways. none of them are accessible via the root zone. to systems like these the aforementioned changes would make no difference in the world.
5. Re:Software development like the good old days... by FoolishOwl · 2010-07-18 07:55 · Score: 1
  
  With the transition to IPv6, I think DNS is going to become even more important. You can memorize and type IPv4 addresses much more easily than IPv6 addresses.
OS Support by dandart · 2010-07-16 15:26 · Score: 1

Are there any OSes that don't support this? (e.g. really old?) Also, first post? :P Possibly.
1. Re:OS Support by Anonymous Coward · 2010-07-16 15:50 · Score: 4, Informative
  
  DNSSEC is generally optional. You can now speak DNSSEC to your local DNS server and now it can stay DNSSEC all the way to the root domain (assuming there are no breaks). Prior to this you could authenticate your own DNS server's response, but you were never sure that it was talking to the right person. If you send a standard DNSSEC request out it will respond in a standard, albeit insecure, way. DNSSEC's sole purpose in life is to prevent DNS hijacking.
2. Re:OS Support by TheRaven64 · 2010-07-16 20:36 · Score: 2, Interesting
  
  A better question is whether there is any portable API for accessing this information. When I call getaddrinfo(), can I tell whether a particular address is DNSSEC-signed? OpenBSD has a flag for this, but is it going to be standardised? Do other platforms have anything equivalent? If it is using DNSSEC, can I also check easily if there is an IPSECKEY record and establish an IPsec connection using it if there is?
  
  --
  I am TheRaven on Soylent News
3. Re:OS Support by Anonymous Coward · 2010-07-17 01:38 · Score: 1, Informative
  
  You can get a plugin for Firefox that does inform you if something is signed and validated, signed and not validated and signed and broken. But you need a caching server that does all the checks for you. If you don't have a chain of trust, either through the entire chain . -> com -> domain -> www or a Parent/Child lookup, DNSSEC doesn't provide any verification of the results.
  DNSSEC Validator is the name of the add-on.
For the rest of us... by oldhack · 2010-07-16 15:38 · Score: 2, Interesting

What do we need to do on our side, the DNS client side?

--
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
1. Re:For the rest of us... by Anonymous Coward · 2010-07-16 15:42 · Score: 2, Insightful
  
  Clients should really never be pointing to the root servers directly, so nothing.
2. Re:For the rest of us... by dattaway · 2010-07-16 16:08 · Score: 1
  
  What would you recommend if your ISP has a seriously slow DNS server?
3. Re:For the rest of us... by h4rr4r · 2010-07-16 16:11 · Score: 3, Informative
  
  8.8.8.8 or another dns provider. Clients should not talk to the roots. That or setup your own DNS server.
4. Re:For the rest of us... by Phroggy · 2010-07-16 16:15 · Score: 1
  
  8.8.8.8 and 8.8.4.4
  
  --
  $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
  $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
5. Re:For the rest of us... by Manfre · 2010-07-16 17:03 · Score: 1, Informative
  
  http://code.google.com/speed/public-dns/faq.html#sla
6. Re:For the rest of us... by Hes+Nikke · 2010-07-16 17:24 · Score: 4, Informative
  
  here is a tool that lets you figure out which are the best DNS servers to use for your internet connection.
  
  --
  Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
7. Re:For the rest of us... by Glorat · 2010-07-16 19:58 · Score: 1
  
  And what should DNS clients do if you're staying in a country with an ISP where many DNS requests are getting poisoned? (Including those to 8.8.4.4 and root servers)
  The obvious thing would be to set up a local recursive bind forwarder to forward to dnssec signed servers, that either is or are children of the root. But I've never done that before
8. Re:For the rest of us... by LoadWB · 2010-07-16 20:37 · Score: 1
  
  That is a thought, actually. How would this affect DNS queries regime-mangled in oppressive countries...
9. Re:For the rest of us... by gmack · 2010-07-16 22:21 · Score: 1
  
  I imagine they would block anything other than the government's approved nameservers.
10. Re:For the rest of us... by maxwell+demon · 2010-07-16 23:40 · Score: 1
  
  Then Google gets all your DNS queries, too. Don't be surprised if one day you get targeted ads based on which DNS queries were done from your IP. Well, maybe you shouldn't have clicked on that goatse link anyway ... :-)
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
11. Re:For the rest of us... by Anonymous Coward · 2010-07-16 23:43 · Score: 1, Informative
  
  That is not generally true. Clients should not configure root servers as one of their recursive resolvers. There's nothing wrong with using root servers as non-recursive resolvers though.
  I recommend running Unbound locally. Unbound is a small recursive resolver which validates records with DNSSEC. You can run it as a service on your Windows machine and point your "DNS" to 127.0.0.1. This way your computer does all the cryptographic checking. It will talk to the root servers directly, but only infrequently (thanks to caching) and only for a few records (the name servers of the top level domains).
12. Re:For the rest of us... by phyrexianshaw.ca · 2010-07-17 01:02 · Score: 2, Funny
  
  and good for them.
  
  at least they'll do something with that data, rather than let it sit in a log somewhere never to be looked at!
13. Re:For the rest of us... by mrtumnus · 2010-07-17 03:11 · Score: 1
  
  http://www.opendns.com/ Pretty simple DNS service, which I've used for a while.
14. Re:For the rest of us... by Glorat · 2010-07-17 03:14 · Score: 1
  
  They poison *all* DNS requests to any DNS server and return a random IP address for sites like twitter. This is precisely the type of thing that DNSSEC should help with (if only people knew how to set it up... it shouldn't be that hard)
15. Re:For the rest of us... by BitZtream · 2010-07-17 04:43 · Score: 1
  
  Also like to meantion namebench, which will recommend the best DNS servers to use for you, as well as tell you all the sites that are pulling tricks like www hijacking or google.com hijacking (al la opendns).
  http://code.google.com/p/namebench/
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
16. Re:For the rest of us... by BitZtream · 2010-07-17 04:49 · Score: 2, Informative
  
  Yea, opendns is awesome if you like the fact that they hijack www.google.com and direct it to their own servers.
  Come to think of it, no, OpenDNS has never really been awesome, its just been better than absolute shit.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
17. Re:For the rest of us... by gmack · 2010-07-17 07:45 · Score: 1
  
  Right and now they can just block anything with DNSSEC enabled.
18. Re:For the rest of us... by Glorat · 2010-07-17 13:15 · Score: 1
  
  Of course they *can* easily block DNSSEC. They can also easily block OpenVPN and other such things but they are choosing not too for now. But while they are not, wouldn't it sure be good to make use of this new standard?
19. Re:For the rest of us... by gmack · 2010-07-17 17:38 · Score: 1
  
  I guess it depends on the country. The country that my friends are working in already blocks VPN.
20. Re:For the rest of us... by FoolishOwl · 2010-07-18 07:58 · Score: 1
  
  OpenDNS has been quite negative about DNSSEC, which is understandable, considering that the hijacking they do is exactly what DNSSEC is supposed to inhibit.
Too complicated: designed by ISC for ISC? by Anonymous Coward · 2010-07-16 15:54 · Score: 1, Interesting

DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
It seems to me that DNSSEC was "designed by ISC for ISC" in the sense that the only people who have the time, resources and willpower to setup Bind/DNSSEC correctly are running the root nameservers. However I would have thought the interface between users and multitudes of privately operated nameservers would be the most critical aspect of securing DNS. If administrators of authoritative and caching nameservers (ranging in size from small companies through to technology giants and ISPs) are unable to correctly setup DNSSEC because it is too complex, what have you gained? A poorly configured implementation of DNSSEC could be less secure on the basis that you have more lines of code containing bugs and more configuration options to get wrong.
When I read about DNSCurve it seems much simpler in achieving similar goals.
So my question is, does DNSSEC really have to appear so complicated? How do they expect nameserver administrators to properly configure their complex DNSSEC-enabled name servers?
1. Re:Too complicated: designed by ISC for ISC? by h4rr4r · 2010-07-16 16:14 · Score: 3, Interesting
  
  http://blog.techscrawl.com/2009/01/13/enabling-dnssec-on-bind/
  Looks pretty easy at least as easy as setting up bind and a few zones.
2. Re:Too complicated: designed by ISC for ISC? by X.25 · 2010-07-16 17:25 · Score: 0, Flamebait
  
  DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
  Nothing stops you from releasing your own solution for the problem.
  Ah, I see. It's easier to whine.
3. Re:Too complicated: designed by ISC for ISC? by jd · 2010-07-16 18:20 · Score: 1
  
  DNSSEC doesn't need to be complex at all. Basically, any secure communications system of this kind must have a mechanism for authenticating whatever provides the service, authenticating (if/as necessary) the recipients of that service, both encrypting and tamper-proofing both the request and the result, and (where necessary) limiting queries to those authorized for that recipient.
  There are plenty of authentication mechanisms out there (Kerberos, SASL, SSL, TLS, S/Key) - some for the server, some for the client, some for both. None of them are rocket-science to set up. Thus, it can be definitively said that any secure channel requiring a more complex setup than the worst of the standard mechanisms out there is far more complex than necessary.
  Encryption is definitely a non-issue. For the initial asymmetric key exchange, use one of the standard algorithms. If you insist on avoiding writing code, make a call to IPSEC's IKEv2 facility. Ok, what then? This is a rapid-fire system so there is probably no need to go to the lengths of producing a symmetric key then exchanging that using the asymmetric one. Just use the appropriate asymmetric encryption algorithm to encrypt the request and then to encrypt the response. To provide tamper-proofing, since asymmetric encryption algorithms are generally block encryption, use OMAC for the encryption mode. No configuration is required for any of this. Where DNS-to-DNS tunnels need to be maintained, packets should be encrypted using a regular block cypher with the keys exchanged via the asymmetric mechanism. To provide the switch between the two modes (sporadic or tunnel), you need exactly one flag. Not hard. And the security implications of an incorrect setting are nil. It'll pessimize performance a little but that's it.
  This leaves restricting responses. If the original request includes mandatory access control information then that requestor gets access to all public records plus all records in all roles the requestor's access control information authorizes. If there is no MAC information, the requestor only has access to public records. The only servers this would have any meaning for would be those which sit on the boundary of two networks where the servers need to know about both networks AND allow limited visibility from one into the other. In short, practically none. Almost nobody for whom it matters sets up DNS that way. Besides which, hiding the name doesn't hide the server. Hiding the name only stops you from trivially discovering a few things about the topology on the other side of the wall. If you want the information hidden that bad, put it on a different server and not one in plain sight. However, on the off-chance such a facility is necessary, let's consider what it would take. Each non-public record set and each non-public record would need to specify which combinations of permissions would be necessary to access that information. Each requestor would need to be registered on that server with what permissions they had. The server would check those permissions against the record set and then against the record being accessed. 998 times out of the entire 1000 cases worldwide this could possibly ever happen in, all authorized users can access all records. In which case, if the user is registered, they have access. So your setup becomes a username/password table. That's it. The system one should do fine. In the 999th case, a simple bitmask should suffice. For the 1000th case, you would want to have the thread that handled the request chown() itself to the requestor's account, then use the built-in access control system for the OS and/or the database to handle record set and record access controls.
  Even in the very very worst, unimaginably horrific scenario imaginable, where you have to have something with each and every one of these features to the limit, configuration of a bi-directionally authenticated connection between two servers should involve a couple of certificates, a couple of digital signatures, the setting of a single bit field on each
  
  --
  It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
4. Re:Too complicated: designed by ISC for ISC? by TheRaven64 · 2010-07-16 20:38 · Score: 3, Insightful
  
  DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
  Given that the DNS protocol is about the simplest protocol currently deployed on the Internet, and yet has managed to scale to the insane degree demanded of it, I can't help think that this implies that you have absolutely no idea what you are talking about.
  
  --
  I am TheRaven on Soylent News
5. Re:Too complicated: designed by ISC for ISC? by Ginger+Unicorn · 2010-07-16 22:12 · Score: 1
  
  how does the arms race to break DRM compare to what i imagine would be an arms race to break DNS? Will DNSSEC be like HDDVD/bluray encryption? Loads of effort for a temporary advantage?
  
  --
  (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
6. Re:Too complicated: designed by ISC for ISC? by Anonymous Coward · 2010-07-17 00:26 · Score: 0
  
  Simple protocols usually scale quite naturally. It's the more complex ones that run into all sorts of problems.
7. Re:Too complicated: designed by ISC for ISC? by XanC · 2010-07-17 01:14 · Score: 2, Insightful
  
  No, with normal encryption like this, you're trying to make sure that only the other party can decrypt and read your communication.
  What kills DRM is the attempt to allow the other party to read, but not decrypt, the communication. This is obviously silly.
8. Re:Too complicated: designed by ISC for ISC? by supradave · 2010-07-17 01:48 · Score: 1
  
  Since you are dealing with public-key cryptography, your private keys have to be maintained as private. That's not so difficult if you have a machine that's not connected to the Internet. If your private key-signing key got out, your signatures could easily be compromised. Then you sneeker-net the zone-signing keys over and sign your zones. Not too difficult if you follow the NIST 140 page manual.
  Of course, a machine that could do all the work for you would be what's best.
9. Re:Too complicated: designed by ISC for ISC? by PybusJ · 2010-07-17 02:30 · Score: 2, Informative
  
  DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).
  ...
  When I read about DNSCurve it seems much simpler in achieving similar goals.
  I read comments like this quite regularly. Actually, DNSCurve does something pretty different from DNSSEC.
  DNSCurve encrypts communication between DNS clients and servers (or between DNS servers). Like with HTTPS or IMAPS, this means someone between you and your DNS provider can't see what you're looking up, or MITM you to change results.
  But DNSCurve does nothing to guarantee you're getting a good answer. You have to trust your DNS provider: both that they are trustworthy and that they have their server secured properly. You also have to trust any recursive DNS lookups your provider does and each of their intentions and configurations.
  DNSSEC, on the other hand, signs the records that you're returned (like PGP signed emails) but it doesn't encrypt the traffic. Someone could still snoop on your DNS traffic and see what you're looking up, but with the hierarchical set of signed records no-one except the authoritative name server can change the answer. Not your DNS provider nor any other resolvers they depend on.
  It's the difference between getting your email over IMAPS and having it PGP signed -- you don't need to trust every intermediary. Yet I don't see anyone saying, "since we can now to SMTP and IMAP over SSL we don't need PGP or SMIME."
  You could certainly use both: DNSCurve to provide encryption, so that no-one but your DNS provider knows what you're looking up, and DNSSEC so you know it is actually a valid record.
10. Re:Too complicated: designed by ISC for ISC? by BitZtream · 2010-07-17 04:56 · Score: 0, Troll
  
  Being overly complex doesn't prevent something from working and scaling, neither does being less complex.
  Being overly complex does not preclude functioning properly, it just means that its possible that it would still function properly if it were less complex.
  DNS and DNSSEC ARE overly complicated for 99.99999% of what it gets used for on a regular basis, the fact that you don't recognize that tells me you really don't have any idea what you're talking about.
  
  --
  Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
11. Re:Too complicated: designed by ISC for ISC? by KonoWatakushi · 2010-07-17 07:32 · Score: 1
  
  Is that supposed to be a joke? Like the DNSSEC in 6 minutes presentation?
  That also glosses over the key rotation issue, which must be addressed, or your DNS will self-destruct.
Huh by AfroTrance · 2010-07-16 16:01 · Score: 2, Funny

Can we still root outside the zone? I haven't had a root in a while, but there's always the possibility.
1. Re:Huh by sherpajohn · 2010-07-16 16:23 · Score: 1
  
  As long as you are not rooting for the wrong team, I don't see why not.
  
  --
  
  Going on means going far
  Going far means returning
What should DNS server administrators do? by Phroggy · 2010-07-16 16:23 · Score: 1

What should DNS server administrators do to sign our own domains, and configure our servers to pay attention to DNSSEC when performing lookups?
I learned how to configure BIND a decade ago, and it's mostly just been smooth sailing since then. I have no idea what's involved in setting up DNSSEC, whether it's something I can figure out how to enable in 20 minutes or a huge project that really won't be feasible for me to undertake at all. Can somebody point me in the right direction?

--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
1. Re:What should DNS server administrators do? by darkpixel2k · 2010-07-16 16:28 · Score: 3, Funny
  
  What should DNS server administrators do to sign our own domains, and configure our servers to pay attention to DNSSEC when performing lookups?
  I learned how to configure BIND a decade ago, and it's mostly just been smooth sailing since then. I have no idea what's involved in setting up DNSSEC, whether it's something I can figure out how to enable in 20 minutes or a huge project that really won't be feasible for me to undertake at all. Can somebody point me in the right direction?
  It's apparently been over a decade since you've tried to look up information on the internet too. We no longer use gopher. There's this new thing called HTTP and WWW. There's also an upstart new search engine company that'll probably die out in a few years--but you can use them here.
  
  ;)
  
  --
  There's no place like ::1 (I've completed my transition to IPv6)
2. Re:What should DNS server administrators do? by h4rr4r · 2010-07-16 16:39 · Score: 1, Informative
  
  http://blog.techscrawl.com/2009/01/13/enabling-dnssec-on-bind/
  Next time you have a question like this you might want to try this new thing called google. It is just amazing.
3. Re:What should DNS server administrators do? by Anonymous Coward · 2010-07-16 19:02 · Score: 0
  
  Read the Howto:
  https://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers
4. Re:What should DNS server administrators do? by mcrbids · 2010-07-16 19:54 · Score: 5, Funny
  
  What is this gopher thing you write about?
  Is it newer than telnet?
  
  --
  I have no problem with your religion until you decide it's reason to deprive others of the truth.
5. Re:What should DNS server administrators do? by Anonymous Coward · 2010-07-16 23:54 · Score: 0
  
  It's sweet you're trying to help, but that article does NOT explain how to enable it for the root-zone.
6. Re:What should DNS server administrators do? by Aero · 2010-07-17 01:12 · Score: 1
  
  Configuration is relatively easy if all you've got is a couple of zones. Maintenance is what takes work. You don't just turn a switch on and let things go on their own.
  Keys expire and need to be rolled over. Signatures expire even more often and need to be refreshed. Your TLD registrar needs to have a robust mechanism for establishing and maintaining the trust chain. And it can all go to hell in an instant if someone's behind a router that is filtering EDNS, or TCP DNS queries, or truncating DNS packets, or doing anything else that speaks of assuming that anything DNS-related that isn't less than 576 bytes over 53/UDP is Evil And Must Be Destroyed.
  There are plenty of tools out there for doing this all relatively painlessly, but it takes diligence and a higher level of meticulousness than most sysadmin tasks. On the other hand, for small setups, it's no worse than keeping an eye on your logs for interesting activity.
  (For the record, I built my workplace's DNSSEC implementation in about 3 weeks, and got it 90% right before I had to go help my wife give birth. But we have dozens of zones, with subdomains, and multiple field offices running their own masters, so we had to deal with TSIG-signed zone transfers with external entities in addition to our primary master. And now that we've got it turned on, we get at least one report a week of someone having issues getting to one of our sites because of said upstream routers that are messing with DNSSEC queries.)
  
  --
  We can believe in you for 3 minutes, but beyond that, even the King of All Cosmos can't be expected to wait.
7. Re:What should DNS server administrators do? by Hurricane78 · 2010-07-17 15:59 · Score: 1
  
  I’s a variation of the badger meme, grandpa. Now get back to your rocking chair on the porch! You know you can’t surf the open net with your weak heart!
  
  --
  Any sufficiently advanced intelligence is indistinguishable from stupidity.
Say goodbye to... by valeo.de · 2010-07-16 18:11 · Score: 2, Insightful

...UDP-based DNS queries.

--
cat: /home/valeo/.sig: No such file or directory
1. Re:Say goodbye to... by Anonymous Coward · 2010-07-16 19:18 · Score: 1
  
  I never really understood the reason for this. What I mean is, in the DNS RFC, if the request exceeds (or is equal?) to 512 bytes, it then decides to use TCP instead of UDP. Fair enough. But why 512 bytes? Why can't we go all the way up to at least 1500 bytes? (the size of an ethernet frame). Or beyond? I suppose it comes down to packet fragmentation issues but still, at least 1024 bytes should be fine.
  I suppose this 'stupid' 512 byte limit was designed in the early days of the internet, when it was a munge of different 'older' networks munged together. Maybe somewhere between them all, 512 was a guaranteed upper bound for no packet fragmentation (or something), If any one does know the real reason for this, I'd love to know.
2. Re:Say goodbye to... by TheRaven64 · 2010-07-16 20:43 · Score: 3, Informative
  
  The Internet is not an Ethernet network. The Internet Protocol guarantees that datagrams under 576 bytes (including packet header) are not fragmented, but a 1500 byte Ethernet frame still will be. You don't find Ethernet anywhere other than the edges of the Internet. The backbones still use a variety of other standards.
  Fragmentation is a problem for a UDP-based protocol, which is why pretty much any UDP-based protocol tells you not to use packets bigger than the network MTU (1500 bytes for Ethernet, 576 for the Internet).
  
  --
  I am TheRaven on Soylent News
3. Re:Say goodbye to... by Anonymous Coward · 2010-07-17 00:03 · Score: 2, Insightful
  
  You'll find Ethernet everywhere. Most ISPs use 10GE and 40GE Links for long haul.
  And the IXes also use Ethernet for connections.
  Really, there are fewer uses of non-Ethernet connections every day.
4. Re:Say goodbye to... by jesset77 · 2010-07-17 10:37 · Score: 1
  
  I'unno, I just look forward to IPv6's builtin MTU discovery. 8I
  
  --
  People willing to trade their freedom of expression for temporary entertainment deserve neither and will lose both.
5. Re:Say goodbye to... by Anonymous Coward · 2010-07-17 10:50 · Score: 1, Informative
  
  Thanks for the explanation. Interestingly, I noticed an exception to this 512 byte size limit - the 'unbound' resolver daemon. I run this on my LAN and from what I can see, it seems to ignore this 512 limit and continues to do full UDP lookups against the root name servers, which are still happy to serve a valid reply to this (here is a full tcpdump):
  23:37:48.840440 00:18:7d:X:X:X > 00:21:d8:X:X:X, ethertype IPv4 (0x0800), length 70: X.X.X.X.11318 > 192.112.36.4.53: 39632% [1au] ANY? . (28)
  23:37:48.895294 00:21:d8:X:X:X > 00:18:7d:X:X:X, ethertype IPv4 (0x0800), length 1193: 192.112.36.4.53 > X.X.X.X.11318: 39632*-| 7/0/1 SOA[|domain]
  That be a 1193 byte UDP reply packet from G.ROOT-SERVERS.NET then, right? :-)
  Personally, I think the limit is a bit of a farce now. Yes, it may have been needed in the old days, but things have drastically moved on now. However, for all those sysadmins who don't run this resolver, better check your firewalls and make sure TCP outbound port 53 is allowed otherwise you ain't gonna be resolving much.
6. Re:Say goodbye to... by Anonymous Coward · 2010-07-17 11:07 · Score: 0
  
  Thanks for the explanation. However, I've noticed the 'unbound' resolver daemon doesn't follow this rule and continues to do full UDP lookups against the root name servers, which are also very happy to reply with no issues:
  23:37:48.840440 00:18:7d:X:X:X > 00:21:d8:X:X:X, ethertype IPv4 (0x0800), length 70: X.X.X.X.11318 > 192.112.36.4.53: 39632% [1au] ANY? . (28)
  23:37:48.895294 00:21:d8:X:X:X > 00:18:7d:X:X:X, ethertype IPv4 (0x0800), length 1193: 192.112.36.4.53 > X.X.X.X.11318: 39632*-| 7/0/1 SOA[|domain]
  That be a 1193 byte UDP reply from G.ROOT-SERVERS.NET, right?
  For everyone else, better make sure you allow outbound port 53 otherwise you're going to get a lot of broken resolved lookups.
7. Re:Say goodbye to... by wayne · 2010-07-17 11:47 · Score: 3, Informative
  
  The "packets of 576 bytes can't be fragmented" is a commonly stated reason, but it is wrong. It is a myth/misunderstanding. It is, in practice, true has has been true since probably the late 1980s, but DNS was around long before that. Indeed, if you read some of the earlier RFCs, it is quite clear that packets of any size could be fragmented, down to something like 16 bytes of payload per fragment. No,the reason for the 512 byte payload size is much more basic than that. Back in the early 80s, memory was tight, you could have mainframes supporting dozens of users on a machine with maybe 1MB of memory, each of user could have more than one active network connection. IP supports packets sizes up to around 64k, but it would be unreasonable to expect every host to be able to accept such a large packet size. It would mean that they could get fragments from all those packets piecemeal and out of order, so reconstructing each packet would require holding lots of 64k buffers, each of those buffers would be 6% of all available memory. It would be very unreasonable to expect every host on the internet to be able to accept any size packet, even if those packets came in fragment that wouldn't saturate your connection. Now, protocols like TCP have the ability to negotiate the packet size, but for UDP, it gets messy and slow. So, it is a *requirement* that each host on the internet can accept a packet with 512 bytes of payload. That packet can be fragmented, but it has to be accepted.
  
  --
  SPF support for most open source mail servers can be found at libspf2.
8. Re:Say goodbye to... by Lennie · 2010-07-18 10:09 · Score: 1
  
  Please lookup edns0, from 1999. It is was is used right now.
  
  --
  New things are always on the horizon
9. Re:Say goodbye to... by Lennie · 2010-07-18 10:10 · Score: 1
  
  Please lookup edns0, from 1999, this is what solves the 512 limit.
  
  --
  New things are always on the horizon
10. Re:Say goodbye to... by dotwaffle · 2010-07-19 20:59 · Score: 1
  
  IPv4 has MTU discovery as well. RFC1191. Many overly-security-conscious networks block all traffic not officially sanctioned, though, which also hampers correct ICMP replies.
11. Re:Say goodbye to... by jesset77 · 2010-07-19 22:56 · Score: 1
  
  IPv4 has MTU discovery as well. RFC1191. Many overly-security-conscious networks block all traffic not officially sanctioned, though, which also hampers correct ICMP replies.
  Yep, I am very pro-ICMP. But IPv6 actually requires MTU discovery, wherein for present state of affairs it is optional, meaning almost never available. :>
  
  --
  People willing to trade their freedom of expression for temporary entertainment deserve neither and will lose both.
I know none of you care by Anonymous Coward · 2010-07-16 18:23 · Score: 0, Interesting

that the USoA government has broken its promises not to meddle. It's sitting on the keys even if through its shills. Of course, the failure to come through on this "hands on" thing was almost inevitable seeing the last sixty years or so of meddling, failure to live up to treaties, and so on. I'll forgive them this once if they manage to spin off the holding of the keys into something like a council of keyholders, at most 10% of them american citizens, that are to the last member chosen by the internet community, not just governments and certainly not just one government. It doesn't have to be an intrusive council; all they have to do is safeguard the keys. But it won't happen. The USoA likes to meddle too much. Land of the free, bravely pissing on other people's freedom. Ha ha.
1. Re:I know none of you care by Anonymous Coward · 2010-07-17 23:57 · Score: 0
  
  Yeah, so, did you actually read anything about this stuff?
  Did you, for example, watch the KSK ceremony? Do those all look like Americans to you?
  Of course the US government could by force of arms take this over. But that's true of lots of other critical systems. They would be unable to do so secretly, and that destroys the value of it.
great.. by geniusj · 2010-07-16 18:33 · Score: 1

Let loose the public DDoS amplification cannons, aka DNS servers running with dnssec.
One More Error Message For Users To Ignore by mbstone · 2010-07-16 20:00 · Score: 1

Sooner or later it will be common for DNSSEC-enabled servers to have expired keys, and the sysadmin who installed DNSSEC (the only person who knows how to renew the key), will have moved on. At that point Aunt Maude will be surfing the Net and she'll get a popup, "Warning! Zone server key has expired!" (or whatever). Auntie will of course click on "Continue Anyway," because she's seen that popup and bypassed it many times before. Of course, sooner or later Maude will log on to what she thinks is the bank....
1. Re:One More Error Message For Users To Ignore by Anonymous Coward · 2010-07-16 21:17 · Score: 4, Informative
  
  Wrong. A bad signature will make the hostname unresolvable.
2. Re:One More Error Message For Users To Ignore by bsDaemon · 2010-07-17 01:29 · Score: 2, Informative
  
  You know this isn't the type of server that users ever actually /see/ right? Or have you never set up/run a DNS infrastructure before to know what DNSSec is actually for?
3. Re:One More Error Message For Users To Ignore by mbstone · 2010-07-17 12:28 · Score: 0
  
  Damn, I'm always running into people like you at job interviews.
Anyone benchmarked browsing speed impact? by trifish · 2010-07-16 20:07 · Score: 1

The best "benchmark" I've found so far says that there will be "some little" slow down when browsing DNSSEC-enabled websites (in contrast to DNSSEC-disabled ones).
Anyone can englighten us as to what those words "some little" really mean?
By benchmarking it, you'll also help webmasters who are considering deployment of DNSSEC.
1. Re:Anyone benchmarked browsing speed impact? by supradave · 2010-07-17 02:24 · Score: 1
  
  Here are a couple results. As you can see, when you request the signed dol.gov, you get a bigger response, i.e. not UDP, but TCP.
  dig @x.x.x.x www.dol.gov
  ; > DiG 9.7.0-P1 > @x.x.x.x www.dol.gov
  ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER> DiG 9.7.0-P1 > +dnssec @x.x.x.x www.dol.gov
  ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: NOERROR, id: 46373 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags: do; udp: 1452 ;; QUESTION SECTION: ;www.dol.gov. IN A ;; ANSWER SECTION:
  www.dol.gov. 889 IN CNAME www.dol.gov.edgekey.net.
  www.dol.gov. 889 IN RRSIG CNAME 7 3 900 20100816030022 20100717030022 50870 dol.gov. l725oDYX1Hyn8KlBxARPtDfB/U4sbuGI/vCF5E23Iy4tANYpU/MY0vZU XgRDpqoVziXSqVw4v9bPGxifzK6e8Sz3Vb3Y0NddidI709YvvblSIKlk cYgvuEcefavrb9oxHfCpy2wewC6m0XDB4sQkaOpbNv6OSxX+ScEhTPrI CZM=
  www.dol.gov.edgekey.net. 21589 IN CNAME e1617.b.akamaiedge.net.
  e1617.b.akamaiedge.net. 9 IN A 96.7.22.185 ;; Query time: 71 msec ;; SERVER: x.x.x.x#53(x.x.x.x) ;; WHEN: Sat Jul 17 08:20:18 2010 ;; MSG SIZE rcvd: 293
2. Re:Anyone benchmarked browsing speed impact? by supradave · 2010-07-17 02:33 · Score: 1
  
  Probably wouldn't switch over to TCP for that response. If the signature were larger though.
  dig @x.x.x.x www.dol.gov
  Results size, 115 bytes
  dig +dnssec @x.x.x.x www.dol.gov
  Results size 293 bytes.
  That's why there could be a perceived slow-down, particularly over a 2400 baud modem.
  Under the flags section, a signed and validated record will have the ad bit set.
  Don't know what happened to the nice formatting above.
3. Re:Anyone benchmarked browsing speed impact? by Anonymous Coward · 2010-07-17 03:21 · Score: 0
  
  UDP is *MUCH* faster than TCP with its handshaking overhead!
  You really should measure the speed of DNSSEC-signed sites (after purging your local DNS caches) and somehow compare it to unsigned. Thanks!
Re: by Anonymous Coward · 2010-07-17 22:25 · Score: 0

If DNS responses are signed, does this make it more awkward to substitute root name servers in the event of an emergency? If it doesn't then what is the point of signing?