Droms R. The DHCP handbook

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

013 3273 CH10 10/3/02 4:59 PM Page 176

IN THIS CHAPTER

• The Domain Name System

• DHCP and DNS

• Dynamic Updates to the DNS

Database

• Dynamic Updates and DHCP

• How the DHCP Server

Updates the DNS

DHCP–DNS Interaction

The Domain Name System (DNS) is a service in which a

distributed database maintains mappings between domain

names and IP addresses. When you contact

www.dhcp-

handbook.com, your Web browser uses DNS to find the IP

address for that Web site.

DHCP manages the assignment of IP addresses, and the

DNS manages the translation of IP addresses to names and

names to IP addresses. In order for a DHCP client to be

identified by name on a network, it must somehow estab-

lish a name in DNS, or a name must be established for it.

This chapter describes the ways in which DHCP servers

and clients interact with DNS and the difficulties and

potential pitfalls in these interactions.

NOTE

For a more detailed description of DNS, see DNS and Bind by

Cricket Liu and Paul Albitz or Internetworking with TCP/IP:

Principles, Protocols, and Architecture by Douglas Comer.

The Domain Name System

DNS is a database that is stored on a widely distributed

collection of servers throughout the Internet. The names

in the DNS comprise a tree-structured hierarchy of

names—or namespaces—and each DNS server manages its

own part of the namespace. DNS servers at the top of the

hierarchy provide a means for discovering which DNS

servers serve the lower parts of the hierarchy. The adminis-

trator for each DNS server establishes policies about DNS

name assignment and management for the parts of the

namespaces managed by that server.

014 3273 CH11 10/3/02 4:56 PM Page 177

Resource records (RRs) represent DNS data and are associated with names in the DNS

namespace. Many different types of RRs exist, and each is associated with a different

type of information. The DNS specification defines these resource record types

(RRtypes) and acknowledges that additional RRtypes continue to be proposed as the

needs of the community evolve.

The

A (address) resource record maps a domain name to an IP address. The PTR

(pointer) record maps a domain name to another domain name and is usually used

for reverse mapping of IP addresses to domain names. There can be more than one

record attached to a domain name, so a single domain name can map to more than

one IP address. It is also permissible to have more than one

PTR record attached to a

domain name, but that is not common.

The

A record is useful because humans can more easily communicate domain names

than IP addresses. It is much easier to tell someone that he or she should connect to

sherchin.fugue.com than it is to tell the person to connect to 10.0.1.5. This is

particularly true with DHCP, with which it is not always possible for a particular

computer, particularly one that roams, to have a consistent IP address.

A reverse mapping is a mapping from an IP address to a name. The domain

in-addr.arpa

contains a hierarchy of names that represent IP addresses. To convert

from an IP address to a name, you convert each octet in the address into a label

and arrange the labels in most- to least-specific order, from left to right. For

example, the IP address

192.168.11.25

is represented in the

in-addr.arpa

domain as

25.11.168.192.in-addr.arpa

. This is called a reverse mapping because the mapping

should point to a name with an

A record that points back at the IP address being

mapped.

Reverse mappings are useful for pretty much the same reason that

A records are

useful: Computer users generally have an easier time recognizing domain names

than IP addresses. For example, if I want to see what computers are connected to my

computer right now, I will be much more interested to know that, for example,

kwanyin.fugue.com (my wife’s computer) has connected to mine than to know that a

computer whose IP address is 10.0.1.4 has connected. This information is really only

a convenience—it is not guaranteed to be correct—but it is useful.

DHCP and DNS

Traditionally, names on a DNS server are managed by the network administrator. The

network administrator learns that a new machine is to be connected to the network

and either comes up with a name for it or negotiates with the owner of the

computer about what the name should be. Sometimes the owner of the computer

wants a name that has already been taken, but that is an easy problem to resolve

over the telephone.

CHAPTER 11 DHCP–DNS Interaction178

014 3273 CH11 10/3/02 4:56 PM Page 178

