nslookup domain search order

Jim Reid jim at rfc1035.com
Wed Sep 27 12:39:05 UTC 2000


>>>>> "Bob" == Bob Vance <bobvance at alumni.caltech.edu> writes:

    Bob> I think that you're way too hard on 'nslookup'.  But then
    Bob> again, IIRC, you also enjoy typing FQDNs for everything, and
    Bob> deprecate the use of "search" :)

Indeed. And with good reasons that have been explained here many times
before. Oh, and I don't think I've been hard enough on nslookup.

    Bob> 'nslookup' is simply trying to emulate this behavior of the
    Bob> resolver library, which is why you should use the vendor's
    Bob> version that corresponds to the resolver lib that your
    Bob> programs are using.

That's all very well, but how can anyone know *for sure* that nslookup
uses the same resolver code as the system's library?

    Bob> Personally, I find this very useful for internal use.  I can
    Bob> configure a Win95 client to use "mailx" for the SMTP relay,
    Bob> for example, and it will still work when I move it to another
    Bob> sub-domain without re-configuring the mail client (assuming
    Bob> that I have configured the requisite servers and DNS
    Bob> properly).

Sorry, but this is just wrong. First of all, your resolvers may be
causing wasteful lookups to the root servers for "mailx.". That sort
of behaviour is evil. [It also accounts for ~90% of the thousands of
lookups per second that the root servers get.] Secondly, you assume
your users have access to have a host called mailx in every domain
that is an SMTP mail server. [What about roving users with laptops?]
And that mail server will always accept mail from the user's PC no
matter what domain that PC thinks it's in. Thirdly, you assume that
the resolver code never deviates from the current sloppy behaviour
you're relying on to append a default domain name. Or walk up the
domain name. This is a big problem with PCs in particular because all
sorts of application software likes to diddle with the system software
- installing drivers, replacing kernel code, etc - or fiddle with
registry settings when you install it. For instance, I have heard of
Quicken nuking a secure TCP/IP stack because it silently replaced one
module of the system's TCP/IP code. Why a bill payment package needs
to mess with the system's TCP/IP stack is a mystery. So what might
happen to the resolver whenever a user upgrades Word (say) or installs
a new game?

You'd feel differently if you ran a name server that was on the
receiving end from hundreds of thousands (millions?) of these idiot
lookups every day. You seem to be favouring sloppiness and laziness -
supposedly for (dubious) convenience - at the expense of needless load
on the root servers and the WAN. Maybe you should see what happens to
local lookups if you lose your external connectivity and all those
queries to the root servers for "mailx." time out?

    Bob> BTW, what "modern" resolver code are you referring to that
    Bob> doesn't allow this?  

The BIND8 resolver. It almost always looks up the name as-is. It does
the right thing.

    Bob> I still consider Win98, NT4, and HP-UX 11.00 fairly modern.

Isn't HPUX11 the OS that shipped with the long-dead BIND4?



More information about the bind-users mailing list