dhcpd.conf(5)
- NetBSD Manual Pages
dhcpd.conf(5) dhcpd.conf(5)
NAME
dhcpd.conf - dhcpd configuration file
DESCRIPTION
The dhcpd.conf file contains configuration information for
dhcpd, the Internet Software Consortium DHCP Server.
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-insen-
sitive. Comments may be placed anywhere within the file
(except within quotes). Comments begin with the # char-
acter and end at the end of the line.
The file essentially consists of a list of statements.
Statements fall into two broad categories - parameters and
declarations.
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 gate-
way 220.177.244.7).
Declarations are used to describe the topology of the net-
work, 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.
Declarations about network topology include the
shared-network and the subnet declarations. If clients
on a subnet are to be assigned addresses dynamically, a
range declaration must appear within the subnet declara-
tion. For clients with statically assigned addresses, or
for installations where only known clients will be served,
each such client must have a host declaration. If param-
eters are to be applied to a group of declarations which
are not related strictly on a per-subnet basis, the group
declaration can be used.
For every subnet which will be served, and for every sub-
net to which the dhcp server is connected, there must be
one subnet declaration, which tells dhcpd how to recognize
that an address is on that subnet. A subnet declaration
is required for each subnet even if no addresses will be
dynamically allocated on that subnet.
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
1
dhcpd.conf(5) dhcpd.conf(5)
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 eth-
ernet until such time as a new physical network can be
added. In this case, the subnet declarations for these
two networks must be enclosed in a shared-network declara-
tion.
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 depart-
ments on the same subnet. For clients which will be
declared explicitly with host declarations, these declara-
tions can be enclosed in a group declaration along with
the parameters which are common to that department. For
clients whose addresses will be dynamically assigned,
class declarations and conditional declarations may be
used to group parameter assignments based on information
the client sends.
When a client is to be booted, its boot parameters are
determined by consulting that client's host declaration
(if any), and then consulting the any class declarations
matching the client, followed by the pool, subnet and
shared-network declarations for the IP address assigned to
the client. Each of these declarations itself appears
within a lexical scope, and all declarations at less spe-
cific 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.
When dhcpd tries to find a host declaration for a client,
it first looks for a host declaration which has a fixed-
address parameter which matches the subnet or shared net-
work on which the client is booting. If it doesn't find
any such entry, it then tries to find an entry which has
no fixed-address parameter.
EXAMPLES
A typical dhcpd.conf file will look something like this:
global parameters...
subnet 204.254.239.0 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.42 204.254.239.62;
2
dhcpd.conf(5) dhcpd.conf(5)
}
subnet 204.254.239.64 netmask 255.255.255.224 {
subnet-specific parameters...
range 204.254.239.74 204.254.239.94;
}
group {
group-specific parameters...
host zappo.test.isc.org {
host-specific parameters...
}
host beppo.test.isc.org {
host-specific parameters...
}
host harpo.test.isc.org {
host-specific parameters...
}
}
Figure 1
Notice that at the beginning of the file, there's a place
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:
option domain-name "isc.org";
option domain-name-servers ns1.isc.org, ns2.isc.org;
Figure 2
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.
The most obvious reason for having subnet-specific parame-
ters as shown in Figure 1 is that each subnet, of neces-
sity, has its own router. So for the first subnet, for
example, there should be something like:
option routers 204.254.239.1;
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 legiti-
mate 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,
3
dhcpd.conf(5) dhcpd.conf(5)
and it would not be appropriate to use that name here.
In Figure 1 there is also a group statement, which pro-
vides 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 sup-
plied to these hosts:
option domain-name "test.isc.org";
Also, given the domain they're in, these are probably test
machines. If we wanted to test the DHCP leasing mecha-
nism, we might set the lease timeout somewhat shorter than
the default:
max-lease-time 120;
default-lease-time 120;
You may have noticed that while some parameters start with
the option keyword, some do not. Parameters starting
with the option 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).
In Figure 1, each host had host-specific parameters.
These could include such things as the hostname option,
the name of a file to upload (the filename parameter) and
the address of the server from which to upload the file
(the next-server 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.
Imagine that you have a site with a lot of NCD X-Termi-
nals. 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:
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";
4
dhcpd.conf(5) dhcpd.conf(5)
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; }
}
ADDRESS POOLS
The 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 fire-
wall, 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 regis-
ter their DHCP clients. To do this, you would set up a
pair of pool declarations:
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;
}
}
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.
5
dhcpd.conf(5) dhcpd.conf(5)
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 per-
mit list is introduced with the allow or deny 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 per-
mit 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.
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 DHCPRE-
QUEST 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.
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 permit-
ted 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.
If no existing lease is found, or if the client is forbid-
den 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 range dec-
larations that appear outside of pool declarations are
grouped into a single pool with no permit list). If the
6
dhcpd.conf(5) dhcpd.conf(5)
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.
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.
DHCP FAILOVER
This version of the ISC DHCP server supports the DHCP
failover protocol as documented in draft-ietf-dhc-
failover-07.txt. This is not a final protocol document,
and we have not done interoperability testing with other
vendors' implementations of this protocol, so you must not
assume that this implementation conforms to the standard.
If you wish to use the failover protocol, make sure that
both failover peers are running the same version of the
ISC DHCP server.
The failover protocol allows two DHCP servers (and no more
than two) to share a common address pool. Each server
will have about half of the available IP addresses in the
pool at any given time for allocation. If one server
fails, the other server will continue to renew leases out
of the pool, and will allocate new addresses out of the
roughly half of available addresses that it had when com-
munications with the other server were lost.
It is possible during a prolonged failure to tell the
remaining server that the other server is down, in which
case the remaining server will (over time) reclaim all the
addresses the other server had available for allocation,
and begin to reuse them. This is called putting the
server into the PARTNER-DOWN state.
When the other server comes back online, it should auto-
matically detect that it has been offline and request a
complete update from the server that was running in the
PARTNER-DOWN state, and then both servers will resume pro-
cessing together.
It is possible to get into a dangerous situation: if you
put one server into the PARTNER-DOWN state, and then
*that* server goes down, and the other server comes back
up, the other server will not know that the first server
was in the PARTNER-DOWN state, and may issue addresses
previously issued by the other server to different
7
dhcpd.conf(5) dhcpd.conf(5)
clients, resulting in IP address conflicts. Before
putting a server into PARTNER-DOWN state, therefore, make
sure that the other server will not restart automatically.
The failover protocol defines a primary server role and a
secondary server role. There are some differences in how
primaries and secondaries act, but most of the differences
simply have to do with providing a way for each peer to
behave in the opposite way from the other. So one server
must be configured as primary, and the other must be con-
figured as secondary, and it doesn't matter too much which
one is which.
CONFIGURING FAILOVER
In order to configure failover, you need to write a peer
declaration that configures the failover protocol, and you
need to write peer references in each pool declaration for
which you want to do failover. You do not have to do
failover for all pools on a given network segment. You
must not tell one server it's doing failover on a particu-
lar address pool and tell the other it is not. You must
not have any common address pools on which you are not
doing failover.
The server currently does very little sanity checking,
so if you configure it wrong, it will just fail in odd
ways. I would recommend therefore that you either do
failover or don't do failover, but don't do any mixed
pools. Also, use the same master configuration file for
both servers, and have a seperate file that con-
tains the peer declaration and includes the master file.
This will help you to avoid configuration mismatches. As
our implementation evolves, this will become less of a
problem. A basic sample dhcpd.conf file for a primary
server might look like this:
failover peer "foo" {
primary;
address anthrax.rc.vix.com;
port 519;
peer address trantor.rc.vix.com;
peer port 520;
max-response-delay 60;
max-unacked-updates 10;
mclt 3600;
hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
load balance max seconds 3;
}
include "/etc/dhcpd.master";
The statements in the peer declaration are as follows:
8
dhcpd.conf(5) dhcpd.conf(5)
The primary and secondary statements
[ primary | secondary ]
This determines whether the server is primary or sec-
ondary, as described earlier under DHCP FAILOVER.
The address statement
address address
The address statement declares the IP address on which the
server should listen for connections from its failover
peer, and also the value to use for the DHCP Failover Pro-
tocol server identifier. Because this value is used as an
identifier, it may not be omitted.
The peer address statement
peer address address
The peer address statement declares the IP address to
which the server should connect to reach its failover peer
for failover messages.
The port statement
port port-number
The port statement declares the TCP port on which the
server should listen for connections from its failover
peer. This statement may not currently be omitted,
because the failover protocol does not yet have a reserved
TCP port number.
The peer port statement
peer port port-number
The peer port statement declares the TCP port to which the
server should connect to reach its failover peer for
failover messages. This statement may not be omitted
because the failover protocol does not yet have a reserved
TCP port number. The port number declared in the peer
port statement may be the same as the port number declared
in the port statement.
The max-response-delay statement
max-response-delay
seconds
The max-response-delay statement tells the DHCP server how
many seconds may pass without receiving a message from its
9
dhcpd.conf(5) dhcpd.conf(5)
failover peer before it assumes that connection has
failed. This number should be small enough that a tran-
sient network failure that breaks the connection will not
result in the servers being out of communication for a
long time, but large enough that the server isn't con-
stantly making and breaking connections. This parameter
must be specified.
The max-unacked-updates statement
max-unacked-updates count
The max-unacked-updates statement tells the DHCP server
how many many BINDUPD messages it can send before it
receives a BNDACK from the failover peer. We don't have
enough operational experience to say what a good value for
this is, but 10 seems to work. This parameter must be
specified.
The mclt statement
mclt seconds
The mclt statement defines the Maximum Client Lead Time.
It must be specified on the primary, and may not be speci-
fied on the secondary. This is the length of time for
which a lease may be renewed by either failover peer with-
out contacting the other. The longer you set this, the
longer it will take for the running server to recover IP
addresses after moving into PARTNER-DOWN state. The
shorter you set it, the more load your servers will expe-
rience when they are not communicating. A value of some-
thing like 3600 is probably reasonable, but again bear in
mind that we have no real operational experience with
this.
The split statement
split index
The split statement specifies the split between the pri-
mary and secondary for the purposes of load balancing.
Whenever a client makes a DHCP request, the DHCP server
runs a hash on the client identification. If the hash
comes out to less than the split value, the primary
answers. If it comes out to equal to or more than the
split, the secondary answers. This value should gener-
ally be set to 128, and can only be configured on the pri-
mary.
The hba statement
hba colon-seperated-hex-list
10
dhcpd.conf(5) dhcpd.conf(5)
The hba statement specifies the split between the primary
and secondary as a bitmap rather than a cutoff, which the-
oretically allows for finer-grained control. In prac-
tice, there is probably no need for such fine-grained con-
trol, however. An example hba statement:
hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;
The load balance max seconds statement
load balance max seconds seconds
This statement allows you to configure a cutoff after
which load balancing is disabled. The cutoff is based on
the number of seconds since the client sent its first
DHCPDISCOVER or DHCPREQUEST message, and only works with
clients that correctly implement the secs field - fortu-
nately most clients do. We recommend setting this to
something like 3 or 5. The effect of this is that if one
of the failover peers gets into a state where it is
responding to failover messages but not responding to some
client requests, the other failover peer will take over
its client load automatically as the clients retry.
CLIENT CLASSING
Clients can be seperated into classes, and treated differ-
ently depending on what class they are in. This sepera-
tion 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.
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 add
statement in the conditional's list of statements:
if substring (option dhcp-client-identifier, 0, 3) = "RAS" {
add "ras-clients";
}
A nearly equivalent way to do this is to simply specify
the conditional expression as a matching expression in the
class statement:
class "ras-clients" {
match if substring (option dhcp-client-identifier, 0, 3) = "RAS";
}
Note that whether you use matching expressions or add
statements (or both) to classify clients, you must always
11
dhcpd.conf(5) dhcpd.conf(5)
write a class declaration for any class that you use. If
there will be no match statement and no in-scope state-
ments for a class, the declaration should look like this:
class "ras-clients" {
}
Also, the 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.
SUBCLASSES
In addition to classes, it is possible to declare sub-
classes. 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. Sub-
classes work as follows:
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;
}
}
The data following the class name in the subclass declara-
tion 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
12
dhcpd.conf(5) dhcpd.conf(5)
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.
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 sub-
classes are declared without scopes. If part of the pur-
pose of the subclass were to define different parameter
values for some clients, you might want to declare some
subclasses with scopes.
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:
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}
In this example, we've used subclassing as a way to con-
trol 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 exam-
ple of this is shown under the VENDOR ENCAPSULATED OPTIONS
head later on in this document.
PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION
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 speci-
fied as follows:
class "limited-1" {
lease limit 4;
}
This will produce a class in which a maximum of four mem-
bers may hold a lease at one time.
SPAWNING CLASSES
It is possible to declare a spawning class. A spawning
class is a class that automatically produces subclasses
based on what the client sends. The reason that spawning
13
dhcpd.conf(5) dhcpd.conf(5)
classes were created was to make it possible to create
lease-limited classes on the fly. The envisioned appli-
cation 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 con-
nected.
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 typi-
cally 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:
class "customer" {
spawn with option agent.circuit-id;
lease limit 4;
}
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 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.
The use of the subclass spawning mechanism is not
restricted to relay agent options - this particular exam-
ple is given only because it is a fairly straightforward
one.
COMBINING MATCH, MATCH IF AND SPAWN WITH
In some cases, it may be useful to use one expression to
assign a client to a particular class, and a second
expression to put it into a subclass of that class. This
can be done by combining the match if and spawn with
statements, or the match if and match statements. For
example:
class "jr-cable-modems" {
match if option dhcp-vendor-identifier = "jrcm";
spawn with option agent.circuit-id;
lease limit 4;
}
class "dv-dsl-modems" {
match if opton dhcp-vendor-identifier = "dvdsl";
14
dhcpd.conf(5) dhcpd.conf(5)
spawn with option agent.circuit-id;
lease limit 16;
}
This allows you to have two classes that both have the
same spawn with expression without getting the clients in
the two classes confused with each other.
DYNAMIC DNS UPDATES
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 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 capabili-
ties.
There are three parameters, which may vary according to
the scope, that control how DDNS updates will be done.
The first two are the ddns-domainname and ddns-rev-domain-
name statements. The 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 exam-
ple, if the client's hostname is "hutson" and the ddns-
domainname is set to "sneedville.edu", then the client's
FQDN will be "hutson.sneedville.edu".
The 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.
A third parameter, 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.
HOW DNS UPDATES WORK
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
15
dhcpd.conf(5) dhcpd.conf(5)
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 net-
work 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.
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.
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 one-
lease-per-client parameter so that roaming clients do not
trigger this same behavior.
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 DHCPRE-
QUEST, 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.
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.
DYNAMIC DNS UPDATE SECURITY
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, how-
ever, 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.
The DNS server must be configured to allow updates for any
zone that the DHCP server will be updating. For example,
16
dhcpd.conf(5) dhcpd.conf(5)
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:
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; };
};
You will also have to configure your DHCP server to do
updates to these zones. To do so, you need to add some-
thing like this to your dhcpd.conf file:
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;
}
You should choose your own secret key, of course. The ISC
BIND 8 and 9 distributions come with a program for gener-
ating secret keys called dnskeygen. 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. The key
above was generated with the command:
dnskeygen -H 128 -u -c -n DHCP_UPDATER
You may wish to enable logging of DNS transactions on your
17
dhcpd.conf(5) dhcpd.conf(5)
DNS server. To do so, you might write a logging statement
like the following:
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; };
};
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.
REFERENCE: EVENTS
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.
To declare a set of statements to execute when an event
happens, you must use the on 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.
The built-in version of the dynamic 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.
REFERENCE: DECLARATIONS
The shared-network statement
18
dhcpd.conf(5) dhcpd.conf(5)
shared-network name {
[ parameters ]
[ declarations ]
}
The shared-network statement is used to inform the DHCP
server that some IP subnets actually share the same physi-
cal network. Any subnets in a shared network should be
declared within a shared-network statement. Parameters
specified in the shared-network 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.
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.
The subnet statement
subnet subnet-number netmask netmask {
[ parameters ]
[ declarations ]
}
The subnet 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-spe-
cific parameters and to specify what addresses may be
dynamically allocated to clients booting on that subnet.
Such addresses are specified using the range declaration.
The subnet-number should be an IP address or domain name
which resolves to the subnet number of the subnet being
described. The 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.
Although a netmask must be given with every subnet decla-
ration, 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.
19
dhcpd.conf(5) dhcpd.conf(5)
The range statement
range [ dynamic-bootp ] low-address [ high-address];
For any subnet on which addresses will be assigned dynami-
cally, there must be at least one range 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 range statement is declared. The
dynamic-bootp 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 sin-
gle address, high-address can be omitted.
The host statement
host hostname {
[ parameters ]
[ declarations ]
}
There must be at least one host statement for every BOOTP
client that is to be served. host statements may also be
specified for DHCP clients, although this is not required
unless booting is only enabled for known hosts.
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 fixed-address
parameter, or more than one host statement may be speci-
fied.
If client-specific boot parameters must change based on
the network to which the client is attached, then multiple
host statements should be used.
If a client is to be booted using a fixed address if it's
possible, but should be allocated a dynamic address other-
wise, then a host statement must be specified without a
fixed-address clause. hostname should be a name identify-
ing the host. If a hostname option is not specified for
the host, hostname is used.
Host declarations are matched to actual DHCP or BOOTP
clients by matching the dhcp-client-identifier option
specified in the host declaration to the one supplied by
the client, or, if the host declaration or the client does
not provide a dhcp-client-identifier option, by matching
the hardware parameter in the host declaration to the net-
work hardware address supplied by the client. BOOTP
clients do not normally provide a dhcp-client-identifier,
so the hardware address must be used for all clients that
may boot using the BOOTP protocol.
20
dhcpd.conf(5) dhcpd.conf(5)
The group statement
group {
[ parameters ]
[ declarations ]
}
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.
REFERENCE: ALLOW AND DENY
The allow and 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 mean-
ings 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 ignore key-
word can be used in place of the deny keyword to prevent
logging of denied requests.
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.
The unknown-clients keyword
allow unknown-clients;
deny unknown-clients;
ignore unknown-clients;
The unknown-clients flag is used to tell dhcpd whether or
not to dynamically assign addresses to unknown clients.
Dynamic address assignment to unknown clients is allowed
by default.
The bootp keyword
allow bootp;
deny bootp;
ignore bootp;
The bootp flag is used to tell dhcpd whether or not to
respond to bootp queries. Bootp queries are allowed by
default.
The booting keyword
allow booting;
21
dhcpd.conf(5) dhcpd.conf(5)
deny booting;
ignore booting;
The booting 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 allowed, but if it is disabled for
a particular client, then that client will not be able to
get and address from the DHCP server. The duplicates key-
word
allow duplicates;
deny duplicates;
Host declarations can match client messages based on the
DHCP Client Identifer option or based on the client's net-
work 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 possi-
ble when one computer has more than one operating system
installed on it - for example, Microsoft Windows and
NetBSD or Linux.
The duplicates 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 iden-
tifiers change regularly from holding many leases at the
same time. By default, duplicates are allowed. The
declines keyword
allow declines;
deny declines;
ignore declines;
The DHCPDECLINE message is used by DHCP clients to indi-
cate 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 thrash-
ing in the DNS, and it will also cause the DHCP server to
forget old DHCP client address allocations.
The declines flag tells the DHCP server whether or not to
honor DHCPDECLINE messages. If it is set to deny or
ignore in a particular scope, the DHCP server will not
respond to DHCPDECLINE messages.
22
dhcpd.conf(5) dhcpd.conf(5)
ALLOW AND DENY WITHIN POOL DECLARATIONS
The uses of the allow and deny keyword shown in the previ-
ous 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.
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.
When a DHCPREQUEST message is processed, address alloca-
tion 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.
When declaring permit lists for address allocation pools,
the following syntaxes are recognized following the allow
or deny keyword:
known clients;
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 any scope, not just the current
scope.
unknown clients;
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).
members of "class";
If specified, this statement either allows or prevents
allocation from this pool to any client that is a member
of the named class.
23
dhcpd.conf(5) dhcpd.conf(5)
dynamic bootp clients;
If specified, this statement either allows or prevents
allocation from this pool to any bootp client.
authenticated clients;
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.
unauthenticated clients;
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.
all clients;
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 renum-
ber 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.
REFERENCE: PARAMETERS
The lease-file-name statement
lease-file-name name;
Name should be the name of the DHCP server's lease file.
By default, this is /var/db/dhcpd.leases. This statement
must appear in the outer scope of the configuration file -
if it appears in some other scope, it will have no effect.
The pid-file-name statement
pid-file-name name;
Name should be the name of the DHCP server's process ID
file. This is the file in which the DHCP server's pro-
cess ID is stored when the server starts. By default,
this is /var/run/dhcpd.pid. Like the lease-file-name
statement, this statement must appear in the outer scope
of the configuration file.
The default-lease-time statement
default-lease-time time;
24
dhcpd.conf(5) dhcpd.conf(5)
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.
The max-lease-time statement
max-lease-time time;
Time should be the maximum length in seconds that will be
assigned to a 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.
The min-lease-time statement
min-lease-time time;
Time should be the minimum length in seconds that will be
assigned to a lease.
The min-secs statement
min-secs seconds;
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.
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.
The hardware statement
hardware hardware-type hardware-address;
In order for a BOOTP client to be recognized, its network
hardware address must be declared using a hardware clause
in the host statement. hardware-type must be the name of
a physical hardware interface type. Currently, only the
ethernet and token-ring types are recognized, although
support for a fddi hardware type (and others) would also
be desirable. The hardware-address should be a set of
hexadecimal octets (numbers from 0 through ff) seperated
25
dhcpd.conf(5) dhcpd.conf(5)
by colons. The hardware statement may also be used for
DHCP clients.
The filename statement
filename "filename";
The filename statement can be used to specify the name of
the initial boot file which is to be loaded by a client.
The filename should be a filename recognizable to whatever
file transfer protocol the client can be expected to use
to load the file.
The server-name statement
server-name "name";
The server-name statement can be used to inform the client
of the name of the server from which it is booting. Name
should be the name that will be provided to the client.
The next-server statement
next-server server-name;
The next-server statement is used to specify the host
address of the server from which the initial boot file
(specified in the filename statement) is to be loaded.
Server-name should be a numeric IP address or a domain
name. If no next-server parameter applies to a given
client, the DHCP server's IP address is used.
The fixed-address statement
fixed-address address [, address ... ];
The fixed-address statement is used to assign one or more
fixed IP addresses to a client. It should only appear in
a host 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 fixed-address
statement are on the network on which the client is boot-
ing, that client will not match the host declaration con-
taining that fixed-address statement. Each address should
be either an IP address or a domain name which resolves to
one or more IP addresses.
The dynamic-bootp-lease-cutoff statement
dynamic-bootp-lease-cutoff date;
The dynamic-bootp-lease-cutoff statement sets the ending
time for all leases assigned dynamically to BOOTP clients.
26
dhcpd.conf(5) dhcpd.conf(5)
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.
Date should be the date on which all assigned BOOTP leases
will end. The date is specified in the form:
W YYYY/MM/DD HH:MM:SS
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 Universal Coordinated
Time (UTC), not local time.
The dynamic-bootp-lease-length statement
dynamic-bootp-lease-length length;
The dynamic-bootp-lease-length 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 length as a num-
ber of seconds. If a client reboots using BOOTP during
the timeout period, the lease duration is reset to length,
so a BOOTP client that boots frequently enough will never
lose its lease. Needless to say, this parameter should be
adjusted with extreme caution.
The get-lease-hostnames statement
get-lease-hostnames flag;
The get-lease-hostnames 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 hostname option. If flag is
true, then this lookup is done for all addresses in the
current scope. By default, or if flag is false, no
lookups are done.
The use-host-decl-names statement
use-host-decl-names flag;
If the use-host-decl-names parameter is true in a given
27
dhcpd.conf(5) dhcpd.conf(5)
scope, then for every host declaration within that scope,
the name provided for the host declaration will be sup-
plied to the client as its hostname. So, for example,
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";
}
An option host-name statement within a host declaration
will override the use of the name in the host declaration.
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configura-
tion information about a given network segment is not
known to be correct and is not authoritative. This is so
that if a naive user installs a DHCP server not fully
understanding how to configure it, it does not send spuri-
ous DHCPNAK messages to clients that have obtained
addresses from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP
servers for their networks should always write authorita-
tive; at the top of their configuration file to indicate
that the DHCP server should send DHCPNAK messages to mis-
configured clients. If this is not done, clients will be
unable to get a correct IP address after changing subnets
until their old lease has expired, which could take quite
a long time.
Usually, writing authoritative; 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.
28
dhcpd.conf(5) dhcpd.conf(5)
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 author-
itative 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 declara-
tions and not others.
The always-reply-rfc1048 statement
always-reply-rfc1048 flag;
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.
If you want to send rfc1048 options to such a client, you
can set the 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.
The always-broadcast statement
always-broadcast flag;
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 set-
ting this flag to 'on' for the relevant scope. To avoid
creating excess broadcast traffic on your network, we rec-
ommend 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 Open-
Transport and ISC DHCP clients.
The one-lease-per-client statement
one-lease-per-client flag;
If this flag is enabled, whenever a client sends a DHCPRE-
QUEST for a particular lease, the server will automati-
cally free any other leases the client holds. This pre-
sumes that when the client sends a DHCPREQUEST, it has
forgotten any lease not mentioned in the DHCPREQUEST -
29
dhcpd.conf(5) dhcpd.conf(5)
i.e., the client has only a single network interface 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.
The use-lease-addr-for-default-route statement
use-lease-addr-for-default-route flag;
If the use-lease-addr-for-default-route parameter is true
in a given scope, then instead of sending the value speci-
fied 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.
The server-identifier statement
server-identifier hostname;
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 must be an IP
address for the DHCP server, and must be reachable by all
clients served by a particular scope.
The use of the server-identifier statement is not recom-
mended - 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 net-
work interface on which the request arrived.
The usual case where the server-identifier 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 appro-
priate for some or all clients served by that interface.
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.
Supplying a value for the dhcp-server-identifier option is
equivalent to using the server-identifier statement.
The ddns-updates statement
ddns-updates flag;
The ddns-updates parameter controls whether or not the
server will attempt to do a ddns update when a lease is
confirmed. Set this to off if the server should not
30
dhcpd.conf(5) dhcpd.conf(5)
attempt to do updates within a certain scope. The ddns-
updates parameter is on by default.
SETTING PARAMETER VALUES USING EXPRESSIONS
Sometimes it's helpful to be able to set the value of a
DHCP server parameter based on some value that the client
has sent. To do this, you can use expression evaluation.
The dhcp-eval(5) manual page describes how to write
expressions. To assign the result of an evaluation to an
option, define the option as follows:
my-parameter = expression ;
For example:
ddns-hostname = binary-to-ascii (16, 8, "-",
substring (hardware, 1, 6));
REFERENCE: OPTION STATEMENTS
DHCP option statements are documented in the dhcp-
options(5) manual page.
SEE ALSO
dhcpd(8), dhcpd.leases(5), RFC2132, RFC2131.
AUTHOR
dhcpd(8) was written by Ted Lemon <mellon@vix.com> under a
contract with Vixie Labs. Funding for this project was
provided by the Internet Software Consortium. Information
about the Internet Software Consortium can be found at
http://www.isc.org/isc.
31
Powered by man-cgi (2024-03-20).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.