Naturally, we like to use perl to get the job done efficiently. Using the Net::DNS package, we can use perl to perform updates:

    #!/usr/bin/perl -w
    use Net::DNS;
    use strict;

    my $key_name = 'update_key';
    my $key = 'fxT7q+Kq8TUmZrN4edxAVeTeOmiX/3A6HQ40HcyI...g==';

    # Create the update packet.
    my $update = Net::DNS::Update->new('domain.tld');

    # Add a TXT record to the domain
    $update->push(update => rr_add('testrec.domain.tld 86400 IN TXT "A test record"'));

    # Send the update to the zone's primary master.
    my $res = Net::DNS::Resolver->new;
    $res->nameservers('192.168.1.3');

    # Sign the update message
    $update->sign_tsig($key_name, $key);

    my $reply = $res->send($update);

    # Check return code
    if ($reply) {
      if ($reply->header->rcode eq 'NOERROR' ) {
        print "Update succeeded\n";
      } else {
        print 'Update failed ', $reply->header->rcode, "\n";
      }
    } else {
      print 'Update failed', $res->errorstring, "\n";
    }

Also be aware that once you start using dynamic updates, you can't really use manual editing of the zones anymore. The BIND server maintains journal files which contain a record of dynamic updates and these need to be taken into account. If you do need to edit a zone manually, the only way is to shut down the DNS server, remove the zone journal ( .jnl ) file, edit the zone, and start the server again.

TSIG-secured zone transfers

Firstly, generate a key to be used for zone transfers. This should not be the same as the key you created for dynamic updates. You could create a separate key for each slave server, but in the examples below I've created a single key for all slaves.

Generate a new key on the master, named "slave_xfers_key":

  dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n HOST slave_xfers_key

  key slave_xfers_key {
        algorithm HMAC-MD5;
        secret "mv0NxiVT4ho/TZbvPID+Kg==";
  };

  zone "domain.tld" IN {
        type master;
        file "domain.tld";
        allow-update { key update_key; };
        allow-transfer { key slave_xfers_key; };
  };

  zone "1.168.192.in-addr.arpa" IN {
        type master;
        file "1.168.192.in-addr.arpa";
        allow-update { key update_key; };
        allow-transfer { key slave_xfers_key; };
  };

On the slave server, configure the same key for the zone in /etc/named.conf:

  key slave_xfers_key {
        algorithm HMAC-MD5;
        secret "mv0NxiVT4ho/TZbvPID+Kg==";
  };

  server 192.168.1.3 {
    keys { slave_xfers_key; };
  };

Now, restart the slave server, and check syslog for errors. If the TSIG-secured zone transfer is successful you should see the following syslog messages on the slave server :

  named[3733]: zone domain.tld/IN: Transfer started.
  named[3733]: transfer of 'domain.tld/IN' from 192.168.1.3#53: connected using 192.168.1.2#32835
  named[3733]: zone domain.tld/IN: transferred serial 1: TSIG 'slave_xfers_key'
  named[3733]: transfer of 'domain.tld/IN' from 192.168.1.3#53: end of transfer

DHCP dynamic updates

In this scenario, we have a client device ( such as a laptop ) which wants to connect to networks and be allocated an IP address ( otherwise known as a DHCP lease ). The client would also like to choose its own host name on the network to be inserted into DNS. In this example I'll configure my linux-based laptop to have the name "gorgon" allocated to it when it connects to networks with a DHCP server and dynamic DNS updates which permit client elected names.

There is 3 steps we need to take to achieve this:

• Step 1 : configure the DHCP server and DNS server to use TSIG dynamic updates
• Step 2 : configure the DHCP server to update the DNS server each time a lease is let for the subnet
• Step 3 : configure the DHCP client to give the DHCP server a domain name to insert into DNS

Step 1. We've already configured our DNS server to permit signed updates above, so using the ISC DHCPD server we can configure the update_key by adding the following into /etc/dhcpd.conf:

  key update_key {
    algorithm HMAC-MD5;
    secret "fxT7q+Kq8TUmZrN4edxAVeTeOmiX/3A6HQ40HcyI...g==";
  }

  zone 1.168.192.in-addr.arpa {
    key update_key;
    primary 192.168.1.3;
  }

  zone domain.tld {
    key update_key;
    primary 192.168.1.3;
  }

  ddns-updates on;
  ddns-update-style interim;
  allow client-updates;

Step 2. when the DHCP server leases an address for a subnet, instruct it to also send a DNS update, in /etc/dhcpd.conf we add a couple of lines to the subnet statement:

  subnet 192.168.1.0 netmask 255.255.255.0 {
      option domain-name "domain.tld";
      option domain-name-servers 192.168.1.3;
      option routers 192.168.1.1;
      range 192.168.1.20 192.168.1.254;

      # Dynamic DNS updates:
      ddns-domainname "domain.tld";
      ddns-rev-domainname "1.168.192.in-addr.arpa";
  }

Step 3. Configure the DHCP-enabled clients to send their names to the DHCP server. Most Windows clients seem to do this automatically, but some *nix DHCP clients need configuration. For those using the ISC DHCP client software, this is in /etc/dhclient.conf and should look like the following example:

     send host-name "gorgon";
     send fqdn.fqdn "gorgon.domain.tld.";
     send fqdn.encoded on;
     send fqdn.server-update on;

There is a number of ways of integrating DHCP and dynamic DNS. An alternative to the above could be to have the clients call a script after they get a DHCP lease and use nsupdate to send the updates themselves. In this case each client would need a TSIG key in order to secure the update packets.

Conclusion

References

Secure Dynamic DNS HOWTO
http://ops.ietf.org/dns/dynupd/secure-ddns-howto.html

Dynamic DNS updates with isc-dhcpd
http://tinyurl.com/6lssd

BIND v9 ARM ( Administrators Reference Manual )
http://www.nominum.com/content/documents/bind9arm.pdf

DNSSEC Operations HOWTO
http://www.ripe.net/disi/Course/TechCourse.pdf

Nominum DNSSEC FAQ
http://www.nominum.com/getOpenSourceResource.php?id=8