Dhcpd sample config file

To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Sample configuration file for ISC dhcpd. Use this to send dhcp log messages to a different log file you also. If it is desirable to be able to boot a DHCP or BOOTP client on more than one subnet with fixed v4 addresses, more than one address may be specified in the fixed-address declaration, or more than one host statement may be specified matching the same client.

The fixed-address6 declaration is used for v6 addresses. At this time it only works with a single address. For multiple addresses specify multiple host statements. If client-specific boot parameters must change based on the network to which the client is attached, then multiple host declarations should be used.

The host declarations will only match a client if one of their fixed-address statements is viable on the subnet or shared network where the client is attached. Conversely, for a host declaration to match a client being allocated a dynamic address, it must not have any fixed-address statements. You may therefore need a mixture of host declarations for any given client 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 network hardware address supplied by the client.

DHCPv6 servers can use the host-identifier option parameter in the host declaration, and specify any option with a fixed value to identify hosts. Please be aware that only the dhcp-client-identifier option and the hardware address can be used to match a host declaration, or the host-identifier option parameter for DHCPv6 servers. For example, it is not possible to match a host declaration to a host-name option.

This is because the host-name option cannot be guaranteed to be unique for any given client, whereas both the hardware address and dhcp-client-identifier option are at least theoretically guaranteed to be unique to a given client.

It can be used to group hosts, shared networks, subnets, or even other groups. The allow and deny keywords actually have different meanings depending on the context. In a pool context, these keywords can be used to set up access lists for address allocation pools. In other contexts, the keywords simply control general server behavior with respect to clients based on scope.

In a non-pool context, the ignore keyword can be used in place of the deny keyword to prevent logging of denied requests. 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 allow ed by default.

An unknown client is simply a client that has no host declaration. The use of this option is now deprecated. 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 allow ed by default. The booting keyword allow booting; 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 allow ed, but if it is disabled for a particular client, then that client will not be able to get an address from the DHCP server.

The duplicates keyword allow duplicates; deny duplicates; Host declarations can match client messages based on the DHCP Client Identifier 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. 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 identifiers change regularly from holding many leases at the same time.

By default, duplicates are allow ed. The server will eventually reclaim these leases, but not while the client is running through the pool. The declines flag is only supported by DHCPv4 servers. Given the large IPv6 address space and the internal limits imposed by the server's address generation mechanism we don't think it is necessary for DHCPv6 servers at this time.

When an address is abandoned it is both recorded as such in the lease file and retained as abandoned in server memory until the server is restarted. Upon restart, the server will process the lease file and all addresses whose last known state is abandoned will be retained as such in memory but not rewritten to the lease file.

This means that a subsequent restart of the server will not see the abandoned addresses in the lease file and therefore have no record of them as abandoned in memory and as such perceive them as free for assignment. The total number addresses in a pool, available for a given DUID value, is internally limited by the server's address generation mechanism.

If through mistaken configuration, multiple clients are using the same DUID they will competing for the same addresses causing the server to reach this internal limit rather quickly. The internal limit isolates this type of activity such that address range is not exhausted for other DUID values. The client-updates keyword allow client-updates; deny client-updates; The client-updates flag tells the DHCP server whether or not to honor the client's intention to do its own update of its A record.

By default, the server will not respond to these packets. Otherwise, the server will simply not respond to the client.

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. 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.

When declaring permit lists for address allocation pools, the following syntaxes are recognized following the allow or deny keywords: known-clients; If specified, this statement either allows or prevents allocation from this pool to any client that has a host declaration i. A client is known if it has a host declaration in any scope, not just the current scope. This is not yet supported. 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.

This can be used when you want to move clients from one pool to another. A short min-lease-time enforces a step change, whereas a longer min-lease-time allows for a gradual change. Abandoned leases will only be offered to clients if there are no free leases. If not defined, the default abandon lease time is seconds 24 hours. Note the abandoned lease time for a given lease is preserved across server restarts.

The parameter may only be set at the global scope and is evaluated only once during server startup. Values less than sixty seconds are not recommended as this is below the ping check threshold and can cause leases once abandoned but since returned to the free state to not be pinged before being offered. The adaptive-lease-time-threshold statement adaptive-lease-time-threshold percentage ; When the number of allocated leases within a pool rises above the percentage given in this statement, the DHCP server decreases the lease length for new clients within this pool to min-lease-time seconds.

Clients renewing an already valid long leases get at least the remaining time from the current lease. Since the leases expire faster, the server may either recover more quickly or avoid pool exhaustion entirely.

Once the number of allocated leases drop below the threshold, the server reverts back to normal lease times. Valid percentages are between 1 and 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. If you want to send rfc options to such a client, you can set the always-reply-rfc option in that client's host declaration, and the DHCP server will respond with an RFCstyle 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.

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 check-secs-byte-order statement check-secs-byte-order flag ; When check-secs-byte-order is enabled, the server will check for DHCPv4 clients that do the byte ordering on the secs field incorrectly. This field should be in network byte order but some clients get it wrong. When this parameter is enabled the server will examine the secs field and if it looks wrong high byte non zero and low byte zero swap the bytes. The default is disabled. This parameter is only useful when doing load balancing within failover.

Formerly, this behavior had to be enabled during compilation configuration via --enable-secs-byteorder. The db-time-format statement db-time-format [ default local ] ; The DHCP server software outputs several timestamps when writing leases to persistent storage. This configuration parameter selects one of two output formats.

