Droms R. The DHCP handbook

Подождите немного. Документ загружается.

specified name in the DNS. If value is also specified, there must not be an RR in the

DNS that is attached to the specified name with the specified value.

Parameter Statements

Parameter statements control how the DHCP server behaves—how long leases should

be, whether to respond to a client’s request, and so on. These statements can appear

in any scope, as well as within conditional statements within a scope, and they

affect the response to any client for which that scope is valid.

The allow, deny, and ignore Statements

The allow, deny and ignore statements are parameters you can use to control the

server’s behavior. These statements should not be confused with

allow and deny pool

permits; although both begin with

allow or deny, they have distinct meanings and

different syntax. Whereas permits are evaluated during address allocation,

allow and

deny statements are evaluated after the address is allocated, so they cannot affect the

address allocation process. The

ignore statement is exactly equivalent to the deny

statement, except that it specifies that the DHCP server should not log the fact that

it didn’t respond.

The

bootp Flag

[ allow | deny | ignore ] bootp;

The bootp flag tells the server whether to respond to BOOTP requests. Responses to

BOOTP requests are allowed by default. The

allow bootp and deny bootp statements

should only be used to specify how the DHCP server responds to BOOTP clients with

fixed-address allocations; to control dynamic BOOTP allocation, you should use pool

permits.

The

booting Flag

[ allow | deny | ignore ] booting;

The booting flag tells the server whether to respond to queries from a particular

client. By default, booting is allowed, but if it is disabled for a particular client, the

server never responds to that client.

The

duplicates Flag

[ allow | deny | ignore ] duplicates;

The duplicates flag tells the server whether to assign a DHCP client with a particu-

lar client identifier a lease if a client with the same link-layer address has already

obtained a lease by using a different client identifier. Duplicate client identifiers for

the same link-layer address are allowed by default.

APPENDIX B ISC DHCP Server Configuration File Reference486

032 3273 App B 10/3/02 5:04 PM Page 486

The declines Flag

[ allow | deny | ignore ] declines;

The declines flag tells the server whether to honor DHCPDECLINE messages sent by

the DHCP client. A malicious or buggy client can easily pollute the DHCP server’s

lease database by declining every lease in it in quick succession. By default, the

DHCP server is configured to honor the

DHCPDECLINE message.

The

client-updates Flag

[ allow | deny ] client-updates;

The client-updates flag tells the server what policy to follow when a DHCP client

indicates that it intends to update its own forward mapping in the DNS. For more

information on how this flag is used, see Chapter 23.

The default-lease-time Statement

default-lease-time time;

The default-lease-time statement specifies the duration of the lease that the DHCP

server assigns if the client requesting the lease does not ask for a specific expiration

time.

time is the duration of the lease in seconds—by default, 12 hours.

The max-lease-time Statement

max-lease-time time;

The max-lease-time statement specifies the maximum duration of the lease that the

DHCP server assigns to a DHCP client. Dynamic BOOTP lease lengths are not

limited by this parameter.

time is the maximum duration of a client lease in

seconds—by default, 24 hours.

The min-lease-time Statement

min-lease-time time;

The min-lease-time statement specifies the minimum duration of a lease that the

DHCP server will assign to a client.

time is the minimum duration of a client lease in

seconds—by default, 0. You can use the

min-lease-time parameter to force DHCP

clients to take leases that are longer than the lease durations that they request.

Parameter Statements 487

032 3273 App B 10/3/02 5:04 PM Page 487

The min-secs Statement

min-secs seconds;

The min-secs statement specifies the minimum number of seconds since a client

began trying to acquire a new lease that the DHCP server should wait before

responding to the client’s request.

The number of seconds is based on what the client reports. The maximum value that

the client can report is 255 seconds. Generally, if you set

seconds to 1, the DHCP

server does not respond to the client’s first request, but it always responds to the

client’s second request.

You can use this parameter to set up a secondary DHCP server that doesn’t offer an

