Weirdness going on

[Mark.Andrews at nominum.com]

	Well you could look back through the logs for the lame
	server messages.  They should give you an idea about which
	machines the server though were responsible for the zone
	in question.

	Also "dig domain @server +norec" is good method for finding
	out which machines a server will ask to resolve a particular
	domain.

	Unfortunately stoping the server destroys the cache and hence
	the evidence required to find where the bad data came from in
	the first place.

	Mark

> 
> 
> Hey guys.  In my previous post I noted I was renumbering our
> network, and was looking for a way to log dns requests going to
> our old ip addresses.  I got good info and set it up, so what I 
> currently have is this:
> 
> One server, running two chrooted copies of BIND 8.2.3, one answering on
> 209.128.224.2 and the other using 206.135.129.13 and 206.135.129.15.
> Both use the same binaries, slightly different named.confs (*obviously*).
> 
> A second server, about 15 miles away, chrooted, running BIND 8.2.3
> using 209.128.232.2.
> 
> I have one local guy who hosts some domains, such as webeans.net.  He is
> concerned that our clients can't get to his server.  Tonight, he reports
> that 209.128.224.2 can't resolve his webeans.net domain.  I test it and
> sure enough, it won't.  My named reports "ns_forw: query (webeans.net) All
> possible A RR's lame" in the log.  I run dnswalk on it and dnswalk finds
> big errors, mostly that no one is authoritative for the domain.  
> 
> The guy had noted that the domain worked with BellAtlantic's dns,
> 199.45.32.37... so I changed my local resolv.conf, and sure enough
> nslookup resolved it and running dnswalk showed a sloppy, but good enough
> domain.  
> 
> So I changed my resolv.conf to my _old_ ip address,
> 206.135.129.13... remember, this is the _same_ binary on the _same_
> machine with two minor changes in the named.conf (one change is added
> logging and the other change is the listen directive).  And it resolved.
> Dnswalk gave me the same results as 199.45.32.37.
> 
> I switched back to my 209.128.224.2, and it still wouldn't resolve or
> dnswalk.  In desperation, I restarted that copy of named, and it worked 
> just like 199.45.32.37 and 206.135.129.13.
> 
> I have had a _long_ history of domains from this guy that just don't agree
> with my dns server, and I just can't figure out why.  I suspect something
> in his setup is tainting my server, but I am at a loss.
> 
> Then he notes that my backup server, 209.128.232.2 is not resolving
> anything but domains it has db files for.  It would seem it was suddenly a
> non-recursive name server, but I know it was working days before.  I
> checked the named.ca, and it is fine (actually, it's current on both
> systems)... again in desperation, I restarted named on this separate
> system and it started recursing again.  This system has never done this
> before. 
> 
> Below is a copy of the named.conf for 209.128.224.2, the conf
> for 206.135.129.13, and 209.128.232.2 are identical except for
> the "listen" directive and some logging.
> 
> Most of my zones have been removed, for brievity.
> 
> // generated by SPA
> 
> acl "bogon" {
>   0.0.0.0/8;
>   1.0.0.0/8;
>   2.0.0.0/8;
>   10.0.0.0/8;
>   169.254.0.0/16;
>   172.16.0.0/12;
>   192.0.2.0/24;
>   192.168.0.0/16;
>   224.0.0.0/3;
>   240.0.0.0/4;
>   };
> 
> options {
>         directory "/etc/namedb";
>         pid-file "/var/run/named.pid";
>         named-xfer "/bin/named-xfer";
>         listen-on { 209.128.224.2; };
>         version "I Forgot!";
>  
>         blackhole {
>           bogon;
>           };
> 
>         /*
>          * If there is a firewall between you and nameservers you want
>          * to talk to, you might need to uncomment the query-source
>          * directive below.  Previous versions of BIND always asked
>          * questions using port 53, but BIND 8.1 uses an unprivileged
>          * port by default.
>          */
>         // query-source address * port 53;
> };
> 
>  
> zone "224.128.209.in-addr.arpa" {
>         type master;
>         file "db.209.128.224";
> };
>  
> zone "0.0.127.in-addr.arpa" {
>         type master;
>         file "db.127.0.0";
> };
> 
> zone "." {
>         type hint;
>         file "named.ca";
> };
> 
> zone "dandy.net" {
>         type master;
>         file "db.dandy.net";
> };
> 
> // End
> 
> Thanx in advance for any help.
> 
> 					----Steve
> Stephen Amadei
> Dandy.net CTO
> Atlantic City, NJ
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com