Maintaining a sensible mapping of domain names to IP addresses is complicated by

DHCP. When a network administrator’s work of keeping track of IP addresses has

been automated by a DHCP server, the network administrator won’t necessarily

know when a new computer is connected to the network. Network administrations

who use registration systems and only allow registered hosts to connect may not

have this problem, but many networks allow connections by unregistered hosts.

On such networks, it is still useful for computers that connect using DHCP to have

names and reverse mappings published in the DNS, but in such a case, the process

of choosing a name and configuring it in DNS can’t easily be done by the

administrator.

One solution is to populate the DNS server with preassigned domain names for all

the addresses that DHCP manages. Because the names of the clients are not known

when DNS is being configured, the network administrator simply makes up a name

for each IP address being managed by DHCP. The name could be imaginative, or it

could be something mechanical, perhaps based on the IP address. For example, if a

DHCP client on the GSI internetwork is assigned 192.168.11.25, its name in DNS

could have been previously configured to be

net11-host25.

genericstartup

.com

. The

DNS database is preconfigured with an

A record that maps net11-host25 to

192.168.11.25 and a

PTR record that maps

25.11.168.192.in-addr.arpa

net11-

host25.

genericstartup

.com

There are a couple problems with this. First, net11-host25.genericstartup.com is

not much easier to remember than 192.168.11.25. This problem could be solved by

simply choosing names that are really names—for example, the names of streets in

the local city. Second, the client’s name changes whenever its IP address changes. For

a desktop computer in an office, that isn’t a big problem, but for a roaming laptop or

for a customer of a broadband ISP that does dynamic IP address allocation, it isn’t

very useful.

Dynamic Updates to the DNS Database

RFC 2136, “Dynamic Updates in the Domain Name System,” describes a mechanism

that allows DNS client programs to automatically make changes to the DNS data-

base, using DNS protocol messages. This means that the DHCP server or the DHCP

client can directly change the

A and PTR records for a particular IP address, without

the intervention of the network administrator.

The dynamic update mechanism enables clients to supply prerequisites, which are

conditions about data in the DNS zone that must be satisfied before the DNS server

performs an update. A DNS server performing a dynamic update first checks all the

prerequisites in the update request. If all those prerequisites are met—that is, if all

the conditions specified as prerequisites are true—the server performs all the

requested changes to the DNS data. For example, DHCP clients and servers use

prerequisites in DNS update messages to detect duplicate domain names.

Dynamic Updates to the DNS Database 179

014 3273 CH11 10/3/02 4:56 PM Page 179

Dynamic Updates and DHCP

DHCP clients and servers can use dynamic DNS updates to register domain names

and reverse mappings for DHCP clients automatically as they are assigned leases. As

a server assigns an address, the server and possibly the client use DNS update

messages to add or update the

A record for the client’s domain name and the PTR

record for the IP address assigned to the client.

You need to consider some questions when you use dynamic DNS updates from

DHCP clients and servers:

•What computers do you trust to do dynamic updates?

• Does the DHCP client or the server select the client’s name?

• Does the client or the server perform the dynamic update?

•What is the relationship between the duration of a client’s lease on an address

and the time-to-live (TTL) on the DNS entries for that client?

•What happens if two DHCP clients select the same name?

•What happens if a client moves?

•What happens if a client’s name changes?

Together, three protocol specifications describe these problems and how to solve

them. All these specifications are currently IETF drafts, meaning that they haven’t

yet been approved by the IETF. The drafts are titled “A DNS RR for Encoding DHCP

Information (

DHCID RR),” “Resolution of DNS Name Conflicts Among DHCP

Clients,” and “The DHCP Client FQDN Option.” Much of what is explained in this

chapter is described in more detail in these protocol specifications.

DHCP Client DNS Name Selection

Three entities can potentially determine the DHCP client’s published domain name.

We have already talked about one—if the administrator sets up a static IP address-to-

domain name mapping in the DNS and does not allow DNS updates, DNS deter-

mines the DHCP client’s published domain name. With DNS updates, however, it is