The default format prints the day, date, and time in UTC, while the local format prints the system seconds-since-epoch, and helpfully provides the day and time in the system timezone in a comment.

The time formats are described in detail in the dhcpd. 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-dual-stack-mixed-mode statement ddns-dual-stack-mixed-mode flag ; The ddns-dual-stack-mixed-mode parameter controls whether or not the server applies Dual Stack Mixed Mode rules during DDNS conflict resolution. This parameter is off by default, has no effect unless update-conflict-detection is enabled, and may only be specified at the global scope.

Proper conflict resolution requires ID matching and should only be disabled after careful consideration. This parameter is on by default, has no effect unless update-conflict-detection is enabled, and may only be specified at the global scope. The dns-local-address4 and dns-local-address6 statements ddns-local-address4 address ; ddns-local-address6 address ; The address parameter should be the local IPv4 or IPv6 address the server should use as the from address when sending DDNS update requests.

The ddns-other-guard-is-dynamic statement ddns-other-guard-is-dynamic flag ; The ddns-other-guard-is-dynamic parameter controls whether or not a a server running DSMM will consider the presence of the other update style DHCID RR as an indcation that a DNS entries may be overwritten.

It should only be enabled after careful study as it allows DNS entries that would otherwise be protected as static, to be overwritten in certain cases. This paramater is off by default, has no effect unless ddns-dual-stack-mixed-mode is enabled, and may only be specified at the global scope.

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. 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 The ddns-update-style parameter ddns-update-style style ; The style parameter must be one of standard , interim or none.

The ddns-update-style statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd. The default is none. 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 default is seconds. The count represents how many DHCPv4 replies maximum will be queued pending transmission until after a database commit event. If this number is reached, a database commit event commonly resulting in fsync and representing a performance penalty will be made, and the reply packets will be transmitted in a batch afterwards.

This preserves the RFC direction that "stable storage" be updated prior to replying to clients. Should the DHCPv4 sockets "go dry" select returns immediately with no read sockets , the commit is made and any queued packets are transmitted.

Similarly, microseconds indicates how many microseconds are permitted to pass inbetween queuing a packet pending an fsync, and performing the fsync. The delayed-ack feature is compiled in by default, but can be disabled at compile time with '.

Please note that the delayed-ack feature is not currently compatible with support for DHPCv4-over-DHCPv6 so when a 4to6 port ommand line argument enables this in the server the delayed-ack value is reset to 0. The dhcp-cache-threshold statement dhcp-cache-threshold percentage ; The dhcp-cache-threshold statement takes one integer parameter with allowed values between 0 and This parameter expresses the percentage of the total lease time, measured from the beginning, during which a client's attempt to renew its lease will result in getting the already assigned lease, rather than an extended lease.

Clients that attempt renewal frequently can cause the server to update and write the database frequently resulting in a performance impact on the server.

The dhcp-cache-threshold statement instructs the DHCP server to avoid updating leases too frequently thus avoiding this behavior. Instead the server replies with the same lease i. None of these changes require writing the lease to disk. When an existing lease is matched to a renewing client, it will be reused if all of the following conditions are true: 1.

The dhcp-cache-threshold is larger than zero 2. The current lease is active 3. The percentage of the lease time that has elapsed is less than dhcp-cache-threshold 4.

The client information provided in the renewal does not alter any of the following: a. Billing class to which the lease is associated IPv4 only c. The host declaration associated with the lease IPv4 only d. The client id - this may happen if a client boots without a client id and then starts using one in subsequent requests. IPv4 only While lease data is not written to disk when a lease is reused, the server will still execute any on-commit statements.

Note that the lease can be reused if the options the client or relay agent sends are changed. These changes will not be recorded in the in-memory or on-disk databases until the client renews after the threshold time is reached. 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. 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 dont-use-fsync statement dont-use-fsync flag ; The dont-use-fsync statement instructs the DHCP server if it should call fsync when writing leases to the lease file. By default and if the flag is set to false the server will call fsync. Suppressing the call to fsync may increase the performance of the server but it also adds a risk that a lease will not be properly written to the disk after it has been issued to a client and before the server stops.

This can lead to duplicate leases being issued to different clients. Using this option is not recommendedFR. 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. 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.

YYYY is the year, including the century. MM is the month expressed as a number from 1 to DD is the day of the month, counting from 1. HH is the hour, from zero to MM is the minute and SS is the second. 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.

The period is specified in length as a number of seconds. Needless to say, this parameter should be adjusted with extreme caution. The echo-client-id statement echo-client-id flag ; The echo-client-id statement is used to enable or disable RFC compliant behavior. In other words if the client sends the option it will receive it back.

By default, this flag is off and client identifiers will not echoed back to the client. 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 It should only appear in a host declaration.

It only takes a minute to sign up. Connect and share knowledge within a single location that is structured and easy to search. I want to set up the isc-dhcp-server, but the dhcp. Your issue seems to lie with the interface enp30s0; line.

Since you refer to the options numerically, I don't think you need to specify the interface. From the dhcpd. 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. I went line by line recreating your dhcpd. The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd. The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written.

If this happens, the dhcpd. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the dhcpd. When the DHCP server is started for the first time, it fails unless the dhcpd. If the same server is also running BIND as a DNS server, this step is not necessary, as starting the named service automatically checks for a dhcpd. By default, the DHCP service does not start at boot time. To configure the daemon to start automatically at boot time, refer to Chapter 15, Controlling Access to Services.

If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device.

This is useful for a firewall machine with two network cards. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet. The default is port