From 9f8b2a7f67edf5517bc8a203f7749b2c5ca7ef8e Mon Sep 17 00:00:00 2001 From: Ted Lemon Date: Thu, 1 Mar 2001 17:10:38 +0000 Subject: [PATCH] - Apply huge numbers of editorial corrections, thanks to Mark Sanders of Inktomi. --- server/dhcpd.conf.5 | 105 ++++++++++++++++++++++---------------------- 1 file changed, 52 insertions(+), 53 deletions(-) diff --git a/server/dhcpd.conf.5 b/server/dhcpd.conf.5 index ba578fd3..aec4cfa7 100644 --- a/server/dhcpd.conf.5 +++ b/server/dhcpd.conf.5 @@ -103,12 +103,12 @@ based on information the client sends. .PP When a client is to be booted, its boot parameters are determined by consulting that client's \fIhost\fR declaration (if any), and then -consulting the any \fIclass\fR declarations matching the client, +consulting any \fIclass\fR declarations matching the client, followed by the \fIpool\fR, \fIsubnet\fR and \fIshared-network\fR declarations for the IP address assigned to the client. Each of these declarations itself appears within a lexical scope, and all declarations at less specific lexical scopes are also consulted for -client option declarations as well. Scopes are never considered +client option declarations. 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. @@ -217,7 +217,7 @@ You may have noticed that while some parameters start with the \fIoption\fR keyword, some do not. Parameters starting with the \fIoption\fR 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 +the behavior 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). .PP @@ -231,7 +231,7 @@ which the parameter appears. .PP Imagine that you have a site with a lot of NCD X-Terminals. 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 +boot files for each model. One way to do this would be to have host declarations for each server and group them by model: .nf @@ -310,9 +310,9 @@ aren't. Each entry in a pool's permit list is introduced with the .I allow or \fIdeny\fR 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 +eligible 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 permit and deny lists exist +the deny list will be eligible. If both permit 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. .SH DYNAMIC ADDRESS ALLOCATION @@ -328,8 +328,8 @@ 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 +nothing about the address, 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. @@ -576,7 +576,7 @@ statement .B max-unacked-updates \fIcount\fR\fB;\fR .PP The \fBmax-unacked-updates\fR statement tells the DHCP server how -many many BINDUPD messages it can send before it receives a BNDACK +many BNDUPD messages it can send before it receives a BNDACK from the failover peer. We don't have enough operational experience to say what a good value for this is, but 10 seems to work. This parameter must be specified. @@ -663,7 +663,7 @@ hold leases at one time, and it is possible to specify automatic subclassing based on the contents of the client packet. .PP To add clients to classes based on conditional evaluation, you would -write an conditional statement to match the clients you wanted in the +write a conditional statement to match the clients you wanted in the class, and then put an .B add statement in the conditional's list of statements: @@ -700,7 +700,7 @@ 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 least for the time being. +server, but it is important to be aware of it at least for the time being. .SH SUBCLASSES .PP In addition to classes, it is possible to declare subclasses. A @@ -861,19 +861,19 @@ 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. .PP -Two DDNS update schemes are currently implemented, and another is -planned. The two that are currently available are the ad-hoc DDNS +Two DNS update schemes are currently implemented, and another is +planned. The two that are currently available are the ad-hoc DNS update mode and the interim DHCP-DNS interaction draft update mode. If and when the DHCP-DNS interaction draft and the DHCID draft make it through the IETF standards process, there will be a third mode, which -will be the standard DDNS update method. The DHCP server must be +will be the standard DNS update method. The DHCP server must be configured to use one of the two currently-supported methods, or not to do dns updates. This can be done with the .I ddns-update-style configuration parameter. -.SH THE AD HOC DNS UPDATE SCHEME -The Ad Hoc Dynamic DNS update scheme implemented in this version of -the ISC DHCP server is an interim implementation, which does not +.SH THE AD-HOC DNS UPDATE SCHEME +The ad-hoc Dynamic DNS update scheme implemented in this version of +the ISC DHCP server is a prototype design, which does not have much to do with the standard update method that is being standardized in the IETF DHC working group, but rather implements some very basic, yet useful, update capabilities. This mode @@ -883,26 +883,26 @@ with the because it does not account for the possibility of two different DHCP servers updating the same set of DNS records. .PP -For the ad hoc DNS update method, the client's FQDN is derived in two +For the ad-hoc DNS update method, the client's FQDN is derived in two parts. First, the hostname is determined. Then, the domain name is determined, and appended to the hostname. .PP The DHCP server determines the client's hostname by first looking for a \fIddns-hostname\fR configuration option, and using that if it is -present. If no such option has is present, the server looks for a -valid hostname in the FQDN option send by the client. If one is +present. If no such option is present, the server looks for a +valid hostname in the FQDN option sent by the client. If one is found, it is used; otherwise, if the client sent a host-name option, that is used. Otherwise, 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. +and will not be able to do a DNS update. .PP The domain name is determined based strictly on the server configuration, not on what the client sends. First, if there is a .I ddns-domainname configuration option, it is used. Second, if there is a \fIdomain-name\fR option configured, that is used. Otherwise, the -server will not do the DDNS update. +server will not do the DNS update. .PP The client's fully-qualified domain name, derived as we have described, is used as the name on which an "A" record will be stored. @@ -923,7 +923,7 @@ server, this should be safe. .PP 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 +will see unpredictable behavior. This is considered a bug, and will be fixed in a later release. It may be helpful to enable the .I one-lease-per-client parameter so that roaming clients do not trigger this same behavior. @@ -958,8 +958,8 @@ draft-ietf-dnsext-dhcid-rr-??.txt Because our implementation is slightly different than the standard, we will briefly document the operation of this update style here. .PP -The first point to understand about this style of DDNS updates is that -unlike the \fIad-hoc\fR style, the DHCP server does not necessarily +The first point to understand about this style of DNS update is that +unlike the ad-hoc style, the DHCP server does not necessarily always update both the A and the PTR records. The FQDN option includes a flag which, when sent by the client, indicates that the client wishes to update its own A record. In that case, the server @@ -986,16 +986,15 @@ If the server is configured not to allow client updates, or if the client doesn't want to do its own update, the server will simply choose a name for the client, possibly using the hostname supplied by the client ("jschmoe" in the previous example). It will use its own -domain name for the client, just as in the \fIad-hoc\fR update scheme. +domain name for the client, just as in the ad-hoc update scheme. It will then update both the A and PTR record, using the name that it chose for the client. If the client sends a fully-qualified domain name in the fqdn option, the server uses only the leftmost part of the domain name - in the example above, "jschmoe" instead of "jschmoe.radish.org". .PP -The other difference between the \fIad-hoc\fR scheme and the -.I interim -scheme is that with the \fIinterim\fR scheme, a method is used that +The other difference between the ad-hoc scheme and the interim +scheme is that with the interim scheme, a method is used that allows more than one DHCP server to update the DNS database without accidentally deleting A records that shouldn't be deleted nor failing to add A records that should be added. The scheme works as follows: @@ -1014,13 +1013,13 @@ TXT record's contents must be equal to hashid. If this update succeeds, then the client has its A record and PTR record. If it fails, then the name the client has been assigned (or requested) is in use, and can't be used by the client. At this point the DHCP server -gives up trying to do a DDNS update for the client until the client +gives up trying to do a DNS update for the client until the client chooses a new name. .PP -The \fIinterim\fR DNS update scheme is called interim for two reasons. +The interim DNS update scheme is called interim for two reasons. First, it does not quite follow the drafts. The current versions of the drafts call for a new DHCID RRtype, but this is not yet -available. The \fIinterim\fR DNS update scheme uses a TXT record +available. The interim DNS update scheme uses a TXT record instead. Also, the existing ddns-resolution draft calls for the DHCP server to put a DHCID RR on the PTR record, but the \fIinterim\fR update method does not do this. It is our position that this is not @@ -1029,7 +1028,7 @@ from the next version of the draft, or better understanding why it is considered useful. .PP In addition to these differences, the server also does not update very -aggressively. Because each DDNS update involves a round trip to the +aggressively. Because each DNS update involves a round trip to the DNS server, there is a cost associated with doing updates even if they do not actually modify the DNS database. So the DHCP server tracks whether or not it has updated the record in the past (this information @@ -1118,7 +1117,7 @@ generated with the command: dnskeygen -H 128 -u -c -n DHCP_UPDATER .fi .PP -You may wish to enable logging of DNS transactions on your DNS server. +You may wish to enable logging of DNS updates on your DNS server. To do so, you might write a logging statement like the following: .PP .nf @@ -1159,11 +1158,11 @@ and the expiry event, when the commitment expires. To declare a set of statements to execute when an event happens, you must use the \fBon\fR 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 +enclosed in braces. Events are used to implement DNS updates, so you should not define your own event handlers if you are -using the built-in dynamic DNS update mechanism. +using the built-in DNS update mechanism. .PP -The built-in version of the dynamic DNS update mechanism is in a text +The built-in version of the DNS update mechanism is in a text string towards the top of server/dhcpd.c. If you want to use events for things other than DNS updates, and you also want DNS updates, you will have to start out by copying this code into your dhcpd.conf file @@ -1327,7 +1326,7 @@ various sorts of requests. 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 -behaviour with respect to clients based on scope. In a non-pool +behavior with respect to clients based on scope. In a non-pool context, the .I ignore keyword can be used in place of the @@ -1431,12 +1430,12 @@ messages. .PP The \fBclient-updates\fR flag tells the DHCP server whether or not to honor the client's intention to do its own update of its A record. -This is only relevant when doing \fIinterim\fR DDNS updates. See the +This is only relevant when doing \fIinterim\fR DNS updates. See the documentation under the heading THE INTERIM DNS UPDATE SCHEME for details. .SH ALLOW AND DENY WITHIN POOL DECLARATIONS .PP -The uses of the allow and deny keyword shown in the previous section +The uses of the allow and deny keywords shown in the previous 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 @@ -1463,7 +1462,7 @@ allocation process is done as described previously in the ADDRESS ALLOCATION section. .PP When declaring permit lists for address allocation pools, the -following syntaxes are recognized following the allow or deny keyword: +following syntaxes are recognized following the allow or deny keywords: .PP \fBknown clients;\fR .PP @@ -1613,7 +1612,7 @@ The \fIddns-hostname\fR statement The \fIname\fR 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 different for each of the +automatically, using an algorithm that varies for each of the different update methods. .RE .PP @@ -1655,7 +1654,7 @@ parameter must be one of \fBad-hoc\fR, \fBinterim\fR or \fBnone\fR. The \fIddns-update-style\fR statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is assigned an IP address, so there is no way -to use different DDNS update styles for different clients. +to use different DNS update styles for different clients. .RE .PP .B The @@ -1666,9 +1665,9 @@ to use different DDNS update styles for different clients. \fBddns-updates \fIflag\fR\fB;\fR .PP The \fIddns-updates\fR parameter controls whether or not the server will -attempt to do a ddns update when a lease is confirmed. Set this to \fIoff\fR +attempt to do a DNS update when a lease is confirmed. Set this to \fIoff\fR if the server should not attempt to do updates within a certain scope. -The \fIddns-updates\fR parameter is on by default. To disable DDNS +The \fIddns-updates\fR parameter is on by default. To disable DNS updates in all scopes, it is preferable to use the \fIddns-update-style\fR statement, setting the style to \fInone\fR. .RE @@ -2069,7 +2068,7 @@ Site-local options in DHCP are those options whose numeric codes are greater than 128. These options are intended for site-specific uses, but are frequently used by vendors of embedded hardware that contains DHCP clients. Because site-specific options are allocated -on an ad-hoc basis, it is quite possible that one vendor's DHCP client +on an ad hoc basis, it is quite possible that one vendor's DHCP client might use the same option code that another vendor's client uses, for different purposes. The \fIsite-option-space\fR option can be used to assign a different set of site-specific options for each such @@ -2102,14 +2101,14 @@ statement .B update-optimization \fIflag\fB;\fR .PP If the \fIupdate-optimization\fR parameter is false for a given client, -the server will attempt a DDNS update for that client each time the +the server will attempt a DNS update for that client each time the client renews its lease, rather than only attempting an update when it appears to be necessary. This will allow the DNS to heal from database inconsistencies more easily, but the cost is that the DHCP -server must do many more DDNS updates. We do not recommend enabling +server must do many more DNS updates. We do not recommend enabling this on large networks with the current DHCP server. This option -only affects the behaviour of the \fIinterim\fR DDNS update scheme, -and has no effect on the \fIad-hoc\fI DDNS update scheme. If this +only affects the behavior of the interim DNS update scheme, +and has no effect on the ad-hoc DNS update scheme. If this parameter is not specified, or is false, the DHCP server will only update when the client information changes, the client gets a different lease, or the client's lease expires. @@ -2122,10 +2121,10 @@ statement .B update-static-leases \fIflag\fB;\fR .PP The \fIupdate-static-leases\fR flag, if enabled, causes the DHCP -server to do DDNS updates for clients even if those clients are being +server to do DNS updates for clients even if those clients are being assigned their IP address using a \fIfixed-address\fR statement - that is, the client is being given a static assignment. This can only -work with the \fIinterim\fR DDNS update scheme. It is not +work with the \fIinterim\fR DNS update scheme. It is not recommended because the DHCP server has no way to tell that the update has been done, and therefore will not delete the record when it is not in use. Also, the server must attempt the update each time the @@ -2170,7 +2169,7 @@ It should be noted here that most DHCP clients completely ignore the host-name option sent by the DHCP server, and there is no way to configure them not to do this. So you generally have a choice of either not having any hostname to client IP address mapping that the -client will recognize, or doing dynamic DNS updates. It is beyond +client will recognize, or doing DNS updates. It is beyond the scope of this document to describe how to make this determination. .RE