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 setting this flag to 'on' for the relevant scope; relevant scopes would be inside a conditional statement, as a parameter for a class, or as a parameter for a host declaration. 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.
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 authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration 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 spurious 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 authoritative; at the top of their configuration file to indicate that the DHCP server should send DHCPNAK messages to misconfigured 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.
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.
The boot-unknown-clients statement
boot-unknown-clients flag;
If the boot-unknown-clients statement is present and has a value of false or off, then clients for which there is no host declaration will not be allowed to obtain IP addresses. If this statement is not present or has a value of true or on, then clients without host declarations will be allowed to obtain IP addresses, as long as those addresses are not restricted by allow and deny statements within their pool declarations.
The ddns-hostname statement
ddns-hostname name;
The name parameter should be the hostname that will be used in setting up the client's A and PTR records. If no ddns-hostname is specified in scope, then the server will derive the hostname automatically, using an algorithm that varies for each of the different update methods.
The ddns-domainname statement
ddns-domainname name;
The name parameter should be the domain name that will be appended to the client's hostname to form a fully-qualified domain-name (FQDN).
The ddns-rev-domainname statement
ddns-rev-domainname name; The name parameter should be 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. By default, this is "in-addr.arpa.", but the default can be overridden here.
The reversed IP address to which this domain name is appended is always the IP address of the client, in dotted quad notation, reversed - for example, if the IP address assigned to the client is 10.17.92.74, then the reversed IP address is 74.92.17.10. So a client with that IP address would, by default, be given a PTR record of 10.17.92.74.in-addr.arpa.
The ddns-update-style parameter
ddns-update-style style;
The style parameter must be one of ad-hoc, interim or none. The ddns-update-style statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is assigned an IP address, so there is no way to use different DNS update styles for different clients.
The ddns-updates statement
ddns-updates flag;
The ddns-updates parameter controls whether or not the server will attempt to do a DNS update when a lease is confirmed. Set this to off if the server should not attempt to do updates within a certain scope. The ddns-updates parameter is on by default. To disable DNS updates in all scopes, it is preferable to use the ddns-update-style statement, setting the style to none.
The default-lease-time statement
default-lease-time time;
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 do-forward-updates statement
do-forward-updates flag;
The do-forward-updates statement instructs the DHCP server as to whether it should attempt to update a DHCP client's A record when the client acquires or renews a lease. This statement has no effect unless DNS updates are enabled and ddns-update-style is set to interim. Forward updates are enabled by default. If this statement is used to disable forward updates, the DHCP server will never attempt to update the client's A record, and will only ever attempt to update the client's PTR record if the client supplies an FQDN that should be placed in the PTR record using the fqdn option. If forward updates are enabled, the DHCP server will still honor the setting of the client-updates flag.
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. Because BOOTP clients do not have any way of renewing leases, and don't know that their leases could expire, by default dhcpd assigns 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 Coordinated Universal 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 number 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 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 fixed-address declaration
fixed-address address [ , address ... ] ;
The fixed-address declaration 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 that corresponds to the network on which it is booting. If none of the addresses in the fixed-address statement are valid for the network to which the client is connected, that client will not match the host declaration containing that fixed-address declaration. Each address in the fixed-address declaration should be either an IP address or a domain name that resolves to one or more IP addresses.
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 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) separated by colons. The hardware statement may also be used for DHCP clients.
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 DBDIR/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 local-port statement
local-port port;
This statement causes the DHCP server to listen for DHCP requests on the UDP port specified in port, rather than on port 67.
The local-address statement
local-address address;
This statement causes the DHCP server to listen for DHCP requests sent to the specified address, rather than requests sent to all addresses. Since serving directly attached DHCP clients implies that the server must respond to requests sent to the all-ones IP address, this option cannot be used if clients are on directly attached networks...it is only realistically useful for a server whose only clients are reached via unicasts, such as via DHCP relay agents.
Note: This statement is only effective if the server was compiled using the USE_SOCKETS #define statement, which is default on a small number of operating systems, and must be explicitly chosen at compile-time for all others. You can be sure if your server is compiled with USE_SOCKETS if you see lines of this format at startup:
Listening on Socket/eth0
Note also that since this bind()s all DHCP sockets to the specified address, that only one address may be supported in a daemon at a given time.
The log-facility statement
log-facility facility;
This statement causes the DHCP server to do all of its logging on the specified log facility once the dhcpd.conf file has been read. By default the DHCP server logs to the daemon facility. Possible log facilities include auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp, and local0 through local7. Not all of these facilities are available on all systems, and there may be other facilities available on other systems.
In addition to setting this value, you may need to modify your syslog.conf file to configure logging of the DHCP server. For example, you might add a line like this:
local7.debug /var/log/dhcpd.log
The syntax of the syslog.conf file may be different on some operating systems - consult the syslog.conf manual page to be sure. To get syslog to start logging to the new file, you must first create the file with correct ownership and permissions (usually, the same owner and permissions of your /var/log/messages or /usr/adm/messages file should be fine) and send a SIGHUP to syslogd. Some systems support log rollover using a shell script or program called newsyslog or logrotate, and you may be able to configure this as well so that your log file doesn't grow uncontrollably.
Because the log-facility setting is controlled by the dhcpd.conf file, log messages printed while parsing the dhcpd.conf file or before parsing it are logged to the default log facility. To prevent this, see the README file included with this distribution, which describes how to change the default log facility. When this parameter is used, the DHCP server prints its startup message a second time after parsing the configuration file, so that the log will be as complete as possible.
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 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.
The omapi-port statement
omapi-port port;
The omapi-port statement causes the DHCP server to listen for OMAPI connections on the specified port. This statement is required to enable the OMAPI protocol, which is used to examine and modify the state of the DHCP server as it is running.
The one-lease-per-client statement
one-lease-per-client flag;
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 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 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 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.
The ping-check statement
ping-check flag;
When the DHCP server is considering dynamically allocating an IP address to a client, it first sends an ICMP Echo request (a ping) to the address being assigned. It waits for a second, and if no ICMP Echo response has been heard, it assigns the address. If a response is heard, the lease is abandoned, and the server does not respond to the client.
This ping check introduces a default one-second delay in responding to DHCPDISCOVER messages, which can be a problem for some clients. The default delay of one second may be configured using the ping-timeout parameter. The ping-check configuration parameter can be used to control checking - if its value is false, no ping check is done.
The ping-timeout statement
ping-timeout seconds;
If the DHCP server determined it should send an ICMP echo request (a ping) because the ping-check statement is true, ping-timeout allows you to configure how many seconds the DHCP server should wait for an ICMP Echo response to be heard, if no ICMP Echo response has been received before the timeout expires, it assigns the address. If a response is heard, the lease is abandoned, and the server does not respond to the client. If no value is set, ping-timeout defaults to 1 second.
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 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 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 appropriate 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 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 site-option-space statement
site-option-space name ;
The site-option-space statement can be used to determine from what option space site-local options will be taken. This can be used in much the same way as the vendor-option-space statement. Site-local options in DHCP are those options whose numeric codes are greater than 128. These options are intended for site-specific uses, but are frequently used by vendors of embedded hardware that contains DHCP clients. Because site-specific options are allocated on an ad hoc basis, it is quite possible that one vendor's DHCP client might use the same option code that another vendor's client uses, for different purposes. The site-option-space option can be used to assign a different set of site-specific options for each such vendor, using conditional evaluation (see dhcp-eval (5) for details).
The stash-agent-options statement
stash-agent-options flag;
If the stash-agent-options parameter is true for a given client, the server will record the relay agent information options sent during the client's initial DHCPREQUEST message when the client was in the SELECTING state and behave as if those options are included in all subsequent DHCPREQUEST messages sent in the RENEWING state. This works around a problem with relay agent information options, which is that they usually not appear in DHCPREQUEST messages sent by the client in the RENEWING state, because such messages are unicast directly to the server and not sent through a relay agent.
The update-optimization statement
update-optimization flag;
If the update-optimization parameter is false for a given client, the server will attempt a DNS update for that client each time the client renews its lease, rather than only attempting an update when it appears to be necessary. This will allow the DNS to heal from database inconsistencies more easily, but the cost is that the DHCP server must do many more DNS updates. We recommend leaving this option enabled, which is the default. This option only affects the behavior of the interim DNS update scheme, and has no effect on the ad-hoc DNS update scheme. If this parameter is not specified, or is true, the DHCP server will only update when the client information changes, the client gets a different lease, or the client's lease expires.
The update-static-leases statement
update-static-leases flag;
The update-static-leases flag, if enabled, causes the DHCP server to do DNS updates for clients even if those clients are being assigned their IP address using a fixed-address statement - that is, the client is being given a static assignment. This can only work with the interim DNS update scheme. It is not recommended because the DHCP server has no way to tell that the update has been done, and therefore will not delete the record when it is not in use. Also, the server must attempt the update each time the client renews its lease, which could have a significant performance impact in environments that place heavy demands on the DHCP server.
The use-host-decl-names statement
use-host-decl-names flag;
If the use-host-decl-names 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,
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.
It should be noted here that most DHCP clients completely ignore the host-name option sent by the DHCP server, and there is no way to configure them not to do this. So you generally have a choice of either not having any hostname to client IP address mapping that the client will recognize, or doing DNS updates. It is beyond the scope of this document to describe how to make this determination.
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 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. The use of this feature is not recommended, because it won't work for many DHCP clients.
The vendor-option-space statement
vendor-option-space string;
The vendor-option-space parameter determines from what option space vendor options are taken. The use of this configuration parameter is illustrated in the dhcp-options(5) manual page, in the VENDOR ENCAPSULATED OPTIONS section.