dns.pdf

Integrating DNS, DHCP, and WINS

By Darin Davis, International Network Services

Introduction

Networking professionals today confront a complex combination of protocols and tools, both commercial

and home-grown, for managing IP networks. This paper answers the questions:

•

How do these protocols integrate to automate the configuration of network devices?

•

How are commercial tools currently addressing integration?

What protocols remain to be developed to complete this integration?

This paper describes at a high level how the various protocols work together. For the sake of clarity, this

paper summarizes and omits a vast amount of protocol detail.

Protocols

BOOTP and DHCP

Traditional IP networks once relied upon manual configuration of hostsÆ IP addresses and names. As

networks grew in size, so did the administrative burden of manually (re)configuring the IP addresses of

large numbers of network stations. This situation prompted the development of automatic configuration

protocols such as BOOTP i and DHCP ii .

BOOTP (Bootstrap Protocol) is a simple client/server protocol by which a client station can obtain its IP

address and little other configuration information from a BOOTP server. BOOTP can be described as

Ãstatically automaticÄ because the network administrator must manually enter the client stationÆs

hardware and IP address into a configuration file on the server. The benefit of BOOTP is that the

administrator need not physically touch the client station to (re)configure it.

DHCP (Dynamic Host Configuration Protocol) provides considerably greater sophistication than

BOOTP. DHCP can be described as Ãdynamically automaticÄ because the administrator need not specify

a particular IP address for a particular hardware address. All a DHCP server needs to know is the range

of addresses it may hand out. The DHCP server takes care of assigning IP addresses to client stations

rather than the administrator. Furthermore, a client station can use DHCP to obtain more than 70

different pieces of configuration information such as default gateway, network mask, etc.

Integrating DNS, DHCP, and WINS

NetworkCare Whitepaper

•

DNS

Early IP networks (typically UNIX-based) used a text file called hosts to translate between IP addresses

and human-friendly names. Each station needed a copy of the hosts file. As the number of stations grew,

the burden of updating each stationÆs hosts file grew as well. The advent of DNS iii (Domain Name

System) enabled stations to translate between addresses and names by querying a server. This simplified

the administratorÆs task enormously as the address-to-name mappings were maintained in a single

location (the server) rather than every station.DNS also introduced greater flexibility in naming network

stations. The hosts file method provides a flat namespace, i.e., each station needed a name that was

unique network-wide. DNS, however, provides a hierarchical namespace that permits two different

stations to have the same name as long as the stations reside in different branches of the hierarchy.

In a medium to large network, typically a number of DNS servers are set up: one primary server and

many secondary servers. The address-to-name mappings are still maintained in a single location (the

primary server), and secondary servers obtain their mappings from the primary server. Secondary servers

query the primary server periodically to determine if any changes to the database have occurred. If there

has been a change, the secondary server requests a zone transfer (AXFR) which copies the entire

database from the primary server to the secondary server. A client station may query the primary or any

secondary server and receive exactly the same information.

Two efficiency enhancements, one for time and the other for space, have recently been made to DNS.

The time efficiency enhancement is the NOTIFY iv mechanism. Rather than waiting for a secondary

server to query the primary server, the primary server can notify each secondary server that a change has

occurred. The secondary server can then request a zone transfer, thereby obtaining an updated database

sooner than the normal query interval. The space efficiency enhancement is the incremental zone

transfer v (IXFR) mechanism. With IXFR, a secondary server can obtain only that portion of the database

that has changed rather than re-transferring the entire database which may waste considerable network

capacity.

NetBIOS

NetBIOS (Network Basic Input/Output System), developed by IBM in the early 1980s for small

networks, is variously described as a protocol or as a software interface and naming convention.

NetBIOS primarily names network stations and services using a flat network model similar to the hosts

file method. NetBEUI (NetBIOS Extended User Interface) is an implementation of NetBIOS which

provides capabilities somewhat similar to ISO Transport Layer services. Both IBM and Microsoft use

NetBIOS in their PC networking products.

NetBIOS/NetBEUI does not implement the ISO Network Layer, and thus is not suitable for routed

networks such as todayÆs IP networks. NetBT vi (NetBIOS over IP) was developed to expand the arena in

which NetBIOS programs can be used. A key component of NetBT is the NBNS (NetBIOS Name

Server) or WINS (Windows Internet Naming Service) server in the Microsoft world. When a NetBIOS

