bind 9.2.1 "partial cache dump"?

[Peter Dambier]

Jon Lewis wrote:
> 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).
> 

I did something similar by writing my own zone file and wildcarding
everything 127.0.0.4

This gives me the bonus that bind will never ask any nameserver about
this domain. But inventing new domain names, that is a different story.

I remember there is an entry in named.conf where you can blackhole
nameservers - but not networks.

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

69.59.130.98 could be in the cache for many reasons.

Say HorseForTroy is a nameserver for GoodTroyan. You start lookingup
GoodTroyan but beware - HorseForTroy is putting

BadSpammer NS HorseForTroy

as glue into its answer. Or imagine

. NS HorseForTroy


If it is the gtld-servers then it could have been

com NS HorseForTroy
net NS HorseForTroy
org NS HorseForTroy

Just a wild guess - but those guys are wild.

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


-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Graeffstrasse 14
D-64646 Heppenheim
+49(6252)671-788 (Telekom)
+49(179)108-3978 (O2 Genion)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
mail: peter at echnaton.serveftp.com
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/