Dynamic DNS Server Updates

Barry Finkel b19141 at achilles.ctd.anl.gov
Fri Jun 3 13:43:28 UTC 2005


"Ryan Davis" <rdavis542 at comcast.net> wrote:

>Greetings:
>
>Been reading through the list for about a week and don't seem to see an
>answer to this, but I have a BIND 9.3.1 server running on Solaris 10 x86
>with a fake domain (internal network) and can't seem to get my DHCP clients
>to update their records to it.  The DHCP addresses to my clients are
>provided by a router and I don't want to run an additional DHCP server as
>the router works fine.  Is there a way to get my clients to update to the
>DDNS server or have the server update these records when it tries to
>register itself with the DNS server?  Nothing seems to be showing up in my
>Windows Event log about not being able to register DNS so I'm assuming it's
>on the BIND side.  Connectivity seems fine as I can see the clients talking
>to the server through a "snoop" command.
>
>Any help is appreciated.  
>
>Respectfully,
>
>Ryan Davis
>
>=========================================================
>My config files
>
>bash-3.00# named -v
>BIND 9.3.1
>bash-3.00# cat /etc/named.conf
>options {
>        directory "/var/named";
>        pid-file "/var/run/named.pid";
>        query-source port *;
>        allow-query { any; };
>        allow-recursion { any; };
>        listen-on { any; };
>        dump-file "named_dump.db";
>        statistics-file "named.stats";
>};
>
>logging {
>        channel sec_file {
>                file "log/bind_security.log";
>#                severity dynamic;
>                severity debug 3;
>                print-time yes;
>                print-category yes;
>                print-severity yes;
>        };
>
>        category default  { sec_file; };
>        category general  { sec_file; };
>        category client   { sec_file;  };
>        category config   { sec_file;  };
>        category database { sec_file; };
>        category dnssec   { sec_file;  };
>        category lame-servers { sec_file; };
>        category network  { sec_file; };
>        category notify   { sec_file; };
>        category queries  { sec_file;  };
>        category resolver { sec_file;  };
>        category security { sec_file;  };
>        category update   { sec_file; };
>        category xfer-in  { sec_file; };
>        category xfer-out { sec_file;  };
>
>};
>
>zone "." IN {
>        type hint;
>        file "root.hint";
>};
>
>zone "localhost" IN {
>  type master;
>  file "localhost.zone";
>};
>
>zone "0.0.127.in-addr.arpa" IN {
>  type master;
>  file "127.0.0.zone";
>};
>
>zone "fake.lan" IN {
>        type master;
>        file "zone/clients.db";
>        allow-update{ 192.168.0/24; };
>};
>
>zone "0.168.192.in-addr.arpa" IN {
>        type master;
>        file "zone/clients.rev";
>        allow-update { 192.168.0/24; };
>};
>
>=================================================
>
>bash-3.00# cat clients.db
>$ORIGIN .
>$TTL 86400      ; 1 day
>fake.lan                IN SOA  amd1800.fake.lan. root.amd1800.fake.lan. (
>                                2005052521 ; serial
>                                21600      ; refresh (6 hours)
>                                3600       ; retry (1 hour)
>                                69120      ; expire (19 hours 12 minutes)
>                                86400      ; minimum (1 day)
>                                )
>                        NS      amd1800.fake.lan.
>$ORIGIN fake.lan.
>amd1800                 A       192.168.0.150
>localhost               A       127.0.0.1
>
>====================================================
>
>bash-3.00# cat clients.rev
>$ORIGIN .
>$TTL 86400      ; 1 day
>0.168.192.in-addr.arpa  IN SOA  amd1800.fake.lan. root.fake.lan. (
>                                2005052521 ; serial
>                                21600      ; refresh (6 hours)
>                                3600       ; retry (1 hour)
>                                69100      ; expire (19 hours 11 minutes 40
>seconds)
>                                86400      ; minimum (1 day)
>                                )
>                        NS      amd1800.fake.lan.
>$ORIGIN 0.168.192.in-addr.arpa.
>150                     PTR     amd1800.fake.lan.


You probably should be searching the list archives at isc.org, as there
have been many postings about DHCP and DDNS over the years.

I am not an expert in DHCP, and I know of at least three DHCP
implementations; all do not behave identically.  And since this is a
BIND discussion list, details of DHCP are not covered in detail.

> and can't seem to get my DHCP clients to update their records to it.

There are two types of DHCP updates - 

   1) The DHCP server dynamically registers both the forward and
      reverse for the client.

   2) The DHCP server registers one, and the client registers the
      other.  I do not remember which registers which.

For any DDNS update, say for

     clientmachine1.example.com

the software performing the registration will do a DNS query to 
retrieve the SOA record for the zone to be updated, in this example,

     example.com

Within the SOA record is the MNAME field.  This field gives the name
of the master DNS server for the zone.  All DDNS updates are then sent
to this master DNS server.  If you do not have the correct DNS server
in the MNAME field (and I believe that DDNS is the ONLY real use of this
field), then the DDNS updates will not be sent to the correct machine.
Also, if the client machine and/or DHCP server is attempting to 
register the client in a different domain, say

     example1.com

then the DDNS updates will not be sent to the DNS server that you
expect.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory          Phone:    +1 (630) 252-7277
9700 South Cass Avenue               Facsimile:+1 (630) 252-4601
Building 222, Room D209              Internet: BSFinkel at anl.gov
Argonne, IL   60439-4828             IBMMAIL:  I1004994



More information about the bind-users mailing list