address to a client until the primary server is given a chance to do so. If the primary

server is down, the client binds to the secondary server; otherwise, clients should

always bind to the primary server. Note that this does not, by itself, permit a primary

server and a secondary server to share a common IP address allocation pool.

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 a way of

renewing leases and do not know their leases can expire, the DHCP server normally

assigns unlimited leases to all BOOTP clients. However, it might 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 end. The date is speci-

fied in this format:

W YYYY/MM/DD HH:MM:SS

W is the day of the week expressed as a number from 0 (Sunday) to 6 (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 0 to 23. MM is

the minute, and

SS is the second. The time is always expressed in Coordinated

Universal Time (UTC), not in local time.

APPENDIX B ISC DHCP Server Configuration File Reference488

032 3273 App B 10/3/02 5:04 PM Page 488

The dynamic-bootp-lease-length Statement

dynamic-bootp-lease-length length;

The dynamic-bootp-lease-length statement specifies the duration of leases that are

dynamically assigned to BOOTP clients. At some sites, it might 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 restarts using BOOTP during the timeout period, the lease dura-

tion is reset to

length, so a BOOTP client that boots frequently enough never loses

its lease.

CAUTION

You should use this parameter with extreme caution.

The get-lease-hostnames Statement

get-lease-hostnames flag;

The get-lease-hostnames statement specifies that what the DHCP server should do

if it has not been given a host-name option for the client it is configuring. If

flag is

true, the server do a reverse lookup on the IP address assigned to the client and

sends the result to the client in the

host-name option. If flag is false, or if no get-

lease-hostnames statement is specified, the server doesn’t do the reverse lookup, and

sends no

host-name option to the client.

The authoritative Statement

[ not ] authoritative;

When the DHCP server receives a DHCPREQUEST message from a DHCP client, request-

ing a specific IP address, DHCP requires that the server determine whether the IP

address is valid for the network to which the client is attached. If the address is not

valid, the DHCP server should respond with a

DHCPNAK message, forcing the client to

acquire a new IP address.

To make this determination for IP addresses on a particular network segment, the

DHCP server must have complete configuration information for that network

segment. Unfortunately, it is not safe to assume that DHCP servers are configured

with complete information. Therefore, the DHCP server normally assumes that it

does not have complete information and thus is not sufficiently authoritative to

safely send

DHCPNAK messages as required by DHCP.

Parameter Statements 489

032 3273 App B 10/3/02 5:04 PM Page 489

This default assumption should not be true for any network segment that is in the

same administrative domain as the DHCP server. For such network segments, you

should specify the

authoritative statement, so that the server sends DHCPNAK

messages as required by the protocol. If the DHCP server receives requests only from

network segments in the your administrative domain, you can specify the

authori-

tative statement at the top of the configuration file (in the global scope).

NOTE

Version 2.0 and earlier of the DHCP server makes the opposite assumption: that the DHCP

server is configured with all configuration information for all network segments of which it is

aware. If this assumption is not valid for your configuration, you must write

not authorita-

tive

statements for all network segments where this assumption is not true (or at the top of

the configuration file). Version 1.0 does not support the authoritative statement.

The always-reply-rfc1048 Statement

always-reply-rfc1048 flag;

Some BOOTP clients expect RFC 1048-style responses but do not follow RFC 1048

when sending their requests. You can tell that a client has this problem if it does not

get 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 RFC 1048 options to such a client, set the always-reply-

rfc1048 parameter in that client’s host declaration to true. The DHCP server

responds with an

RFC-1048-style vendor options field. You can set this flag in any

scope, and it affects all clients covered by that scope.

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 particular scope,

instead of sending the value specified in the

routers option (or sending no value at

all), the DHCP server uses the IP address of the lease being assigned to the client in

the

routers option.

The server-identifier Statement

server-identifier hostname;

You can use the server-identifier statement 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 it must be reachable by all clients served by a

particular scope.

APPENDIX B ISC DHCP Server Configuration File Reference490

032 3273 App B 10/3/02 5:04 PM Page 490

Use of the server-identifier statement is not recommended. You should use it

only to force a value to be sent when it is incorrect to send the default value (that is,

the first IP address associated with the physical network interface on which the

request arrives).

Usually, the

server-identifier statement is needed 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 in which

server-identifier is needed is when you define an

IP alias for the purpose of having a consistent IP address for the DHCP server, and

you want the clients to use this IP address when contacting the server. If the DHCP

server crashes, you can start a hot spare with the same IP alias but with a different

primary address, and the spare server will receive

DHCPREQUEST messages from clients

in the

RENEWING state.

Supplying a value for the dhcp-server-identifier option is equivalent to using the

server-identifier statement.

The vendor-option-space Statement

vendor-option-space option-space;

The vendor-option-space statement instructs the server to construct a vendor-

encapsulated-options option, using all the defined options in the option space. If

vendor-encapsulated-options option is defined, the server sends this option to

the client, if appropriate.

The site-option-space Statement

site-option-space option-space;

The site-option-space statement determines the option space from which site-local

options are taken. Site-local options have codes ranging from 128 to 254. If no

site-

option-space is specified, site-specific options are taken from the default option

space.

The always-broadcast Statement

always-broadcast flag;

The always-broadcast statement directs the DHCP server to set the broadcast bit in

its response to any client in whose scope this directive appears, and if the client is on

the local network, to broadcast the response to the client, even if the client did not

request a broadcast response. This is not normally useful, but for some buggy clients,

it can be helpful.

Parameter Statements 491

032 3273 App B 10/3/02 5:04 PM Page 491

The ddns-domainname Statement

ddns-domainname “name”;

The ddns-domainname statement directs the DHCP server to use the domain name

specified in

name as the domain in which a DHCP client’s name will be stored when

that DHCP client’s

A record is updated.

The ddns-hostname Statement

ddns-hostname “name”;

The ddns-hostname statement directs the DHCP server to use the name specified in

name as the hostname that will be used when that DHCP client’s A record is updated.

Normally this value should simply be whatever the client sends and should not be

set by the DHCP server administrator.

The ddns-rev-domainname Statement

ddns-rev-domainname “name”;

The ddns-rev-domainname statement directs the DHCP server to use the domain

name specified in

name as the domain in which a DHCP client’s name will be stored

when that DHCP client’s

PTR record is updated.

The lease-file-name Statement

lease-file-name name;

The lease-file-name statement directs the DHCP server to use the specified name

for its lease file.

The pid-file-name Statement

pid-file-name name;

The pid-file-name statement directs the DHCP server to use the specified name for

its process ID (PID) file.

The ddns-updates Statement

ddns-updates flag;

The ddns-updates statement tells the DHCP server whether to perform DNS updates

for DHCP clients that match the scope in which it appears. If flag is

true, the DHCP

server performs DNS updates; if

flag is false, it does not. This parameter allows for

APPENDIX B ISC DHCP Server Configuration File Reference492

032 3273 App B 10/3/02 5:04 PM Page 492

fine-grained control over which clients receive DNS updates. It has no effect unless

DNS updates are enabled globally with the

ddns-update-style statement.

The omapi-port Statement

omapi-port port;

The omapi-port statement instructs the DHCP server to listen for OMAPI connec-

tions on the specified port. OMAPI is an experimental protocol that is new in version

3 of the ISC DHCP server. Limited documentation for OMAPI is available in the ISC

DHCP distribution.

The omapi-key Statement

omapi-key key;

The omapi-key statement instructs the DHCP server to authenticate all OMAPI

connections by using the specified key, which must be defined in a

key declaration.

If no OMAPI key is specified, OMAPI connections are not authenticated, which is

rather dangerous.

The stash-agent-options Statement

stash-agent-options flag;

Unicast DHCPREQUEST messages do not go through a relay agent. Relay agent options

are added by the DHCP relay agent, not the DHCP client. This means that relay

agent options are present when a lease is first acquired but not when it is renewed.

The

stash-agent-options statement tells the DHCP server whether to keep a copy of

the relay agent information option it receives when a DHCP client acquires its lease,

for use when the lease is renewed. If

flag is true, relay agent information options

are saved; otherwise, they are not. By default, relay information options are saved.

The ddns-ttl Statement

ddns-ttl ttl;

The ddns-ttl statement tells the DHCP server what TTL value to send when it does a

DNS update.

ttl is specified as a number of seconds.

The update-optimization Statement

update-optimization flag;

The update-optimization statement tells the DHCP server whether to do DNS

update optimization. If update optimization is enabled, the DHCP server only does a

Parameter Statements 493

032 3273 App B 10/3/02 5:04 PM Page 493

DNS update for a particular lease when it is first assigned, when it is released, and

when it expires. This can reduce the DNS update load on the DHCP server substan-

tially, but it opens up the possibility that in some cases the DNS will get out of sync

with the DHCP server’s recollection of what it has stored in the DNS.

The ping-check Statement

ping-check flag;

The ping-check statement tells the DHCP server whether to send an ICMP echo

request to probe an IP address before it offers it to a DHCP client. The

ping check

can protect the DHCP server from allocating a lease to a client for an IP address that

is in use, but it delays the DHCP server’s response by 1 second, which in some cases

is too long.

The update-static-leases Statement

update-static-leases flag;

The update-static-leases statement tells the DHCP server whether to perform DNS

updates for DHCP clients whose addresses are statically allocated. This is not

normally done because the DHCP server does not keep track of statically assigned

leases and therefore would not know when to remove the DHCP client’s DNS infor-

mation from the DNS database. Also, the DHCP server can’t remember whether it

has updated the DNS information for the client, so it updates it every time the client

renews its lease.

The log-facility Statement

log-facility facility;

The log-facility statement tells the DHCP server what syslog facility code to use

when logging DHCP server messages to the system logger. Possible codes are

kern,

user, mail, daemon (this is the default), auth, syslog, lpr, news, uucp, cron, authpriv,

ftp, and local0 through local7. Not all values are defined on all systems. The log-

facility statement doesn’t take effect until the DHCP server has parsed the

dhcpd.conf file, so the initial DHCP server logging always goes to the default log

facility.

Statements That Define Values to Send to Clients

Four statements define specific values to send to DHCP clients:

• the filename statement

• the server-name statement

APPENDIX B ISC DHCP Server Configuration File Reference494

032 3273 App B 10/3/02 5:04 PM Page 494

• the next-server statement

• the option statement

The first three statements define the values to send in the filename, server-name,

and

siaddr fields of the BOOTP or DHCP packet. The option statement is used to

define the options sent back to the client in the

option portion of the DHCP packet.

The filename Statement

filename “filename “;

You can use the filename statement to specify the name of the initial boot file to be

loaded by a client.

filename should be the name of a file that is recognizable to

whatever file transfer protocol the client is expected to use to load the file. Some

clients might prefer to receive this information in the

bootfile-name option.

The server-name Statement

server-name “name”;

You can use the server-name statement to inform the client of the name of the

server from which it should load its boot file.

name should be the name that is

provided to the client. Some clients prefer to receive the server name in the

server-

name option.

The next-server Statement

next-server server-name;

You use the next-server statement 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 option Statement

option option-name option-values;

option option-name = data-expression;

The option statement defines the value that is sent to a client for a particular DHCP

option, if the server finds that it is appropriate to send a value for that option.

option-name is the name of the option whose value is specified—either an option

space name, followed by a period (

.), followed by the name of that option or the

name of an option in the

dhcp option space.

Statements That Define Values to Send to Clients 495

032 3273 App B 10/3/02 5:04 PM Page 495