dhcpd.conf.5

DHCP服务器源码

"fs.sneedville.edu", and the client claims its hostname is "fs", no
DNS update will be done for that client, and an error message will be
logged.
.PP
If the A record update succeeds, a PTR record update for the assigned
IP address will be done, pointing to the A record.   This update is
unconditional - it will be done even if another PTR record of the same
name exists.   Since the IP address has been assigned to the DHCP
server, this should be safe.
.PP
Please note that the current implementation assumes clients only have
a single network interface.   A client with two network interfaces
will see unpredictable behavior.   This is considered a bug, and will
be fixed in a later release.   It may be helpful to enable the
.I one-lease-per-client
parameter so that roaming clients do not trigger this same behavior.
.PP
The DHCP protocol normally involves a four-packet exchange - first the
client sends a DHCPDISCOVER message, then the server sends a
DHCPOFFER, then the client sends a DHCPREQUEST, then the server sends
a DHCPACK.   In the current version of the server, the server will do
a DNS update after it has received the DHCPREQUEST, and before it has
sent the DHCPACK.   It only sends the DNS update if it has not sent
one for the client's address before, in order to minimize the impact
on the DHCP server.
.PP
When the client's lease expires, the DHCP server (if it is operating
at the time, or when next it operates) will remove the client's A and
PTR records from the DNS database.   If the client releases its lease
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:
.PP
.nf
.ce 3
draft-ietf-dhc-ddns-resolution-??.txt
draft-ietf-dhc-fqdn-option-??.txt
draft-ietf-dnsext-dhcid-rr-??.txt
.fi
.PP
Because our implementation is slightly different than the standard, we
will briefly document the operation of this update style here.
.PP
The first point to understand about this style of DNS update is that
unlike the ad-hoc style, the DHCP server does not necessarily
always update both the A and the PTR records.   The FQDN option
includes a flag which, when sent by the client, indicates that the
client wishes to update its own A record.   In that case, the server
can be configured either to honor the client's intentions or ignore
them.   This is done with the statement \fIallow client-updates;\fR or
the statement \fIignore client-updates;\fR.   By default, client
updates are allowed.
.PP
If the server is configured to allow client updates, then if the
client sends a fully-qualified domain name in the FQDN option, the
server will use that name the client sent in the FQDN option to update
the PTR record.   For example, let us say that the client is a visitor
from the "radish.org" domain, whose hostname is "jschmoe".   The
server is for the "example.org" domain.   The DHCP client indicates in
the FQDN option that its FQDN is "jschmoe.radish.org.".   It also
indicates that it wants to update its own A record.   The DHCP server
therefore does not attempt to set up an A record for the client, but
does set up a PTR record for the IP address that it assigns the
client, pointing at jschmoe.radish.org.   Once the DHCP client has an
IP address, it can update its own A record, assuming that the
"radish.org" DNS server will allow it to do so.
.PP
If the server is configured not to allow client updates, or if the
client doesn't want to do its own update, the server will simply
choose a name for the client, possibly using the hostname supplied by
the client ("jschmoe" in the previous example).   It will use its own
domain name for the client, just as in the ad-hoc update scheme.
It will then update both the A and PTR record, using the name that it
chose for the client.   If the client sends a fully-qualified domain
name in the fqdn option, the server uses only the leftmost part of the
domain name - in the example above, "jschmoe" instead of
"jschmoe.radish.org".
.PP
The other difference between the ad-hoc scheme and the interim
scheme is that with the interim scheme, a method is used that
allows more than one DHCP server to update the DNS database without
accidentally deleting A records that shouldn't be deleted nor failing
to add A records that should be added.   The scheme works as follows:
.PP
When the DHCP server issues a client a new lease, it creates a text
string that is an MD5 hash over the DHCP client's identification (see
draft-ietf-dnsext-dhcid-rr-??.txt for details).   The update adds an A
record with the name the server chose and a TXT record containing the
hashed identifier string (hashid).   If this update succeeds, the
server is done.
.PP
If the update fails because the A record already exists, then the DHCP
server attempts to add the A record with the prerequisite that there
must be a TXT record in the same name as the new A record, and that
TXT record's contents must be equal to hashid.   If this update
succeeds, then the client has its A record and PTR record.   If it
fails, then the name the client has been assigned (or requested) is in
use, and can't be used by the client.   At this point the DHCP server
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.
.PP
In addition to these differences, the server also does not update very
aggressively.  Because each DNS update involves a round trip to the
DNS server, there is a cost associated with doing updates even if they
do not actually modify the DNS database.   So the DHCP server tracks
whether or not it has updated the record in the past (this information
is stored on the lease) and does not attempt to update records that it
thinks it has already updated.
.PP
This can lead to cases where the DHCP server adds a record, and then
the record is deleted through some other mechanism, but the server
never again updates the DNS because it thinks the data is already
there.   In this case the data can be removed from the lease through
operator intervention, and once this has been done, the DNS will be
updated the next time the client renews.
.SH DYNAMIC DNS UPDATE SECURITY
.PP
When you set your DNS server up to allow updates from the DHCP server,
you may be exposing it to unauthorized updates.  To avoid this, you
should use TSIG signatures - a method of cryptographically signing
updates using a shared secret key.   As long as you protect the
secrecy of this key, your updates should also be secure.   Note,
however, that the DHCP protocol itself provides no security, and that
clients can therefore provide information to the DHCP server which the
DHCP server will then use in its updates, with the constraints
described previously.
.PP
The DNS server must be configured to allow updates for any zone that
the DHCP server will be updating.  For example, let us say that
clients in the sneedville.edu domain will be assigned addresses on the
10.10.17.0/24 subnet.  In that case, you will need a key declaration
for the TSIG key you will be using, and also two zone declarations -
one for the zone containing A records that will be updates and one for
the zone containing PTR records - for ISC BIND, something like this:
.PP
.nf
key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret pRP5FapFoJ95JEL06sv4PQ==;
};

