DNS queries for . IN A return rcode 2 SERVFAIL from windows DNS recursing resolvers
vixie at isc.org
Tue Jan 12 09:21:02 CST 2010
Joe Maimon <jmaimon at ttec.com> writes:
> Hey all,
> This must be old news for everyone else. While looking at a dns monitor
> on a load balancer that defaulted to . A queries to check liveliness on
> DNS resolvers, it became quite clear that windows 2000/2003 DNS server
> appears to return rcode=2 for queries looking for an A record for the
> root. The resolvers appear to work properly in all other regards.
well, there is no A RR for the root domain. RCODE=2 is still an error,
you should receive RCODE=0 ANCOUNT=0 for an unused RR type. but many
resolvers get confused when the root domain is the QNAME, so let's assume
that you're using one of those.
> So the monitors were switched to localhost. A
> (Is this a bad idea?)
probably. there is no "localhost" in the root zone. this name is a TCP/IP
stack convention, not a standard. for health monitoring purposes you should
probably choose one of your own local names, since there's almost certainly
no local intelligence in your resolver about them. that means to look up
one of your own names the resolver probably has to iterate downward from the
root zone to the top level and all the way down to your authority nameservers.
(the problem here is, you may be testing more than you intend, and a failure
in your own authority server or in the delegation path to it would look the
same as an IP path failure or a resolver problem.)
> A little testing later and the results for . A are:
> Windows NT 4, ancount=0, authority=1, rcode=0
> Windows 2000, rcode=2
> Windows 2003, rcode=2
> bind, ancount=0, authority=1, rcode=0
> To my (inexpert) eyes that doesnt seem quite right.
probably resolver bugs, either in those TCP/IP stacks or in the "recursive
nameserver" they are using. (is the same recursive nameserver used in all
> I cant seem to find any online information regarding this difference of
> Enlightenment appreciated.
i suggest re-asking this over on dns-operations at lists.dns-oarc.net, since it
a bit deep in the DNS bits for a general purpose list like NANOG.
More information about the NANOG