possible for either a DHCP server or client to determine the domain name.

There are good reasons to allow the client to choose its name, and there are also

good reasons for the server to choose—or at least control—the client’s choice of

name. Which method is used varies from site to site, depending on the needs and

preferences of the network administrators and users at each site.

CHAPTER 11 DHCP–DNS Interaction180

014 3273 CH11 10/3/02 4:56 PM Page 180

If the DHCP server controls name assignments, it can use the following mechanisms:

• The server can be configured with a name for each client.

• The server can generate a name for each client, based on some algorithm or

heuristic.

• The server can generate a name for the client, based on a name supplied to the

server by the client when it attempts to get an IP address.

One way for the server to determine the client’s domain name is for the network

administrators to set up a client registration system. In such a system, the user or the

administrator chooses a name for the client and enters it into the registration

system. The registration system validates the name (by making sure it is not forbid-

den and that some other client isn’t already using it) and then enters the name into

the DHCP server’s configuration. Whenever the DHCP server assigns the client an IP

address, it updates DNS, using the new IP address and the name assigned to the

client. This means that the DHCP client’s domain name stays the same even when

its IP address changes, but this still allows for central administration of domain

name assignments.

In a more typical configuration, the DHCP server forms the name by appending the

local domain name to the hostname that the DHCP client sends. Many operating

systems now encourage the owner of a computer running that operating system to

configure the computer with a hostname. For example, if my laptop sends the name

sherchin to the DHCP server at work, the DHCP server might form the domain

name

sherchin.nominum.com. This is a very natural way to associate a name with a

particular DHCP client because it means the user doesn’t need to be told what his or

her computer’s domain name is—the user knows the domain name because he or

she typed it in. This system also doesn’t require a special registration application

because the user or system administrator chooses the name when setting up the

computer the first time.

Some operating systems allow the user to specify a fully qualified domain name

(FQDN) such as

sherchin.fugue.com instead of a simple hostname such as sherchin.

The reason for doing this is to allow a DHCP client to roam from one administrative

domain to another while retaining a consistent, globally accessible domain name.

For example, my laptop can always have an

A record pointing from

sherchin.fugue.com to its current IP address. This works whether I am at

Nominum’s corporate headquarters, where the company’s domain name is

nominum.com, or whether I am at home in Chicago, connected through my DSL

provider. For this to work, the DHCP server can’t be involved in determining the

hostname—it has to trust the name supplied by the client.

Dynamic Updates and DHCP 181

014 3273 CH11 10/3/02 4:56 PM Page 181

Responsibility for Performing DNS Updates

Which entity performs the DNS update? Because the DHCP server controls IP address

allocation, it is natural for it to update the

PTR record associated with each IP address

it allocates. The real question is whether the client or the server should update the

record.

The main issue to consider when deciding whether clients or servers should update

DNS is a key-management issue. A DHCP client or server needs to have credentials in

order to update DNS. These credentials need to be unique to a particular updater—if

they are not, then it’s impossible to restrict the set of records that any given updater

is allowed to change.

Typically there are fewer DHCP servers than DHCP clients, so a site that has the

DHCP server do the DNS updates needs to keep track of fewer keys than a site that

allows DHCP clients to do the updates. At the time of this writing, the authors are

not aware of any large sites where DHCP clients are allowed to update DNS directly.

However, at smaller sites, where trust issues can be handled on the basis of personal

relationships between network administrators and users, it is practical to allow DHCP

clients to update DNS on a case-by-case basis.

If the DHCP client is to update its own

A record, it chooses the name for that A

record. After it has received an IP address from the DHCP server, it sends the update

to the DNS server that manages the namespace containing that name. However, the

DHCP server still has to update the

PTR record. The DHCP server and the DNS server

may be in different administrative domains. The Internet Draft titled “The DHCP

Client FQDN Option” defines a DHCP option that the DHCP client and server use to

communicate about the FQDN that the client wants, who should do the update, and

what the DHCP server should store in the