client initializes, it registers its name with the NBNS. When a NetBIOS client needs to resolve a name, it

queries the NBNS.

Integrating DNS, DHCP, and WINS

NetworkCare Whitepaper

•

How the Protocols Integrate

DNS and DHCP

The first integration issue is enabling DNS to provide names and addresses of DHCP clients. Most

DHCP clients are end-user PCs which no other user will access by hostname. However, a growing

number of network server applications perform a reverse name lookup (query for the name given the IP

address) before allowing a client to use the application. The intent of this reverse name lookup is to

enforce a minimal amount of security: the client must at least be known to the DNS server.

Solution 1: Static Names

A simple but very limited solution is to pre-define names for DHCP clients. The network administrator

knows the ranges of addresses that will be used for DHCP and can simply encode in DNS a name for

every address in the range. For example:

dhcp1

10.23.4.1

dhcp2

10.23.4.2

dhcp3

10.23.4.3

This solution has several drawbacks. If the ranges are large, the administrator will have to do a lot of

typing to specify a name for every address. Also, users of the client stations may want to specify a

customized name for their PC. In addition, if only a small percentage of the network users operate their

PCs at the same time, the DNS database will be unnecessarily large. Another drawback is a sophisticated

user (or cracker) could ÃstealÄ an unused address and access network applications surreptitiously.

Because the IP address has a name statically defined in DNS, a network application that performs a

reverse lookup will erroneously conclude that the address has been officially assigned to the requesting

client.

Solution 2: Dynamic DNS

Rather than statically pre-defining names for DHCP-assigned addresses, DNS has been enhanced with a

new mechanism called the UPDATE vii operation, also known as DDNS (Dynamic DNS). With DDNS,

database entries can be added, modified, and removed on an ad hoc basis. For example, when a DHCP

client receives an IP address, that information can be added to DNS immediately, thus the DNS database

is accurate, current, and does not contain unnecessary or misleading information.

By itself, however, the UPDATE operation is not sufficient to integrate DHCP with DNS. There are two

additional requirements. First, there must be a mechanism to control who can perform the UPDATE

operation. Uncontrolled modification of DNS would wreak havoc on a network, particularly at the hands

of a malicious user. As a result, security extensions to DNS (called DNSSEC viii and SDNSDU i x ) have

been defined. DNSSEC provides additional data structures (the SIG, KEY, and NXT resource records)

and protocol operations. These additions can be used to authenticate both the queries to and responses

from a DNS server x . SDNSDU specifies how DNSSEC can be used in conjunction with dynamic

updates.

These security extensions are rather complex, however. So, in order to enable early implementations of

the UPDATE operation, RFC 2136 suggests a simpler although less effective security mechanism.

Updates can be restricted to stations (typically DHCP servers) whose IP addresses are statically

configured on the DNS server.

Integrating DNS, DHCP, and WINS

NetworkCare Whitepaper

•

The second additional requirement is the need for a protocol to define how DHCP will use the UPDATE

operation. This requirement is addressed in the Internet draft entitled ÃInteraction Between DHCP and

DNSÄ xi . This Ãwork in progressÄ proposes protocols for DHCP clients and servers to use to update DNS.

Specifically, the Draft suggests two scenarios: (1) the DHCP server updates both the forward and reverse

information (A and PTR resource records) for the DHCP client; (2) the DHCP client updates the forward

information and the DHCP server updates the reverse information. The choice between these two

scenarios will depend on how DNSSEC is implemented, e.g. it may be that only the DHCP client will

have the necessary cryptographic keys to perform a credible UPDATE operation.

Solution 3: Use the Same Database

A third alternative is for the DNS and DHCP servers to share a common database. This proprietary non-

RFC-based technique is used by several leading IP management products. When the DHCP server issues

an IP address to a DHCP client, the server updates the database. A database monitor process detects the

change and updates the DNS server.

DNS and WINS

Another integration issue is synchronizing the DNS and WINS (NBNS) databases. Integration of DNS

with WINS is important for networks in which Microsoft Windows or IBM OS/2 clients are used because

Windows and OS/2 employ NetBIOS. Networks consisting solely of other operating systems, such as

UNIX, NetWare, Banyon, and Macintosh, do not use NetBIOS and thus have no need for WINS.

The following example illustrates the integration problem. Assume there are two users, Joe and Rita.

