summaryrefslogtreecommitdiff
path: root/common/dhcp-eval.5
diff options
context:
space:
mode:
authorTed Lemon <source@isc.org>1999-07-31 18:30:14 +0000
committerTed Lemon <source@isc.org>1999-07-31 18:30:14 +0000
commit3c8a36ab52c287f9692a2909e0fa46bca10cfef2 (patch)
tree016b589e64d7ef3e1330d6d799f76117f8cc11a6 /common/dhcp-eval.5
parent7b9767eaa816a358d35864029adbc5729bba68b7 (diff)
downloadisc-dhcp-3c8a36ab52c287f9692a2909e0fa46bca10cfef2.tar.gz
Preliminary documentation for the dns-update function, from Brian Murrell.
Diffstat (limited to 'common/dhcp-eval.5')
-rw-r--r--common/dhcp-eval.559
1 files changed, 54 insertions, 5 deletions
diff --git a/common/dhcp-eval.5 b/common/dhcp-eval.5
index cce50431..6c0b28e1 100644
--- a/common/dhcp-eval.5
+++ b/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.