Slow internal resolution

Kevin Darcy kcd at
Thu Mar 9 04:14:37 UTC 2000

Well, from the outside, and are both aliases to, which resides in the zone, all of which resolve fine, and
the name doesn't resolve at all. Unfortunately, you
haven't given us much to go on vis-a-vis your DNS architecture for resolving
internal versus external names, how you resolve things in "", are you
running a "split DNS", etc. so it's a matter of pure guesswork why some queries
for inside clients might be slow.

I don't really understand the references to "basic database" and "subnet
database" either; I don't think you're referring to anything that BIND uses.

As for using traceroute to troubleshoot DNS problems, be aware that the path
used to connect to a given server may be totally different than the paths used
between nameservers to translate that server's name into an IP address, so
I doubt that the traceroute results are going to help you much in
troubleshooting your query-slowness problem. What's more relevant is what
server the desktop clients are using to resolve the name, and how *that* server
is configured to resolve the name, whether it be forwarding, referral or

Lastly, don't worry too much about the age of your Internet root "cache" file
(assuming that's what you're referring to); I don't think it's changed much in
the last 4.5 years anyway, and you really only need 1 good entry in the file in
order to resolve Internet names.

- Kevin

Stewart.Ann wrote:

> One of our Web servers, which is, of course, outside the firewall, has a
> name that doesn't end with our domain name.  Specifically, our domain is
>, our main Web site is <> ,
> and the server in question (on the same subnet as
> <> ) is called
> <> .  The resolver lives at a different
> agency;  we have nothing to do with it.  The resolver lives here
> and I'm the homeless schizophrenic they picked up off the street to
> administer it, so I only know rudimentary things about DNS and BIND.  To
> make it worse, we're running BIND 4.9.3 and our cache table hasn't been
> updated for 4.5 years. <>  has 2
> aliases: and   All 3 are in our basic database,
> which we call (I inherited all of this -- don't blame anything on
> me).  The one in the subnet database file for 209.210.72 is
> <>  (with a dot after it). As far as I can tell,
> everything is right for <>  in our
> DNS tables.  If you do an nslookup, the name gets changed to
> <> , and it
> resolves to the correct IP address (
> >From the outside world, if you put
> <>  in your browser, you get the Web page
> immediately.  From inside the organization it takes "too long" (say, a
> minute or so) -- long enough that we're getting complaints.  If, from inside
> the organization, you put the IP address in the browser, you get the page
> immediately.  If, from inside the organization, you put in
> <> , you get it immediately.
> Before we started looking into this, my PC, from which I was testing it, and
> which runs NT workstation, had nothing for domain or DNS Service search
> order under TCP/IP protocol properties.  I added the domain ( and
> our (internal) primary and secondary name server IP addresses, and I was
> confident that this would solve the problem.  However, having the domain
> name and DNS name servers in my system doesn't help at all.
> tracert (from "DOS") waits a long time (about a minute), then shows the
> resolved name/IP (
> <> ) and 2 hops: 10ms to the first router
> and 10 ms to the second router, then fizzles out.  traceroute from a Unix
> machine waits about a minute, then shows the resolved name/IP and 3 hops:
> 1ms/1ms/1ms to the first router, 1ms/1ms/1ms to the second router, and
> 1ms/1ms/2ms to the firewall.
> Why does it take so long to get the name resolved?  At first I thought maybe
> it was going to the other agency to resolve the "", but based on the
> results from traceroute, it looks like it's resolving here.  Does it have
> something to do with the duplicated ""?  Is that confusing BIND?
> I get the digest, and would very much appreciate it if anyone answering
> would cc my e-mail address:  ann_stewart at
> <mailto:ann_stewart at> .
> Thank you.
> Ann Stewart
> DSSS Unix Support
> California Franchise Tax Board
> ann_stewart at
> (916) 845-3790

More information about the bind-users mailing list