BIND 8.2.3, DDNS, and search directive.

[Danny Mayer]

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 domain.com which has my servers listed in
>it.
>server1.domain.com
>server2.domain.com
>
>I have dDNS enabled to allow updates to this zone from the DHCP
>server, so I have;
>client1.domain.com
>client2.domain.com
>
>DHCP hands out the "domain" of domain.com, so when the user tries
>a non FQDN name, say of server1, the client resolves
>server1.domain.com
>
>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;
>
>server1.domain.com  192.168.100.1
>server1.domain.com  192.168.123.23

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
>dDNS.domain.com 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
>server1.ddns.domain.com but not server1.domain.com

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:
>
>domain.com
>ddns.domain.com
>
>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
searched.

>   NSlookup from the client to the DNS server for
>SERVER1 still results in a query for server1.ddns.domain.com.  It
>never tries to query server1.domain.com.

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 domain.com first then ddns.domain.com.

Did you do this on each client?


>If the client is handed a domain of ddns.domain.com, then it will
>alway append ddns.domain.com first, regardless of the fact that
>domain.com 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.  server1.ddns.domain.com and server1.domain.com.  When
>the client makes a non FQDN query for server1, the client now always
>gets server1.ddns.domain.com.

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) domain.com first, then try ddns.domain.com second.  I just am
>not finding anyway to do this.

Did you do this on the client or the server?

Danny

>Thanks;
>
>Edwin Davidson