1997-03-30 00:52:15 +03:00
|
|
|
.\" dhcpd.conf.5
|
|
|
|
.\"
|
2000-04-22 12:18:11 +04:00
|
|
|
.\" Copyright (c) 1996-1999 Internet Software Consortium.
|
|
|
|
.\" Use is subject to license terms which appear in the file named
|
|
|
|
.\" ISC-LICENSE that should have accompanied this file when you
|
|
|
|
.\" received it. If a file named ISC-LICENSE did not accompany this
|
|
|
|
.\" file, or you are not sure the one you have is correct, you may
|
|
|
|
.\" obtain an applicable copy of the license at:
|
1997-03-30 00:52:15 +03:00
|
|
|
.\"
|
2000-04-22 12:18:11 +04:00
|
|
|
.\" http://www.isc.org/isc-license-1.0.html.
|
1997-03-30 00:52:15 +03:00
|
|
|
.\"
|
2000-04-22 12:18:11 +04:00
|
|
|
.\" This file is part of the ISC DHCP distribution. The documentation
|
|
|
|
.\" associated with this file is listed in the file DOCUMENTATION,
|
|
|
|
.\" included in the top-level directory of this release.
|
1997-03-30 00:52:15 +03:00
|
|
|
.\"
|
2000-04-22 12:18:11 +04:00
|
|
|
.\" Support and other services are available for ISC products - see
|
|
|
|
.\" http://www.isc.org for more information.
|
1997-03-30 00:52:15 +03:00
|
|
|
.TH dhcpd.conf 5
|
|
|
|
.SH NAME
|
|
|
|
dhcpd.conf - dhcpd configuration file
|
|
|
|
.SH DESCRIPTION
|
|
|
|
The dhcpd.conf file contains configuration information for
|
|
|
|
.IR dhcpd,
|
|
|
|
the Internet Software Consortium DHCP Server.
|
|
|
|
.PP
|
|
|
|
The dhcpd.conf file is a free-form ASCII text file. It is parsed by
|
|
|
|
the recursive-descent parser built into dhcpd. The file may contain
|
|
|
|
extra tabs and newlines for formatting purposes. Keywords in the file
|
|
|
|
are case-insensitive. Comments may be placed anywhere within the
|
|
|
|
file (except within quotes). Comments begin with the # character and
|
|
|
|
end at the end of the line.
|
|
|
|
.PP
|
|
|
|
The file essentially consists of a list of statements. Statements
|
|
|
|
fall into two broad categories - parameters and declarations.
|
|
|
|
.PP
|
|
|
|
Parameter statements either say how to do something (e.g., how long a
|
|
|
|
lease to offer), whether to do something (e.g., should dhcpd provide
|
|
|
|
addresses to unknown clients), or what parameters to provide to the
|
|
|
|
client (e.g., use gateway 220.177.244.7).
|
|
|
|
.PP
|
|
|
|
Declarations are used to describe the topology of the
|
|
|
|
network, to describe clients on the network, to provide addresses that
|
|
|
|
can be assigned to clients, or to apply a group of parameters to a
|
|
|
|
group of declarations. In any group of parameters and declarations,
|
|
|
|
all parameters must be specified before any declarations which depend
|
|
|
|
on those parameters may be specified.
|
|
|
|
.PP
|
|
|
|
Declarations about network topology include the
|
1997-11-22 12:13:21 +03:00
|
|
|
\fIshared-network\fR and the \fIsubnet\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
declarations. If clients on a subnet are to be assigned addresses
|
|
|
|
dynamically, a \fIrange\fR declaration must appear within the
|
|
|
|
\fIsubnet\fR declaration. For clients with statically assigned
|
|
|
|
addresses, or for installations where only known clients will be
|
|
|
|
served, each such client must have a \fIhost\fR declaration. If
|
|
|
|
parameters are to be applied to a group of declarations which are not
|
|
|
|
related strictly on a per-subnet basis, the \fIgroup\fR declaration
|
|
|
|
can be used.
|
|
|
|
.PP
|
1997-11-22 12:13:21 +03:00
|
|
|
For every subnet which will be served, and for every subnet
|
1997-03-30 00:52:15 +03:00
|
|
|
to which the dhcp server is connected, there must be one \fIsubnet\fR
|
|
|
|
declaration, which tells dhcpd how to recognize that an address is on
|
|
|
|
that subnet. A \fIsubnet\fR declaration is required for each subnet
|
|
|
|
even if no addresses will be dynamically allocated on that subnet.
|
|
|
|
.PP
|
|
|
|
Some installations have physical networks on which more than one IP
|
|
|
|
subnet operates. For example, if there is a site-wide requirement
|
|
|
|
that 8-bit subnet masks be used, but a department with a single
|
|
|
|
physical ethernet network expands to the point where it has more than
|
|
|
|
254 nodes, it may be necessary to run two 8-bit subnets on the same
|
|
|
|
ethernet until such time as a new physical network can be added. In
|
|
|
|
this case, the \fIsubnet\fR declarations for these two networks may be
|
|
|
|
enclosed in a \fIshared-network\fR declaration.
|
|
|
|
.PP
|
|
|
|
Some sites may have departments which have clients on more than one
|
|
|
|
subnet, but it may be desirable to offer those clients a uniform set
|
|
|
|
of parameters which are different than what would be offered to
|
|
|
|
clients from other departments on the same subnet. For clients which
|
|
|
|
will be declared explicitly with \fIhost\fR declarations, these
|
|
|
|
declarations can be enclosed in a \fIgroup\fR declaration along with
|
|
|
|
the parameters which are common to that department. For clients
|
2000-04-22 12:18:11 +04:00
|
|
|
whose addresses will be dynamically assigned, class declarations and
|
|
|
|
conditional declarations may be used to group parameter assignments
|
|
|
|
based on information the client sends.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
When a client is to be booted, its boot parameters are determined by
|
2000-04-22 12:18:11 +04:00
|
|
|
consulting that client's \fIhost\fR declaration (if any), and then
|
|
|
|
consulting the any \fIclass\fR declarations matching the client,
|
|
|
|
followed by the \fIpool\fR, \fIsubnet\fR and \fIshared-network\fR
|
|
|
|
declarations for the IP address assigned to the client. Each of
|
|
|
|
these declarations itself appears within a lexical scope, and all
|
|
|
|
declarations at less specific lexical scopes are also consulted for
|
|
|
|
client option declarations as well. Scopes are never considered
|
|
|
|
twice, and if parameters are declared in more than one scope, the
|
|
|
|
parameter declared in the most specific scope is the one that is
|
|
|
|
used.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
When dhcpd tries to find a \fIhost\fR declaration for a client, it
|
|
|
|
first looks for a \fIhost\fR declaration which has a
|
|
|
|
\fIfixed-address\fR parameter which matches the subnet or shared
|
|
|
|
network on which the client is booting. If it doesn't find any such
|
|
|
|
entry, it then tries to find an entry which has no \fIfixed-address\fR
|
|
|
|
parameter. If no such entry is found, then dhcpd acts as if there is
|
|
|
|
no entry in the dhcpd.conf file for that client, even if there is an
|
|
|
|
entry for that client on a different subnet or shared network.
|
|
|
|
.SH EXAMPLES
|
|
|
|
.PP
|
|
|
|
A typical dhcpd.conf file will look something like this:
|
|
|
|
.nf
|
|
|
|
|
|
|
|
.I global parameters...
|
|
|
|
|
2000-04-22 12:18:11 +04:00
|
|
|
subnet 204.254.239.0 netmask 255.255.255.224 {
|
|
|
|
\fIsubnet-specific parameters...\fR
|
|
|
|
range 204.254.239.10 204.254.239.30;
|
|
|
|
}
|
|
|
|
|
|
|
|
subnet 204.254.239.32 netmask 255.255.255.224 {
|
|
|
|
\fIsubnet-specific parameters...\fR
|
|
|
|
range 204.254.239.42 204.254.239.62;
|
1997-03-30 00:52:15 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
subnet 204.254.239.64 netmask 255.255.255.224 {
|
|
|
|
\fIsubnet-specific parameters...\fR
|
|
|
|
range 204.254.239.74 204.254.239.94;
|
|
|
|
}
|
|
|
|
|
|
|
|
group {
|
|
|
|
\fIgroup-specific parameters...\fR
|
|
|
|
host zappo.test.isc.org {
|
|
|
|
\fIhost-specific parameters...\fR
|
|
|
|
}
|
|
|
|
host beppo.test.isc.org {
|
|
|
|
\fIhost-specific parameters...\fR
|
|
|
|
}
|
|
|
|
host harpo.test.isc.org {
|
|
|
|
\fIhost-specific parameters...\fR
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
.ce 1
|
|
|
|
Figure 1
|
|
|
|
|
|
|
|
.fi
|
|
|
|
.PP
|
1997-11-22 12:13:21 +03:00
|
|
|
Notice that at the beginning of the file, there's a place
|
1997-03-30 00:52:15 +03:00
|
|
|
for global parameters. These might be things like the organization's
|
|
|
|
domain name, the addresses of the name servers (if they are common to
|
|
|
|
the entire organization), and so on. So, for example:
|
|
|
|
.nf
|
|
|
|
|
|
|
|
option domain-name "isc.org";
|
1997-06-03 06:49:04 +04:00
|
|
|
option domain-name-servers ns1.isc.org, ns2.isc.org;
|
1997-03-30 00:52:15 +03:00
|
|
|
|
|
|
|
.ce 1
|
|
|
|
Figure 2
|
|
|
|
.fi
|
|
|
|
.PP
|
2000-04-22 12:18:11 +04:00
|
|
|
As you can see in Figure 2, you can specify host addresses in
|
|
|
|
parameters using their domain names rather than their numeric IP
|
|
|
|
addresses. If a given hostname resolves to more than one IP address
|
|
|
|
(for example, if that host has two ethernet interfaces), then where
|
|
|
|
possible, both addresses are supplied to the client.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
The most obvious reason for having subnet-specific parameters as
|
|
|
|
shown in Figure 1 is that each subnet, of necessity, has its own
|
|
|
|
router. So for the first subnet, for example, there should be
|
|
|
|
something like:
|
|
|
|
.nf
|
|
|
|
|
|
|
|
option routers 204.254.239.1;
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
Note that the address here is specified numerically. This is not
|
|
|
|
required - if you have a different domain name for each interface on
|
|
|
|
your router, it's perfectly legitimate to use the domain name for that
|
|
|
|
interface instead of the numeric address. However, in many cases
|
|
|
|
there may be only one domain name for all of a router's IP addresses, and
|
|
|
|
it would not be appropriate to use that name here.
|
|
|
|
.PP
|
|
|
|
In Figure 1 there is also a \fIgroup\fR statement, which provides
|
|
|
|
common parameters for a set of three hosts - zappo, beppo and harpo.
|
|
|
|
As you can see, these hosts are all in the test.isc.org domain, so it
|
|
|
|
might make sense for a group-specific parameter to override the domain
|
|
|
|
name supplied to these hosts:
|
|
|
|
.nf
|
|
|
|
|
|
|
|
option domain-name "test.isc.org";
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
Also, given the domain they're in, these are probably test machines.
|
|
|
|
If we wanted to test the DHCP leasing mechanism, we might set the
|
|
|
|
lease timeout somewhat shorter than the default:
|
|
|
|
|
|
|
|
.nf
|
|
|
|
max-lease-time 120;
|
|
|
|
default-lease-time 120;
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
You may have noticed that while some parameters start with the
|
|
|
|
\fIoption\fR keyword, some do not. Parameters starting with the
|
|
|
|
\fIoption\fR keyword correspond to actual DHCP options, while
|
|
|
|
parameters that do not start with the option keyword either control
|
|
|
|
the behaviour of the DHCP server (e.g., how long a lease dhcpd will
|
|
|
|
give out), or specify client parameters that are not optional in the
|
|
|
|
DHCP protocol (for example, server-name and filename).
|
|
|
|
.PP
|
|
|
|
In Figure 1, each host had \fIhost-specific parameters\fR. These
|
|
|
|
could include such things as the \fIhostname\fR option, the name of a
|
|
|
|
file to upload (the \fIfilename parameter) and the address of the
|
|
|
|
server from which to upload the file (the \fInext-server\fR
|
|
|
|
parameter). In general, any parameter can appear anywhere that
|
|
|
|
parameters are allowed, and will be applied according to the scope in
|
|
|
|
which the parameter appears.
|
|
|
|
.PP
|
|
|
|
Imagine that you have a site with a lot of NCD X-Terminals. These
|
|
|
|
terminals come in a variety of models, and you want to specify the
|
|
|
|
boot files for each models. One way to do this would be to have host
|
|
|
|
declarations for each server and group them by model:
|
|
|
|
.nf
|
|
|
|
|
|
|
|
group {
|
|
|
|
filename "Xncd19r";
|
|
|
|
next-server ncd-booter;
|
|
|
|
|
|
|
|
host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
|
|
|
|
host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
|
|
|
|
host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
|
|
|
|
}
|
|
|
|
|
|
|
|
group {
|
|
|
|
filename "Xncd19c";
|
|
|
|
next-server ncd-booter;
|
|
|
|
|
|
|
|
host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
|
|
|
|
host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
|
|
|
|
}
|
|
|
|
|
|
|
|
group {
|
|
|
|
filename "XncdHMX";
|
|
|
|
next-server ncd-booter;
|
|
|
|
|
|
|
|
host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
|
|
|
|
host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
|
|
|
|
host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
|
|
|
|
}
|
|
|
|
.fi
|
2000-04-22 12:18:11 +04:00
|
|
|
.SH ADDRESS POOLS
|
|
|
|
.PP
|
|
|
|
The
|
|
|
|
.B pool
|
|
|
|
declaration can be used to specify a pool of addresses that will be
|
|
|
|
treated differently than another pool of addresses, even on the same
|
|
|
|
network segment or subnet. For example, you may want to provide a
|
|
|
|
large set of addresses that can be assigned to DHCP clients that are
|
|
|
|
registered to your DHCP server, while providing a smaller set of
|
|
|
|
addresses, possibly with short lease times, that are available for
|
|
|
|
unknown clients. If you have a firewall, you may be able to arrange
|
|
|
|
for addresses from one pool to be allowed access to the Internet,
|
|
|
|
while addresses in another pool are not, thus encouraging users to
|
|
|
|
register their DHCP clients. To do this, you would set up a pair of
|
|
|
|
pool declarations:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
subnet 10.0.0.0 netmask 255.255.255.0 {
|
|
|
|
option routers 10.0.0.254;
|
|
|
|
|
|
|
|
# Unknown clients get this pool.
|
|
|
|
pool {
|
|
|
|
option domain-name-servers bogus.example.com;
|
|
|
|
max-lease-time 300;
|
|
|
|
range 10.0.0.200 10.0.0.253;
|
|
|
|
allow unknown clients;
|
|
|
|
}
|
|
|
|
|
|
|
|
# Known clients get this pool.
|
|
|
|
pool {
|
|
|
|
option domain-name-servers ns1.example.com, ns2.example.com;
|
|
|
|
max-lease-time 28800;
|
|
|
|
range 10.0.0.5 10.0.0.199;
|
|
|
|
deny unknown clients;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
It is also possible to set up entirely different subnets for known and
|
|
|
|
unknown clients - address pools exist at the level of shared networks,
|
|
|
|
so address ranges within pool declarations can be on different
|
|
|
|
subnets.
|
|
|
|
.PP
|
|
|
|
As you can see in the preceding example, pools can have permit lists
|
|
|
|
that control which clients are allowed access to the pool and which
|
|
|
|
aren't. Each entry in a pool's permit list is introduced with the
|
|
|
|
.I allow
|
|
|
|
or \fIdeny\fR keyword. If a pool has a permit list, then only those
|
|
|
|
clients that match specific entries on the permit list will be
|
|
|
|
elegible to be assigned addresses from the pool. If a pool has a
|
|
|
|
deny list, then only those clients that do not match any entries on
|
|
|
|
the deny list will be elegible. If both permit and deny lists exist
|
|
|
|
for a pool, then only clients that match the permit list and do not
|
|
|
|
match the deny list will be allowed access.
|
|
|
|
.SH ADDRESS ALLOCATION
|
|
|
|
Address allocation is actually only done when a client is in the INIT
|
|
|
|
state and has sent a DHCPDISCOVER message. If the client thinks it
|
|
|
|
has a valid lease and sends a DHCPREQUEST to initiate or renew that
|
|
|
|
lease, the server has only three choices - it can ignore the
|
|
|
|
DHCPREQUEST, send a DHCPNAK to tell the client it should stop using
|
|
|
|
the address, or send a DHCPACK, telling the client to go ahead and use
|
|
|
|
the address for a while. If the server finds the address the client
|
|
|
|
is requesting, and that address is available to the client, the server
|
|
|
|
will send a DHCPACK. If the address is no longer available, or the
|
|
|
|
client isn't permitted to have it, the server will send a DHCPNAK. If
|
|
|
|
the server knows nothing about the, it will remain silent, unless the
|
|
|
|
address is incorrect for the network segment to which the client has
|
|
|
|
been attached and the server is authoritative for that network
|
|
|
|
segment, in which case the server will send a DHCPNAK even though it
|
|
|
|
doesn't know about the address.
|
|
|
|
.PP
|
|
|
|
When the DHCP server allocates a new address for a client (remember,
|
|
|
|
this only happens if the client has sent a DHCPDISCOVER), it first
|
|
|
|
looks to see if the client already has a valid lease on an IP address,
|
|
|
|
or if there is an old IP address the client had before that hasn't yet
|
|
|
|
been reassigned. In that case, the server will take that address and
|
|
|
|
check it to see if the client is still permitted to use it. If the
|
|
|
|
client is no longer permitted to use it, the lease is freed if the
|
|
|
|
server thought it was still in use - the fact that the client has sent
|
|
|
|
a DHCPDISCOVER proves to the server that the client is no longer using
|
|
|
|
the lease.
|
|
|
|
.PP
|
|
|
|
If no existing lease is found, or if the client is forbidden to
|
|
|
|
receive the existing lease, then the server will look in the list of
|
|
|
|
address pools for the network segment to which the client is attached
|
|
|
|
for a lease that is not in use and that the client is permitted to
|
|
|
|
have. It looks through each pool declaration in sequence (all
|
|
|
|
.I range
|
|
|
|
declarations that appear outside of pool declarations are grouped into
|
|
|
|
a single pool with no permit list). If the permit list for the pool
|
|
|
|
allows the client to be allocated an address from that pool, the pool
|
|
|
|
is examined to see if there is an address available. If so, then the
|
|
|
|
client is tentatively assigned that address. Otherwise, the next
|
|
|
|
pool is tested. If no addresses are found that can be assigned to
|
|
|
|
the client, no response is sent to the client.
|
|
|
|
.PP
|
|
|
|
If an address is found that the client is permitted to have, and that
|
|
|
|
has never been assigned to any client before, the address is
|
|
|
|
immediately allocated to the client. If the address is available for
|
|
|
|
allocation but has been previously assigned to a different client, the
|
|
|
|
server will keep looking in hopes of finding an address that has never
|
|
|
|
before been assigned to a client.
|
|
|
|
.SH CLIENT CLASSING
|
|
|
|
Clients can be seperated into classes, and treated differently
|
|
|
|
depending on what class they are in. This seperation can be done
|
|
|
|
either with a conditional statement, or with a match statement within
|
|
|
|
the class declaration. It is possible to specify a limit on the
|
|
|
|
total number of clients within a particular class or subclass that may
|
|
|
|
hold leases at one time, and it is possible to specify automatic
|
|
|
|
subclassing based on the contents of the client packet.
|
|
|
|
.PP
|
|
|
|
To add clients to classes based on conditional evaluation, you would
|
|
|
|
write an conditional statement to match the clients you wanted in the
|
|
|
|
class, and then put an
|
|
|
|
.B add
|
|
|
|
statement in the conditional's list of statements:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
if substring (option dhcp-client-identifier, 0, 3) = "RAS" {
|
|
|
|
add "ras-clients";
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
A nearly equivalent way to do this is to simply specify the conditional
|
|
|
|
expression as a matching expression in the class statement:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
class "ras-clients" {
|
|
|
|
match if substring (option dhcp-client-identifier, 0, 3) = "RAS";
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
Note that whether you use matching expressions or add statements (or
|
|
|
|
both) to classify clients, you must always write a class declaration
|
|
|
|
for any class that you use. If there will be no match statement and
|
|
|
|
no in-scope statements for a class, the declaration should look like
|
|
|
|
this:
|
|
|
|
.nf
|
|
|
|
class "ras-clients" {
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
Also, the
|
|
|
|
.B add
|
|
|
|
statement adds the client to the class as the client's scopes are being
|
|
|
|
evaluated - after any address assignment decision has been made. This means
|
|
|
|
that a client that's a member of a class due to an add statement will not
|
|
|
|
be affected by pool permits related to that class - when the pool permit list
|
|
|
|
is computed, the client will not yet be a member of the pool. This is an
|
|
|
|
inconsistency that will probably be addressed in later versions of the DHCP
|
|
|
|
server, but it important to be aware of it at lease for the time being.
|
|
|
|
.SH SUBCLASSES
|
|
|
|
.PP
|
|
|
|
In addition to classes, it is possible to declare subclasses. A
|
|
|
|
subclass is a class with the same name as a regular class, but with a
|
|
|
|
specific submatch expression which is hashed for quick matching.
|
|
|
|
This is essentially a speed hack - the main difference between five
|
|
|
|
classes with match expressions and one class with five subclasses is
|
|
|
|
that it will be quicker to find the subclasses. Subclasses work as
|
|
|
|
follows:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
class "allocation-class-1" {
|
|
|
|
match pick-first-value (option dhcp-client-identifier, hardware);
|
|
|
|
}
|
|
|
|
|
|
|
|
class "allocation-class-2" {
|
|
|
|
match pick-first-value (option dhcp-client-identifier, hardware);
|
|
|
|
}
|
|
|
|
|
|
|
|
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
|
|
|
|
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
|
|
|
|
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
|
|
|
|
|
|
|
|
subnet 10.0.0.0 netmask 255.255.255.0 {
|
|
|
|
pool {
|
|
|
|
allow members of "allocation-class-1";
|
|
|
|
range 10.0.0.11 10.0.0.50;
|
|
|
|
}
|
|
|
|
pool {
|
|
|
|
allow members of "allocation-class-2";
|
|
|
|
range 10.0.0.51 10.0.0.100;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
The data following the class name in the subclass declaration is a
|
|
|
|
constant value to use in matching the match expression for the class.
|
|
|
|
When class matching is done, the server will evaluate the match
|
|
|
|
expression and then look the result up in the hash table. If it
|
|
|
|
finds a match, the client is considered a member of both the class and
|
|
|
|
the subclass.
|
|
|
|
.PP
|
|
|
|
Subclasses can be declared with or without scope. In the above
|
|
|
|
example, the sole purpose of the subclass is to allow some clients
|
|
|
|
access to one address pool, while other clients are given access to
|
|
|
|
the other pool, so these subclasses are declared without scopes. If
|
|
|
|
part of the purpose of the subclass were to define different parameter
|
|
|
|
values for some clients, you might want to declare some subclasses
|
|
|
|
with scopes.
|
|
|
|
.PP
|
|
|
|
In the above example, if you had a single client that needed some
|
|
|
|
configuration parameters, while most didn't, you might write the
|
|
|
|
following subclass declaration for that client:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
|
|
|
|
option root-path "samsara:/var/diskless/alphapc";
|
|
|
|
filename "/tftpboot/netbsd.alphapc-diskless";
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
In this example, we've used subclassing as a way to control address
|
|
|
|
allocation on a per-client basis. However, it's also possible to use
|
|
|
|
subclassing in ways that are not specific to clients - for example, to
|
|
|
|
use the value of the vendor-class-identifier option to determine what
|
|
|
|
values to send in the vendor-encapsulated-options option. An example
|
|
|
|
of this is shown under the VENDOR ENCAPSULATED OPTIONS head later on
|
|
|
|
in this document.
|
|
|
|
.SH PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
|
|
|
|
.PP
|
|
|
|
You may specify a limit to the number of clients in a class that can
|
|
|
|
be assigned leases. The effect of this will be to make it difficult
|
|
|
|
for a new client in a class to get an address. Once a class with
|
|
|
|
such a limit has reached its limit, the only way a new client in that
|
|
|
|
class can get a lease is for an existing client to relinquish its
|
|
|
|
lease, either by letting it expire, or by sending a DHCPRELEASE
|
|
|
|
packet. Classes with lease limits are specified as follows:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
class "limited-1" {
|
|
|
|
lease limit 4;
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
This will produce a class in which a maximum of four members may hold
|
|
|
|
a lease at one time.
|
|
|
|
.SH SPAWNING CLASSES
|
|
|
|
.PP
|
|
|
|
It is possible to declare a
|
|
|
|
.I spawning class\fR.
|
|
|
|
A spawning class is a class that automatically produces subclasses
|
|
|
|
based on what the client sends. The reason that spawning classes
|
|
|
|
were created was to make it possible to create lease-limited classes
|
|
|
|
on the fly. The envisioned application is a cable-modem environment
|
|
|
|
where the ISP wishes to provide clients at a particular site with more
|
|
|
|
than one IP address, but does not wish to provide such clients with
|
|
|
|
their own subnet, nor give them an unlimited number of IP addresses
|
|
|
|
from the network segment to which they are connected.
|
|
|
|
.PP
|
|
|
|
Many cable modem head-end systems can be configured to add a Relay
|
|
|
|
Agent Information option to DHCP packets when relaying them to the
|
|
|
|
DHCP server. These systems typically add a circuit ID or remote ID
|
|
|
|
option that uniquely identifies the customer site. To take advantage
|
|
|
|
of this, you can write a class declaration as follows:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
class "customer" {
|
|
|
|
spawn with option agent.circuit-id;
|
|
|
|
lease limit 4;
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
Now whenever a request comes in from a customer site, the circuit ID
|
|
|
|
option will be checked against the class's hash table. If a subclass
|
|
|
|
is found that matches the circuit ID, the client will be classified in
|
|
|
|
that subclass and treated accordingly. If no subclass is found
|
|
|
|
matching the circuit ID, a new one will be created and logged in the
|
|
|
|
.B dhcpd.leases
|
|
|
|
file, and the client will be classified in this new class. Once the
|
|
|
|
client has been classified, it will be treated according to the rules
|
|
|
|
of the class, including, in this case, being subject to the per-site
|
|
|
|
limit of four leases.
|
|
|
|
.PP
|
|
|
|
The use of the subclass spawning mechanism is not restricted to relay
|
|
|
|
agent options - this particular example is given only because it is a
|
|
|
|
fairly straightforward one.
|
|
|
|
.SH DYNAMIC DNS UPDATES
|
|
|
|
.PP
|
|
|
|
The DHCP server has 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. The DHCP server will only
|
|
|
|
perform DNS updates if it has been built with DNS updates enabled as
|
|
|
|
described in the README file that comes with the DHCP distribution.
|
|
|
|
.PP
|
|
|
|
The Dynamic DNS update scheme implemented in this version of the ISC
|
|
|
|
DHCP server is an interim implementation, which does not implement any
|
|
|
|
of the standard update methods that have been discussed in the working
|
|
|
|
group, but rather implements some very basic, yet useful, update
|
|
|
|
capabilities.
|
|
|
|
.PP
|
|
|
|
There are three parameters, which may vary according to the scope,
|
|
|
|
that control how DDNS updates will be done. The first two are the
|
|
|
|
.I ddns-domainname
|
|
|
|
and
|
|
|
|
.I ddns-rev-domainname
|
|
|
|
statements. The
|
|
|
|
.I ddns-domainname
|
|
|
|
parameter sets the domain name that will be appended to the client's
|
|
|
|
hostname to form a fully-qualified domain-name (FQDN). For example,
|
|
|
|
if the client's hostname is "hutson" and the
|
|
|
|
.I ddns-domainname
|
|
|
|
is set to "sneedville.edu", then the client's FQDN will be
|
|
|
|
"hutson.sneedville.edu".
|
|
|
|
.PP
|
|
|
|
The
|
|
|
|
.I ddns-rev-domainname
|
|
|
|
parameter sets the domain name that will be appended to the client's
|
|
|
|
reversed IP address to produce a name for use in the client's PTR
|
|
|
|
record. Normally, you would set this to "in-addr.arpa", but this is
|
|
|
|
not required.
|
|
|
|
.PP
|
|
|
|
A third parameter,
|
|
|
|
.I ddns-hostname
|
|
|
|
can be used to specify the hostname that will be used as the client's
|
|
|
|
hostname. If no ddns-hostname is specified in scope, then the server
|
|
|
|
will use a host-name option sent by the client. If the client did
|
|
|
|
not send a host-name option, then if there is a host declaration that
|
|
|
|
applies to the client, the name from that declaration will be used.
|
|
|
|
If none of these applies, the server will not have a hostname for the
|
|
|
|
client, and will not be able to do a DDNS update.
|
|
|
|
.SH HOW DNS UPDATES WORK
|
|
|
|
.PP
|
|
|
|
The client's FQDN, derived as we have described, is used as the name
|
|
|
|
on which an "A" record will be stored. The A record will contain the
|
|
|
|
IP address that the client was assigned in its lease. If there is
|
|
|
|
already an A record with the same name in the DNS server, no update of
|
|
|
|
either the A or PTR records will occur - this prevents a client from
|
|
|
|
claiming that its hostname is the name of some network server. For
|
|
|
|
example, if you have a fileserver called "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 behaviour. 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 DHCPOFFER. 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 DYNAMIC DNS UPDATE SECURITY
|
|
|
|
.PP
|
|
|
|
Support for TSIG and DNSSEC is not yet available. 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, the best you
|
|
|
|
can do right now is to use IP address-based packet filtering to
|
|
|
|
prevent unauthorized hosts from submitting update requests.
|
|
|
|
.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, assuming you are using ISC BIND
|
|
|
|
8.2.1 or later, you would need to have the following declarations in
|
|
|
|
your /etc/named.conf file:
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
zone "sneedville.edu" {
|
|
|
|
type master;
|
|
|
|
file "sneedville.edu.db";
|
|
|
|
allow-update { localhost; };
|
|
|
|
};
|
|
|
|
|
|
|
|
zone "17.10.10.in-addr.arpa" {
|
|
|
|
type master;
|
|
|
|
file "10.10.17.db";
|
|
|
|
allow-update { localhost; };
|
|
|
|
};
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
This assumes that your DHCP server and your name server will be
|
|
|
|
running on the same computer - the "localhost" name is taken in the
|
|
|
|
DNS server as an alias for all of that host's IP addresses, and
|
|
|
|
updates from any of those addresses will be accepted.
|
|
|
|
.PP
|
|
|
|
You may wish to enable logging of DNS transactions 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 dynamic DNS
|
|
|
|
updates, so you should not define your own event handlers if you are
|
|
|
|
using the built-in dynamic DNS update mechanism.
|
1997-03-30 00:52:15 +03:00
|
|
|
.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
|
|
|
|
.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
|
2000-04-22 12:18:11 +04:00
|
|
|
.B range\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
.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
|
|
|
|
There must be at least one
|
|
|
|
.B host
|
|
|
|
statement for every BOOTP client that is to be served.
|
|
|
|
.B host
|
|
|
|
statements may also be specified for DHCP clients, although this is
|
|
|
|
not required unless booting is only enabled for known hosts.
|
|
|
|
.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
|
|
|
|
parameter, 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
|
|
|
|
statements 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
|
|
|
|
statement must be specified without a
|
|
|
|
.B fixed-address
|
|
|
|
clause.
|
|
|
|
.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
|
|
|
|
.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.
|
2000-04-22 12:18:11 +04:00
|
|
|
.SH REFERENCE: ALLOW AND DENY
|
1997-03-30 00:52:15 +03:00
|
|
|
The
|
|
|
|
.I allow
|
|
|
|
and
|
|
|
|
.I deny
|
2000-04-22 12:18:11 +04:00
|
|
|
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
|
|
|
|
behaviour 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.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
2000-04-22 12:18:11 +04:00
|
|
|
.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.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I unknown-clients
|
|
|
|
.B keyword
|
|
|
|
.PP
|
|
|
|
\fBallow unknown-clients;\fR
|
|
|
|
\fBdeny unknown-clients;\fR
|
2000-04-22 12:18:11 +04:00
|
|
|
\fBignore unknown-clients;\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
.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.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I bootp
|
|
|
|
.B keyword
|
|
|
|
.PP
|
|
|
|
\fBallow bootp;\fR
|
|
|
|
\fBdeny bootp;\fR
|
2000-04-22 12:18:11 +04:00
|
|
|
\fBignore bootp;\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
.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
|
|
|
|
.B The
|
|
|
|
.I booting
|
|
|
|
.B keyword
|
|
|
|
.PP
|
|
|
|
\fBallow booting;\fR
|
|
|
|
\fBdeny booting;\fR
|
2000-04-22 12:18:11 +04:00
|
|
|
\fBignore booting;\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
.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 and address from the DHCP server.
|
2000-04-22 12:18:11 +04:00
|
|
|
.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.
|
|
|
|
.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.
|
|
|
|
.SH ALLOW AND DENY WITHIN POOL DECLARATIONS
|
|
|
|
.PP
|
|
|
|
The uses of the allow and deny keyword 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 keyword:
|
|
|
|
.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.
|
1997-03-30 00:52:15 +03:00
|
|
|
.SH REFERENCE: PARAMETERS
|
|
|
|
.PP
|
|
|
|
.B The
|
2000-04-22 12:18:11 +04:00
|
|
|
.I lease-file-name
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
.B lease-file-name
|
|
|
|
.I name\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Name
|
|
|
|
should be the name of the DHCP server's lease file. By default, this
|
|
|
|
is DBDIR/dhcpd.leases. This statement \fBmust\fR appear in the outer
|
|
|
|
scope of the configuration file - if it appears in some other scope,
|
|
|
|
it will have no effect.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I pid-file-name
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
.B pid-file-name
|
|
|
|
.I name\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Name
|
|
|
|
should be the name of the DHCP server's process ID file. This is the
|
|
|
|
file in which the DHCP server's process ID is stored when the server
|
|
|
|
starts. By default, this is RUNDIR/dhcpd.pid. Like the
|
|
|
|
lease-file-name statement, this statement must appear in the outer scope
|
|
|
|
of the configuration file.
|
|
|
|
.PP
|
|
|
|
.B The
|
1997-03-30 00:52:15 +03:00
|
|
|
.I default-lease-time
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBdefault-lease-time\fR \fItime\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Time
|
|
|
|
should be the length in seconds that will be assigned to a lease if
|
|
|
|
the client requesting the lease does not ask for a specific expiration
|
|
|
|
time.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I max-lease-time
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBmax-lease-time\fR \fItime\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Time
|
|
|
|
should be the maximum length in seconds that will be assigned to a
|
2000-04-22 12:18:11 +04:00
|
|
|
lease. The only exception to this is that Dynamic BOOTP lease
|
|
|
|
lengths, which are not specified by the client, are not limited by
|
|
|
|
this maximum.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I min-lease-time
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBmin-lease-time\fR \fItime\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Time
|
|
|
|
should be the minimum length in seconds that will be assigned to a
|
|
|
|
lease.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I min-secs
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBmin-secs\fR \fIseconds\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
.I Seconds
|
|
|
|
should be the minimum number of seconds since a client began trying to
|
|
|
|
acquire a new lease before the DHCP server will respond to its request.
|
|
|
|
The number of seconds is based on what the client reports, and the maximum
|
|
|
|
value that the client can report is 255 seconds. Generally, setting this
|
|
|
|
to one will result in the DHCP server not responding to the client's first
|
|
|
|
request, but always responding to its second request.
|
|
|
|
.PP
|
|
|
|
This can be used
|
|
|
|
to set up a secondary DHCP server which never offers an address to a client
|
|
|
|
until the primary server has been given a chance to do so. If the primary
|
|
|
|
server is down, the client will bind to the secondary server, but otherwise
|
|
|
|
clients should always bind to the primary. Note that this does not, by
|
|
|
|
itself, permit a primary server and a secondary server to share a pool of
|
|
|
|
dynamically-allocatable addresses.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I hardware
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBhardware\fR \fIhardware-type\fR \fIhardware-address\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
In order for a BOOTP client to be recognized, its network hardware
|
|
|
|
address must be declared using a \fIhardware\fR clause in the
|
|
|
|
.I host
|
|
|
|
statement.
|
|
|
|
.I hardware-type
|
|
|
|
must be the name of a physical hardware interface type. Currently,
|
|
|
|
only the
|
|
|
|
.B ethernet
|
|
|
|
and
|
1999-02-19 01:04:06 +03:00
|
|
|
.B token-ring
|
|
|
|
types are recognized, although support for a
|
1997-03-30 00:52:15 +03:00
|
|
|
.B fddi
|
1999-02-19 01:04:06 +03:00
|
|
|
hardware type (and others) would also be desirable.
|
1997-03-30 00:52:15 +03:00
|
|
|
The
|
|
|
|
.I hardware-address
|
|
|
|
should be a set of hexadecimal octets (numbers from 0 through ff)
|
1999-03-26 20:52:45 +03:00
|
|
|
seperated by colons. The \fIhardware\fR statement may also be used
|
1997-03-30 00:52:15 +03:00
|
|
|
for DHCP clients.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I filename
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBfilename\fR \fB"\fR\fIfilename\fR\fB";\fR
|
|
|
|
.PP
|
|
|
|
The \fIfilename\fR statement can be used to specify the name of the
|
|
|
|
initial boot file which is to be loaded by a client. The
|
|
|
|
.I filename
|
|
|
|
should be a filename recognizable to whatever file transfer protocol
|
|
|
|
the client can be expected to use to load the file.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I server-name
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBserver-name\fR \fB"\fR\fIname\fR\fB";\fR
|
|
|
|
.PP
|
|
|
|
The \fIserver-name\fR statement can be used to inform the client of
|
|
|
|
the name of the server from which it is booting. \fIName\fR should
|
|
|
|
be the name that will be provided to the client.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I next-server
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBnext-server\fR \fIserver-name\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fInext-server\fR statement is used to specify the host address of
|
|
|
|
the server from which the initial boot file (specified in the
|
|
|
|
\fIfilename\fR statement) is to be loaded. \fIServer-name\fR should
|
|
|
|
be a numeric IP address or a domain name. If no \fInext-server\fR
|
1997-11-22 12:13:21 +03:00
|
|
|
parameter applies to a given client, the DHCP server's IP address is
|
|
|
|
used.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I fixed-address
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBfixed-address\fR \fIaddress\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fIfixed-address\fR statement is used to assign one or more fixed
|
|
|
|
IP addresses to a client. It should only appear in a \fIhost\fR
|
|
|
|
declaration. If more than one address is supplied, then when the
|
|
|
|
client boots, it will be assigned the address which corresponds to the
|
|
|
|
network on which it is booting. If none of the addresses in the
|
|
|
|
\fIfixed-address\fR statement are on the network on which the client
|
|
|
|
is booting, that client will not match the \fIhost\fR declaration
|
|
|
|
containing that \fIfixed-address\fR statement. Each \fIaddress\fR
|
|
|
|
should be either an IP address or a domain name which resolves to one
|
|
|
|
or more IP addresses.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I dynamic-bootp-lease-cutoff
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBdynamic-bootp-lease-cutoff\fR \fIdate\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fIdynamic-bootp-lease-cutoff\fR statement sets the ending time
|
|
|
|
for all leases assigned dynamically to BOOTP clients. Because BOOTP
|
|
|
|
clients do not have any way of renewing leases, and don't know that
|
|
|
|
their leases could expire, by default dhcpd assignes infinite leases
|
|
|
|
to all BOOTP clients. However, it may make sense in some situations
|
|
|
|
to set a cutoff date for all BOOTP leases - for example, the end of a
|
|
|
|
school term, or the time at night when a facility is closed and all
|
|
|
|
machines are required to be powered off.
|
|
|
|
.PP
|
|
|
|
.I Date
|
|
|
|
should be the date on which all assigned BOOTP leases will end. The
|
|
|
|
date is specified in the form:
|
|
|
|
.PP
|
|
|
|
.ce 1
|
|
|
|
W YYYY/MM/DD HH:MM:SS
|
|
|
|
.PP
|
|
|
|
W is the day of the week expressed as a number
|
|
|
|
from zero (Sunday) to six (Saturday). YYYY is the year, including the
|
|
|
|
century. MM is the month expressed as a number from 1 to 12. DD is
|
|
|
|
the day of the month, counting from 1. HH is the hour, from zero to
|
|
|
|
23. MM is the minute and SS is the second. The time is always in
|
1998-09-10 23:30:37 +04:00
|
|
|
Universal Coordinated Time (UTC), not local time.
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I dynamic-bootp-lease-length
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBdynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fIdynamic-bootp-lease-length\fR statement is used to set the
|
|
|
|
length of leases dynamically assigned to BOOTP clients. At some
|
|
|
|
sites, it may be possible to assume that a lease is no longer in
|
|
|
|
use if its holder has not used BOOTP or DHCP to get its address within
|
|
|
|
a certain time period. The period is specified in \fIlength\fR as a
|
|
|
|
number of seconds. If a client reboots using BOOTP during the
|
|
|
|
timeout period, the lease duration is reset to \fIlength\fR, so a
|
|
|
|
BOOTP client that boots frequently enough will never lose its lease.
|
|
|
|
Needless to say, this parameter should be adjusted with extreme
|
|
|
|
caution.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I get-lease-hostnames
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBget-lease-hostnames\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fIget-lease-hostnames\fR statement is used to tell dhcpd whether
|
|
|
|
or not to look up the domain name corresponding to the IP address of
|
|
|
|
each address in the lease pool and use that address for the DHCP
|
|
|
|
\fIhostname\fR option. If \fIflag\fR is true, then this lookup is
|
|
|
|
done for all addresses in the current scope. By default, or if
|
|
|
|
\fIflag\fR is false, no lookups are done.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I use-host-decl-names
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBuse-host-decl-names\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
If the \fIuse-host-decl-names\fR parameter is true in a given scope,
|
|
|
|
then for every host declaration within that scope, the name provided
|
|
|
|
for the host declaration will be supplied to the client as its
|
|
|
|
hostname. So, for example,
|
|
|
|
.PP
|
|
|
|
.nf
|
|
|
|
group {
|
|
|
|
use-host-decl-names on;
|
|
|
|
|
|
|
|
host joe {
|
|
|
|
hardware ethernet 08:00:2b:4c:29:32;
|
|
|
|
fixed-address joe.fugue.com;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
is equivalent to
|
|
|
|
|
|
|
|
host joe {
|
|
|
|
hardware ethernet 08:00:2b:4c:29:32;
|
|
|
|
fixed-address joe.fugue.com;
|
|
|
|
option host-name "joe";
|
|
|
|
}
|
|
|
|
.fi
|
|
|
|
.PP
|
|
|
|
An \fIoption host-name\fR statement within a host declaration will
|
|
|
|
override the use of the name in the host declaration.
|
|
|
|
.PP
|
1997-11-22 12:13:21 +03:00
|
|
|
.B The
|
1999-02-19 01:04:06 +03:00
|
|
|
.I authoritative
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBauthoritative;\fR
|
|
|
|
.PP
|
|
|
|
\fBnot authoritative;\fR
|
|
|
|
.PP
|
|
|
|
The DHCP server will normally assume that the configuration
|
|
|
|
information about a given network segment is known to be correct and
|
|
|
|
is authoritative. So if a client requests an IP address on a given
|
|
|
|
network segment that the server knows is not valid for that segment,
|
|
|
|
the server will respond with a DHCPNAK message, causing the client to
|
|
|
|
forget its IP address and try to get a new one.
|
|
|
|
.PP
|
|
|
|
If a DHCP server is being configured by somebody who is not the
|
|
|
|
network administrator and who therefore does not wish to assert this
|
|
|
|
level of authority, then the statement "not authoritative" should be
|
|
|
|
written in the appropriate scope in the configuration file.
|
|
|
|
.PP
|
|
|
|
Usually, writing \fBnot authoritative;\fR at the top level of the file
|
|
|
|
should be sufficient. However, if a DHCP server is to be set up so
|
|
|
|
that it is aware of some networks for which it is authoritative and
|
|
|
|
some networks for which it is not, it may be more appropriate to
|
|
|
|
declare authority on a per-network-segment basis.
|
|
|
|
.PP
|
|
|
|
Note that the most specific scope for which the concept of authority
|
|
|
|
makes any sense is the physical network segment - either a
|
|
|
|
shared-network statement or a subnet statement that is not contained
|
|
|
|
within a shared-network statement. It is not meaningful to specify
|
|
|
|
that the server is authoritative for some subnets within a shared
|
|
|
|
network, but not authoritative for others, nor is it meaningful to
|
|
|
|
specify that the server is authoritative for some host declarations
|
|
|
|
and not others.
|
|
|
|
.PP
|
|
|
|
.B The
|
1999-04-09 21:55:01 +04:00
|
|
|
.I always-reply-rfc1048
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBalways-reply-rfc1048\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
Some BOOTP clients expect RFC1048-style responses, but do not follow
|
|
|
|
RFC1048 when sending their requests. You can tell that a client is
|
|
|
|
having this problem if it is not getting the options you have
|
|
|
|
configured for it and if you see in the server log the message
|
|
|
|
"(non-rfc1048)" printed with each BOOTREQUEST that is logged.
|
|
|
|
.PP
|
|
|
|
If you want to send rfc1048 options to such a client, you can set the
|
|
|
|
.B always-reply-rfc1048
|
|
|
|
option in that client's host declaration, and the DHCP server will
|
|
|
|
respond with an RFC-1048-style vendor options field. This flag can
|
|
|
|
be set in any scope, and will affect all clients covered by that
|
|
|
|
scope.
|
|
|
|
.PP
|
|
|
|
.B The
|
2000-04-22 12:18:11 +04:00
|
|
|
.I always-broadcast
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBalways-broadcast\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The DHCP and BOOTP protocols both require DHCP and BOOTP clients to
|
|
|
|
set the broadcast bit in the flags field of the BOOTP message header.
|
|
|
|
Unfortunately, some DHCP and BOOTP clients do not do this, and
|
|
|
|
therefore may not receive responses from the DHCP server. The DHCP
|
|
|
|
server can be made to always broadcast its responses to clients by
|
|
|
|
setting this flag to 'on' for the relevant scope. To avoid creating
|
|
|
|
excess broadcast traffic on your network, we recommend that you
|
|
|
|
restrict the use of this option to as few clients as possible. For
|
|
|
|
example, the Microsoft DHCP client is known not to have this problem,
|
|
|
|
as are the OpenTransport and ISC DHCP clients.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I one-lease-per-client
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBone-lease-per-client\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
If this flag is enabled, whenever a client sends a DHCPREQUEST for a
|
|
|
|
particular lease, the server will automatically free any other leases
|
|
|
|
the client holds. This presumes that when the client sends a
|
|
|
|
DHCPREQUEST, it has forgotten any lease not mentioned in the
|
|
|
|
DHCPREQUEST - i.e., the client has only a single network interface
|
|
|
|
.I and
|
|
|
|
it does not remember leases it's holding on networks to which it is
|
|
|
|
not currently attached. Neither of these assumptions are guaranteed
|
|
|
|
or provable, so we urge caution in the use of this statement.
|
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I use-lease-addr-for-default-route
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBuse-lease-addr-for-default-route\fR \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
If the \fIuse-lease-addr-for-default-route\fR parameter is true in a
|
|
|
|
given scope, then instead of sending the value specified in the
|
|
|
|
routers option (or sending no value at all), the IP address of the
|
|
|
|
lease being assigned is sent to the client. This supposedly causes
|
|
|
|
Win95 machines to ARP for all IP addresses, which can be helpful if
|
|
|
|
your router is configured for proxy ARP.
|
|
|
|
.PP
|
|
|
|
.B The
|
1997-11-22 12:13:21 +03:00
|
|
|
.I server-identifier
|
|
|
|
.B statement
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
1997-11-22 12:13:21 +03:00
|
|
|
\fBserver-identifier \fIhostname\fR\fB;\fR
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
1999-02-19 01:04:06 +03:00
|
|
|
The server-identifier statement can be used to define the value that
|
|
|
|
is sent in the DHCP Server Identifier option for a given scope. The
|
|
|
|
value specified \fBmust\fR be an IP address for the DHCP server, and
|
|
|
|
must be reachable by all clients served by a particular scope.
|
|
|
|
.PP
|
|
|
|
The use of the server-identifier statement is not recommended - the only
|
|
|
|
reason to use it is to force a value other than the default value to be
|
|
|
|
sent on occasions where the default value would be incorrect. The default
|
|
|
|
value is the first IP address associated with the physical network interface
|
1999-02-24 07:14:34 +03:00
|
|
|
on which the request arrived.
|
|
|
|
.PP
|
|
|
|
The usual case where the
|
1999-02-19 01:04:06 +03:00
|
|
|
\fIserver-identifier\fR statement needs to be sent is when a physical
|
|
|
|
interface has more than one IP address, and the one being sent by default
|
|
|
|
isn't appropriate for some or all clients served by that interface.
|
1999-02-24 07:14:34 +03:00
|
|
|
Another common case is when an alias is defined for the purpose of
|
|
|
|
having a consistent IP address for the DHCP server, and it is desired
|
|
|
|
that the clients use this IP address when contacting the server.
|
|
|
|
.PP
|
|
|
|
Supplying a value for the dhcp-server-identifier option is equivalent
|
|
|
|
to using the server-identifier statement.
|
2000-04-22 12:18:11 +04:00
|
|
|
.PP
|
|
|
|
.B The
|
|
|
|
.I ddns-updates
|
|
|
|
.B statement
|
|
|
|
.PP
|
|
|
|
\fBddns-updates \fIflag\fR\fB;\fR
|
|
|
|
.PP
|
|
|
|
The \fIddns-updates\fR parameter controls whether or not the server will
|
|
|
|
attempt to do a ddns update when a lease is confirmed. Set this to \fIoff\fR
|
|
|
|
if the server should not attempt to do updates within a certain scope.
|
|
|
|
The \fIddns-updates\fR parameter is on by default.
|
1997-11-22 12:13:21 +03:00
|
|
|
.SH REFERENCE: OPTION STATEMENTS
|
1997-03-30 00:52:15 +03:00
|
|
|
.PP
|
1997-11-22 12:13:21 +03:00
|
|
|
DHCP option statements are documented in the
|
|
|
|
.B dhcp-options(5)
|
|
|
|
manual page.
|
1997-03-30 00:52:15 +03:00
|
|
|
.SH SEE ALSO
|
1997-11-22 12:13:21 +03:00
|
|
|
dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131.
|
1997-03-30 00:52:15 +03:00
|
|
|
.SH AUTHOR
|
|
|
|
.B dhcpd(8)
|
|
|
|
was written by Ted Lemon <mellon@vix.com>
|
|
|
|
under a contract with Vixie Labs. Funding
|
2000-04-22 12:18:11 +04:00
|
|
|
for this project was provided by the Internet Software Consortium.
|
1997-03-30 00:52:15 +03:00
|
|
|
Information about the Internet Software Consortium can be found at
|
|
|
|
.B http://www.isc.org/isc.
|