Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security The Internet Technology

DNSSEC May Cause Problems On May 5 132

Posted by kdawson from the packets-available-but-not-to-you dept.
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.
This discussion has been archived. No new comments can be posted.

DNSSEC May Cause Problems On May 5 More

DNSSEC May Cause Problems On May 5

Comments Filter:

  • Jeez, And the day after (Score:4, Funny)

    by coniferous ( 1058330 ) on Friday April 30, 2010 @08:40AM (#32043482) Homepage
    And the day after star wars day too... We are going to have some seriously bipolar geeks by the time this is all done.
    • I really expected someone to go "I think star wars day is on the _____" but nobody ever did... I'm just going to ruin the joke. May the fourth be with you.

  • Be happy (Score:2, Funny)

    by Anonymous Coward

    Now you will have an excuse to replace all that crappy old networking equipment "because it does not work with the new secure internet".

  • Already, the test nameserver... (Score:4, Informative)

    by Crackez ( 605836 ) on Friday April 30, 2010 @08:50AM (#32043572)

    is slashdotted.

  • So what do I do? (Score:5, Interesting)

    by OzPeter ( 195038 ) on Friday April 30, 2010 @08:51AM (#32043576)

    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?

    • Re: (Score:2)

      by OzPeter ( 195038 )
      Oops - I meant EDNS. not EDSL

      And BTW moving off Comcast is not an option.

    • Re: (Score:1, Informative)

      by Anonymous Coward

      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)

      by Anonymous Coward on Friday April 30, 2010 @08:56AM (#32043626)

      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.

      • Re: (Score:2)

        by OzPeter ( 195038 )
        +1 Thanks for that. Now I realised that I just fell for the FUD - although I did find out that my router will have issues with EDNS.

        • I've been using Comcast's DNSSEC test servers for months, without any difficulty. They're leading the pack on implementing DNSSEC. In fact, they're advocating its adoption, even though that means giving up their Comcast Domain Helper service.

          See their DNSSEC Trial FAQs [comcast.net].

          (I had opted out of using Domain Helper anyway, as it's the DNS equivalent of "Clippy" -- help I don't want.)

      • Oh, and kudos to kdawson for continuing the streak of truly shitacular articles. Well done!

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        And according to DSLReports this bogus story started with The Register. Can we please get that tabloid to cover two headed babies and alien abductions instead of IT? It's some of the most irresponsible journalism I've seen since Dvorak's heyday.

    • Re: (Score:1, Interesting)

      by Anonymous Coward
      Can I get those instructions in windows?

      No seriously!

    • Re: (Score:3, Informative)

      by Joehonkie ( 665142 )
      OpenDNS fails this, too. Hopefully they will be quick on fixing it.

      • Re: (Score:2)

        by Lennie ( 16154 )

        They don't support the DNSSEC-extension (and also not EDNS), they do think DNSCurve is a good idea though.

    • 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?

      You can run your own DNS server and use Comcast only as the pipe. Caching DNS servers are particularly easy to run compared to things like mail servers or web servers as they require little or no maintainence once you get them going.

      • Re: (Score:2)

        by jonwil ( 467024 )

        Caching DNS servers also have the advantage that you are immune if your ISP messes with DNS or violates the DNS RFCs (such as by returning something other than NXDOMAIN for a non-existent domain)

        • What makes you think that? If your DNS server doesn't know how to resolve an address it's going to forward to another DNS server, usually your ISPs DNS server in which case they can resolve whatever they want. You'll want a caching service combined with a 3rd party DNS provider that won't hijack your address resolution. That's not particularly hard yet but saying a caching DNS server makes you immune to ISP monkeying is just not true.

    • Re:So what do I do? (Score:4, Funny)

      by Fnord666 ( 889225 ) on Friday April 30, 2010 @11:31AM (#32045798) Journal
      I ran the command on the test page and the results are

      C:\Documents and Settings\root\Desktop>dig +short rs.dns-oarc.net txt
      'dig' is not recognized as an internal or external command,
      operable program or batch file.

      What does that mean?

    • Re: (Score:1)

      by em0te ( 807074 )
      You use comcasts DNS servers, you are down stream from them in a "line". Their DNS servers will be (or have already been) updated to recieve DNSSEC responses, but they will translate and forward regular DNS responses to your cable modem. they can do it. It seems like a good way to force comcast customers be unable to bypass their DNS servers. This way they won't need to update any firmware on the customers end, which will save them man-hours and they can hijack failed DNS responses and display a page wit

  • Upgrade or die (Score:4, Interesting)

    by K2tech ( 1685250 ) on Friday April 30, 2010 @08:52AM (#32043588)
    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.

  • Odd results? (Score:4, Interesting)

    by Aladrin ( 926209 ) on Friday April 30, 2010 @09:05AM (#32043714)

    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?

  • DNS server slashdotted (Score:3, Informative)

    by fialar ( 1545 ) on Friday April 30, 2010 @09:06AM (#32043728)

    dig +short rs.dns-oarc.net txt now returns absolutely nothing.. on IPv4. The IPv6 one still works.

    • Strange... from my work computer, I get a connection timeout. From my Comcast connection at home, I get
      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"

      • Re: (Score:1, Informative)

        by Anonymous Coward

        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.

        • You are right. I posted before my morning coffee. I got connection timeouts from my brain as well. My nameserver is set to Google's though, with OpenDNS as a backup. I wouldn't put it past Comcast to mess with that too.

    • Re: (Score:3, Informative)

      by marcansoft ( 727665 )

      The IPv6 one is dead now too. A +trace run ends here:

      rs.dns-oarc.net. 3600 IN NS ns00.rs.dns-oarc.net.
      ns00.rs.dns-oarc.net. 3600 IN A 149.20.58.133
      ns00.rs.dns-oarc.net. 3600 IN AAAA 2001:4f8:3:2bc:2::133 ;; Received 96 bytes from 2001:500:2e::1#53(sns-pb.isc.org) in 128 ms

      Both the v4 and v6 IP for ns00.rs.dns-oarc.net. are dead, so the whole thing just dies after that.

    • Re: (Score:1)

      by ctschap ( 749362 )
      Same here...though I noticed that every time I ran the query, my firewall blocked an icpm packet from one specific IP address...

  • What about djbdns? (Score:4, Insightful)

    by mukund ( 163654 ) on Friday April 30, 2010 @09:11AM (#32043780) Homepage

    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?

    • 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.

      • Re: (Score:2)

        by MyHair ( 589485 )

        djbdns is a collection of programs. The 512B limit doesn't apply to all of them. The resolver dnscache would be the program of concern in this context, and it can both request and serve requests over 512B on TCP in the default build. I am currently using other resolvers for IPv6 reasons, but I don't expect dnscache to have a problem with DNSSEC on the root servers.

    • Re:What about djbdns? (Score:4, Informative)

      by Anonymous Coward on Friday April 30, 2010 @09:33AM (#32044024)

      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: (Score:2)

        by kindbud ( 90044 )

        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.

        Don't be silly. dnscache and axfr-dns fully support large responses via TCP. That's ancient stuff that's been a part of DNS long before Bernstein released a byte of code.

        • Re: (Score:2)

          by Lennie ( 16154 )

          dnscache even uses EDNS, have a look at it's root priming query, it asks for EDNS.

  • Not everyone runs Windows^Wa DNS cache, you insensitive clod!

  • Things only break in some circumstances... (Score:4, Informative)

    by Anonymous Coward on Friday April 30, 2010 @09:14AM (#32043852)

    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

  • Netalyzr includes tests for this... (Score:5, Informative)

    by nweaver ( 113078 ) on Friday April 30, 2010 @09:25AM (#32043970) Homepage

    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: (Score:2)

      by DarkOx ( 621550 )

      CISCO PIX devices running 6.3 and prior with DNS inspect on will have this issue. Most people by now have turned it off because plenty of other DNS queries already execed that limit.

      • Re: (Score:2)

        by lazlo ( 15906 )

        I recall way back when windows 2003 server (I believe) started shipping, it caused a lot of problems, because its DNS server requested EDNS0 by default. That meant that sites that had crafted their DNS replies to be *exactly* 512 bytes (I know Yahoo was one) replied with 512 bytes *plus* an acknowledgement of the EDNS0 flag, which pushed it over 512. Older PIX firewalls would drop this, and there was no way to get around it. Shortly, there was a version that came out where you could change the inspection

  • 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?

    • What will kill DJBDNS is when PCI and other standards groups start to require DNSSEC in order to do business. Then companies will be forced to switch to a less secure DNS server just to speak a slightly more secure protocol.

  • That's okay (Score:5, Funny)

    by LordNimon ( 85072 ) on Friday April 30, 2010 @09:39AM (#32044098)
    We can celebrate Sync-o de Mayo!

  • What does DNSSEC mean for ISPs that mess wtih DNS? (Score:5, Interesting)

    by jonwil ( 467024 ) on Friday April 30, 2010 @09:44AM (#32044166)

    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?)

    • 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.

    • Re: (Score:3, Interesting)

      by phantomcircuit ( 938963 )

      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.

    • Re: (Score:2)

      by Lennie ( 16154 )

      Nothing at all, because you would need a DNS-client which asks for DNSSEC-extension information and actually check it, which most don't.

  • Will airplanes fall out of the sky? ~:-)B

    • Re: (Score:1)

      by e9th ( 652576 )
      I'm predicting that this will be so calamitous it'll make Y2K seem like a non-event.

  • ...to celebrate the day DNSSEC went live :P

    • Re: (Score:1, Informative)

      by Anonymous Coward

      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.

  • 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...*

    • If your DNS server or stub resolver doesn't request DNSSEC data (by setting the "DO" bit in the request) then the response will be exactly the same as it was before the introduction of DNSSEC. Nothing will break.

      The changes will not in general DNS lookups between home PCs and their ISPs.

      The people at greatest risk are those (enterprises?) that run their own full DNS servers but whose:

      • network equipment blocks or otherwise filters long DNS responses, and.
      • whose DNS servers send upstream queries with the DO b

  • Cisco PIX is affected (Score:4, Informative)

    by gazuga ( 128955 ) on Friday April 30, 2010 @10:35AM (#32044882) Homepage

    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. ;)

    • What do you mean, how can i test if im affected, i have a pix whit 6.3 fw.

    • Here's my results behind a PIX


      Cisco PIX Firewall Version 6.3(5) (It's a 505)
      CentOS release 5.4 (Final)
      Bind version: 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2
      ISP: Comcast
      Using google public DNS

      [bitwise@localhost ~]$ dig +short rs.dns-oarc.net txt
      rst.x1247.rs.dns-oarc.net.
      rst.x1257.x1247.rs.dns-oarc.net.
      rst.x1228.x1257.x1247.rs.dns-oarc.net.
      "xxx.xxx.xxx.xxx DNS reply size limit is at least 1257"
      "xxx.xxx.xxx.xxx sent EDNS buffer size 1280"
      "Tested at 2010-04-30 18:11:21 UTC"

      In my PIX config there is

    • 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. ;)

      And then what...? Upgrade the ASA to a 10 year-old PC running OpenBSD to get some decent features, vastly better ease of use, and support? I seem to be missing step 2 here...

  • Simple solution ... (Score:4, Funny)

    by PPH ( 736903 ) on Friday April 30, 2010 @11:38AM (#32045906)

    Grab a copy of the DNS namespace and load it into /etc/hosts.

  • .SE has had DNSSEC deployed for almost five years now. We should have found most bug by now...

  • 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 'tes

  • 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 w

Slashdot Top Deals

FORTUNE'S FUN FACTS TO KNOW AND TELL: A black panther is really a leopard that has a solid black coat rather then a spotted one.

Close