dhcpd.conf.5

DHCP服务器源码

.I subnet-number
should be an IP address or domain name which resolves to the subnet
number of the subnet being described.   The 
.I netmask
should be an IP address or domain name which resolves to the subnet mask
of the subnet being described.   The subnet number, together with the
netmask, are sufficient to determine whether any given IP address is
on the specified subnet.
.PP
Although a netmask must be given with every subnet declaration, it is
recommended that if there is any variance in subnet masks at a site, a
subnet-mask option statement be used in each subnet declaration to set
the desired subnet mask, since any subnet-mask option statement will
override the subnet mask declared in the subnet statement.
.PP
.B The
.I range
.B statement
.PP
.nf
.B range\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR
.fi
.PP
For any subnet on which addresses will be assigned dynamically, there
must be at least one \fIrange\fR statement.   The range statement
gives the lowest and highest IP addresses in a range.   All IP
addresses in the range should be in the subnet in which the
\fIrange\fR statement is declared.   The \fIdynamic-bootp\fR flag may
be specified if addresses in the specified range may be dynamically
assigned to BOOTP clients as well as DHCP clients.   When specifying a
single address, \fIhigh-address\fR can be omitted.
.PP
.B The
.I host
.B statement
.PP
.nf
 \fBhost\fR \fIhostname\fR {
   [ \fIparameters\fR ]
   [ \fIdeclarations\fR ]
 \fB}\fR
.fi
.PP
The
.B host
declaration provides a scope in which to provide configuration information about
a specific client, and also provides a way to assign a client a fixed address.
The host declaration provides a way for the DHCP server to identify a DHCP or
BOOTP client, and also a way to assign the client a static IP address.
.PP
If it is desirable to be able to boot a DHCP or BOOTP
client on more than one subnet with fixed addresses, more than one
address may be specified in the
.I fixed-address
declaration, or more than one
.B host
statement may be specified.
.PP
If client-specific boot parameters must change based on the network
to which the client is attached, then multiple 
.B host
declaration should
be used.
.PP
If a client is to be booted using a fixed address if it's
possible, but should be allocated a dynamic address otherwise, then a
.B host
declaration must be specified without a
.B fixed-address
declaration.
.I hostname
should be a name identifying the host.  If a \fIhostname\fR option is
not specified for the host, \fIhostname\fR is used.
.PP
\fIHost\fR declarations are matched to actual DHCP or BOOTP clients
by matching the \fRdhcp-client-identifier\fR option specified in the
\fIhost\fR declaration to the one supplied by the client, or, if the
\fIhost\fR declaration or the client does not provide a
\fRdhcp-client-identifier\fR option, by matching the \fIhardware\fR
parameter in the \fIhost\fR declaration to the network hardware
address supplied by the client.   BOOTP clients do not normally
provide a \fIdhcp-client-identifier\fR, so the hardware address must
be used for all clients that may boot using the BOOTP protocol.
.PP
Please be aware that
.B only
the \fIdhcp-client-identifier\fR option and the hardware address can be
used to match a host declaration.   For example, it is not possible to match
a host declaration to a \fIhost-name\fR option.   This is because the
host-name option cannot be guaranteed to be unique for any given client,
whereas both the hardware address and \fIdhcp-client-identifier\fR option
are at least theoretically guaranteed to be unique to a given client.
.PP
.B The
.I group
.B statement
.PP
.nf
 \fBgroup\fR {
   [ \fIparameters\fR ]
   [ \fIdeclarations\fR ]
 \fB}\fR
.fi
.PP
The group statement is used simply to apply one or more parameters to
a group of declarations.   It can be used to group hosts, shared
networks, subnets, or even other groups.
.SH REFERENCE: ALLOW AND DENY
The
.I allow
and
.I deny
statements can be used to control the response of the DHCP server to
various sorts of requests.  The allow and deny keywords actually have
different meanings depending on the context.  In a pool context, these
keywords can be used to set up access lists for address allocation
pools.  In other contexts, the keywords simply control general server
behavior with respect to clients based on scope.   In a non-pool
context, the
.I ignore
keyword can be used in place of the
.I deny
keyword to prevent logging of denied requests.
.PP
.SH ALLOW DENY AND IGNORE IN SCOPE
The following usages of allow and deny will work in any scope,
although it is not recommended that they be used in pool
declarations.
.PP
.B The
.I unknown-clients
.B keyword
.PP
 \fBallow unknown-clients;\fR
 \fBdeny unknown-clients;\fR
 \fBignore unknown-clients;\fR
.PP
The \fBunknown-clients\fR flag is used to tell dhcpd whether
or not to dynamically assign addresses to unknown clients.   Dynamic
address assignment to unknown clients is \fBallow\fRed by default.
An unknown client is simply a client that has no host declaration.
.PP
The use of this option is now \fIdeprecated\fR.  If you are trying to
restrict access on your network to known clients, you should use \fBdeny
unknown-clients;\fR inside of your address pool, as described under the
heading ALLOW AND DENY WITHIN POOL DECLARAIONS.
.PP
.B The
.I bootp
.B keyword
.PP
 \fBallow bootp;\fR
 \fBdeny bootp;\fR
 \fBignore bootp;\fR
