diff options
Diffstat (limited to 'server/dhcpd.conf.cat5')
| -rw-r--r-- | server/dhcpd.conf.cat5 | 1716 |
1 files changed, 0 insertions, 1716 deletions
diff --git a/server/dhcpd.conf.cat5 b/server/dhcpd.conf.cat5 deleted file mode 100644 index f104d635..00000000 --- a/server/dhcpd.conf.cat5 +++ /dev/null @@ -1,1716 +0,0 @@ - - - -dhcpd.conf(5) dhcpd.conf(5) - - -NNAAMMEE - dhcpd.conf - dhcpd configuration file - -DDEESSCCRRIIPPTTIIOONN - The dhcpd.conf file contains configuration information for - _d_h_c_p_d_, 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 - _s_h_a_r_e_d_-_n_e_t_w_o_r_k and the _s_u_b_n_e_t declarations. If clients - on a subnet are to be assigned addresses dynamically, a - _r_a_n_g_e declaration must appear within the _s_u_b_n_e_t declara - tion. For clients with statically assigned addresses, or - for installations where only known clients will be served, - each such client must have a _h_o_s_t declaration. If param - eters are to be applied to a group of declarations which - are not related strictly on a per-subnet basis, the _g_r_o_u_p - 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 _s_u_b_n_e_t declaration, which tells dhcpd how to recognize - that an address is on that subnet. A _s_u_b_n_e_t 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 _s_u_b_n_e_t declarations for these - two networks may be enclosed in a _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _h_o_s_t declarations, these declara - tions can be enclosed in a _g_r_o_u_p 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 _h_o_s_t declaration - (if any), and then consulting the any _c_l_a_s_s declarations - matching the client, followed by the _p_o_o_l, _s_u_b_n_e_t and - _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _h_o_s_t declaration for a client, - it first looks for a _h_o_s_t declaration which has a _f_i_x_e_d_- - _a_d_d_r_e_s_s 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 _f_i_x_e_d_-_a_d_d_r_e_s_s parameter. If no such entry is found, - then dhcpd acts as if there is no entry in the dhcpd.conf - file for that client, even if there is an entry for that - client on a different subnet or shared network. - -EEXXAAMMPPLLEESS - A typical dhcpd.conf file will look something like this: - - _g_l_o_b_a_l _p_a_r_a_m_e_t_e_r_s_._._. - - subnet 204.254.239.0 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.10 204.254.239.30; - } - - - - - 2 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - subnet 204.254.239.32 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.42 204.254.239.62; - } - - subnet 204.254.239.64 netmask 255.255.255.224 { - _s_u_b_n_e_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - range 204.254.239.74 204.254.239.94; - } - - group { - _g_r_o_u_p_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - host zappo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host beppo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - host harpo.test.isc.org { - _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s_._._. - } - } - - 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 - - - - 3 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - - In Figure 1 there is also a _g_r_o_u_p 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 _o_p_t_i_o_n keyword, some do not. Parameters starting - with the _o_p_t_i_o_n 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 _h_o_s_t_-_s_p_e_c_i_f_i_c _p_a_r_a_m_e_t_e_r_s. - These could include such things as the _h_o_s_t_n_a_m_e option, - the name of a file to upload (the _f_i_l_e_n_a_m_e _p_a_r_a_m_e_t_e_r_) _a_n_d - _t_h_e _a_d_d_r_e_s_s _o_f _t_h_e _s_e_r_v_e_r _f_r_o_m _w_h_i_c_h _t_o _u_p_l_o_a_d _t_h_e _f_i_l_e - _(_t_h_e _n_e_x_t_-_s_e_r_v_e_r 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; } - - - - 4 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - } - - group { - filename "Xncd19c"; - next-server ncd-booter; - - host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; } - host ncd3 { hardware ethernet 0:c0:c3:00:14:11; } - } - - group { - filename "XncdHMX"; - next-server ncd-booter; - - host ncd1 { hardware ethernet 0:c0:c3:11:90:23; } - host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; } - host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; } - } - -AADDDDRREESSSS PPOOOOLLSS - The ppooooll 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; - } - } - - - - - 5 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - - 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 _a_l_l_o_w or _d_e_n_y 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. - -AADDDDRREESSSS AALLLLOOCCAATTIIOONN - 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 - - - - 6 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 _r_a_n_g_e dec - larations that appear outside of pool declarations are - grouped into a single pool with no permit list). If the - permit list for the pool allows the client to be allocated - an address from that pool, the pool is examined to see if - there is an address available. If so, then the client is - tentatively assigned that address. Otherwise, the next - pool is tested. If no addresses are found that can be - assigned to the client, no response is sent to the client. - - 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. - -CCLLIIEENNTT CCLLAASSSSIINNGG - 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 aadddd - 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 - 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" { - } - - - - 7 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - Also, the aadddd 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. - -SSUUBBCCLLAASSSSEESS - 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 - 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 - - - - 8 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - -PPEERR--CCLLAASSSS LLIIMMIITTSS OONN DDYYNNAAMMIICC AADDDDRREESSSS AALLLLOOCCAATTIIOONN - 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. - -SSPPAAWWNNIINNGG CCLLAASSSSEESS - It is possible to declare a _s_p_a_w_n_i_n_g _c_l_a_s_s. A spawning - class is a class that automatically produces subclasses - based on what the client sends. The reason that spawning - classes were created was to make it possible to create - lease-limited classes on the fly. The envisioned 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 - - - - 9 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 ddhhccppdd..lleeaasseess 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. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEESS - The DHCP server has the ability to dynamically update the - Domain Name System. Within the configuration files, you - can define how you want the Domain Name System to be - updated. These updates are RFC 2136 compliant so any DNS - server supporting RFC 2136 should be able to accept - updates from the DHCP server. The DHCP server will only - perform DNS updates if it has been built with DNS updates - enabled as described in the README file that comes with - the DHCP distribution. - - 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 _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e and _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_ - _n_a_m_e statements. The _d_d_n_s_-_d_o_m_a_i_n_n_a_m_e parameter sets the - - - - 10 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 _d_d_n_s_- - _d_o_m_a_i_n_n_a_m_e is set to "sneedville.edu", then the client's - FQDN will be "hutson.sneedville.edu". - - The _d_d_n_s_-_r_e_v_-_d_o_m_a_i_n_n_a_m_e 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, _d_d_n_s_-_h_o_s_t_n_a_m_e 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. - -HHOOWW DDNNSS UUPPDDAATTEESS WWOORRKK - The client's FQDN, derived as we have described, is used - as the name on which an "A" record will be stored. The A - record will contain the IP address that the client was - assigned in its lease. If there is already an A record - with the same name in the DNS server, no update of either - the A or PTR records will occur - this prevents a client - from claiming that its hostname is the name of some 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 _o_n_e_- - _l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t 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 - - - - 11 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - -DDYYNNAAMMIICC DDNNSS UUPPDDAATTEE SSEECCUURRIITTYY - Support for TSIG and DNSSEC is not yet available. When - you set your DNS server up to allow updates from the DHCP - server, you may be exposing it to unauthorized updates. - To avoid this, the best you can do right now is to use IP - address-based packet filtering to prevent unauthorized - hosts from submitting update requests. - - The DNS server must be configured to allow updates for any - zone that the DHCP server will be updating. For example, - let us say that clients in the sneedville.edu domain will - be assigned addresses on the 10.10.17.0/24 subnet. In - that case, assuming you are using ISC BIND 8.2.1 or later, - you would need to have the following declarations in your - /etc/named.conf file: - - zone "sneedville.edu" { - type master; - file "sneedville.edu.db"; - allow-update { localhost; }; - }; - - zone "17.10.10.in-addr.arpa" { - type master; - file "10.10.17.db"; - allow-update { localhost; }; - }; - - This assumes that your DHCP server and your name server - will be running on the same computer - the "localhost" - name is taken in the DNS server as an alias for all of - that host's IP addresses, and updates from any of those - addresses will be accepted. - - You may wish to enable logging of DNS transactions on your - DNS server. To do so, you might write a logging statement - like the following: - - logging { - channel update_debug { - file "/var/log/update-debug.log"; - - - - 12 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - -RREEFFEERREENNCCEE:: EEVVEENNTTSS - 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 oonn 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. - -RREEFFEERREENNCCEE:: DDEECCLLAARRAATTIIOONNSS - TThhee _s_h_a_r_e_d_-_n_e_t_w_o_r_k ssttaatteemmeenntt - - sshhaarreedd--nneettwwoorrkk _n_a_m_e {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_h_a_r_e_d_-_n_e_t_w_o_r_k 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 _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement. Parameters - specified in the _s_h_a_r_e_d_-_n_e_t_w_o_r_k statement will be used - when booting clients on those subnets unless parameters - provided at the subnet or host level override them. If - - - - 13 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - - _N_a_m_e 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. - - TThhee _s_u_b_n_e_t ssttaatteemmeenntt - - ssuubbnneett _s_u_b_n_e_t_-_n_u_m_b_e_r nneettmmaasskk _n_e_t_m_a_s_k {{ - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - The _s_u_b_n_e_t 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 _r_a_n_g_e declaration. - - The _s_u_b_n_e_t_-_n_u_m_b_e_r should be an IP address or domain name - which resolves to the subnet number of the subnet being - described. The _n_e_t_m_a_s_k 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. - - TThhee _r_a_n_g_e ssttaatteemmeenntt - - rraannggee [ ddyynnaammiicc--bboooottpp ] _l_o_w_-_a_d_d_r_e_s_s [ _h_i_g_h_-_a_d_d_r_e_s_s];; - - For any subnet on which addresses will be assigned dynami - cally, there must be at least one _r_a_n_g_e 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 _r_a_n_g_e statement is declared. The - _d_y_n_a_m_i_c_-_b_o_o_t_p 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 - - - - 14 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - single address, _h_i_g_h_-_a_d_d_r_e_s_s can be omitted. - - TThhee _h_o_s_t ssttaatteemmeenntt - - hhoosstt _h_o_s_t_n_a_m_e { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - There must be at least one hhoosstt statement for every BOOTP - client that is to be served. hhoosstt 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 _f_i_x_e_d_-_a_d_d_r_e_s_s - parameter, or more than one hhoosstt statement may be speci - fied. - - If client-specific boot parameters must change based on - the network to which the client is attached, then multiple - hhoosstt 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 hhoosstt statement must be specified without a - ffiixxeedd--aaddddrreessss clause. _h_o_s_t_n_a_m_e should be a name identify - ing the host. If a _h_o_s_t_n_a_m_e option is not specified for - the host, _h_o_s_t_n_a_m_e is used. - - _H_o_s_t declarations are matched to actual DHCP or BOOTP - clients by matching the dhcp-client-identifier option - specified in the _h_o_s_t declaration to the one supplied by - the client, or, if the _h_o_s_t declaration or the client does - not provide a dhcp-client-identifier option, by matching - the _h_a_r_d_w_a_r_e parameter in the _h_o_s_t declaration to the net - work hardware address supplied by the client. BOOTP - clients do not normally provide a _d_h_c_p_-_c_l_i_e_n_t_-_i_d_e_n_t_i_f_i_e_r, - so the hardware address must be used for all clients that - may boot using the BOOTP protocol. - - TThhee _g_r_o_u_p ssttaatteemmeenntt - - ggrroouupp { - [ _p_a_r_a_m_e_t_e_r_s ] - [ _d_e_c_l_a_r_a_t_i_o_n_s ] - }} - - 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. - - - - - 15 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -RREEFFEERREENNCCEE:: AALLLLOOWW AANNDD DDEENNYY - The _a_l_l_o_w and _d_e_n_y 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 _i_g_n_o_r_e key - word can be used in place of the _d_e_n_y keyword to prevent - logging of denied requests. - - -AALLLLOOWW DDEENNYY AANNDD IIGGNNOORREE IINN SSCCOOPPEE - The following usages of allow and deny will work in any - scope, although it is not recommended that they be used in - pool declarations. - - TThhee _u_n_k_n_o_w_n_-_c_l_i_e_n_t_s kkeeyywwoorrdd - - aallllooww uunnkknnoowwnn--cclliieennttss;; - ddeennyy uunnkknnoowwnn--cclliieennttss;; - iiggnnoorree uunnkknnoowwnn--cclliieennttss;; - - The uunnkknnoowwnn--cclliieennttss flag is used to tell dhcpd whether or - not to dynamically assign addresses to unknown clients. - Dynamic address assignment to unknown clients is aalllloowwed - by default. - - TThhee _b_o_o_t_p kkeeyywwoorrdd - - aallllooww bboooottpp;; - ddeennyy bboooottpp;; - iiggnnoorree bboooottpp;; - - The bboooottpp flag is used to tell dhcpd whether or not to - respond to bootp queries. Bootp queries are aalllloowwed by - default. - - TThhee _b_o_o_t_i_n_g kkeeyywwoorrdd - - aallllooww bboooottiinngg;; - ddeennyy bboooottiinngg;; - iiggnnoorree bboooottiinngg;; - - The bboooottiinngg 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 aalllloowwed, but if it is disabled for - a particular client, then that client will not be able to - get and address from the DHCP server. TThhee _d_u_p_l_i_c_a_t_e_s kkeeyy - wwoorrdd - - aallllooww dduupplliiccaatteess;; - - - - 16 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - ddeennyy dduupplliiccaatteess;; - - 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 dduupplliiccaatteess 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 aalllloowwed. TThhee - _d_e_c_l_i_n_e_s kkeeyywwoorrdd - - aallllooww ddeecclliinneess;; - ddeennyy ddeecclliinneess;; - iiggnnoorree ddeecclliinneess;; - - 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 ddeecclliinneess flag tells the DHCP server whether or not to - honor DHCPDECLINE messages. If it is set to ddeennyy or - iiggnnoorree in a particular scope, the DHCP server will not - respond to DHCPDECLINE messages. - -AALLLLOOWW AANNDD DDEENNYY WWIITTHHIINN PPOOOOLL DDEECCLLAARRAATTIIOONNSS - 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 - - - - 17 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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: - - kknnoowwnn cclliieennttss;; - - 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 _a_n_y scope, not just the current - scope. - - uunnkknnoowwnn cclliieennttss;; - - 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). - - mmeemmbbeerrss ooff ""class"";; - - If specified, this statement either allows or prevents - allocation from this pool to any client that is a member - of the named class. - - ddyynnaammiicc bboooottpp cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any bootp client. - - aauutthheennttiiccaatteedd cclliieennttss;; - - If specified, this statement either allows or prevents - allocation from this pool to any client that has been - authenticated using the DHCP authentication protocol. - - - - 18 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - This is not yet supported. - - uunnaauutthheennttiiccaatteedd cclliieennttss;; - - 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. - - aallll cclliieennttss;; - - 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. - -RREEFFEERREENNCCEE:: PPAARRAAMMEETTEERRSS - TThhee _l_e_a_s_e_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - lleeaassee--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e should be the name of the DHCP server's lease file. - By default, this is /var/db/dhcpd.leases. This statement - mmuusstt appear in the outer scope of the configuration file - - if it appears in some other scope, it will have no effect. - - TThhee _p_i_d_-_f_i_l_e_-_n_a_m_e ssttaatteemmeenntt - - ppiidd--ffiillee--nnaammee _n_a_m_e;; - - _N_a_m_e 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. - - TThhee _d_e_f_a_u_l_t_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - ddeeffaauulltt--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e 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. - - TThhee _m_a_x_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmaaxx--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the maximum length in seconds that will be - - - - 19 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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. - - TThhee _m_i_n_-_l_e_a_s_e_-_t_i_m_e ssttaatteemmeenntt - - mmiinn--lleeaassee--ttiimmee _t_i_m_e;; - - _T_i_m_e should be the minimum length in seconds that will be - assigned to a lease. - - TThhee _m_i_n_-_s_e_c_s ssttaatteemmeenntt - - mmiinn--sseeccss _s_e_c_o_n_d_s;; - - _S_e_c_o_n_d_s 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. - - TThhee _h_a_r_d_w_a_r_e ssttaatteemmeenntt - - hhaarrddwwaarree _h_a_r_d_w_a_r_e_-_t_y_p_e _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s;; - - In order for a BOOTP client to be recognized, its network - hardware address must be declared using a _h_a_r_d_w_a_r_e clause - in the _h_o_s_t statement. _h_a_r_d_w_a_r_e_-_t_y_p_e must be the name of - a physical hardware interface type. Currently, only the - eetthheerrnneett and ttookkeenn--rriinngg types are recognized, although - support for a ffddddii hardware type (and others) would also - be desirable. The _h_a_r_d_w_a_r_e_-_a_d_d_r_e_s_s should be a set of - hexadecimal octets (numbers from 0 through ff) seperated - by colons. The _h_a_r_d_w_a_r_e statement may also be used for - DHCP clients. - - TThhee _f_i_l_e_n_a_m_e ssttaatteemmeenntt - - ffiilleennaammee ""_f_i_l_e_n_a_m_e"";; - - The _f_i_l_e_n_a_m_e statement can be used to specify the name of - the initial boot file which is to be loaded by a client. - - - - 20 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - The _f_i_l_e_n_a_m_e should be a filename recognizable to whatever - file transfer protocol the client can be expected to use - to load the file. - - TThhee _s_e_r_v_e_r_-_n_a_m_e ssttaatteemmeenntt - - sseerrvveerr--nnaammee ""_n_a_m_e"";; - - The _s_e_r_v_e_r_-_n_a_m_e statement can be used to inform the client - of the name of the server from which it is booting. _N_a_m_e - should be the name that will be provided to the client. - - TThhee _n_e_x_t_-_s_e_r_v_e_r ssttaatteemmeenntt - - nneexxtt--sseerrvveerr _s_e_r_v_e_r_-_n_a_m_e;; - - The _n_e_x_t_-_s_e_r_v_e_r statement is used to specify the host - address of the server from which the initial boot file - (specified in the _f_i_l_e_n_a_m_e statement) is to be loaded. - _S_e_r_v_e_r_-_n_a_m_e should be a numeric IP address or a domain - name. If no _n_e_x_t_-_s_e_r_v_e_r parameter applies to a given - client, the DHCP server's IP address is used. - - TThhee _f_i_x_e_d_-_a_d_d_r_e_s_s ssttaatteemmeenntt - - ffiixxeedd--aaddddrreessss _a_d_d_r_e_s_s [,, _a_d_d_r_e_s_s ... ];; - - The _f_i_x_e_d_-_a_d_d_r_e_s_s statement is used to assign one or more - fixed IP addresses to a client. It should only appear in - a _h_o_s_t 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 _f_i_x_e_d_-_a_d_d_r_e_s_s - statement are on the network on which the client is boot - ing, that client will not match the _h_o_s_t declaration con - taining that _f_i_x_e_d_-_a_d_d_r_e_s_s statement. Each _a_d_d_r_e_s_s should - be either an IP address or a domain name which resolves to - one or more IP addresses. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--ccuuttooffff _d_a_t_e;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_c_u_t_o_f_f statement sets the ending - time for all leases assigned dynamically to BOOTP clients. - Because BOOTP clients do not have any way of renewing - leases, and don't know that their leases could expire, by - default dhcpd assignes infinite leases to all BOOTP - clients. However, it may make sense in some situations to - set a cutoff date for all BOOTP leases - for example, the - end of a school term, or the time at night when a facility - is closed and all machines are required to be powered off. - - _D_a_t_e should be the date on which all assigned BOOTP leases - - - - 21 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 Greenwich Mean Time - (GMT), not local time. - - TThhee _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h ssttaatteemmeenntt - - ddyynnaammiicc--bboooottpp--lleeaassee--lleennggtthh _l_e_n_g_t_h;; - - The _d_y_n_a_m_i_c_-_b_o_o_t_p_-_l_e_a_s_e_-_l_e_n_g_t_h 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 _l_e_n_g_t_h as a num - ber of seconds. If a client reboots using BOOTP during - the timeout period, the lease duration is reset to _l_e_n_g_t_h, - so a BOOTP client that boots frequently enough will never - lose its lease. Needless to say, this parameter should be - adjusted with extreme caution. - - TThhee _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s ssttaatteemmeenntt - - ggeett--lleeaassee--hhoossttnnaammeess _f_l_a_g;; - - The _g_e_t_-_l_e_a_s_e_-_h_o_s_t_n_a_m_e_s 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 _h_o_s_t_n_a_m_e option. If _f_l_a_g is - true, then this lookup is done for all addresses in the - current scope. By default, or if _f_l_a_g is false, no - lookups are done. - - TThhee _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s ssttaatteemmeenntt - - uussee--hhoosstt--ddeeccll--nnaammeess _f_l_a_g;; - - If the _u_s_e_-_h_o_s_t_-_d_e_c_l_-_n_a_m_e_s parameter is true in a given - 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; - - - - 22 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - 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 _o_p_t_i_o_n _h_o_s_t_-_n_a_m_e statement within a host declaration - will override the use of the name in the host declaration. - - TThhee _a_u_t_h_o_r_i_t_a_t_i_v_e ssttaatteemmeenntt - - aauutthhoorriittaattiivvee;; - - nnoott aauutthhoorriittaattiivvee;; - - 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 aauutthhoorriittaa - ttiivvee;; at the top of their configuration file to indicate - that the DHCP server _s_h_o_u_l_d 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 aauutthhoorriittaattiivvee;; 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 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. - - - - 23 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - TThhee _a_l_w_a_y_s_-_r_e_p_l_y_-_r_f_c_1_0_4_8 ssttaatteemmeenntt - - aallwwaayyss--rreeppllyy--rrffcc11004488 _f_l_a_g;; - - 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 aallwwaayyss--rreeppllyy--rrffcc11004488 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. - - TThhee _a_l_w_a_y_s_-_b_r_o_a_d_c_a_s_t ssttaatteemmeenntt - - aallwwaayyss--bbrrooaaddccaasstt _f_l_a_g;; - - 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. - - TThhee _o_n_e_-_l_e_a_s_e_-_p_e_r_-_c_l_i_e_n_t ssttaatteemmeenntt - - oonnee--lleeaassee--ppeerr--cclliieenntt _f_l_a_g;; - - 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 - - i.e., the client has only a single network interface _a_n_d - 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. - - TThhee _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e ssttaatteemmeenntt - - uussee--lleeaassee--aaddddrr--ffoorr--ddeeffaauulltt--rroouuttee _f_l_a_g;; - - - - - 24 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - - If the _u_s_e_-_l_e_a_s_e_-_a_d_d_r_-_f_o_r_-_d_e_f_a_u_l_t_-_r_o_u_t_e 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. - - TThhee _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r ssttaatteemmeenntt - - sseerrvveerr--iiddeennttiiffiieerr _h_o_s_t_n_a_m_e;; - - 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 mmuusstt 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 _s_e_r_v_e_r_-_i_d_e_n_t_i_f_i_e_r 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. - - TThhee _d_d_n_s_-_u_p_d_a_t_e_s ssttaatteemmeenntt - - ddddnnss--uuppddaatteess _f_l_a_g;; - - The _d_d_n_s_-_u_p_d_a_t_e_s parameter controls whether or not the - server will attempt to do a ddns update when a lease is - confirmed. Set this to _o_f_f if the server should not - attempt to do updates within a certain scope. The _d_d_n_s_- - _u_p_d_a_t_e_s parameter is on by default. - -RREEFFEERREENNCCEE:: OOPPTTIIOONN SSTTAATTEEMMEENNTTSS - DHCP option statements are documented in the ddhhccpp-- - ooppttiioonnss((55)) manual page. - -SSEEEE AALLSSOO - dhcpd.conf(5), dhcpd.leases(5), RFC2132, RFC2131. - - - - - 25 - - - - - -dhcpd.conf(5) dhcpd.conf(5) - - -AAUUTTHHOORR - ddhhccppdd((88)) 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 - hhttttpp::////wwwwww..iisscc..oorrgg//iisscc.. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26 - - |