DNSSEC May Cause Problems On May 5 132
An anonymous reader notes the coming milestone of May 5, at 17:00 UTC — at this time DNSSEC will be rolled out across all 13 root servers. Some Internet users, especially those inside corporations and behind smaller ISPs, may experience intermittent problems. The reason is that some older networking equipment is preconfigured to block any reply to a DNS request that exceeds 512 bytes in size. DNSSEC replies are typically four times as large. "DNSSEC is in fact already rolled out across most of the world's 13 root servers. ... But to date ... it would only have resulted in a slight lag in the loading of a web page for those with outdated network equipment. The beauty of DNS is that should a request made to one root server not receive a response, the DNS resolver on a user's machine simply makes the same request along the line of the 13 root servers until it gets a satisfactory response. But on May 5, once all 13 root servers are live with the DNSSEC signatures, responses from all 13 root servers won't make it back inside the corporate LAN on some older systems. ... The problem may take several days to surface and be inconsistent from one user's PC to the next. A user at one machine who hasn't switched on his PC for two or three days will have no access to the Internet. A user who left his machine on the night before will have some pages — and responses from DNS servers — cached on his machine, and will still have connectivity." The article links a test site you can use ahead of time to check for any problems.
Already, the test nameserver... (Score:4, Informative)
is slashdotted.
Re:So what do I do? (Score:1, Informative)
This might be the blind leading the blind, but I just tested my (also Comcast) DNS and had the same error, so I switched my router's primary DNS to http://code.google.com/speed/public-dns/
Re:So what do I do? (Score:5, Informative)
Read Chris Griffin's of Comcast's response in the DSLReports thread on this topic: http://www.dslreports.com/shownews/No-DNSSEC-Upgrades-Wont-Break-The-Internet-Next-Week-108154
In short, they don't expect anything to happen on May 5. If you like, and are on Comcast, you can also join the DNSSec trial (I use it at home) by changing to the DNSSec test servers.
DNS server slashdotted (Score:3, Informative)
dig +short rs.dns-oarc.net txt now returns absolutely nothing.. on IPv4. The IPv6 one still works.
Re:So what do I do? (Score:4, Informative)
While Microsoft did included an nslookup command with Windows, it is quite basic compared to the dig utility. Go download dig [members.shaw.ca] for Win32.
Re:No linux or unix.. (Score:2, Informative)
Get dig for windows: http://members.shaw.ca/nicholas.fong/dig/ [members.shaw.ca]
Re:Huh? (Score:5, Informative)
It's not about blocking, it's about limit. DNS requests/replies are by nature very short - there's not much data to be transferred. So you can reliably believe if someone is transferring more than a kilobyte of data per packet on DNS port, they are performing some kind of DoS. You just restrict maximum packet size and everything is dandy. Then a new version of the protocol comes that has more overhead and suddenly valid requests are longer than 1K. Oops.
Things only break in some circumstances... (Score:4, Informative)
This story is a bit sensationalist.
DNS resolution will break if the resolving server claims to support EDNS0 AND requests DNSSEC validation but isn't able to receive large UDP responses. Servers which don't support EDNS0 will fail the tests but will still work perfectly come May 5th
Re:So what do I do? (Score:3, Informative)
Mod parent up, this is just FUD (Score:3, Informative)
Oh, and kudos to kdawson for continuing the streak of truly shitacular articles. Well done!
Netalyzr includes tests for this... (Score:5, Informative)
Netalyzr [berkeley.edu] also checks for this, both for the client and for the DNS resolver, and reports specifically the DNS resolver's status.
The resolver side tests include actual DNS MTU, advertised MTU, EDNS and DNSSEC requseting, whether the resolver can failover to using TCP, and other related issues.
Overall, the "512B" thing is largely a myth, a few resolvers have this problem but most don't. Rather, the big problem is lack of support for fragmented responses, which won't affect deployment from the root but will affect things when zones start getting signed.
For the end system connection, however, the "512B" or "No EDNS" is a bit more common, but still fragmentation is overall a larger issue.
Re:What about djbdns? (Score:4, Informative)
djbdns does lack EDNS, which means you're already screwed if you don't want to fall back to TCP for large responses, e.g., that contain IPv6 glue. Djbdns is no longer maintained by the author and doesn't support EDNS or DNSSEC (regardless of whether Bernstein thinks it is a good idea -- larger answers and DNSSEC _are_ being deployed). It's long past time to put djbdns out of our misery. If for religious reasons you don't like BIND there is unbound (http://unbound.net/) that fully supports the DNS.
Re:DNS server slashdotted (Score:3, Informative)
The IPv6 one is dead now too. A +trace run ends here:
Both the v4 and v6 IP for ns00.rs.dns-oarc.net. are dead, so the whole thing just dies after that.
Re:So what do I do? (Score:3, Informative)
Re:DNS server slashdotted (Score:1, Informative)
Not strange. It's cause comcast is shit and they're giving you their own response so they can redirect you to their pages for non existent hosts.
Re:Be happy (Score:4, Informative)
To use a car analogy, what the GP did was like someone saying "I have a red convertible." Well no duh it's red, that's the only colour they make convertibles! Don't even try to say that non-red cars can be convertibles, everyone knows that all true convertibles are red [wikipedia.org]. There is nothing particularly wrong with pointing out that his convertible is red though, it's just more descriptive for people 'not in the know'.
Cisco PIX is affected (Score:4, Informative)
If you have an old PIX or old firmware (6.3(2) or older) then you will be affected. And if you do, you should just go ahead and upgrade to an ASA at this point. ;)
Re:Cinco de Mayo is now a geek holiday (Score:1, Informative)
DNSSEC will not go live in May. On that date, DNSSEC will be deployed on all root DNS servers, but with deliberately unvalidatable signatures. This is to test exactly for the kinds of problems described in the article before people start relying on DNSSEC. If all goes well, the properly signed root zone is scheduled for July.
Re:Mod parent up, this is just FUD (Score:1, Informative)
Fear, uncertainty, and doubt (FUD)
Re:Huh? (Score:2, Informative)
DNS uses UDP by default. If the response is too big for UDP, then it switches to TCP. The limit for UDP packets used to be 512 bytes but extensions allow the size to be much larger. Old firewalls think that 512-bytes is the limit of DNS over UDP and block any longer packets.