.PP
The \fBbootp\fR flag is used to tell dhcpd whether
or not to respond to bootp queries.  Bootp queries are \fBallow\fRed
by default.
.PP
This option does not satisfy the requirement of failover peers for denying
dynamic bootp clients.  The \fBdeny dynamic bootp clients;\fR option should
be used instead. See the ALLOW AND DENY WITHIN POOL DECLARATIONS section
of this man page for more details.
.PP
.B The
.I booting
.B keyword
.PP
 \fBallow booting;\fR
 \fBdeny booting;\fR
 \fBignore booting;\fR
.PP
The \fBbooting\fR flag is used to tell dhcpd whether or not to respond
to queries from a particular client.  This keyword only has meaning
when it appears in a host declaration.   By default, booting is
\fBallow\fRed, but if it is disabled for a particular client, then
that client will not be able to get an address from the DHCP server.
.PP
.B The
.I duplicates
.B keyword
.PP
 \fBallow duplicates;\fR
 \fBdeny duplicates;\fR
.PP
Host declarations can match client messages based on the DHCP Client
Identifer option or based on the client's network hardware type and
MAC address.   If the MAC address is used, the host declaration will
match any client with that MAC address - even clients with different
client identifiers.   This doesn't normally happen, but is possible
when one computer has more than one operating system installed on it -
for example, Microsoft Windows and NetBSD or Linux.
.PP
The \fBduplicates\fR flag tells the DHCP server that if a request is
received from a client that matches the MAC address of a host
declaration, any other leases matching that MAC address should be
discarded by the server, even if the UID is not the same.   This is a
violation of the DHCP protocol, but can prevent clients whose client
identifiers change regularly from holding many leases at the same time.
By default, duplicates are \fBallow\fRed.
.PP
.B The
.I declines
.B keyword
.PP
 \fBallow declines;\fR
 \fBdeny declines;\fR
 \fBignore declines;\fR
.PP
The DHCPDECLINE message is used by DHCP clients to indicate that the
lease the server has offered is not valid.   When the server receives
a DHCPDECLINE for a particular address, it normally abandons that
address, assuming that some unauthorized system is using it.
Unfortunately, a malicious or buggy client can, using DHCPDECLINE
messages, completely exhaust the DHCP server's allocation pool.   The
server will reclaim these leases, but while the client is running
through the pool, it may cause serious thrashing in the DNS, and it
will also cause the DHCP server to forget old DHCP client address
allocations.
.PP
The \fBdeclines\fR flag tells the DHCP server whether or not to honor
DHCPDECLINE messages.   If it is set to \fBdeny\fR or \fBignore\fR in
a particular scope, the DHCP server will not respond to DHCPDECLINE
messages.
.PP
.B The
.I client-updates
.B keyword
.PP
 \fBallow client-updates;\fR
 \fBdeny client-updates;\fR
.PP
The \fBclient-updates\fR flag tells the DHCP server whether or not to
honor the client's intention to do its own update of its A record.
This is only relevant when doing \fIinterim\fR DNS updates.   See the
documentation under the heading THE INTERIM DNS UPDATE SCHEME for
details.
.SH ALLOW AND DENY WITHIN POOL DECLARATIONS
.PP
The uses of the allow and deny keywords shown in the previous section
work pretty much the same way whether the client is sending a
DHCPDISCOVER or a DHCPREQUEST message - an address will be allocated
to the client (either the old address it's requesting, or a new
address) and then that address will be tested to see if it's okay to
let the client have it.   If the client requested it, and it's not
okay, the server will send a DHCPNAK message.   Otherwise, the server
will simply not respond to the client.   If it is okay to give the
address to the client, the server will send a DHCPACK message.
.PP
The primary motivation behind pool declarations is to have address
allocation pools whose allocation policies are different.   A client
may be denied access to one pool, but allowed access to another pool
on the same network segment.   In order for this to work, access
control has to be done during address allocation, not after address
allocation is done.
.PP
When a DHCPREQUEST message is processed, address allocation simply
consists of looking up the address the client is requesting and seeing
if it's still available for the client.  If it is, then the DHCP
server checks both the address pool permit lists and the relevant
in-scope allow and deny statements to see if it's okay to give the
lease to the client.  In the case of a DHCPDISCOVER message, the
allocation process is done as described previously in the ADDRESS
ALLOCATION section.
.PP
When declaring permit lists for address allocation pools, the
following syntaxes are recognized following the allow or deny keywords:
.PP
 \fBknown-clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any client that has a host declaration (i.e., is known).
A client is known if it has a host declaration in \fIany\fR scope, not
just the current scope.
.PP
 \fBunknown-clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any client that has no host declaration (i.e., is not
known).
.PP
 \fBmembers of "\fRclass\fB";\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any client that is a member of the named class.
.PP
 \fBdynamic bootp clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any bootp client.
.PP
 \fBauthenticated clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any client that has been authenticated using the DHCP
authentication protocol.   This is not yet supported.
.PP
 \fBunauthenticated clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to any client that has not been authenticated using the DHCP
authentication protocol.   This is not yet supported.
.PP
 \fBall clients;\fR
.PP
If specified, this statement either allows or prevents allocation from
this pool to all clients.   This can be used when you want to write a
pool declaration for some reason, but hold it in reserve, or when you
want to renumber your network quickly, and thus want the server to
force all clients that have been allocated addresses from this pool to
obtain new addresses immediately when they next renew.
.SH REFERENCE: PARAMETERS
The
.I always-broadcast
statement
.RS 0.25i
.PP
.B always-broadcast \fIflag\fR\fB;\fR
.PP
The DHCP and BOOTP