Problems resolving hosts in vetcentric.com domain

Smith, William E. (Bill), Jr. Bill.Smith at jhuapl.edu
Thu Jun 30 19:01:41 UTC 2005


Mark,

Given your response, we ran did some packet sniffing and found our name
servers are indeed setting the DO bit indicating that they understand
DNSSEC RRs when in fact they do not.  We do not have the dnssec-enable
option included in our named.conf but my understanding 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

- Bill

-----Original Message-----
From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]=20
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


	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.

	You can use a server clause to disable EDNS with the servers
	for the zone.

	Note: this really needs to be fixed at the remote end by
	replacing / reconfiguring the firewall and upgrading the
	nameserver to be EDNS aware.

	Mark

% dig vetcentric.com soa @65.207.23.10 +bufsize=3D512 +norec +qr

; <<>> 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;vetcentric.com.                        IN      SOA

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 32670 ;; flags: qr
ra; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; 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

% dig vetcentric.com soa @65.207.23.10 +bufsize=3D512 +norec +qr +dnssec

; <<>> 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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;vetcentric.com.                        IN      SOA

;; connection timed out; no servers could be reached %=20

> We are having some problems here where we are temporarily (or in some=20
> cases u ntil we stop/restart named) unable to resolve hosts within the

> vetcentric.com  domain.  Since a stop/restart of named resolved the=20
> problems the first time this occurred, we initially thought something=20
> was corrupted with the DNS cach e.  However, the problem continues to=20
> crop up randomly.  In some cases, it wi ll stop resolving for say 20=20
> minutes or so and then begin resolving again wit h no action taken on=20
> our end.  We have eliminated firewall 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=20
> despite the level I use.  What's more baffling is that if I attempted=20
> to start named from the c ommand line with a debug level of 1 or 2=20
> that it does not create the named.ru n file.  Only when I enabled=20
> debugging at level 3 or higher does i  t create it.  In any case, I'm=20
> somewhat puzzled as to what is causing this o n again/off again type=20
> behavior with resolving hosts in this domain.  Any ide as,=20
> suggestions, etc would be appreciated.  Will provide other 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



More information about the bind-users mailing list