DYNAMIC DNS UPDATE SECURITY
       When  you set your DNS server up to allow updates from the DHCP server,
       you may be exposing it to unauthorized updates.   To  avoid  this,  you
       should  use  TSIG  signatures  -  a method of cryptographically signing
       updates using a shared secret key.   As long as you protect the secrecy
       of  this key, your updates should also be secure.   Note, however, that
       the DHCP protocol itself provides no security,  and  that  clients  can
       therefore  provide information to the DHCP server which the DHCP server
       will then use in its updates, with  the  constraints  described  previ-
       ously.

       The  DNS  server  must be configured to allow updates for any zone that
       the DHCP server will be updating.  For example, let us say that clients
       in  the  sneedville.edu  domain  will  be  assigned  addresses  on  the
        10 . 10 . 17 . 0 / 24  subnet.  In that case, you will need  a  key  declaration
       for  the  TSIG  key you will be using, and also two zone declarations -
       one for the zone containing A records that will be updates and one  for
       the zone containing PTR records - for ISC BIND, something like this:

       key DHCP_UPDATER {
         algorithm HMAC-MD5.SIG-ALG.REG.INT;
         secret pRP5FapFoJ95JEL06sv4PQ==;
       };

       zone "example.org" {
            type master;
            file "example.org.db";
            allow-update { key DHCP_UPDATER; };
       };

       zone "17.10.10.in-addr.arpa" {
            type master;
            file "10.10.17.db";
            allow-update { key DHCP_UPDATER; };
       };

       You will also have to configure your DHCP server to do updates to these
       zones.   To do so,  you  need  to  add  something  like  this  to  your
       dhcpd.conf file:

       key DHCP_UPDATER {
         algorithm HMAC-MD5.SIG-ALG.REG.INT;
         secret pRP5FapFoJ95JEL06sv4PQ==;
       };

       zone EXAMPLE.ORG. {
         primary  127 . 0 . 0 . 1 ;
         key DHCP_UPDATER;
       }

       zone  17 . 127 . 10 .in-addr.arpa. {
         primary  127 . 0 . 0 . 1 ;
         key DHCP_UPDATER;
       }

       Note that the zone declarations have to correspond to authority records
       in your name server - in the above example, there must be an SOA record
       for  "example.org." and for "17.10.10.in-addr.arpa.".   For example, if
       there were a subdoman "foo.example.org" with no seperate SOA, you could
       not  write a zone declaration for "foo.example.org."  Also keep in mind
       that zone names in your DHCP configuration should end in a "."; this is
       the  preferred  syntax.  If you do not end your zone name in a ".", the
       DHCP server will figure it out.  Also note that in the DHCP  configura-
       tion,  zone names are not encapsulated in quotes where there are in the
       DNS configuration.

       You should choose your own secret key, of course.  The ISC BIND  8  and  9 
       distributions  come  with  a  program for generating secret keys called
       dnssec-keygen.  The version that comes with BIND  9  is likely to produce
       a  substantially more random key, so we recommend you use that one even
       if you are not using BIND  9  as your DNS server.  If you are using  BIND
        9 's dnssec-keygen, the above key would be created as follows:
            dnssec-keygen -a HMAC-MD5 -b  128  -n USER DHCP_UPDATER