Preliminary documentation for the dns-update function, from Brian Murrell.

common/dhcp-eval.5

@@ -207,11 +207,14 @@ the packet to which the server is responding.
 .PP
 .RS 0.25i
 The \fBhardware\fR operator returns a data string whose first element
-is the \fIhtype\fR field of the packet being considered, and whose
-subsequent elements are first \fIhlen\fR bytes of the \fIchaddr\fR
-field of the packet, as specified in \fBRFC 2131\fR .  If there is no
-packet, or if the \fIhlen\fR field is invalid, then the result is
-null.
+is the type of network interface indicated in packet being considered,
+and whose subsequent elements are client's link-layer address.   If
+there is no packet, or if the RFC2131 \fIhlen\fR field is invalid,
+then the result is null.   Hardware types include ethernet (1),
+token-ring (6), and fddi (8).   Hardware types are specified by the
+IETF, and details on how the type numbers are defined can be found in
+RFC2131 (in the ISC DHCP distribution, this is included in the doc/
+subdirectory).
 .RE
 .PP
 .B packet (\fIoffset\fB, \fIlength\fB)\fR
@@ -341,6 +344,52 @@ the current time and the time that the lease expires.
 Any number between zero and the maximum representable size may be
 specified as a numeric expression.
 .RE
+.SH REFERENCE: DYNAMIC DNS UPDATES
+.PP
+The DHCP client and server have the ability to dynamically update the
+Domain Name System.  Within the configuration files, you can define
+how you want the Domain Name System to be updated.  These updates are
+RFC 2136 compliant so any DNS server supporting RFC 2136 should be
+able to accept updates from the DHCP server.
+.SH SECURITY
+Support for TSIG and DNSSEC is not yet available.  When you set your
+DNS server up to allow updates from the DHCP server or client, you may
+be exposing it to unauthorized updates.  To avoid this, the best you
+can do right now is to use IP address-based packet filtering to
+prevent unauthorized hosts from submitting update requests.
+Obviously, there is currently no way to provide security for client
+updates - this will require TSIG or DNSSEC, neither of which is yet
+available in the DHCP distribution.
+.PP
+Dynamic DNS (DDNS) updates are performed by using the \fBdns-update\fR
+expression.  The \fBdns-update\fR expression is a boolean expression
+that takes four parameters.  If the update succeeds, the result is
+true.  If it fails, the result is false.  The four parameters that the
+are the resource record type (RR), the left hand side of the RR, the
+right hand side of the RR and the ttl that should be applied to the
+record.  The simplest example of the use of the function can be found
+in the reference section of the dhcpd.conf file, where events are
+described.  In this example several statements are being used to make
+the arguments to the \fBdns-update\f\R.
+.PP
+In the example, the first argument to the first \f\Bdns-update\fR
+expression is a data expression that evaluates to the A RR type.  The
+second argument is constructed by concatenating the DHCP host-name
+option with a text string containing the local domain, in this case
+"ssd.example.net".  The third argument is constructed by converting
+the address the client has been assigned from a 32-bit number into an
+ascii string with each byte separated by a ".".  The fourth argument,
+the TTL, specifies the amount of time remaining in the lease (note
+that this isn't really correct, since the DNS server will pass this
+TTL out whenever a request comes in, even if that is only a few
+seconds before the lease expires).
+.PP
+If the first \fBdns-update\fR statement succeeds, it is followed up
+with a second update to install a PTR RR.  The installation of a PTR
+record is similar to installing an A RR except that the left hand side
+of the record is the leased address, reversed, with ".in-addr.arpa"
+concatenated.  The right hand side is the fully qualified domain name
+of the client to which the address is being leased.
 .SH SEE ALSO
 dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8),
 dhclient(8), RFC2132, RFC2131.