zone "example.org" {
	type master;
	file "example.org.db";
	allow-update { key DHCP_UPDATER; };
};

zone "17.10.10.in-addr.arpa" {
	type master;
	file "10.10.17.db";
	allow-update { key DHCP_UPDATER; };
};
.fi
.PP
You will also have to configure your DHCP server to do updates to
these zones.   To do so, you need to add something like this to your
dhcpd.conf file:
.PP
.nf
key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret pRP5FapFoJ95JEL06sv4PQ==;
};

zone EXAMPLE.ORG. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

zone 17.127.10.in-addr.arpa. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}
.fi
.PP
The \fIprimary\fR statement specifies the IP address of the name
server whose zone information is to be updated.
.PP
Note that the zone declarations have to correspond to authority
records in your name server - in the above example, there must be an
SOA record for "example.org." and for "17.10.10.in-addr.arpa.".   For
example, if there were a subdoman "foo.example.org" with no separate
SOA, you could not write a zone declaration for "foo.example.org."  
Also keep in mind that zone names in your DHCP configuration should end in a
"."; this is the preferred syntax.  If you do not end your zone name in a
".", the DHCP server will figure it out.  Also note that in the DHCP
configuration, zone names are not encapsulated in quotes where there are in
the DNS configuration.
.PP
You should choose your own secret key, of course.  The ISC BIND 8 and
9 distributions come with a program for generating secret keys called
dnssec-keygen.  The version that comes with BIND 9 is likely to produce a
substantially more random key, so we recommend you use that one even
if you are not using BIND 9 as your DNS server.  If you are using BIND 9's
dnssec-keygen, the above key would be created as follows:
.PP
.nf
	dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER
.fi
.PP
If you are using the BIND 8 dnskeygen program, the following command will
generate a key as seen above:
.PP
.nf
	dnskeygen -H 128 -u -c -n DHCP_UPDATER
.fi
.PP
You may wish to enable logging of DNS updates on your DNS server.
To do so, you might write a logging statement like the following:
.PP
.nf
logging {
	channel update_debug {
		file "/var/log/update-debug.log";
		severity	debug 3;
		print-category	yes;
		print-severity	yes;
		print-time	yes;
	};
	channel security_info	{
		file	"/var/log/named-auth.info";
		severity	info;
		print-category	yes;
		print-severity	yes;
		print-time	yes;
	};

	category update { update_debug; };
	category security { security_info; };
};
.fi
.PP
You must create the /var/log/named-auth.info and
/var/log/update-debug.log files before starting the name server.   For
more information on configuring ISC BIND, consult the documentation
that accompanies it.
.SH REFERENCE: EVENTS
.PP
There are three kinds of events that can happen regarding a lease, and
it is possible to declare statements that occur when any of these
events happen.   These events are the commit event, when the server
has made a commitment of a certain lease to a client, the release
event, when the client has released the server from its commitment,
and the expiry event, when the commitment expires.
.PP
To declare a set of statements to execute when an event happens, you
must use the \fBon\fR statement, followed by the name of the event,
followed by a series of statements to execute when the event happens,
enclosed in braces.   Events are used to implement DNS
updates, so you should not define your own event handlers if you are
using the built-in DNS update mechanism.
.PP
The built-in version of the DNS update mechanism is in a text
string towards the top of server/dhcpd.c.   If you want to use events
for things other than DNS updates, and you also want DNS updates, you
will have to start out by copying this code into your dhcpd.conf file
and modifying it.
.SH REFERENCE: DECLARATIONS
.PP
.B The 
.I shared-network
.B statement
.PP
.nf
 \fBshared-network\fR \fIname\fR \fB{\fR
   [ \fIparameters\fR ]
   [ \fIdeclarations\fR ]
 \fB}\fR
.fi
.PP
The \fIshared-network\fR statement is used to inform the DHCP server
that some IP subnets actually share the same physical network.  Any
subnets in a shared network should be declared within a
\fIshared-network\fR statement.  Parameters specified in the
\fIshared-network\fR statement will be used when booting clients on
those subnets unless parameters provided at the subnet or host level
override them.  If any subnet in a shared network has addresses
available for dynamic allocation, those addresses are collected into a
common pool for that shared network and assigned to clients as needed.
There is no way to distinguish on which subnet of a shared network a
client should boot.
.PP
.I Name
should be the name of the shared network.   This name is used when
printing debugging messages, so it should be descriptive for the
shared network.   The name may have the syntax of a valid domain name
(although it will never be used as such), or it may be any arbitrary
name, enclosed in quotes.
.PP
.B The 
.I subnet
.B statement
.PP
.nf
 \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR
   [ \fIparameters\fR ]
   [ \fIdeclarations\fR ]
 \fB}\fR
.fi
.PP
The \fIsubnet\fR statement is used to provide dhcpd with enough
information to tell whether or not an IP address is on that subnet.
It may also be used to provide subnet-specific parameters and to
specify what addresses may be dynamically allocated to clients booting
on that subnet.   Such addresses are specified using the \fIrange\fR
declaration.
.PP
The