odd behavior in bind-8.2.2_P3 (fwd) - "illegitimate COM server" - more

[jlewis at lewis.org]

On Thu, 7 Sep 2000, LaMont Jones wrote:

> > to bind-8.2.2_P5 to see if that would help.  It didn't.  If I turn off
> > forwarding, this ceases to be a problem, even on the 8.2.2_P3 systems.
> 
> In the presence of forwarding, the bad referral will overwrite the
> correct answers, but (as long as you're not giving out auth answers to
> some other NS), you'll never actually query the com servers(*) (you
> query the forwarder), so it's not really as bad as it sounds.

I don't think it was always working that way though.  The situation I had
was a strictly caching name server being used by thousands of clients.
That caching server is Red Hat 5.2 / bind-8.2.2_P3-0.5.2.  The config was:

options {
        forwarders { a.b.c.d; };
        directory "/var/named";
        allow-query { 209.208.0.0/17; 127.0.0.1; };
};
zone "." { type hint; file "named.ca"; };
zone "0.0.127.in-addr.arpa" { type master; file "named.local"; };

a.b.c.d is a Red Hat 6.1 system which had bind-8.2.2_P3, but was upgraded
today to bind-8.2.2_P5-9.  a.b.c.d is authoratative for some zones and is
also used by thousands of clients as one of their DNS servers.

Using this sequence of commands (from Ted Rule) on the 5.2 system:

 dig @localhost com any +norecurse
 dig @a.root-servers.net www.erosrouge.com a +norecurse
 dig @myifriendsns1.webpower.com www.erosrouge.com a +norecurse
 dig @localhost com any +norecurse
 dig @localhost www.erosrouge.com a
 dig @localhost com any +norecurse

I could watch the bad referral replace the NS and SOA records for com. But
this didn't necessarily break looking up A records for a.b.com hosts that
were not already in the cache.  What prompted me to look into this problem
in the first place though was that on two recent occasions, this caching
name server was failing to resolve multiple a.b.com hosts in different
zones (returning NXDOMAIN) that our other name servers could resolve...and
that seemed to be because it had a bogus NS record for com.  Perhaps, on
occasion, the requests forwarded to a.b.c.d didn't return answers quickly
enough, the caching server querried the bogus NS for com, and then cached
the NXDOMAIN returned by the myifriendsns1 server.

For now, I've disabled forwarding on our caching DNS server.

----------------------------------------------------------------------
 Jon Lewis *jlewis at lewis.org*|  I route
 System Administrator        |  therefore you are
 Atlantic Net                |  
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________