Home network: using bind for name resolution

Kevin Darcy kcd at daimlerchrysler.com
Sat Aug 19 00:18:56 UTC 2000


Bruce Phipps wrote:

> I have a home network with a dial-up modem link to my ISP. I am trying to
> learn the basics of DNS by:
>
> * Implementing a caching-only nameserver
> * Using named to resolve names on the internal network
>
> 10.0.0.2    Elvis.myinternal.net    #Linux, running named8.2
> 10.0.0.4    Gordon.myinternal.net
>
> where myinternal.net is an "invented" name for the home network.
> /etc/resolv.conf has:
> domain myinternal.net
> nameserver    127.0.0.1
>
> nslookup Elvis.myinternal.net is OK
> nslookup 10.0.0.4 is OK
>
> nslookup myinternal.net gives
> myinternal.net.myinternal.net
>
> Has anyone seen this error before? Probably a missing dot!

Maybe. The combination of a missing dot and nslookup's "search" behavior could
generate this result -- yet another reason to use "dig" instead of nslookup.

I recommend using "@" for all records owned by the domain name itself. No
chance of a missing dot problem there!

> I also connected to my ISP and did a few nslookups (yahoo.com etc.) -- they
> worked OK.
> But then I logged off and tried:
>
> nslookup yahoo.com
>
> expecting named to have cached  the correct answer while I was online and so
> I could retrieve it locally.
> But named dialled out to look for yahoo.com! Obvuiously isn't caching it
> locally..

You can dump named's database using "ndc dumpdb" or by sending a INT signal to
the "named" process. By looking at the dump file you can tell if certain
records are in the cache at any given point in time. I'll note that yahoo.com's
A records have a TTL (time to live) of only 30 minutes. So if it was 30 minutes
or more between lookups, that explains why your nameserver had to re-fetch
them.


- Kevin





More information about the bind-users mailing list