DNSSEC on May 5th

I read that too. I've already updated our firewalls to handle EDNS just in case (or DNS replies with > 512b packets). I'm not sure there is any other action item at this time.
 
I read about that a while back too, but kind of forgot about it. I used the linked test of simply running a dig command to make sure we didn't have problems here.
Code:
dig +short rs.dns-oarc.net txt

The "x" numbers in the response are the packet sizes, and will tell you how large a packet your system can receive. As long as you can get the new ~2KB packets and you're not limited to ~512B, you should be ok.
 
I'm unsure if I should even do anything, both as an end-user and as one of the IT guys at work.

I ran the dig utility from my laptop and I got the following:

Code:
C:\dig>dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"208.69.84.9 sent EDNS buffer size 4096"
"208.69.84.9 DNS reply size limit is at least 3843"
"Tested at 2010-05-03 16:58:15 UTC"

I'm assuming FiberTech Networks (my ISP) is okay?
 
I'm unsure if I should even do anything, both as an end-user and as one of the IT guys at work.

I ran the dig utility from my laptop and I got the following:

Code:
C:\dig>dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
"208.69.84.9 sent EDNS buffer size 4096"
"208.69.84.9 DNS reply size limit is at least 3843"
"Tested at 2010-05-03 16:58:15 UTC"

I'm assuming FiberTech Networks (my ISP) is okay?

It's really not the ISP that is in question, as the DNS packets look like any other packet as far as their network is concerned. ...Plus an ISP probably is well ahead of any change like this.
 
It's really not the ISP that is in question, as the DNS packets look like any other packet as far as their network is concerned. ...Plus an ISP probably is well ahead of any change like this.

So the problem is whether the resolver is able to handle the DNS request? As in, if the DNS request is more than 512 bytes, it just gets dropped?

I guess I'm kind of confused whether I should even attempt to do anything at all, lol.

I saw this on a dslreport page :

Upgrading to DNSSEC is a slow and measured affair that's only just really getting off the ground, and despite The Register's claims that the Internet may grind to a halt next Wednesday -- all 13 root servers upgraded with DNSSEC next week will behave normally to end users whether your ISP is fully prepared or not (and most certainly aren't). However there is a small problem that could slow the Internet down slightly for a very small portion of users, as "El Reg" explores:
Normal DNS traffic uses the UDP protocol, which is faster and less resource-hungry than TCP. Normal DNS UDP packets are also quite small, under 512 bytes. Because of this, some pieces of network gear are configured out of the box to reject any UDP packet over 512 bytes on the basis that it's probably broken or malicious. Signed DNSSEC packets are quite a lot bigger that 512 bytes, and from 5 May all the DNS root servers will respond with signed DNSSEC answers.
Kind of -- except for the fact that as we understand it -- root servers will only return signed DNSSEC answers to queries that have explicitly asked for them. In other words? The vast majority of Internet users won't notice a damn thing next week.

So, I guess I just need to sit back and watch what happens...

Source: http://www.dslreports.com/shownews/No-DNSSEC-Upgrades-Wont-Break-The-Internet-Next-Week-108154
 
So the problem is whether the resolver is able to handle the DNS request? As in, if the DNS request is more than 512 bytes, it just gets dropped?

From what I understand, yes. The DNS resolving "fails" because of incorrect packet size.
 
No expert here by any means, but I think what you'll need to watch for is dropped dns packets in your firewall.
We have W2k3 DNS servers in house and after doing some digging discovered DNSSEC is only fully supported in W2k8 servers.
The dns packets will still get delivered but it might take more than one try and will be divided into multiple packets provided your firewall will allow them.
As mentioned, a kind of wait and see thing.
 
Some Cisco PIX and ASA's are configured out of the box to accept DNS replies with <= 512 bytes. I think if you are on the latest code though, it's not a problem.

I admit I just started reading about the problem today, but some firewalls are indeed locked down tight in regards to what they accept. Those are the people who have to worry. If you have a Linksys or something like that at home - no worries.
 
We have Win2K3 and ASA5510s at the office as well, so I'm rather curious to know how to enable EDNS in the firewall configuration. Also, how to allow for <= 512 bytes.

Is there a security risk for doing this? Performance drops? Anything worth mentioning as a tip? :D

I am going to sit and wait it out too, but I just wanted to be a little bit prepared to answer questions in the near future.
 
I just updated a couple of 7.0 code PIX's from this:

Code:
policy-map global_policy
 class inspection_default
  inspect dns maximum-length 512

To this:

Code:
policy-map global_policy
 class inspection_default
  inspect dns maximum-length 4096
 
I believe there's another option you can use on Cisco gear..."inspect dns maximum-length maximum client auto" or something to that extent
 
Actually, I would be interested in knowing the actual "show" command to see what the policy_map global-policy says in the ASA5510.
 
Sooooo here's the deal.

Most home users use the ISP's DNS. Many businesses do this as well (or use something like OpenDNS). These ISPs will already have dealt with this.

That leaves big corporations which might utilize their own DNS servers and whatnot. One would ASSUME most big corporations at least know this is coming.

So the Internet will shut down for many? Heck no. I think it's just blown out of proportion myself. I think the folks seeing this issue will be unheard of.
 
Actually, I would be interested in knowing the actual "show" command to see what the policy_map global-policy says in the ASA5510.

Code:
FW# sh service-policy global

Global policy:
  Service-policy: global_policy
    Class-map: inspection_default
      Inspect: dns maximum-length 512, packet xxxxxx, drop xxxxxx, reset-drop xxxxxx
 
Well I for one am confused if we are fine or not based on my test results.

Code:
C:\dig>dig +short rs.dns-oarc.net txt

returns the result of
Code:
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"208.69.36.12 DNS reply size limit is at least 490"
"208.69.36.12 lacks EDNS, defaults to 512"
"Tested at 2010-05-04 16:47:05 UTC"


DNS-OARC site said:
No EDNS

The following result comes from a DSL router that does not support EDNS:

rst.x486.rs.dns-oarc.net.
rst.x454.x486.rs.dns-oarc.net.
rst.x384.x454.x486.rs.dns-oarc.net.
"X.X.X.X DNS reply size limit is at least 486 bytes"
"X.X.X.X lacks EDNS, defaults to 512"

So am I fine or am I screwed come tomorrow.
 
It appears the biggest problem resides with your ISP. The best way to know if your dns resolver is ok is to use a command to query a server which bypasses your ISP.

Try this command.

dig @ns1.megapath.net +short rs.dns-oarc.net

If your response shows support for edns then your resolver should be fine. It will be up to the ISP's to deal with any other issues that may occur.

For those of you using Sonicwall's as I do, you may want want to check 2 settings. Go to Network, then on your Wan setting go to "configure". On advanced settings make sure "Fragment Non-VPN packets larger than this interface's MTU" is checked and "Ignore DF Bit" is unchecked.
 
Last edited:
When I tried the above I got

Code:
C:\dig>dig @ns1.megapath.net +short rs.dns-oarc.net
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.

C:\dig>

Which is the first part but then I never received the two lines after that showing the size.
 
Back
Top