resolv.conf question

[Jim Reid]

>>>>> "Ralf" == Ralf Hildebrandt <Ralf.Hildebrandt at innominate.de> writes:

    Ralf> My question: Is there any way to automatically reorder the
    Ralf> server in such a way, that query time is optimal?
    >>  No. And even if there were, few applications would be able to
    >> exploit it. Most applications make 1 DNS request - maybe
    >> repeated to 2 or 3 name servers - and then don't do another DNS
    >> lookup after they've got the answer.

    Ralf> ?  I thought the programs would use resolver routines, and
    Ralf> the resolver would take care of the resolution itself.

Yes, but most applications use those resolver routines exactly once.
For instance, when you type "ftp ftp.isc.org", the ftp process uses
the resolver to lookup the IP address of ftp.isc.org. Once it gets
that address, the ftp process initiates a connection to the ftp server
and the process never uses the resolver again. [Unless of course you
close the ftp session and initiate a connection to another ftp
server.] So if the resolver kept state information such as RTTs -
presumably in some private per-process data structure - nothing would
ever look at it or have reason to look at it. It sent a query, got an
answer back from some name server and simply returned that answer,
whatever it was.

    Ralf> So the resolver would have to keep track of the reachability
    Ralf> (like xntpd)

In UNIX systems the resolver is not normally a separate process or
something buried in the kernel. It's a bunch of routines for encoding
and decoding DNS packets and a per-process data structure (a struct
res or __res_state) that's pretty much a C representation of
/etc/resolv.conf. Take a look at <resolv.h>. These functions are
linked into the application either at compile-time or via a shared
library. When the application does a gethostby{name,addr}(), the code
eventually invokes res_init() to read resolv.conf and initialise a
struct __res_state and usually then calls res_query() or res_search()
to make the DNS lookup. Once all that unwinds, the typical application
has been returned an IP address to connect to and doesn't need to make
another DNS lookup. A web browser is one of the few applications I can
think of that makes many DNS lookups during its lifetime. However,
these tend to have their own built-in resolvers that also do a little
cacheing as well: Netscape's dns_helper process for instance. Maybe
these keep track of the RTT to the nameservers in resolv.conf, who
knows? Or cares?

    >> So keeping track of the round trip times would be pointless for
    >> most things that use the DNS. The rotate option in the BIND8
    >> resolver might help a little, but only for the handful of
    >> applications which make lots of DNS lookups. And even then this
    >> only round-robins queries between the three nameserver
    >> directives, so the bad name server(s) still get queried.

    Ralf> What exactly is the name of that option (so I can look it up
    Ralf> in the docs)?

Er, rotate. Bear in mind that this might not be implemented in the
OS's resolver. Vendors generally ship very old name server code.

I maintain that you should address the real problem rather than tinker
at the margin with an obscure and not-widely-deployed resolver option
that doesn't really solve that problem. Fix the broken resolver
configurations so that they query reliable name servers. That's what's
actually wrong, isn't it? After all, you'd be changing resolv.conf
anyway to add this rotate option - assuming it works for you. You
might as well replace the broken nameserver directives while you're at
it.