DNSSEC and UDP buffer size

edmund · Apr 14, 2010, 10:18 AM

Is this going to be a problem come May 5th when the root servers transfer to DNSSEC - is seems that UDP packets are going to be getting larger. Testing pfSense returns the message:

"Your resolver was only able to get packets SMALLER than 512 bytes" with the explanation:

This usually implies that a packet filter or firewall is blocking UDP packets bigger than 512 bytes from reaching your resolver. Your resolver works now, although it is probably not able to resolve some names. However, when the root zone is signed your resolver will not be able to receive most responses, and it is possible that you will lose DNS service. You should reconfigure your firewall or packet filter to allow large UDP packets through.

http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues

mhab12 · Apr 30, 2010, 6:17 PM

BUMP - same question here…
Here is another way to test reply sizes:
https://www.dns-oarc.net/oarc/services/replysizetest
As well as the article that got me concerned:
http://tech.slashdot.org/article.pl?sid=10/04/30/1258234

cwadge · Apr 30, 2010, 6:28 PM

Indeed, it also looks like dnsmasq is using the old EDNS max packet size default of 1280, whereas the current default for dnsmasq is 4096.


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280

mhab12 · Apr 30, 2010, 6:40 PM

Is there a conf file we can edit to up the max size?

jimp · May 3, 2010, 3:53 PM

Unfortunately on 1.2.3 dnsmasq couldn't be updated because they removed the feature for registering DHCP leases. So if the fix requires updating dnsmasq, it may mean losing that feature. There is a script in 2.0 that tries to replicate the behavior, but it needs more testing.

jimp · May 3, 2010, 4:06 PM

I tried this from behind 1.2.3 and 2.0 and it seems the failures are really the fault of your upstream DNS is most cases.

It works for me from behind a 1.2.3 box with a good DNS server, and fails behind one with an upstream DNS that is apparently lacking.

From 1.2.3:

jim@loki:~$ 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.
"x.x.x.x DNS reply size limit is at least 3843"
"Tested at 2010-05-03 16:01:48 UTC"
"x.x.x.x sent EDNS buffer size 4096"

From 2.0:

jim@chomp:~$ 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.
"204.74.103.103 lacks EDNS, defaults to 512"
"204.74.103.103 DNS reply size limit is at least 490"
"Tested at 2010-05-03 16:04:42 UTC"

In both cases, the IPs in the query were those of my ISP server DNS, not pfSense.

sullrich · May 3, 2010, 4:10 PM

DNSMASQ does support EDNS. See: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

I would imagine your upstream DNS is not supporting it. Switch to OpenDNS and you should be OK.. I recommend using OpenDNS either way. It is fantastic.

http://www.opendns.com/

jimp · May 3, 2010, 4:18 PM

Google's public DNS may also work: 8.8.8.8 / 8.8.4.4

Though when I try to query both OpenDNS and Google's DNS, both seem to fail the dig test.

mhab12 · May 3, 2010, 4:41 PM

We use OpenDNS (and agree it is fantastic). I ran the test with it, Google DNS, and our ISP (Time Warner BC / San Diego). They all failed. OpenDNS claims to support the larger packet size through some kind of background manipulation…we'll see what happens when everything starts requiring DNSSec later this year. Seems like we'll be okay for a while.

jimp · May 3, 2010, 4:52 PM

OpenDNS claims that the test fails but it fails because that query does not actually need to respond that large over UDP, and the reply is crafted in a way that should force the query to happen again over TCP instead. I'm not sure if that dig test supports that methodology. Though I can imagine that between the increased size and use of TCP, DNS resolution may take a bit longer overall.

http://forums.opendns.com/comments.php?DiscussionID=6595

cwadge · May 3, 2010, 5:57 PM

@sullrich:

DNSMASQ does support EDNS. See: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

The problem in my case was that dnsmasq is throwing away larger than expected UDP replies. Since the reasonable size of a DNS query prior to [stupid] DNSSec is ~512b, the dnsmasq default max value of 1280 was sane. Now that they can potentially surpass 3k and still be legitimate DNS responses, the limit has been raised to 4096 by default in recent builds of dnsmasq. Still, the binary doesn't need to be updated to apply this change. I've tested and confirmed that it works as expected on dnsmasq 2.45 just by setting the config option 'edns-packet-max=4096' either in its config or as an argument at launch.

For further reference:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2010q2/003896.html

mhab12 · May 4, 2010, 6:32 PM

Where is the DNSMasq conf file located in pfsense?

jimp · May 4, 2010, 6:45 PM

@mhab12:

Where is the DNSMasq conf file located in pfsense?

pfSense only uses command line parameters for dnsmasq, not a configuration file.

mhab12 · May 4, 2010, 7:32 PM

Is there any way to pass the larger packet size to dnsmasq via shell or some other conf file at startup?

jimp · May 4, 2010, 7:36 PM

If you really want to change it, you can edit line 639 of /etc/inc/services.inc to read:

mwexec("/usr/local/sbin/dnsmasq --all-servers --edns-packet-max=4096 {$args}");

Though thus far I haven't seen evidence that it will really break without that setting. If it does break, it should be easy to produce a patch or update for that simple change.

mhab12 · May 4, 2010, 7:45 PM

Exactly what I was looking for - thank you!

cwadge · May 5, 2010, 1:07 AM

@jimp:

…Though thus far I haven't seen evidence that it will really break without that setting. If it does break, it should be easy to produce a patch or update for that simple change.

Since EDNS is already supported in dnsmasq some DNSSec queries will work, as they come in at under the 1280b payload size expected by dnsmasq's default EDNS value. Others, for instance some signed zones in the .gov and .org TLD's, use much closer to the 4k ceiling defined in RFC2671.

jimp · May 5, 2010, 1:25 AM

I added a very simple package that just applies a patch that makes the change I mentioned. If you find you need it, just install the "dnsmasq EDNS size increase" package that should show up momentarily in the package repo.

cwadge · May 5, 2010, 2:18 AM

@jimp:

I added a very simple package that just applies a patch that makes the change I mentioned. If you find you need it, just install the "dnsmasq EDNS size increase" package that should show up momentarily in the package repo.

Thanks for the quick patch, Jim. I'm sure that will help people out as new and exciting DNS issues begin to arise.

ezat · May 5, 2010, 2:24 AM

@jimp:

I added a very simple package that just applies a patch that makes the change I mentioned. If you find you need it, just install the "dnsmasq EDNS size increase" package that should show up momentarily in the package repo.

Thanks for the patch. Bit of an issue though.

1.2.3

Parse error: syntax error, unexpected '-', expecting '(' in /usr/local/pkg/dnsmasq-edns.inc on line 3