Commit 29dce0da authored by Shawn Routhier's avatar Shawn Routhier
Browse files

Documentation fixes

[ISC-Bugs #17959] add text to AIX section describing how to have it send
responses to the all-ones address.
[ISC-Bugs #19615] update the includes in dhcpctl/dhcpctl.3 to be more correct
[ISC-Bugs #20676] update dhcpd.conf.5 to include the RFC numbers for DDNS
parent ad321100
......@@ -454,10 +454,26 @@ server and relay will work only on a single interface. (They do work
on multi-interface machines if configured to listen on only one of the
interfaces.)
We have reports of Windows XP clients having difficutly retrieving
addresses from a server running on an AIX machine. This issue
was traced to the client requiring messages be sent to the all ones
broadcast address (255.255.255.255) while the AIX server was sending
to 192.168.0.255.
You may be able to solve this by including a relay between the client
and server with the relay configured to use a broadcast of all-ones.
A second option that worked for AIX 5.1 but doesn't seem to work for
AIX 5.3 was to:
create a host file entry for all-ones (255.255.255.255)
and then add a route:
route add -host all-ones -interface <local-ip-address>
The ISC DHCP distribution does not include a dhclient-script for AIX--
AIX comes with a DHCP client. Contribution of a working dhclient-script
for AIX would be welcome.
MacOS X
The MacOS X system uses a TCP/IP stack derived from FreeBSD with a
......
......@@ -135,6 +135,12 @@ work on other platforms. Please report any problems and suggested fixes to
subnet the root configuration area is examined. Server now also returns
vendor-class-id option, if client sent it. [ISC-Bugs #21094]
- Documentation fixes
[ISC-Bugs #17959] add text to AIX section describing how to have it send
responses to the all-ones address.
[ISC-Bugs #19615] update the includes in dhcpctl/dhcpctl.3 to be more correct
[ISC-Bugs #20676] update dhcpd.conf.5 to include the RFC numbers for DDNS
Changes since 4.1-ESV-R1
! In dhclient check the data for some string options for
......
......@@ -2,8 +2,9 @@
.\"
.\" Project: DHCP
.\" File: dhcpctl.3
.\" RCSId: $Id: dhcpctl.3,v 1.6.8.2 2009/07/24 22:04:52 sar Exp $
.\" RCSId: $Id: dhcpctl.3,v 1.6.8.2.10.1 2011/04/26 00:01:57 sar Exp $
.\"
.\" Copyright (c) 2011 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 2000-2003 by Internet Software Consortium
.\" Copyright (c) 2000 Nominum, Inc.
......@@ -417,16 +418,20 @@ released.
The following program will connect to the DHCP server running on the local
host and will get the details of the existing lease for IP address
10.0.0.101. It will then print out the time the lease is due to expire. Note
that most error checking has been ommitted for brevity.
that most error checking has been ommitted for brevity.
.Bd -literal -offset indent
#include <stdarg.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <isc/result.h>
#include <dhcpctl/dhcpctl.h>
#include "isc-dhcp/result.h"
#include "dhcpctl.h"
int main (int argc, char **argv) {
dhcpctl_data_string ipaddrstring = NULL;
......
.\" dhcpd.conf.5
.\"
.\" Copyright (c) 2004-2010 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 2004-2011 by Internet Systems Consortium, Inc. ("ISC")
.\" Copyright (c) 1996-2003 by Internet Software Consortium
.\"
.\" Permission to use, copy, modify, and distribute this software for any
......@@ -27,7 +27,7 @@
.\" Support and other services are available for ISC products - see
.\" https://www.isc.org for more information or to learn more about ISC.
.\"
.\" $Id: dhcpd.conf.5,v 1.99.10.4 2010/07/02 23:37:07 sar Exp $
.\" $Id: dhcpd.conf.5,v 1.99.10.4.6.1 2011/04/26 00:01:57 sar Exp $
.\"
.TH dhcpd.conf 5
.SH NAME
......@@ -1048,13 +1048,13 @@ compliant so any DNS server supporting RFC 2136 should be able to
accept updates from the DHCP server.
.PP
Two DNS update schemes are currently implemented, and another is
planned. The two that are currently available are the ad-hoc DNS
planned. The two that are currently implemented are the ad-hoc DNS
update mode and the interim DHCP-DNS interaction draft update mode.
If and when the DHCP-DNS interaction draft and the DHCID draft make it
through the IETF standards process, there will be a third mode, which
will be the standard DNS update method. The DHCP server must be
configured to use one of the two currently-supported methods, or not
to do dns updates. This can be done with the
In the future we plan to add a third mode which will be the standard
DNS update method based on the RFCS for DHCP-DNS interaction and DHCID
The DHCP server must be configured to use one of the two
currently-supported methods, or not to do dns updates.
This can be done with the
.I ddns-update-style
configuration parameter.
.SH THE AD-HOC DNS UPDATE SCHEME
......@@ -1146,15 +1146,31 @@ by sending a DHCPRELEASE message, the server will likewise remove the
A and PTR records.
.SH THE INTERIM DNS UPDATE SCHEME
The interim DNS update scheme operates mostly according to several
drafts that are being considered by the IETF and are expected to
become standards, but are not yet standards, and may not be
standardized exactly as currently proposed. These are:
drafts considered by the IETF. While the drafts have since become
RFCs the code was written before they were finalized and there are
some differences between our code and the final RFCs. We plan to
update our code, probably adding a standard DNS update option, at
some time. The basic framework is similar with the main material
difference being that a DHCID RR was assigned in the RFCs whereas
our code continues to use an experimental TXT record. The format
of the TXT record bears a resemblance to the DHCID RR but it is not
equivalent (MD5 vs SHA1, field length differences etc).
The standard RFCs are:
.PP
.nf
.ce 3
RFC 4701 (updated by RF5494)
RFC 4702
RFC 4703
.fi
.PP
And the corresponding drafts were:
.PP
.nf
.ce 3
draft-ietf-dhc-ddns-resolution-??.txt
draft-ietf-dhc-fqdn-option-??.txt
draft-ietf-dnsext-dhcid-rr-??.txt
draft-ietf-dhc-fqdn-option-??.txt
draft-ietf-dhc-ddns-resolution-??.txt
.fi
.PP
Because our implementation is slightly different than the standard, we
......@@ -1233,15 +1249,12 @@ gives up trying to do a DNS update for the client until the client
chooses a new name.
.PP
The interim DNS update scheme is called interim for two reasons.
First, it does not quite follow the drafts. The current versions of
the drafts call for a new DHCID RRtype, but this is not yet
available. The interim DNS update scheme uses a TXT record
instead. Also, the existing ddns-resolution draft calls for the DHCP
server to put a DHCID RR on the PTR record, but the \fIinterim\fR
update method does not do this. It is our position that this is not
useful, and we are working with the author in hopes of removing it
from the next version of the draft, or better understanding why it is
considered useful.
First, it does not quite follow the RFCs. The RFCs call for a
new DHCID RRtype while he interim DNS update scheme uses a TXT record.
The ddns-resolution draft cllaed for the DHCP server to put a DHCID RR
on the PTR record, but the \fIinterim\fR update method does not do this.
In the final RFC this requirement was relaxed such that a server may
add a DHCID RR to the PTR record.
.PP
In addition to these differences, the server also does not update very
aggressively. Because each DNS update involves a round trip to the
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment