Side-effects of edns-udp-size 512

Mark Andrews marka at isc.org
Mon May 3 23:45:23 UTC 2010 

In message <20100503163413.GA2086 at esri.com>, Ray Van Dolson writes:
> On Fri, Apr 30, 2010 at 11:55:48PM -0700, Cathy Almond wrote:
> > 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
> 
> Thanks Cathy, that makes sense.
> 
> I believe having edns-udp-size set at 512 gives us maximum
> compatibility with anything out there behind a broken firewall, etc,
> though we should look at removing the limit at some point in the future
> when possible.
> 
> Ray

As long as your local net supports packets EDNS packets up to 4096
bytes you don't need to do anything other than make sure you don't
block outgoing DNS queries over TCP.  Named and other nameservers
will workout what the remote end supports.  Remember EDNS is over
10 years old now and the root have been sending responses > 512
bytes for many years now.  They started doing this well before DURZ
started.  The number of referrals that exceed 512 bytes increases
with DURZ but if you were coping before you will cope now.

; <<>> DiG 9.7.0 <<>> foo.com +edns=0 @a.root-servers.net +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15785
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 16

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;foo.com.			IN	A

;; AUTHORITY SECTION:
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.

;; ADDITIONAL SECTION:
a.gtld-servers.net.	172800	IN	A	192.5.6.30
a.gtld-servers.net.	172800	IN	AAAA	2001:503:a83e::2:30
b.gtld-servers.net.	172800	IN	A	192.33.14.30
b.gtld-servers.net.	172800	IN	AAAA	2001:503:231d::2:30
c.gtld-servers.net.	172800	IN	A	192.26.92.30
d.gtld-servers.net.	172800	IN	A	192.31.80.30
e.gtld-servers.net.	172800	IN	A	192.12.94.30
f.gtld-servers.net.	172800	IN	A	192.35.51.30
g.gtld-servers.net.	172800	IN	A	192.42.93.30
h.gtld-servers.net.	172800	IN	A	192.54.112.30
i.gtld-servers.net.	172800	IN	A	192.43.172.30
j.gtld-servers.net.	172800	IN	A	192.48.79.30
k.gtld-servers.net.	172800	IN	A	192.52.178.30
l.gtld-servers.net.	172800	IN	A	192.41.162.30
m.gtld-servers.net.	172800	IN	A	192.55.83.30

;; Query time: 181 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Tue May  4 09:38:05 2010
;; MSG SIZE  rcvd: 524

The only real difference with DURZ is that when named falls back
to EDNS at 512, due to stupid firewalls that block DNS responses >
512, NXDOMAIN responses will have TC set and named will use TCP for
these.

Note: "tc" is set.

; <<>> DiG 9.3.6-P1 <<>> sdohflkahs +dnssec +norec +bufsize=512 @a.root-servers.net +ignore
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sdohflkahs.			IN	A

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2010050301 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20100510070000 20100503060000 55138 . MCATvGhIJvN4WXtc3hqKiEl3k8Kr7nZcq1SSn1doOlJB2KTU2HQGLCcv B0j6NvT62QdpT+e6ytuiE/tyo5OM4+S4GswBhpdj9O1ys8/m5c3A6706 SIiQB3/H4Vxu0mgAVLu1PjKRxZliLqxDneh/CslfBqWyVGEQfB36UqBI Zjc=
.			86400	IN	NSEC	ac. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20100510070000 20100503060000 55138 . w9jVwhztJwniILKh/HNdZhZ+cdaWFPwNrGxiikX/sRYAI2YnTu71KfYG fP5Zf1mBdsxd3Ip/k8f+K7+O85noZsW3aT7VxCBuIhsuBYCTYPmAxyDj VkLarV0v8lBvjCPXU+48qqpq9mc3lqtQQP0gNsoeScVyCam3WCd6hCvX mTc=
sd.			86400	IN	NSEC	se. NS RRSIG NSEC

;; Query time: 182 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Tue May  4 09:33:02 2010
;; MSG SIZE  rcvd: 480

Normal referral will still fit in 512 bytes though not with as many glue
records so TCP is not needed for them.

; <<>> DiG 9.3.6-P1 <<>> foo.com +dnssec +norec +bufsize=512 @a.root-servers.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47897
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;foo.com.			IN	A

;; AUTHORITY SECTION:
com.			172800	IN	NS	d.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			86400	IN	NSEC	coop. NS RRSIG NSEC
com.			86400	IN	RRSIG	NSEC 8 1 86400 20100510070000 20100503060000 55138 . UzR6wy5xtoUWlM1Cg/ieSaPk238p4y6O/ZuhI89Yw1yFW5heqraObzmE SkQTg1MPZ7TJjvgZBG0DVnDPeMpRqIsDikefuQrlrKR9WKKoWHiESIOu MpdVp0lt30+P1eMb0UGf3rgvLGlu7edythALrweo0t8b1oLsh0A6qlbZ h8g=

;; ADDITIONAL SECTION:
a.gtld-servers.net.	172800	IN	A	192.5.6.30
a.gtld-servers.net.	172800	IN	AAAA	2001:503:a83e::2:30
b.gtld-servers.net.	172800	IN	A	192.33.14.30

;; Query time: 188 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Tue May  4 09:32:24 2010
;; MSG SIZE  rcvd: 505

Mark

> > 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the bind-users mailing list