Side-effects of edns-udp-size 512

[Ray Van Dolson]

Have been doing some testing[1] of our firewalls and DNS servers for
the upcoming signing of the last root server and ran into something I'm
not completely sure about.

The tests in the ISC post[1] from earlier this year run fine when
pointed directly at the L server (IOW, our firewalls do handle this
just fine), but, in the past we'd set edns-udp-size 512 on our internal
resolvers to work around some _remote_ domains that didn't play nice
with EDNS or larger packet sizes.

Yeah, I know it's probably better from a "good netizen" standpoint to
not use this parameter and instead try to get remote sites that cause
problems to fix their environments, but... that's how it is for now.

Now, when I re-run the tests in the ISC post[1] pointing at our local
resolver instead of the L server, many of the larger responses come
back truncated.

For example the query:

  dig +dnssec +norec +ignore any . @<resolver>

On a BIND server _without_ edns-udp-size 512 set returns the full list
of servers in the "additional" section.  However, on the server that
_does_ have edns-udp-size 512 set, we only get back three of the root
servers.

Now, is this directly the result of us limiting edns via UDP to 512
bytes or is our DNS server not reassembling fragmented packets to
correctly form the entire response?

What other potential side effects might we run into from using
edns-udp-size 512?  It was my understanding that there really shouldn't
be any -- thinsg should just keep working as always, but these tests
have given me some pause.

Thanks!

Ray

[1] https://lists.isc.org/mailman/htdig/bind-users/2010-February/078755.html