Slashdot Mirror
DNSSEC May Cause Problems On May 5
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.
And the day after star wars day too... We are going to have some seriously bipolar geeks by the time this is all done.
Now you will have an excuse to replace all that crappy old networking equipment "because it does not work with the new secure internet".
Why should my old router not be able to handle a TCP stream to a DNS server? (And whoever configured their firewall to block TCP on port 53 should be shot on the spot.)
In some older networking equipment, any larger request than this would be blocked by pre-configured factory settings
I've never seen equipment that does that per default, am I not old enough or is our stuff not enterprisy enough?
is slashdotted.
I ran the command on the test page and the results are
>>dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"68.87.73.244 DNS reply size limit is at least 490"
"68.87.73.244 lacks EDNS, defaults to 512"
"Tested at 2010-04-30 13:42:26 UTC"
According to the test page this seems to mean that Comcast doesn't support EDSL (at the moment). So the big question is:
What can I do - aside from praying that Comcast will get their shit together by next week?
I am Slashdot. Are you Slashdot as well?
This should force any and all companies or ISPs to upgrade (read MAINTAIN) their systems. Too many organizations install systems and them let them rot expecting them to run forever without so much as a thought or care for maintenance. This problem extends to the point that some companies have a system so long and have no documentation on it, that when there is a problem, they have NO knowledge of the system. I'm glad we are finally implementing some form of security DNS. Let this expose the any problems or issues smaller companies/ISPs have. It will force them to actually do something about it. Hopefully that in turn will make them look at other systems/processes within their organization.
At work, using my ISP's DNS, I'm getting a timeout.
At home, using Google's DNS, I'm getting a blank string back.
Those 2 aren't even covered by the linked page. Any idea what they mean?
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
dig +short rs.dns-oarc.net txt now returns absolutely nothing.. on IPv4. The IPv6 one still works.
So the test they list requires a CLI on a Linux or Unix machine of some sort?
I don't have one available where I am. How can I test using Windows?
This is with a stock dnscache from djbdns-1.05:
[muks@misha ~]$ dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"178.63.21.2 DNS reply size limit is at least 490"
"178.63.21.2 lacks EDNS, defaults to 512"
"Tested at 2010-04-30 13:41:05 UTC"
This seems to say dnscache lacks EDNS. Can anyone with more knowledge of DNS comment whether djbdns is affected?
Banu
Read Chris Griffin's of Comcast's response in the DSLReports thread on this topic
^^^^^^^^^^^^^^^^^^^^
I'll bet he catches hell over his name a lot.
Not sure how accurate it is, but there is a Java-based test located at http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues
Not everyone runs Windows^Wa DNS cache, you insensitive clod!
I want to delete my account but Slashdot doesn't allow it.
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
Oh, and kudos to kdawson for continuing the streak of truly shitacular articles. Well done!
Netalyzr 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.
Test your net with Netalyzr
DJBDNS doesn't request DNSSEC data, so it will see the same thing it always has.
In fact, it doesn't do EDNS at all, so it can't accept any DNS response (regardless of the reason) over 512B in size.
Test your net with Netalyzr
Just as logn as CSN CHI and Directv and or comcast / vs are not messed up.
Then people in Chicago will not care that the internet net is down for some time!
I realize that tinydns and dnscache will work just as they always have so long as the other servers still continue to support non-DNSSEC requests.
Is it likely that at some point the root servers or common resolvers will be DNSSEC only?
Go green: turn off your refrigerator.
We can celebrate Sync-o de Mayo!
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Does DNSSEC mean that an ISP with a caching DNS server that returns an IP address other than the correct IP address cant do it anymore (i.e. clients that support DNSSEC will respond with an error)?
Does DNSSEC do anything about NXDOMAIN fiddling? (are there any proposals out there that would allow users to get around ISPs that point NXDOMAIN at ad-laden ISP search pages or is using a non-ISP caching DNS server the only option here?)
Will airplanes fall out of the sky? ~:-)B
...to celebrate the day DNSSEC went live :P
"When information is power, privacy is freedom" - Jah-Wren Ryel
I can't really believe the entities behind the root DNS servers would haphazardly throw the switch without some sort of contingency for the DNS requests that aren't DNSSEC-based.
*adds playboy.com to /etc/hosts, just in case...*
There's a 68.71% chance you're right.
see subj
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. ;)
"I turn away with fright and horror from the lamentable evil of functions which do not have derivatives."
So uh, are there any KISS guides for kernel modules, config file edits, etc, needed for DNSEC to work?
disone# dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
disone#
When I followed the command to specifiy a buffersize, I received the following.
disone# dig +bufsize=1024 rs.dns-oarc.net txt
; > DiG 9.6.1-P1 > +bufsize=1024 rs.dns-oarc.net txt ;; global options: +cmd ;; Got answer: ;; ->>HEADERhttps://www.dns-oarc.net/oarc/services/replysizetest
???
By receiving a reply, without warnings about the size of the buffer. Does that indicate it worked?
Anonymous comments are as pathetic as the anonymous "sources" that contaminate gutless journalism from the New York Time
disone# dig +bufsize=1024 rs.dns-oarc.net txt
; > DiG 9.6.1-P1 > +bufsize=1024 rs.dns-oarc.net txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER- opcode: QUERY, status: SERVFAIL, id: 1322 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ;; QUESTION SECTION: ;rs.dns-oarc.net. IN TXT ;; ANSWER SECTION: ;; Query time: 1031 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Fri Apr 30 12:18:28 2010 ;; MSG SIZE rcvd: 67
; EDNS: version: 0, flags:; udp: 4096
rs.dns-oarc.net. 49 IN CNAME rst.x476.rs.dns-oarc.net.
disone#
Anonymous comments are as pathetic as the anonymous "sources" that contaminate gutless journalism from the New York Time
Grab a copy of the DNS namespace and load it into /etc/hosts.
Have gnu, will travel.
To re-enable: dnscmd /Config /EnableEDnsProbes 1
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
Yes, DNSSEC can detect false IP information and prevent spoofed NXDOMAIN responses, but only if the domain you're querying and all of its parent domains are DNSSEC signed.
We have Adonis 1750 BlueCats at our door step. Are they up to snuff they eat encrypted jumbo sized UDP 4096 bit extended DNS packets for breakfast.
No way, I'll just download a firmware update .. ..
Oh wait
Hey don't blame me, IANAB
.SE has had DNSSEC deployed for almost five years now. We should have found most bug by now...
DNS clients that request Authenticated Data will be able to detect that the response is not authentic. So it depends on how the DNS client handles that situation.
Possibly the ISP could fake there being no DNS servers supporting DNSSEC available and convince the client to accept the un-signed version. I suspect that turning on DNSSEC on all the root servers is specifically designed to stop this though.
It is generally not made clear that problems are only to be expected for those users behind DNS resolvers that ask 'DNSSEC OK=1' questions by default.
Such 'do=1' default behaviour was enabled in BIND, most likely in an effort to 'make the world safe for DNSSEC'. Even though no further DNSSEC processing is performed by default.
Other implementations, like PowerDNS & DJBDNS, do not wantonly ask 'DNSSEC OK=1' questions. This means that for these (and other) resolvers, on May 5th nothing will happen.
The 'testing' sites linked do not clarify if you are behind a resolver that asks 'do=0' or 'do=1' questions, and may thus lead to needless worry.
Cheers,
Bert - PowerDNS.
The root will use DNSSEC ? So what ? It does not change a thing for anybody not wanting to take advantage of it.
_ one has to explicitely ask for the DNSSEC information to get it (it's a flag). Otherwise it's just a few more unused, somewhat heavy, records on the root zone files.
_ there are not a lot of TLDs using DNSSEC. Granted there is at least one (.se) and probably some are ready to unroll it too but it will not be done in a day.
When more TLDs, registrars and registrants will be DNSSEC compliant and when the end user will switch to this then only we will be able to really feel the increase in bandwidth.
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
Nothing at all, because you would need a DNS-client which asks for DNSSEC-extension information and actually check it, which most don't.
New things are always on the horizon
The question was WHY is it FUD, not what is FUD. Be a nice boy and fuck off.
i'm late to this party, but what has been the response to questions concerning this "FIX" will enable government agencies to backdoor any computer that it wants to?