|
|
楼主 |
发表于 2005-2-25 17:59:57
|
显示全部楼层
1、default-lease-time 600; #如果客户端不能请求一个指定的租用期，就使用该参数来定义该地址租用的时间长度
max-lease-time 7200; #用来指定租用的最长时间，尽管租用的时间长度是根据客户端的请求决定的。
2、
DYNAMIC DNS UPDATES
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.
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 DNS update method. The DHCP server
must be configured to use one of the two currently-sup-
ported methods, or not to do dns updates. This can be
done with the ddns-update-style configuration parameter.
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 does not work with the
failover protocol because it does not account for the pos-
sibility of two different DHCP servers updating the same
set of DNS records.
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.
The DHCP server determines the client's hostname by first
looking for a ddns-hostname configuration option, and
using that if it is present. If no such option is pre-
sent, 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 DNS update.
The domain name is determined based strictly on the server
configuration, not on what the client sends. First, if
there is a ddns-domainname configuration option, it is
used. Second, if there is a domain-name option config-
ured, that is used. Otherwise, the server will not do the
DNS update.
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. 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 network 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 behav-
ior. This is considered a bug, and will be fixed in a
later release. It may be helpful to enable the one-
lease-per-client 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
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.
THE INTERIM DNS UPDATE SCHEME
The interim DNS update scheme operates mostly according to
several drafts that are being considered by the IETF and
are expected to become standards, but are not yet stan-
dards, and may not be standardized exactly as currently
proposed. These are:
draft-ietf-dhc-ddns-resolution-??.txt
draft-ietf-dhc-fqdn-option-??.txt
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.
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 can be
configured either to honor the client's intentions or
ignore them. This is done with the statement allow
client-updates; or the statement ignore client-updates;.
By default, client updates are allowed.
If the server is configured to allow client updates, then
if the client sends a fully-qualified domain name in the
FQDN option, the server will use that name the client sent
in the FQDN option to update the PTR record. For
example, let us say that the client is a visitor from the
"radish.org" domain, whose hostname is "jschmoe". The
server is for the "example.org" domain. The DHCP client
indicates in the FQDN option that its FQDN is
"jschmoe.radish.org.". It also indicates that it wants
to update its own A record. The DHCP server therefore
does not attempt to set up an A record for the client, but
does set up a PTR record for the IP address that it
assigns the client, pointing at jschmoe.radish.org. Once
the DHCP client has an IP address, it can update its own A
record, assuming that the "radish.org" DNS server will
allow it to do so.
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 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".
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:
When the DHCP server issues a client a new lease, it cre-
ates a text string that is an MD5 hash over the DHCP
client's identification (see draft-ietf-dnsext-dhcid-
rr-??.txt for details). The update adds an A record with
the name the server chose and a TXT record containing the
hashed identifier string (hashid). If this update suc-
ceeds, the server is done.
If the update fails because the A record already exists,
then the DHCP server attempts to add the A record with the
prerequisite that there must be a TXT record in the same
name as the new A record, and that 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 DNS update
for the client until the client chooses a new name.
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 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 interim
update method does not do this. It is our position that
this is not useful, and we are working with the author in
hopes of removing it from the next version of the draft,
or better understanding why it is considered useful.
In addition to these differences, the server also does not
update very 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 is stored on the lease) and does not attempt
to update records that it thinks it has already updated.
This can lead to cases where the DHCP server adds a
record, and then the record is deleted through some other
mechanism, but the server never again updates the DNS
because it thinks the data is already there. In this
case the data can be removed from the lease through opera-
tor intervention, and once this has been done, the DNS
will be updated the next time the client renews.
3、
The use-host-decl-names statement
use-host-decl-names flag;
If the use-host-decl-names parameter is true in a given
scope, then for every host declaration within that
scope, the name provided for the host declaration will
be supplied to the client as its hostname. So, for
example,
group {
use-host-decl-names on;
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
}
}
is equivalent to
host joe {
hardware ethernet 08:00:2b:4c:29:32;
fixed-address joe.fugue.com;
option host-name "joe";
}
An option host-name statement within a host declaration
will override the use of the name in the host declara-
tion.
It should be noted here that most DHCP clients com-
pletely ignore the host-name option sent by the DHCP
server, and there is no way to configure them not to do
this. So you generally have a choice of either not
having any hostname to client IP address mapping that
the client will recognize, or doing DNS updates. It
is beyond the scope of this document to describe how to
make this determination. |
|
IP卡
狗仔卡
发表于 2005-2-24 15:16:34
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2005-2-25 11:17:20