Problems resolving hosts in vetcentric.com domain

Tue Jul 19 11:47:38 UTC 2005

I just wanted to follow-up on this issue.  After contacting an admin at
the remote site, he more or less confirmed what Mark had stated.  He
also gave no indication that they would make any changes on our end.
The end user here reporting the problem stated it was not a major
inconvenience, etc and that he could always call the user if need be.
As such, we have decided not to use the server clauses as suggested

- Bill=20

-----Original Message-----
From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=20
Sent: Thursday, June 30, 2005 8:23 PM
To: Smith, William E. (Bill), Jr.
Cc: bind-users at isc.org
Subject: Re: Problems resolving hosts in vetcentric.com domain=20

> Mark,
>=20
> Given your response, we ran did some packet sniffing and found our=20
> name servers are indeed setting the DO bit indicating that they=20
> understand DNSSEC RRs when in fact they do not.  We do not have the=20
> dnssec-enable option included in our named.conf but my understanding=20
> from reading the BIND ARM is that the default is no anyhow.  Any ideas

> why we might be seeing this behavior?  We're contemplating hard coding

> the option to no and seeing if we get different results but curious as

> to why the default does not appear to be working here
>=20
> - Bill

	I would just use server clauses to disable edns (and hence DO)
	to those servers.

	You might try to find out what firewall (vendor and version)
	they are running as the rest of the list would like to know
	so we can avoid running it.

	Mark
=20
> -----Original Message-----
> From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]
> Sent: Tuesday, June 28, 2005 8:17 PM
> To: Smith, William E. (Bill), Jr.
> Cc: bind-users at isc.org
> Subject: Re: Problems resolving hosts in vetcentric.com domain
>=20
>=20
> 	I suspect that there is a non-DNSSEC aware EDNS aware
> 	firewall in front of a non-EDNS aware nameservers.  This
> 	is causing DNSSEC queries to not be answered.  Named has
> 	to timeout before falling back to issuing non-EDNS queries.
> 	Because named doesn't make a plain EDNS query it doesn't
> 	get a cachable (FORMERR) indication that the remote server
> 	doesn't understand EDNS.  As a result every query to this
> 	zone has to got through the timeout and as the records have
> 	a low TTL this is a frequent occurance.
>=20
> 	You can use a server clause to disable EDNS with the servers
> 	for the zone.
>=20
> 	Note: this really needs to be fixed at the remote end by
> 	replacing / reconfiguring the firewall and upgrading the
> 	nameserver to be EDNS aware.
>=20
> 	Mark
>=20
> % dig vetcentric.com soa @65.207.23.10 +bufsize=3D512 +norec +qr
>=20
> ; <<>> DiG 9.3.1 <<>> vetcentric.com soa @65.207.23.10 +bufsize=3D512
> +norec +qr ; (1 server found) ;; global options:  printcmd ;; Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32670 ;; flags:;
> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>=20
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;vetcentric.com.                        IN      SOA
>=20
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 32670 ;; flags: qr

> ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>=20
> ;; Query time: 247 msec
> ;; SERVER: 65.207.23.10#53(65.207.23.10) ;; WHEN: Wed Jun 29 09:34:01
> 2005 ;; MSG SIZE  rcvd: 12
>=20
> % dig vetcentric.com soa @65.207.23.10 +bufsize=3D512 +norec +qr =
+dnssec
>=20
> ; <<>> DiG 9.3.1 <<>> vetcentric.com soa @65.207.23.10 +bufsize=3D512
> +norec +qr +dnssec ; (1 server found) ;; global options:  printcmd ;;
> Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59965 ;; flags:;
> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>=20
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION:
> ;vetcentric.com.                        IN      SOA
>=20
> ;; connection timed out; no servers could be reached %
>=20
> > We are having some problems here where we are temporarily (or in=20
> > some cases u ntil we stop/restart named) unable to resolve hosts=20
> > within the
>=20
> > vetcentric.com  domain.  Since a stop/restart of named resolved the=20
> > problems the first time this occurred, we initially thought=20
> > something was corrupted with the DNS cach e.  However, the problem=20
> > continues to crop up randomly.  In some cases, it wi ll stop=20
> > resolving for say 20 minutes or so and then begin resolving again=20
> > wit h no action taken on our end.  We have eliminated firewall=20
> > issues after some extensive
> investigation on that end and believe it's something DNS related.
> > I've attempted to put named in debug mode (setting level as high as=20
> > 5); howev er, named continues to log only information as shown below

> > despite the level I use.  What's more baffling is that if I=20
> > attempted to start named from the c ommand line with a debug level=20
> > of 1 or 2 that it does not create the named.ru n file.  Only when I=20
> > enabled debugging at level 3 or higher does i  t create it.  In any=20
> > case, I'm somewhat puzzled as to what is causing this o n again/off=20
> > again type behavior with resolving hosts in this domain.  Any ide=20
> > as, suggestions, etc would be appreciated.  Will provide other=20
> > information
> as  needed/requested.
> > Our servers are all running 9.3.1 at present.  FWIW, we are able to=20
> > resolve h osts in the domain, including just vetcentric.com itself=20
> > from remote DNS serv ers, thus indicating some issue on our end or=20
> > somewhere between us and the ve tcentric name servers.
> >=20
> > 28-Jun-2005 13:06:46.792 client @1eea90: udprecv
> > 28-Jun-2005 13:06:46.792 client @1f0910: accept
> > 28-Jun-2005 13:06:46.792 client @1f2b50: udprecv
> > 28-Jun-2005 13:06:46.792 client @1f49e8: accept
> > 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: UDP request
> > 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: view internet:=20
> > using view 'in ternet'
> > 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: view internet:=20
> > query
> > 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: view internet:=20
> > replace
> > 28-Jun-2005 13:06:47.197 client @1d9470: create
> > 28-Jun-2005 13:06:47.197 client @1d9470: udprecv
> > 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: UDP request
> > 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: view internet:=20
> > using view  'i nternet'
> > 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: view internet:=20
> > query
> > 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: view internet:=20
> > replace
> > 28-Jun-2005 13:06:47.216 client @255db0: create
> > 28-Jun-2005 13:06:47.216 client @255db0: udprecv
> > 28-Jun-2005 13:06:47.341 client 192.112.36.4#53: UDP request
> > 28-Jun-2005 13:06:47.341 client 192.112.36.4#53: next
> > 28-Jun-2005 13:06:47.341 client 192.112.36.4#53: endrequest
> > 28-Jun-2005 13:06:47.341 client @255db0: udprecv
> >=20
> > Bill Smith
> > <mailto:bill.smith at jhuapl.edu>
> > ISS Server Systems Group
> > Johns Hopkins University Applied Physics Laboratory 11100 Johns=20
> > Hopkins Road Laurel, MD 20723
> > Phone:  443-778-5523
> > Web:  http://www.jhuapl.edu <http://www.jhuapl.edu/>   =20
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>=20
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org