Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

DNSSEC May Cause Problems On May 5

kdawson posted more than 4 years ago | from the packets-available-but-not-to-you dept.

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

cancel ×

132 comments

Frits Post (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#32043472)

Woot!

Jeez, And the day after (3, Funny)

coniferous (1058330) | more than 4 years ago | (#32043482)

And the day after star wars day too... We are going to have some seriously bipolar geeks by the time this is all done.

Be happy (2, Funny)

Anonymous Coward | more than 4 years ago | (#32043502)

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

Re:Be happy (2, Funny)

WrongSizeGlass (838941) | more than 4 years ago | (#32043590)

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

I still support 7-bit ASCII, you insensitive clod!

Re:Be happy (2, Funny)

OzPeter (195038) | more than 4 years ago | (#32043632)

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

I still support 7-bit ASCII, you insensitive clod!

7 bit ASCII?!??!?! Geez .. get off my lawn .. its Baudot or nothing!!

Re:Be happy (1, Funny)

Anonymous Coward | more than 4 years ago | (#32043704)

You have Baudot?

You lucky bastard, all I've got is ones and zeroes.

Re:Be happy (4, Funny)

OzPeter (195038) | more than 4 years ago | (#32043858)

You have Baudot?

You lucky bastard, all I've got is ones and zeroes.

Um .. Baudot *is* ones and zeroes.

Re:Be happy (1, Funny)

Anonymous Coward | more than 4 years ago | (#32043868)

Ones and zeroes?! Ones and zeroes?!

I'm making do with a stick and a hoop here, you jammy git!

Re:Be happy (2, Funny)

Anonymous Coward | more than 4 years ago | (#32043870)

You have ones? You lucky bastard, all I've got is a zero! Yes, only one!

Re:Be happy (1, Funny)

Anonymous Coward | more than 4 years ago | (#32044360)

You have ones? You lucky bastard, all I've got is a zero! Yes, only one!

Then you have one!

Re:Be happy (1)

www.sorehands.com (142825) | more than 4 years ago | (#32044476)

I still have to punch holes in punch card (yes 1) in ebcdic. I have to glue the card back together for each line.

Re:Be happy (0)

Anonymous Coward | more than 4 years ago | (#32045290)

You had zeroes? All we had was the letter "O".

Re:Be happy (1)

TheOtherChimeraTwin (697085) | more than 4 years ago | (#32045936)

And how did you count that?

Re:Be happy (1)

ganjadude (952775) | more than 4 years ago | (#32044940)

I think I saw a 2

Re:Be happy (1)

Darth Sdlavrot (1614139) | more than 4 years ago | (#32043928)

I still support 7-bit ASCII, you insensitive clod!

7-bit ASCII? Versus what? ASCII is and was only 7-bit.

(And don't try to use http://en.wikipedia.org/wiki/Extended_ASCII [wikipedia.org] to claim otherwise. Read the first paragraph.)

Re:Be happy (3, Informative)

Sir_Lewk (967686) | more than 4 years ago | (#32044776)

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

In Other Words, DNSSEC (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32043556)

is a botnet [myvideo.de] .

Cheers.

Yours In Astrakhan,
Kilgore Trout

Huh? (0)

Anonymous Coward | more than 4 years ago | (#32043560)

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?

Re:Huh? (0)

Anonymous Coward | more than 4 years ago | (#32043676)

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

I don't encourage violence.
dig @dns1.ssa.gov www.ssa.gov +tcp

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?

Man, you have to be young. You weren't around when Cisco PIX version 6.2.5 was the hottest firewall out there.
http://www.icann.org/en/committees/security/sac016.htm

Re:Huh? (4, Informative)

SharpFang (651121) | more than 4 years ago | (#32043802)

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.

Re:Huh? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32043974)

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.

Hey stupid, 512 bytes is HALF of a kilobyte. Do you drive 110mph in a 55mph speed limit area too?

Re:Huh? (2, Informative)

iburrell (537197) | more than 4 years ago | (#32045890)

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.

Re:Huh? (1)

ciggieposeur (715798) | more than 4 years ago | (#32046326)

Most DNS is UDP, not TCP.

Already, the test nameserver... (4, Informative)

Crackez (605836) | more than 4 years ago | (#32043572)

is slashdotted.

So what do I do? (4, Interesting)

OzPeter (195038) | more than 4 years ago | (#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:So what do I do? (1)

OzPeter (195038) | more than 4 years ago | (#32043600)

Oops - I meant EDNS. not EDSL

And BTW moving off Comcast is not an option.

Re:So what do I do? (1, Informative)

Anonymous Coward | more than 4 years ago | (#32043604)

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? (5, Informative)

Anonymous Coward | more than 4 years ago | (#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.

Family Guy (0, Funny)

Anonymous Coward | more than 4 years ago | (#32043804)

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.

Re:Family Guy (1)

Alnitak73 (739151) | more than 4 years ago | (#32046436)

He would, if that was actually his name. The Comcast guy as actually Chris Griffiths.

Re:So what do I do? (1)

OzPeter (195038) | more than 4 years ago | (#32043828)

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

Mod parent up, this is just FUD (2, Informative)

Abcd1234 (188840) | more than 4 years ago | (#32043946)

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

Re:Mod parent up, this is just FUD (1)

osssmkatz (734824) | more than 4 years ago | (#32044562)

why is it FUD? could you message me and explain?

Re:Mod parent up, this is just FUD (1, Informative)

Anonymous Coward | more than 4 years ago | (#32045152)

Fear, uncertainty, and doubt (FUD)

Re:So what do I do? (2, Insightful)

Anonymous Coward | more than 4 years ago | (#32044920)

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:So what do I do? (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32043646)

Can I get those instructions in windows?

No seriously!

Re:So what do I do? (3, Informative)

atomic-penguin (100835) | more than 4 years ago | (#32043730)

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:So what do I do? (0)

Anonymous Coward | more than 4 years ago | (#32043794)

thank you for this link...i tired the test bu got this

C:\dig>dig +short rs.dns-oarc.net txt ;; connection timed out; no servers could be reached

C:\dig>

any other way to test if this will affect me.

Re:So what do I do? (0)

Anonymous Coward | more than 4 years ago | (#32044554)

I had the same error on Linux. Just try it again after a minute or two (I think the DNS is overloaded).

If it still doesn't work then try dig +short +bufsize=4096 rs.dns-oarc.net txt instead.

Re:So what do I do? (0)

Anonymous Coward | more than 4 years ago | (#32044572)

Leave off the +short, it is apparently not supported on windows.

Re:So what do I do? (2, Informative)

The MAZZTer (911996) | more than 4 years ago | (#32044202)

FYI for cygwin users: dig is part of cygwin so get it from the "bind" cygwin package.

Re:So what do I do? - Windows specific (1)

Havokmon (89874) | more than 4 years ago | (#32046270)

If you run Windows DNS internally - some schmuck might have disabled DNSSEC. This really sucks because you don't expect that to be the case, and spend an hour trying to figure out why the new router isn't working.

To re-enable: dnscmd /Config /EnableEDnsProbes 1

Re:So what do I do? (1)

OzPeter (195038) | more than 4 years ago | (#32043790)

This link is apparently a port of dig to windows Dig [members.shaw.ca]

Re:So what do I do? (0)

Anonymous Coward | more than 4 years ago | (#32043700)

I receive a timeout message... :( (standard Ubuntu 9.04 BIND). I think I'd better check my iptables...

Re:So what do I do? (2, Informative)

Joehonkie (665142) | more than 4 years ago | (#32043860)

OpenDNS fails this, too. Hopefully they will be quick on fixing it.

Re:So what do I do? (1)

causality (777677) | more than 4 years ago | (#32043982)

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:So what do I do? (1)

jonwil (467024) | more than 4 years ago | (#32044070)

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)

Re:So what do I do? (1)

Vancorps (746090) | more than 4 years ago | (#32046162)

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? (3, Funny)

Fnord666 (889225) | more than 4 years ago | (#32045798)

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:So what do I do? (1)

em0te (807074) | more than 4 years ago | (#32046096)

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 with "we R teh roxors!" or something in it. It could happen anyway.

Upgrade or die (4, Interesting)

K2tech (1685250) | more than 4 years ago | (#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? (3, Interesting)

Aladrin (926209) | more than 4 years ago | (#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?

Re:Odd results? (0)

Anonymous Coward | more than 4 years ago | (#32043912)

Getting the same thing. I tried it at my GF's place (AT&T DSL): timeout. Try it at my place (Comcast): blank string.

No idea what it means.

Re:Odd results? (0)

Anonymous Coward | more than 4 years ago | (#32043964)

Blank string here too.

I'm assuming no news is good news? :-)

Re:Odd results? (0)

Anonymous Coward | more than 4 years ago | (#32044792)

If you remove the +short on the Goggle one, you'll probably see a SERVFAIL under the Status.

slashdot effect (n/t) (0)

Anonymous Coward | more than 4 years ago | (#32044880)

see subj

Re:Odd results? (1)

kindbud (90044) | more than 4 years ago | (#32046254)

Any idea what they mean?

I forsee a large sneakernet in your future.

DNS server slashdotted (2, Informative)

fialar (1545) | more than 4 years ago | (#32043728)

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

Re:DNS server slashdotted (0)

Anonymous Coward | more than 4 years ago | (#32043798)

I can confirm this...

Re:DNS server slashdotted (1)

silverglade00 (1751552) | more than 4 years ago | (#32044010)

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:DNS server slashdotted (1, Informative)

Anonymous Coward | more than 4 years ago | (#32044498)

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:DNS server slashdotted (1)

silverglade00 (1751552) | more than 4 years ago | (#32044878)

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:DNS server slashdotted (2, Informative)

marcansoft (727665) | more than 4 years ago | (#32044088)

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:DNS server slashdotted (1)

ctschap (749362) | more than 4 years ago | (#32044362)

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

No linux or unix.. (0)

jonnythan (79727) | more than 4 years ago | (#32043738)

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?

Re:No linux or unix.. (2, Informative)

d1r3lnd (1743112) | more than 4 years ago | (#32043762)

Get dig for windows: http://members.shaw.ca/nicholas.fong/dig/ [members.shaw.ca]

Re:No linux or unix.. (1)

jonnythan (79727) | more than 4 years ago | (#32043808)

Thanks.

I am getting nothing but timeout errors, both here and on the Linux box at home. Oh well, try again later.

Re:No linux or unix.. (0)

Anonymous Coward | more than 4 years ago | (#32043786)

Put your LiveCD into your drive and reboot.

What about djbdns? (3, Insightful)

mukund (163654) | more than 4 years ago | (#32043780)

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?

Re:What about djbdns? (0)

Anonymous Coward | more than 4 years ago | (#32043954)

DJBDNS won't have a problem on May 5th. You can check this by setting up a test server which only uses the root servers which are already serving signed responses (e.g. l.root-servers.net)

DJBDNS does not request DNSSEC (1)

nweaver (113078) | more than 4 years ago | (#32044020)

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:What about djbdns? (4, Informative)

Anonymous Coward | more than 4 years ago | (#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:What about djbdns? (1)

kindbud (90044) | more than 4 years ago | (#32045988)

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.

idiot article (2, Funny)

Gothmolly (148874) | more than 4 years ago | (#32043846)

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

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

Anonymous Coward | more than 4 years ago | (#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... (5, Informative)

nweaver (113078) | more than 4 years ago | (#32043970)

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:Netalyzr includes tests for this... (1)

DarkOx (621550) | more than 4 years ago | (#32044518)

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:Netalyzr includes tests for this... (1)

lazlo (15906) | more than 4 years ago | (#32045524)

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

*now*, if you've upgraded your PIX to an ASA (or to version 7.X or 8.X), then it will helpfully convert that DNS inspection to a migrated DNS policy map, like thus:

policy-map type inspect dns migrated_dns_map_1
  parameters
    message-length maximum 512

Which, as I read this, may well break things.

Just as logn as CSN CHI and Dtv and not messed up (0)

Anonymous Coward | more than 4 years ago | (#32044052)

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!

Is DNSSEC going to kill djbdns? (1)

characterZer0 (138196) | more than 4 years ago | (#32044056)

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?

Re:Is DNSSEC going to kill djbdns? (0)

Anonymous Coward | more than 4 years ago | (#32044102)

Requests are never signed, you just get (static) signatures back. There's no handshake or anything. If you ignore the additional information and aren't tripped up by the larger packets, nothing changes for you.

That's okay (5, Funny)

LordNimon (85072) | more than 4 years ago | (#32044098)

We can celebrate Sync-o de Mayo!

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

jonwil (467024) | more than 4 years ago | (#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?)

Re:What does DNSSEC mean for ISPs that mess wtih D (1)

Alnitak73 (739151) | more than 4 years ago | (#32046484)

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.

Will my car still start? (1)

KiwiCanuck (1075767) | more than 4 years ago | (#32044306)

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

Re:Will my car still start? (0)

Anonymous Coward | more than 4 years ago | (#32045676)

Only during volcano season...

Re:Will my car still start? (1)

e9th (652576) | more than 4 years ago | (#32045944)

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

Cinco de Mayo is now a geek holiday (1)

GameboyRMH (1153867) | more than 4 years ago | (#32044382)

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

Re:Cinco de Mayo is now a geek holiday (1, Informative)

Anonymous Coward | more than 4 years ago | (#32045002)

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'm doubtful... (1)

Target Practice (79470) | more than 4 years ago | (#32044520)

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

Re:I'm doubtful... (1)

Alnitak73 (739151) | more than 4 years ago | (#32046566)

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 bit set.

Cisco PIX is affected (3, Informative)

gazuga (128955) | more than 4 years ago | (#32044882)

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:Cisco PIX is affected (0)

Anonymous Coward | more than 4 years ago | (#32045420)

I was unable to find any clear indication what versions of Cisco ASA/PIX firmware might have problems. Anything below 8.2.2 does not do anything to EDNS queries from what I can gather. The default 'message-length maximum 512' parameter that's set on DNS queries didn't seem to impact my tests when done against 4.2.2.2 server from behind a firewall with that parameter set. DNSSEC and size up to 4096 tested fine. This was on an ASA running 8.2.1.

Any idea if 6.3.2 or earlier will be impacted only if they have inspect dns turned on? Or only if they have the message length parameter enabled?

Re:Cisco PIX is affected (1)

hviniciusg (1481907) | more than 4 years ago | (#32045430)

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

Linux... (0)

Anonymous Coward | more than 4 years ago | (#32045520)

So uh, are there any KISS guides for kernel modules, config file edits, etc, needed for DNSEC to work?

Using opendns instead of isp's name servers (0, Offtopic)

pgmrdlm (1642279) | more than 4 years ago | (#32045570)

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?

Sorry, complete reply using +bufsize=1024 in dig (1)

pgmrdlm (1642279) | more than 4 years ago | (#32045604)

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:
; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;rs.dns-oarc.net. IN TXT ;; ANSWER SECTION:
rs.dns-oarc.net. 49 IN CNAME rst.x476.rs.dns-oarc.net. ;; 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

disone#

Simple solution ... (3, Funny)

PPH (736903) | more than 4 years ago | (#32045906)

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

DNSSEC OK (0)

Anonymous Coward | more than 4 years ago | (#32046920)

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...