Paul Wouters: Re: [dnssec-deployment] DNS cache issue

[Mark Andrews]

> In message <200711222318.lAMNIxnf095379 at drugs.dv.isc.org> (on 23 November
> 2007 10:18:59 +1100), Mark_Andrews at isc.org (Mark Andrews) wrote:
> >
> >> > .., and I am pretty sure both networks should not have edns issues.
> >> 
> >> most edns issues are really ip fragmentation issues.  firewalls that allow
> >> a certain server to send or receive udp/53 but which don't retain IP ID
> >> state to allow matching fragments, tend break edns.  most of the firewalls
> >> that do this are software devices running on the same host as the dns
> >> server.  fairly often the cure is worse than the disease (allow all frags)
> .
> > 
> >	Most OS's now have code to deal with fragmentation attacks.
> >	I've also found that most responses still fit in a single
> >	Ethernet packet.
> >
> >		edns-udp-size 1460;  
> >
> >	This is from a box which sits behind a nat that doesn't handle
> >	out-of-order fragments.
> 
> Perhaps, before switching to non-edns, BIND could turn down the
> edns-udp-size option itself, and the (much less frequent, please!) log
> messages stating it was doing this could suggest doing this manually to
> prevent further log messages?
> 
> 	      -Allen

	It does.  EDNS -> EDNS at 512 -> no EDNS

	Since November 2

	grep "too many timeouts resolving" /var/log/named | wc
	     166    2324   20054

	If you actually look at this it ends up being a handful of
	remote zones.

	grep "too many timeouts resolving" /var/log/named | \
	awk '{ print $12}' | sort -u | wc
	      26      26     485

		139.51.80.in-addr.arpa
		219.81.in-addr.arpa
		BA-DSG.NET
		DSG.NET
		SWBELL.NET
		adobe.com
		apnic.NET
		arin.NET
		baltimorecity.gov
		cn.NET
		coco.CA
		download.mcafee.com	* load balancer
		ims-oman.com
		inmail.com
		iut-dhaka.edu
		marketworks.com
		micom.mn
		mng.NET
		netti.fi
		smtp04.bradesco.com.br	* load balancer
		smtp06.bradesco.com.br	* load balancer
		smtp07.bradesco.com.br	* load balancer
		techsecure.ca
		wip3.adobe.com		* load balancer?
		xpasc-x.com
		xpasc.com

	Some of those are clearly load balancers.
	Some of them may just be a dead/overloaded link/server.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org