PTR record.

When a client is configured to do its own update, it sends an FQDN option in each

message it sends to the DHCP server. The FQDN option sent to the server contains

the fully qualified domain name the client has chosen. The option also carries a

flag that indicates whether the client wants the server to do the update of the

record; if the flag is not set, the client asserts that it will be doing the A record

update.

When a DHCP server receives an FQDN option in which the update flag indicates

that the client will update its own

A record, the DHCP server can choose to honor

the client’s request, or it can follow its own local policy and assign the client a name

of its own choosing. This can be independent of the site’s policy on allowing clients

to update DNS. If the client indicates that it can update the DNS, the server can just

assume that the client knows what it’s doing.

The DHCP server sends an FQDN option in its response to the client. If the server

chose not to honor the client’s intention to update its own

A record, it sends an

FQDN option telling the client what name the server assigned it, and it also sets a

CHAPTER 11 DHCP–DNS Interaction182

014 3273 CH11 10/3/02 4:56 PM Page 182

flag in the option that tells the client not to update its own A record. The client is, of

course, free to ignore this flag, but its reverse mapping points to the name of the

server assigned it, not to the name it chooses. If the server chooses to honor the

client’s intention, it sends to the client an FQDN option that contains the same

domain name the client sent as well as a flag that tells the client that the server is

cooperating with it.

The FQDN option is intended to be the standard way that a DHCP client tells the

DHCP server the name that it wants to use, whether the client or server updates the

DNS. If a client only has a hostname, rather than an FQDN, it should send that host-

name to the DHCP server, using the FQDN option. Older DHCP clients use the host-

name option to tell the DHCP server their names.

NOTE

Some versions of the Microsoft DHCP client that implements the FQDN option attempt to

update their own A records by using GSS-TSIG authentication, a special variant of transaction

signatures (TSIG) that uses the Kerberos protocol to manage keys. They do this by default,

even if they don’t share credentials with the DNS server for the namespace that would

contain their A records. This is mostly harmless because the updates can’t succeed, but it can

generate a lot of noise in the DNS server’s log. The easy workaround to this problem is to

configure the DHCP server not to cooperate with clients that want to update DNS. When the

Microsoft client receives the information from the server that the server doesn’t want it to do

the DNS update, it doesn’t attempt an update. This creates a problem at sites that would like

to support client updates on a case-by-case basis, though, because updates are disabled for all

clients—not just for Microsoft clients that haven’t been configured correctly. The ISC DHCP

server works around this problem by noticing that the FQDN option from these Microsoft

clients contains just a hostname, not a FQDN, and tells the client not to do the update in this

case.

DHCP Client Name Collision

If the users of DHCP clients are permitted by local policy to select their own host-

names, one problem that can arise is that two users may choose the same name for

their computers. Currently no provision exists in the DHCP protocol to resolve such

conflicts, although (as discussed in Chapter 21, “DHCP Clients”) the Microsoft

DHCP client tries to use the Windows Internet Name Service (WINS) protocol to

resolve naming conflicts.

The Internet Draft titled “Resolution of DNS Name Conflicts Among DHCP Clients”

refers to the situation in which two DHCP clients have the same name as a name

collision, or a name conflict, and it provides a method that clients and servers can

use to detect this. When a DHCP server or client updates an

A record, it attaches a

DHCID record to the same name to which it is attaching the A record. The DHCID

Dynamic Updates and DHCP 183

014 3273 CH11 10/3/02 4:56 PM Page 183

record contains data that identifies the client: the value of the DHCP

client-

identifier

option that the client sent in its DHCP request or, if it did not send a

client identifier, its link-layer address. Because the

DHCID record is publicly accessible

in DNS, the client’s identification information is masked by hashing it, along with

the client’s FQDN, using the MD5 algorithm. This produces an identifier that does

not reveal any information about the client but can be reliably regenerated from the

client’s identification information.

Whether the A record update is performed by the DHCP client or by the server, the

updater can use the prerequisites section of the update query to ensure that no other

