certain records not being returned from cache?

[Ian Veach]

Greetings and thanks for any help -

I'm running into what seems like a strange problem.  On our bind
(9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3, but patched to latest), we seem to be
having some domains [we aren't auth for] that aren't returning expected
information from cache (although thousand of other domains resolve just
fine).  Digs on/from other providers (with other recursing servers outside
our networks) seem to work correctly.  To me, it seems like all information
at least to the gTLD (and the ns of the domain?) is correct.  So the
problem seems to be us, but I'm not sure why.  It seems that bind has the
correct info in it's cache db  (see below), and yet it will not return the
data.  Details below, happy to provide more upon request!

An example is carsoncityschools.com.  A dig +trace from two of our
(different) networks works fine until after retrieving NS records:

carsoncityschools.com.  172800  IN      NS      ns1.carsoncityschools.com.
carsoncityschools.com.  172800  IN      NS      ns2.carsoncityschools.com.

That's fine.  But then [a packet sniff reveals that] the local resolver
hits our server to look up (e.g.) ns1.carsoncityschools.com, and our
servers (all) respond back with SERVFAIL.

A dig @GTLD (any) of ns1 returns correct results with glue, and a dig, from
one of our name servers directly to @50.23.15.156, return correct results:

;; QUESTION SECTION:
;ns1.carsoncityschools.com.     IN      A

;; AUTHORITY SECTION:
carsoncityschools.com.  172800  IN      NS      ns1.carsoncityschools.com.
carsoncityschools.com.  172800  IN      NS      ns2.carsoncityschools.com.

;; ADDITIONAL SECTION:
ns1.carsoncityschools.com. 172800 IN    A       50.23.15.156
ns2.carsoncityschools.com. 172800 IN    A       50.23.28.180


However, a dig direct to @OURDNS (tried three distinct systems/networks)
for, e.g. ns1.carsoncityschools.com, yields poor results:

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-2.el6_1.P3.3 <<>> @OURDNS
ns1.carsoncityschools.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32117
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.carsoncityschools.com.     IN      A


So, if I'm on the right track here, it seems like perhaps our server is not
caching the information or retrieving the info, because everything else
seems fine.  A restart of named does not fix the problem.  I then ran a
rndc dumpdb, and looked at the file (after attempting a dig again).
 The (internal cache db) dumpdb yields this:

carsoncityschools.com.  172791  NS      ns1.carsoncityschools.com.
                        172791  NS      ns2.carsoncityschools.com.
; glue
ns1.carsoncityschools.com. 172791 A     50.23.15.156
; glue
ns2.carsoncityschools.com. 172791 A     50.23.28.180

and in the

; ns2.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected]
;       50.23.28.180 [srtt 1] [flags 00000000]
; ns1.carsoncityschools.com [v4 TTL 1] [v4 success] [v6 unexpected]
;       50.23.15.156 [srtt 14] [flags 00000000]

Not knowing the db structure in detail, I can't be sure, but doesn't it
look like the cache has correct data in it.  If that's the case, why does a
local dig @OURDNS return a value?

Does anyone have other suggestions to try?

THANK YOU!

-- 

cheers and thanks,
Ian Veach, Systems Analyst
System Computing Services, Nevada System of Higher Education
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120109/b5899fcc/attachment.html>