bind 9.2.1 "partial cache dump"?
peter at peter-dambier.de
Wed Jun 7 22:06:28 UTC 2006
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
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, 188.8.131.52) are
> unreachable (null routed). Instead of giving up though after getting no
> reply from 184.108.40.206, our cache would then ask 220.127.116.11 for the
> MX. 18.104.22.168 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.
22.214.171.124 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 126.96.36.199
> ; additional
> mx.parlay6.NET. 176 A 188.8.131.52
> ; glue
> ns1.parlay6.NET. 172535 A 184.108.40.206
> ; glue
> ns2.parlay6.NET. 172535 A 220.127.116.11
> Why would bind repeatadly (after records expired from the cache) ask
> 18.104.22.168 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 22.214.171.124 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
+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
More information about the bind-users