Intermittent failures

Jim Reid jim at rfc1035.com
Wed Dec 6 23:48:09 UTC 2000


>>>>> "Matt" == Matt Campbell <mrcsys at rit.edu> writes:

    Matt> I didn't include the CNAME because it isn't just one, and I
    Matt> didn't polute the message in case it was a common error and
    Matt> I just had done something stupid....

Please read what you've just said and think about it. How could
providing relevant information "pollute the message"? The problem you
describe is not a common error or even a special new bug in
8.2.2P7. Why would a name server stop processing CNAMEs all of a
sudden? It's unlikely that any DNS implementation would have a
fundamental bug that stopped it handling CNAMEs.

So if some apparently valid name can't be looked up, it means there's
a configuration error, most likely in a zone file. To get help help
here, that would mean you supplying the name that's being looked up
and details of appropriate name servers: ie names and addresses for
someone to probe with a decent lookup tool like dig. Once you did
that, there was something concrete to work on. 

    Matt> The CNAME points to nissrv2.rit.edu which has an A record
    Matt> pointing to 129.21.224.172.

Er, not quite. One of the name servers for rit.edu, ns1.isc.rit.edu
says that www.ntid.rit.edu is a CNAME for a224-h172.rit.edu. This
name does not exist in any of the advertised rit.edu servers.

	% dig @ns1.isc.rit.edu www.ntid.rit.edu any

	; <<>> DiG 8.2 <<>> @ns1.isc.rit.edu www.ntid.rit.edu any 
	; (1 server found)
	;; res options: init recurs defnam dnsrch
	;; got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
	;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 6
	;; QUERY SECTION:
	;;      www.ntid.rit.edu, type = ANY, class = IN

	;; ANSWER SECTION:
	www.ntid.rit.edu.       1D IN CNAME     a224-h172.rit.edu.

	;; AUTHORITY SECTION:
	rit.edu.                1D IN NS        ns1.isc.rit.edu.
	rit.edu.                1D IN NS        ns2.isc.rit.edu.
	rit.edu.                1D IN NS        ns3.isc.rit.edu.
	rit.edu.                1D IN NS        ns1.appliedtheory.com.
	rit.edu.                1D IN NS        ns2.appliedtheory.com.
	rit.edu.                1D IN NS        ns3.appliedtheory.com.

	;; ADDITIONAL SECTION:
	ns1.isc.rit.edu.        1D IN A         129.21.3.17
	ns2.isc.rit.edu.        1D IN A         129.21.4.18
	ns3.isc.rit.edu.        1D IN A         129.21.5.19
	ns1.appliedtheory.com.  1d15h11m6s IN A  204.168.28.9
	ns2.appliedtheory.com.  1d15h11m6s IN A  168.75.17.11
	ns3.appliedtheory.com.  1d15h11m6s IN A  207.127.101.8

This is the source of the problem. Unluckily for you, your name server
appears to have queried ns1.isc.rit.edu, got the CNAME and found it
pointing at this non-existent name, a224-h172.rit.edu. It cached the
fact that this name didn't exist. The result of that is NXDOMAIN
replies - "Non-existent host/domain" - until your server expires the
negative cache entry.

I think you need to find out why your name servers have inconsistent
zone contents for the rit.edu zone even though they all have the same
SOA serial number. This could well be related to someone or something
doing silly or evil things with DDNS.

BTW, *please* use a decent DNS lookup tool like dig. nslookup is just
awful.

    Matt> As mentioned before, BIND 8.2.2p7... I didn't mention that
    Matt> we use DDNS heavily, and very rarely restart the server.

Did you consider that the DDNS updates could be messing up resource
records throughout the rit.edu zone? And it's a pity that you didn't
give us a usable IP address for the name server you got nslookup to
use. I could have queried it with dig and seen the whole answer packet
rather than the selective and usually confusing drivel nslookup outputs.
Oh well. Next time, perhaps?



More information about the bind-users mailing list