bind 9.2.1 "partial cache dump"?

[Jon Lewis]

Is there any known issue that could cause bind (Red Hat's 9.2.1-9) acting 
as a caching DNS server to use an NS for a domain that's not listed as an 
NS, and not "known" as an NS in the cache?...or at least that doesn't show 
up in a cache dump?

Tired of receiving spam from a particular spammer who sends through 
proxies and uses an ever growing list of domains (both in the envelope and 
message body) that always use the same NS, I null routed the network 
containing their NS.  The idea being, that should cause their spam to be 
refused with something like 451 DNS temporary failure (#4.3.0).

So, I was somewhat surprised when I got multiple spams from them yesterday 
from domains with NS's I'd already null routed.  tcpdump on our bind 
caching server showed that when I asked it for mx parlay6.net (the 
envelope from domain in one spam), the caching server would ask a 
gtld-server for the mx.  The gtld-server would respond with the expected 
NS records. Both NS's (which are actually the same IP, 65.246.161.71) are 
unreachable (null routed).  Instead of giving up though after getting no 
reply from 65.246.161.71, our cache would then ask 69.59.130.98 for the 
MX.  69.59.130.98 appears to be some kind of stealth NS and is 
authoratative for parlay6.net.  The odd part is, it doesn't show up in a 
named_dump.db I got from rndc dump_db on our cache.

The cache dump I did contains the following records for parlay6.net:

; authauthority
parlay6.NET.            176     NS      ns1.parlay6.net.
                         176     NS      ns2.parlay6.net.
; authanswer
                         176     MX      10 mx.parlay6.net.
; authanswer
cin4pk6rqil6czi4hq.parlay6.NET. 335 A   210.114.232.53
; additional
mx.parlay6.NET.         176     A       65.246.161.71
; glue
ns1.parlay6.NET.        172535  A       65.246.161.71
; glue
ns2.parlay6.NET.        172535  A       65.246.161.71

Why would bind repeatadly (after records expired from the cache) ask 
69.59.130.98 for records for parlay6.net, if it doesn't show up as a 
parlay6.net NS in the cache dump?

After obtaining the dump, I restarted bind, and this behavior ceased.

It's conceivable that some parlay6.net records were cached before the null 
route was in place.  It's quite possible that the spammer alters what they 
return as NS's for the domain during a spam run.  The only thing I don't 
get, is how bind could be using 69.59.130.98 as an NS for parlay6.net, but 
not have that NS show up in the cache dump.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________