Problems resolving hosts in vetcentric.com domain

Wed Jun 29 00:16:44 UTC 2005

	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=512 +norec +qr

; <<>> DiG 9.3.1 <<>> vetcentric.com soa @65.207.23.10 +bufsize=512 +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=512 +norec +qr +dnssec

; <<>> DiG 9.3.1 <<>> vetcentric.com soa @65.207.23.10 +bufsize=512 +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
% 

> We are having some problems here where we are temporarily (or in some cases u
> ntil we stop/restart named) unable to resolve hosts within the vetcentric.com
>  domain.  Since a stop/restart of named resolved the problems the first time 
> this occurred, we initially thought something was corrupted with the DNS cach
> e.  However, the problem continues to crop up randomly.  In some cases, it wi
> ll stop resolving for say 20 minutes or so and then begin resolving again wit
> h no action taken on 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 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 attempted to start named from the c
> ommand line with a debug level of 1 or 2 that it does not create the named.ru
> n file.  Only when I enabled debugging at level 3 or higher does i
>  t create it.  In any case, I'm somewhat puzzled as to what is causing this o
> n again/off again type behavior with resolving hosts in this domain.  Any ide
> as, 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 resolve h
> osts in the domain, including just vetcentric.com itself from remote DNS serv
> ers, thus indicating some issue on our end or somewhere between us and the ve
> tcentric name servers.
> 
> 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: using view 
> 'in
> ternet'
> 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: view internet: query
> 28-Jun-2005 13:06:47.196 client 128.244.197.32#53: view internet: 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: using view
>  'i
> nternet'
> 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: view internet: query
> 28-Jun-2005 13:06:47.216 client 128.244.194.100#53: view internet: 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
> 
> Bill Smith
> <mailto:bill.smith at jhuapl.edu>
> ISS Server Systems Group
> Johns Hopkins University Applied Physics Laboratory 
> 11100 Johns Hopkins Road 
> Laurel, MD 20723
> Phone:  443-778-5523
> Web:  http://www.jhuapl.edu <http://www.jhuapl.edu/>    
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org