diff options
author | Ted Lemon <source@isc.org> | 1999-07-31 18:30:14 +0000 |
---|---|---|
committer | Ted Lemon <source@isc.org> | 1999-07-31 18:30:14 +0000 |
commit | 3c8a36ab52c287f9692a2909e0fa46bca10cfef2 (patch) | |
tree | 016b589e64d7ef3e1330d6d799f76117f8cc11a6 /common/dhcp-eval.5 | |
parent | 7b9767eaa816a358d35864029adbc5729bba68b7 (diff) | |
download | isc-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.5 | 59 |
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. |