Side-effects of edns-udp-size 512

[Cathy Almond]

Hi Ray,

I'd recommend not using type 'any' in your tests - the results won't
always be what you expect.  ANY is a diagnostic query type - and what a
recursive nameserver does when it receives it will depend on what it has
already in cache - sometimes it will answer with what it has already,
and sometimes it will go off and make onward queries.  What happens to
be in cache at the moment the query is received and not the
edns-udp-size setting is the more likely explanation for what you're
observing.

Cathy

Ray Van Dolson wrote:
> 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
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users