BIND 8.2.3, DDNS, and search directive.

Danny Mayer mayer at
Wed Dec 18 03:45:18 UTC 2002

At 02:55 PM 12/17/02, Edwin Davidson wrote:

First of all, run, don't walk, and get yourself the latest version of BIND.
8.3.4 if you must still run BIND 8, 9.2.2rc1 if you can run BIND 9.
There are many security fixes between your version and these, not
to mention bug fixes.

>I have a forward zone called which has my servers listed in
>I have dDNS enabled to allow updates to this zone from the DHCP
>server, so I have;
>DHCP hands out the "domain" of, so when the user tries
>a non FQDN name, say of server1, the client resolves
>An issue occurs when, for whatever reason, a server is switched from a
>static IP address to use DHCP.

You should never be running a server with a dynamic address. Client
addresses can change, server addresses never should. Even worse,
since Microsoft implemented DNS Client Caching in 2K and XP the
clients, once they have retrieved the address keep it in memory, until
the timeout. You are going to get all sorts of strange behaviours
because of this.

>   The admin may be using Ghost to back
>it up. I end up with two A records;

I believe that you can tell DHCP that you require the IP address to
be unique, but check the documentation for details.

>To resolve this issue, I would like to setup a domain of
> and have dDNS update go to this domain, and this
>domain only.  The problem is that when my client tries to resolve a
>non FQDN name, say server1, it doesn't resolve.  It tries
> but not

You should make it a practice always fully qualifying domain names.
This demonstrates the reason why.

>According to the O'Reilly book, the SEARCH directive in RESOLV.CONF is
>what I should use -- however my entire setup is NT, and there is no
>RESOLV.CONF.   I have configured the NT DNS servers to have domain
>suffix search order of:
>But this doesn't work.

It shouldn't. It has nothing to do with a server. It's a client side issue.
Windows doesn't have a resolv.conf as you know, because it puts
everything in the registry. You need to be looking at the CLIENT.
There is a setting in the DNS setup of the clients' network control
panel which allows you to specify the search order. I don't remember
if giving a search order overrides the domain name but I believe it
does. On Unix, the last one in the resolv.conf file defines how it gets

>   NSlookup from the client to the DNS server for
>SERVER1 still results in a query for  It
>never tries to query

Right. See above.

>I tried adding the domain suffix search order at the NT workstation
>level, but it doesn't follow my domain suffix search order. I go into
>control panel and add first then

Did you do this on each client?

>If the client is handed a domain of, then it will
>alway append first, regardless of the fact that
> is first in my search order.

As I said before, train the users to use FQDN.

>This doesn't solve my example problem.  If a network admin takes a
>static IP server, grabs a lease for Ghosting, then reboots - I have
>two A records. and  When
>the client makes a non FQDN query for server1, the client now always

You need to train your network admins and give them a fixed IP address to
use while Ghosting and avoid the problem.

>Is there a way to do this?  I want non FQDN names to ALWAYS search
>(append) first, then try second.  I just am
>not finding anyway to do this.

Did you do this on the client or the server?


>Edwin Davidson

More information about the bind-users mailing list