Re(2): Blinded root !

Jim Reid jim at rfc1035.com
Sun Sep 3 14:29:30 UTC 2000


>>>>> "Didier" == Didier Journois <djr at invivo.edu> writes:

    Didier> OK I understand and I adopted dig ;-) ->

But then you used nslookup again... sigh.

    Didier> Nervertheless how to explain that using one other NS (the
    Didier> primary one for the French regristration name
    Didier> organisation) I get using nslookup a different output ? Do
    Didier> they have a (very) different root.cache file ?->

You can never tell from a query what was in a name server's root.cache
file. All that file does is provide hints to your name server about
where the root servers can be found. You can put any old junk in the
root.cache file provided it points the name server at the root
servers, though most people use the version of the file held at
ftp.rs.internic.net which contains the names and addresses of the
actual root servers.

If you'd used dig as you were advised, you'd have seen the complete
answers from both name servers. Although the two names servers gave
different answers, both are correct. The two servers have different
configurations, so they give different answers for some queries.

Your server returned an empty answer section and the SOA record for
the zone containing the name being looked up - "." in this case - in
the authority section. This is the correct behaviour for an up to date
name server that's found that the name/type/class being looked up does
not exist. See RFC2308. Your server asked a root server if there were
any A records for "." and was told there weren't.

The answer from ns1.nic.fr was a referral - "go and query the name
servers for ".", don't ask me". It has an empty answer section, but
had the NS records and A records for the root servers in the authority
and additional sections respectively. [For reasons best known to
itself, nslookup confused you by printing all that stuff without
indicating that it didn't come from the answer section of the reply.]
The reason for the referral is that ns1.nic.fr has been configured as
a non-recursive server. It won't find the answers for recursive
queries like those that are normally made by dig or nslookup. Your
server does handle those recursive requests BTW, which is why it gives
a different answer from ns1.nic.fr. That name server is only supposed
to get queries from other name servers who should be capable of
recursing for themselves.

If you'd used dig, you might have noticed that the answer from
ns1.nic.fr did not have the RA bit set which meant that recursion was
not available on that server. In other words, the server's answer
showed that it was a non-recursive server and therefore that the
answer it returned was a referral. But all that important and relevant
information passed you by because you persisted with the useless
nslookup instead of a decent DNS diagnostic tool like dig. Oh well.

Moral: if you want meaningful output from DNS queries, use a proper
tool like dig that shows the whole answer packet. Don't pay attention
to the often confused and misleading output from nslookup.

[Begin rant.] Someone should really put a bullet into nslookup and rid
the world of that worthless piece of junk forever. [End rant.]



More information about the bind-users mailing list