JoeÆs PC uses NetBT and RitaÆs PC uses strictly IP and DNS. When Joe boots his PC, it registers its

name with its WINS server, but the networkÆs DNS server has no entry for JoeÆs PC. Now Rita wishes to

FTP a file from JoeÆs PC to hers. In her FTP client program, Rita specifies the NetBIOS name of JoeÆs

PC, and the FTP client program queries the DNS server. The DNS server fails to locate an IP address for

the name of JoeÆs PC. Consequently, Rita must use the IP address of JoeÆs PC (assuming Joe knows

what it is).

There are two problems illustrated by this scenario. First, both PCs have IP addresses and have network

layer connectivity, but they do not have session layer (name resolution) connectivity because the DNS

server was not updated with the name of JoeÆs PC. Second, even if the DNS server was updated, it is not

clear where in the DNS hierarchy JoeÆs PC would reside. You will recall that NetBIOS uses a flat

namespace whereas DNS uses a hierarchical namespace. An additional protocol or policy would have to

place JoeÆs PC in an appropriate branch of the DNS hierarchy.

Solution 1: Rely on DHCP

The first solution to synchronizing the DNS and WINS databases is not to integrate DNS and WINS at

all. We can require JoeÆs PC to use DHCP to obtain an IP address. Thus, we rely on DHCP to update

DNS with the name of JoeÆs PC, and JoeÆs PC already updates the WINS server.

Solution 2: Fall-Back Query

With a Ãfall-backÄ query approach, the DNS and WINS databases are neither synchronized nor combined

into one. Instead, an additional communication mechanism is employed. When RitaÆs PC queries the

DNS server, the DNS server fails to find the name of JoeÆs PC in the DNS database, so the DNS server

queries the WINS server. If the WINS server knows the IP address of JoeÆs PC, the WINS server returns

it to the DNS server which provides it to RitaÆs PC.

Integrating DNS, DHCP, and WINS

NetworkCare Whitepaper

•

Solution 3: Use the Same Database

Alternatively, the DNS and WINS servers could use the same database. In this scheme, all the IP

address- to-name mappings would be stored in a single database. The DNS server would update the

database either by manual configuration by the administrator or automatically via DDNS. The WINS

server would update the database by NetBIOS clients registering with the WINS server. The DNS and

WINS servers would simply have different views of the database. Such a solution would have to provide

a way to decide where in the DNS hierarchy NetBIOS names fall.

Commercial Implementations

The author is aware of at least eleven vendors in the IP management market. The following discussion

focuses on the five products which appear to be used most widely. In alphabetical order by product

name, they are:

•

IPserver (Network TeleSystems)

•

MetaIP (MetaInfo)

•

NetID (Bay Networks, formerly Isotro)

•

NT (Microsoft)

•

QIP (Quadritek)

DNS and DHCP

The following table summarizes how the leading IP management products integrate DNS and DHCP:

Vendor

Static

Names

DDNS (DHCP server directly updates DNS

server)

Use Same

Database

IPserver

3.0

Yes

Proprietary Implementation

MetaIP 3.1 Yes

RFC 2136 Compliant (restricts updates based

on senderÆs IP address)

NetID 3.0 Yes

Yes

NT 4.0

Yes

QIP 3.1

Yes

Proprietary Implementation

Yes

At least two IP management products (IPserver and QIP) have implemented a proprietary protocol for a

DHCP server to update a DNS server. However, QIP also provides a mechanism for the updates to flow

from a DHCP server through a central database to a DNS server. NetID is planning to implement their

own proprietary DDNS protocol in a future product release.

The author performed some informal performance tests to compare the efficiency of a DDNS solution

compared to a shared database solution. As one might expect, the DDNS solution exhibited a much

lower total latency. IPserver and NetID were subjected to a stress test in which each was presented with

500 simulated DHCP client IP address requests in very rapid succession (well under half a second).

IPserver (in 7 seconds) took more than twice as long as NetID (in 3 seconds) to complete the DHCP

protocol exchange DISCOVER-OFFER-REQUEST-ACK. However, IPserver was able to provide a

complete zone transfer of the dynamically-added names as soon as the last ACK was received by the

DHCP client simulator program. In contrast, NetID required approximately 10 additional minutes before

it was able to provide a zone transfer containing the dynamically added names. This additional time is

Integrating DNS, DHCP, and WINS

NetworkCare Whitepaper

•

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: