Droms R. The DHCP handbook

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

There are perhaps three types of risks that you might be taking in accepting a client-

supplied domain name and installing it in that client’s

PTR record:

• The client might use this as an attack on the name server.

• The client might use the presence of the name in DNS as a way to bypass some

DNS-based security mechanism.

• The client might use the

PTR record to misrepresent its domain name while

doing something nefarious.

It is theoretically possible that if your DNS server has a bug, a DNS update of a

PTR

record with a client-supplied name might compromise the DNS server. Although this

is not a threat to be completely discounted, it is certainly a difficult attack to mount.

Attacks of this sort generally involve some sort of buffer overflow. But the client is

sending the DHCP server a domain name, and the DHCP server is going to validate

it. So an attacker has to construct a domain name that is malformed in such a way

that it will compromise the DNS server but will get past the DHCP server. This seems

unlikely; in reality, the DHCP server will probably be unable to process such a

domain name. It is more likely that an attack on the DHCP server itself would

succeed than that an attack through the DHCP server to the DNS server would

succeed.

The second possibility is that the client could insert a name into its

PTR record and

then use that

PTR record to bypass some sort of authentication mechanism. But this

is a very unlikely attack as well. The problem with this attack is that sites that use

domain-name–based security mechanisms don’t trust the

PTR record—they check the

A record as well. But if the client can update its A record, it is not lying about the

name it provided to the DHCP server, so there is no problem.

The third possibility is that the client might put some bogus name in its

PTR record

before doing something improper. If the improper behavior were detected, the blame

for it might be deflected on the rightful owner of the domain name. This is probably

the most likely of the three threats described here. It seems unlikely that it would

present a problem, however, because any sensible system administrator is going to

check the

A record as well as the PTR record when trying to figure out where an

attack originated. However, there’s no guarantee that this will happen—it is certainly

possible that people will jump to the wrong conclusions and bad things will happen

as a result.

Client-Supplied Hostnames

Microsoft Windows clients and Apple Macintosh clients always provide their own

hostnames. Microsoft clients are generally not willing to accept hostnames provided

by the DHCP server. So in practice, if you want users of DHCP clients configured by

CHAPTER 23 Updating DNS with DHCP396

027 3273 CH23 10/3/02 5:00 PM Page 396

your server to be able to communicate with each other conveniently, you must

configure your DHCP server to do domain name updates using the name supplied by

the client.

No Supplied Hostname

Sometimes the client doesn’t supply a hostname. In most cases, this is because the

client is some kind of device that doesn’t know its name—for example, a printer.

Also, DHCP clients on some operating systems, such as Linux, do not require the

user to set a hostname, and if no hostname is set, they do not send a hostname.

In the case of a printer, you need to configure the printer with a hostname so that

users can find the printer. In the case of Linux clients, if the user wants his or her

client to have a name, he or she will give it one. However, users who are not very

knowledgeable might never need to name their clients but might want to be able to

use network services that do domain name checking. For such clients, you might

want to configure your DHCP server to make up a name when the client doesn’t

supply one.

Name Clashes

It is quite possible for two users of two different computers to give their computers

the same name. The DHCP server checks to see if the name the client provides is in

use before it installs the name in the DNS server. If the name exists and belongs to

some other client or was not installed by a DHCP server, the client requesting the

name doesn’t get it. If the DHCP server can, it informs the client that it cannot have

the name it wants. The mechanism whereby this is done is described in Chapter 11,

in the section “DHCP Client Name Collision.”

Dual Booting

In some cases, a computer with one name may run two different operating systems,

with two different DHCP clients, and the DHCP clients may provide different identi-

fication, but use the same hostname. (Client identifiers are explained in Chapter 16,

“Client Identification and Fixed-Address Allocation”) In this case, the two DHCP

clients get different IP addresses, and the name is associated with only one of those

IP addresses. To resolve this problem, you should make sure both DHCP clients send

the same identification information or that they send different hostnames.

DNS Update Security

In order to protect your DNS server from unauthorized updates while permitting the

DHCP server and perhaps DHCP clients to do updates, you must establish a security

policy on the DNS server and configure the DHCP server and clients to use whatever

DNS Update Security 397

027 3273 CH23 10/3/02 5:00 PM Page 397

authentication mechanism that policy requires. There are two basic authentication

mechanisms you can use: IP address–based authentication and cryptographic authen-

tication.

It is very easy to make cryptographic authentication work, and in our experience it is

quite difficult to get IP address–based authentication to work, so we don’t recom-

mend that you waste any time on IP address–based authentication; not only is it less

secure, but it’s actually more difficult to set up.

There are four different ways of using cryptographic authentication in DHCP

updates:

• TSIG-based shared secret

• SIG(0)-based public key

• TKEY shared secret

• GSS-TSIG

The simplest of these is TSIG. With TSIG, the client that does the update is config-

ured with a private key, and the DNS server is configured with that same key. The

update client signs its update with the key, and the DNS server checks the signature

to verify that the update client has the key.

Although TSIG is very simple, it has the classic key distribution problem: You have

to arrange to install the private key on the DNS server and on every update client. If

the update client is a single DHCP server or a pair of DHCP servers, this is very easy.

It is much more difficult to install a different TSIG key on every DHCP client. Also,

when the key changes, you have to update every client and server that is using the

key.

SIG(0) provides a solution to the key distribution problem by using DNS to store the

public part of a key. The update client keeps the private part of the key. The update

client needs to register the public key in DNS to establish trust, but this is not too

difficult because the key is not secret. Therefore, SIG(0) is a much better choice than

TSIG for DHCP clients.

Unfortunately, SIG(0) suffers from the fact that public key cryptography is expensive.

The TKEY protocol provides a somewhat complicated solution to this problem: A

SIG(0) key is used to establish a shared secret key, and the shared secret key is used

to sign updates as with TSIG. The TKEY key is not permanent; if the DNS server

forgets the key, the client has to reestablish it, which it can do with the SIG(0) key.

The Microsoft DHCP server, client, and DNS servers all support a keying system

called GSS-TSIG. GSS-TSIG uses Kerberos to distribute private keys, which solves the

key management problem. Unfortunately, the protocol is complicated, and different

CHAPTER 23 Updating DNS with DHCP398

027 3273 CH23 10/3/02 5:00 PM Page 398

versions of Windows implement it differently, so there aren’t many non-Microsoft

DHCP or DNS products that work with GSS-TSIG. If you are running a Microsoft-

only shop, GSS-TSIG is your only choice, but if you are not, it might not be possible

for you to use it.

It is beyond the scope of this chapter to describe in detail how all these keying

systems work. The ISC DHCP server supports only TSIG updates, so we mostly talk

about TSIG here.

NOTE

One important feature that all these four mechanisms share is that they use the time that the

update was generated to detect a replay attack. In order for this to work, the update client

and the DNS server have to agree on what time it is. If their clocks differ by more than about

five minutes, the update fails. So you must synchronize the clocks on the update client and

DNS server, using NTP or some similar mechanism.

Generating a TSIG Key

To generate a TSIG key with ISC BIND version 9, you use the dnssec-keygen

command, as shown in Example 23.1.

Example 23.1

dnssec-keygen -a HMAC-MD5 -b 256 -n USER mykey.example.com

This generates two output files, both of which contain a key whose name is

mykey.example.com. The name is very important: It has to be the same on the DNS

server and the update client. The TSIG key’s name doesn’t have to be an FQDN, and

it does not appear anywhere in the DNS server (in fact, it can’t because it’s a secret).

Unfortunately,

dnssec-keygen does not produce the key in the format that the DNS

and DHCP servers want, so you have to extract the secret and put it into the right

format. The output files are named

kmykey.example.com.fingerprint.key and

kmykey.example.com.fingerprint.private. fingerprint is the key’s fingerprint,

which is two numbers, separated by a period. You don’t need to use the fingerprint,

but you see it in the filename that

dnssec-keygen uses. The contents of the key file

look something like Example 23.2.

Example 23.2

mykey.example.com IN KEY 0 2 157 \

rxOEG1ZXiIRv1vXSvaHFpyxkFq1GUtn4P3uxovceRfQ=

DNS Update Security 399

027 3273 CH23 10/3/02 5:00 PM Page 399

The part that looks like a bunch of garbled text followed by an = is the secret key

that the two servers must share. To make it into a TSIG key declaration that the ISC

DHCP server and ISC BIND can understand, rewrite it as shown in Example 23.3.

Example 23.3

key mykey.example.com. {

algorithm HMAC-MD5.SIG-ALG.REG.INT;

secret rxOEG1ZXiIRv1vXSvaHFpyxkFq1GUtn4P3uxovceRfQ=;

};

This key declaration can be shared between the DNS server and the DHCP server if

they are running on the same computer—just put it in a file that both servers can

reach and include that file in both servers’ configuration files.

NOTE

It is very important that the file containing the secret keys for DNS update be readable only to

root. If it can be read by other users, those users can learn the secret, and they can use the

key to do DNS updates.

Configuring the Servers

You need to configure at least two servers: the DHCP server and the DNS server. You

might need to configure more than one DNS server; if the

A record and the PTR

record are not on the same DNS server, you have to configure both DNS servers to

accept updates. If your DHCP server will update

A records in more than one domain

and those domains are served by separate DNS servers, you have to configure each

DNS server to accept updates from the DHCP server. If you will be doing DNS

updates from a DHCP client, you also have to configure the DHCP client.

Configuring the DHCP Server to Do Updates

In order for a DHCP server (or a DHCP client, for that matter) to update DNS, it

needs to know what DNS server to contact, and it needs to know how to identify

itself to the DNS server.

NOTE

In some cases, when both DHCP and DNS are being managed by the same software product,

it might not be necessary to explicitly configure the DHCP server or the DNS server with DNS

update information. However, in the case of the ISC DHCP and DNS servers, you must config-

ure them explicitly.

CHAPTER 23 Updating DNS with DHCP400

027 3273 CH23 10/3/02 5:00 PM Page 400

DNS is a hierarchy of DNS zones. A zone is a portion of the hierarchy that is

managed as a unit; a single DNS server is the master for any given zone, and each

zone has a start of authority (

SOA) record that describes it.

Every domain name is contained in a zone. It is not possible to tell which zone

contains a given domain name by looking at the domain name—for example, the

name

oxytocin.sci.example.com might be in the zone sci.example.com or the zone

example.com, or it might be the top of the zone oxytocin.sci.example.com.

This is an important problem because in order to update a domain name, the DHCP

server must know which zone it’s in, and it must know the IP address of the master

domain name server for that zone. There are two ways the DHCP server can get this

information: You can configure it, or the DHCP server can look it up in DNS.

The ISC DHCP server can do either—if you do not configure it with zone informa-

tion, it looks up that information in DNS. This is a little bit of extra work, but the

DHCP server caches the zone information, so there isn’t much performance impact.

The main reason to use zone declarations is that you can only specify the DNS

update key in a zone declaration.

Example 23.4 shows how to configure the DHCP server with zone information and

update keys for a forward zone and a reverse zone. In this example, we assume that

the key we generated earlier is stored in a file called

/etc/update-keys.

Example 23.4

include “/etc/update-keys”;

zone “sci.example.com” {

master 10.0.100.17;

key mykey.example.com.;

}

zone “0.0.10.in-addr.arpa” {

master 10.0.100.17;

key mykey.example.com.;

}

You must be certain that the zone declaration matches an actual zone in DNS. A

zone in DNS is a domain name that has an SOA record. So if the name specified in

the zone is not a name that has an SOA record, the zone declaration does not work,

and the update fails, probably with a very cryptic error message.

You can check to see if the name you are using is actually a zone by using the

dig

command, as shown in Example 23.5.

Configuring the Servers 401

027 3273 CH23 10/3/02 5:00 PM Page 401

Example 23.5

dechen% dig sci.example.com. soa

...

;; ANSWER SECTION:

sci.example.com. 3600 IN SOA ns.sci.example.com. \

postmaster.example.com. \

1999032501 3600 1800 \

604800 3600

...

dechen%

If you don’t see an SOA record in the answer section, the name you have chosen is

not a zone, and if you use it in a zone declaration, updates fail.

Configuring the DNS Server to Allow Updates

You must configure the DNS server to allow updates from the DHCP server. This

involves configuring the DNS server with the same key you used with the DHCP

server and configuring the DNS server to allow updates using that key.

Example 23.6 shows an example of a DNS server configuration that corresponds

to the DHCP server configuration shown in Example 23.4.

Example 23.6

include “/etc/update-keys”;

zone “sci.example.org.” {

type master;

file “sci.db”;

allow-update { key mykey.example.com; };

};

zone “0.0.10.in-addr.arpa.” {

type master;

file “10.0.0.db”;

allow-update { key mykey.example.com; };

};

Completing the DHCP Server Configuration

The ISC DHCP server does not do DNS updates by default. You have to enable them.

You can do this with the

ddns-update-style statement. The ISC DHCP server

supports three styles:

none, ad-hoc and interim. The ad-hoc style is not recom-

mended, so if you want DNS updates, use the

interim style, as shown in

Example 23.7.

CHAPTER 23 Updating DNS with DHCP402

027 3273 CH23 10/3/02 5:00 PM Page 402

Example 23.7

ddns-update-style interim;

By default, the ISC DHCP server allows clients to do their own DNS updates. To

make the DHCP server do updates on behalf of the client, even if the client wants to

do its own update, you use the

deny client-updates; statement.

To specify the domain name in which the DHCP server should install A records for

clients, you use the

ddns-domainname statement, as shown in Example 23.8.

Example 23.8

ddns-domainname “sci.example.com”;