client is currently using the name in question. The updater first sends an update

request for the

A and DHCID records to the DNS server. The update has a prerequisite

that prevents the update from being done if the name exists in DNS.

If the name being added already exists, the updater attempts to delete all

A records

currently attached to the name and add the new one. This time the update has a

prerequisite that if the name exists and has attached to it a

DHCID record that does

not match the

DHCID record that the updater generated based on the client’s identifi-

cation information, the update will fail. If the prerequisite test in this second request

succeeds, the DNS server updates the

A record for the client to reflect the client’s new

IP address and leaves the

DHCID record in place.

NOTE

This second DNS update can fail for one of two reasons. If a different client’s DHCID record

exists, then some other client is using the domain name in question. If there is no DHCID

record, then the name was entered by something or someone other than a DHCP server—

probably the network administrator. In either of these cases, the new client doesn’t get the

name it asked for. DHCP does not provide a mechanism for the client to choose a new name;

if the client can’t have the name it wants, the DHCP server must either assign it a different

name or not give it a name at all.

Lease Expiration

When a lease expires, or is released, the updaters of the A and PTR records try to

remove these records from the DNS database. This prevents the DNS database from

becoming overloaded with stale names, and it frees disused names for reuse. It also

allows a client with two network interfaces to associate its name with the interface it

is using at any given time because the client identifier is usually associated with an

interface and the updater is using the client identifier to determine the owner of the

name.

DHCP servers and clients keep records of names they have added so that they can

remove them later. However, the mere fact that a DHCP agent remembers adding a

CHAPTER 11 DHCP–DNS Interaction184

014 3273 CH11 10/3/02 4:56 PM Page 184

name does not mean that the records currently associated with that name in DNS

are still the records that the agent added. A name to which an

A record has been

assigned by a DHCP agent should have a

DHCID record as well, and the A record asso-

ciated with the name should be the same one that the DHCP agent added. So when

a DHCP agent removes an

A record and the name associated with it, it places a

prerequisite on the DNS update that it sends. The prerequisite is that the

A record

that the agent added must still be attached to the name, and the

DHCID record that is

attached to the name must match the

DHCID record the server used to add the name.

If both of these conditions are true, the DNS server removes the name.

Because the DHCP server controls the IP address, the server is responsible for updat-

ing and deleting the reverse mapping that corresponds to the address. To delete

the reverse mapping, the DHCP server simply sends an update that deletes the

in-addr.arpa

name.

If the DHCP server adds the A RR, it is also responsible for deleting the A and DHCID

RRs when the client’s lease expires. If the DHCP client adds its own A record, it is

responsible for removing the records before its DHCP lease expires (that is, before it

releases its lease).

NOTE

Removal of A records by clients is another of the protocol issues that touches on sites’ admin-

istrative policies. If sites decide to allow DNS updates from their DHCP clients, their clients

should be reliably able to maintain the DNS information that they add, or additional manual

administrative effort may be required in order to police their DNS updates. Clients may be

shut down and removed from the network without warning as individuals move about and as

organizations replace hardware. This means that it is unlikely that the client will remove its A

record beforehand. When the client gets a new lease, it corrects this problem, but during the

period that it is not connected to the network, its A record is incorrect.

Client Relocation

Many organizations that use dynamic DNS also use multiple DHCP servers. Suppose

a site has two buildings and uses a separate DHCP server in each building. What

happens when a laptop is shut down at a user’s desk in Building A and is restarted

on the network in a conference room in Building B?

The DHCP server in Building A (Server A) doesn’t know that this happened. It knows

only that the client has an active lease with it. When the DHCP server in Building B

(Server B) leases an IP address to the client, it expects to add a

PTR record that corre-

sponds to the IP address and an

A record that corresponds to the client’s domain

name. However, Server A already had an

A record (one that contains the IP address

that Server A leased to the client). The client’s

A record should represent the most

Dynamic Updates and DHCP 185

014 3273 CH11 10/3/02 4:56 PM Page 185