|
Help
|
NameSurfer 7.6.4.1 |
|||||||||||||||||||||||||||||||||
Dynamic DNS updates
The ISC 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.
There are three parameters, which may vary according to the scope, that
control how Dynamic DNS (DDNS) updates will be done. The first two are
the ddns-domainname and ddns-rev-domain-name
statements. The ddns-domainname parameter sets the domain name
that will be appended to the client's hostname to form a fully-qualified
domain-name (FQDN). For example, if the client's hostname is "hutson" and
the ddns-domainname option is set to "sneedville.edu", then
the client's FQDN will be "hutson.sneedville.edu". Without this option,
dynamic DNS will not work.
The ddns-rev-domainname 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, ddns-hostname can be used to specify the
hostname that will be used as the client's hostname. If no
ddns-hostname is specified in scope, the server will use a
host-name option sent by the client. If the client did not send a host-name
option, but 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. It is suggested that your clients should specify this
option. Hosts using the ISC DHCP client can do this as described below. The
configuration file, /etc/dhclient.conf should look as follows:
interface "ed0" {
send host-name <hostname>
}
How DNS updates work
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 network server. For example, if you have a fileserver calledfs.sneedville.edu, and the client claims its
hostname is fs, no DNS update will be performed 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 that clients only have a single network interface. A client with two network interfaces will see unpredictable behavior. 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 DHCPREQUEST,
then the server sends a DHCPACK. In the current version of the
server, the server will perform a DNS update before it has received the
DHCPREQUEST, and after 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 it next 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.
Making dynamic updates work with FusionLayer NameSurfer
In order to make dynamic updates to work properly with FusionLayer NameSurfer, the FusionLayer NameSurfer server should be the primary server for both forward and reverse zones.For ISC DHCP server version 3 (the one which is included in the FusionLayer NameSurfer package) it is important to have a NS record in the dynamic zone which points to the actual primary server (the server where FusionLayer NameSurfer is running). Otherwise the DHCP server cannot determine the server to which it should send DNS dynamic updates to. The ISC DHCP server provided with FusionLayer NameSurfer is modified to perform dynamic updates securely using DNS transaction signatures (TSIGs).
Microsoft Windows 2000 DHCP server is capable of making dynamic DNS updates. However, this server cannot be configured to perform DNS updates securely using statically configured transaction signatures. In order to make it work with FusionLayer NameSurfer, insecure dynamic updates should be enabled in FusionLayer NameSurfer server configuration files and DHCP server IP address has to be specified in the server.conf file. A Microsoft DHCP server determines DNS server to update using the SOA record and the Master NS field of zones. The field should specify the actual primary name server name, and this name should not be an alias for the actual host name.