To specify a hostname for a particular client, you put a ddns-hostname statement in

the

host declaration for that client as shown in Example 23.9.

Example 23.9

host foo {

hardware ethernet 10:02:22:3c:d2:aa;

ddns-hostname “foo”;

}

To generate a unique hostname for all clients, you can write an expression that

derives the hostname. For example, to generate the hostname based on the client’s

IP address, you could write a statement like the one in Example 23.10.

Example 23.10

ddns-hostname =

concat (“dhcp-”,

binary-to-ascii (10, 8, “-”, leased-address));

Finally, to generate a unique hostname for clients that don’t specify their hostname

but use the client’s hostname if the client specifies it, you could write a statement

like the one in Example 23.11.

Example 23.11

ddns-hostname =

pick (option fqdn.hostname, option host-name,

concat (“dhcp-”,

binary-to-ascii (10, 8, “-”, leased-address)));

Configuring the Servers 403

027 3273 CH23 10/3/02 5:00 PM Page 403

The ISC DHCP server has other flags that control DNS updates, but they are gener-

ally fairly obscure; they are listed in Appendix B, “ISC DHCP Server Configuration

File Reference.”

Configuring the DHCP Client to Do Updates

To configure a DHCP client to update its own A record, you must do the following:

• Configure the client with its FQDN

• Configure the client to cooperate with the DHCP server

• Configure the client with a key so that it can update its A record

• Configure the client to contact the DNS server

• Configure the DNS server to accept the update

In order for a DHCP client to cooperate with a DHCP server in updating the DNS

server, it must use the

fqdn option, which is described in Chapter 11. At the time of

this writing, only two DHCP clients support the

fqdn option: the ISC DHCP client

and the Microsoft DHCP client.

It is possible to configure any DHCP client that supports scripting to update its

record: Simply configure the client to call a script that updates the FQDN. However,

a client that cannot send an

fqdn option cannot get the DHCP server to update its

PTR record. The following sections show an example of how to update a client’s A

record from a script.

Configuring the ISC DHCP Client to Update Its A Record

To configure the ISC DHCP client to update its own

A record, you simply configure it

to send the server an

fqdn option that contains a FQDN and indicates that the client

will be doing the update. The ISC DHCP client then assumes that you actually want

it to do the update. You can configure this as shown in Example 23.12.

Example 23.12

send fqdn.fqdn “dechen.sci.example.com.”;

send fqdn.encoded on;

send fqdn.server-update false;

Note that the FQDN has a period at the end. This is absolutely required; without it,

the domain name is not fully qualified, and the DHCP server appends the local

domain to it. The client currently requires that you set the

fqdn.encoded option,

although this might be set automatically in the future. The

fqdn.server-update

option tells the server whether the client expects the server to do the update; by

setting it to

false, you indicate that the client intends to do the update itself.

CHAPTER 23 Updating DNS with DHCP404

027 3273 CH23 10/3/02 5:00 PM Page 404

You must also configure the client with a key declaration and a zone declaration, as

with the DHCP server. The DHCP client itself only supports TSIG keys, although you

can do a SIG(0) update from an external script if you prefer. The DHCP client key

configuration is exactly the same as the DHCP server configuration, although you

should not use the same key for the client that you use for the server. The code in

Example 23.13 shows a key declaration and a zone declaration for a DHCP client

that will be updating its name in the

sci.example.com zone.

Example 23.13

key dechen.keys.example.com. {

algorithm HMAC-MD5.SIG-ALG.REG.INT;

secret UAEydKm+sEkbG8CpPS4k3oPBW6Az6LybYKdBYHkl6u0=;

};

zone sci.example.com {

key dechen.keys.example.com.;

primary 10.0.100.17;

}

Configuring the DNS Server for Client Updates

Finally, you must configure the DNS server to allow the client to update its own

name. In the DHCP server example, we gave the DHCP server permission to update

the entire forward and reverse zone. You probably do not want to give any client

access to the entire zone in which its name resides. BIND version 9 provides an

update-policy directive that allows finer-grained control. The configuration code in

Example 23.14 gives update clients that have the key

dechen.keys.example.com

permission to update records on the name dechen.sci.example.com.

Example 23.14

include “/etc/update-keys”;

key dechen.keys.example.com. {

algorithm HMAC-MD5.SIG-ALG.REG.INT;

secret UAEydKm+sEkbG8CpPS4k3oPBW6Az6LybYKdBYHkl6u0=;

};

zone “sci.example.com” {

type master;

file “sci.db”;

update-policy {

grant mykey.example.com subdomain sci.example.com;

Configuring the Servers 405

027 3273 CH23 10/3/02 5:00 PM Page 405