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 BOOTPi and DHCPii.
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 " 1
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 DNSiii (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 NOTIFYiv 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
transferv (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. NetBTvi (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 " 2
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 UPDATEvii 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 DNSSECviii and SDNSDUix) 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 serverx. 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 " 3
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 " 4
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 DDNS (DHCP server directly updates DNS Use Same
Names server) Database
IPserver Yes Proprietary Implementation No
3.0
MetaIP 3.1 Yes RFC 2136 Compliant (restricts updates based No
on sender s IP address)
NetID 3.0 Yes No Yes
NT 4.0 Yes No No
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 " 5
accounted for by the fact that NetID s database manager daemon had to write the DHCP server s
information to an Oracle database and then read that information from the database and send it to the
DNS server.
DNS and WINS
The following table summarizes how the leading IP management products integrate DNS and WINS:
Rely on DHCP Fall-Back Query Use Same
Database
IPserver Yes Yes No
3.0
MetaIP 3.1 No Yes No
NetID 3.0 Yes No No
NT 4.0 No Yes No
QIP 3.1 Yes No No
As the table indicates, all of the products either rely on DHCP or a fall-back query protocol. None of the
products use a common database for DNS and WINS.
As we noted above, integration of DNS with WINS is important for  mixed networks, i.e., containing
both NetBIOS and non-NetBIOS-speaking clients.  Pure networks, i.e., containing all NetBIOS-
speaking or all non-NetBIOS-speaking clients, have no DNS/WINS integration issue.
Future Issues
Several further integration issues are on the network administration horizon.
DHCP Inter-Server Protocol
For the purpose of redundancy, it is desirable for DHCP servers to communicate with each other on a
peer-to-peer basis. A primitive form of DHCP redundancy (which does not involve peer-to-peer
communication) can be achieved via a technique called  scope splitting. For example, suppose a class
C-sized network is served by a primary and secondary DHCP server. The primary DHCP server is
configured to provide addresses from the lower two-thirds of the class C. The secondary server is
configured (but not actively running) to provide addresses from the upper third of the class C. If the
primary server fails for some reason, the network administrator manually turns the secondary DHCP on
until the primary can be brought back on line. Two significant drawbacks of this solution are:
redundancy is achieved by manual human intervention, and one-third of the address space is essentially
wasted.
Several IP management vendors have developed their own proprietary protocol for achieving DHCP
redundancy. NetID and QIP offer a DHCP  warm standby configuration in which the primary DHCP
server continually updates the secondary DHCP server with leases that have been issued. The secondary
server monitors the status of the primary server and activates automatically when the primary service
fails. IPserver provides a fully redundant DHCP solution. Two DHCP servers can be configured as
backups of each other. Both operate concurrently and maintain identical scope and lease information. If
either should fail, the other continues to function. When the failed server restarts, its backup peer
supplies all the updated information that the failed server missed while it was out of service.
Integrating DNS, DHCP, and WINS NetworkCare Whitepaper " 6
In recognition of the need for redundancy, the IETF is considering the Internet Draft entitled  An Inter-
Server Protocol for DHCP. xii Approval of such a protocol will, in theory, enable DHCP servers from
various vendors to interoperate and provide redundancy.
RADIUS
RADIUSxiii is a client/server protocol for securely authenticating dial-in users. Authentication is
achieved by the use of a shared password known to both the user and the RADIUS server and a
challenge-response mechanism. After connecting to a dial-in server (for example, a terminal server), the
user provides a username. The RADIUS server asks the user to encrypt a random number using the
shared password as the encryption key. The RADIUS server receives the encrypted number from the
user and decrypts it using the shared password (based on the username provided by the user). If the
decrypted number matches the original number, the user is considered authenticated. (Note that the
shared password is not transmitted to or from the RADIUS server.) Now authenticated, the user is sent
whatever configuration information (for example, an IP address) is necessary to access the network.
Several vendors such as NTS and Quadritek have announced plans for providing RADIUS service as part
of their IP management product set. With this capability, network administrators would have a single,
integrated interface for maintaining both user profiles and the IP addresses assigned for use by dial-in
users.
Directory Services
With the growth of large networks has come a multitude of network and user configuration information.
A number of efforts (e.g., X.500xiv and LDAPxv) to administer and distribute this information have been
made. However, the complexity of implementation, and performance of running large-scale network
directory services has proven a significant challenge. Even so, commercial directory services such as
Novell s NetWare Directory Services and Microsoft s Active Directory (planned for inclusion in NT 5.0)
are appearing. Directory services offer an option for storing DNS and DHCP information.
Consequently, several IP management vendors (e.g., MetaIP, NetID, and Quadritek) have announced
plans for making their products LDAP capable.
Integrating DNS, DHCP, and WINS NetworkCare Whitepaper " 7
Conclusion
The need for integrating DNS, DHCP and WINS has spawned a new market in IP management tools.
The leading IP management vendors have made significant strides in integrating DNS and DHCP in a
proprietary manner; however, much work remains to complete the necessary Internet standards, and
beyond that, to achieve standards-based vendor interoperability. The network manager facing a
burgeoning administrative burden now has commercial tools available to simplify the task, although
those tools currently require a single, proprietary solution enterprise-wide. IP management is one of the
fastest growing technologies in IP internetworking, and we can expect to see increased integration as the
standards solidify.
For further information, see NetworkCare's website at http://www.lucent-networkcare.com or call
1-888-767-2988 in the U.S. or 1-727-217-2303 outside the U.S.
References
i
RFCs 951 (Bootstrap Protocol) and 1542 (Clarifications and Extensions for the Bootstrap Protocol).
ii
RFCs 2131 (Dynamic Host Configuration Protocol) and 2132 (DHCP Options and BOOTP Vendor
Extensions).
iii
RFCs 1034 (Domain Names - Concepts and Facilities) and 1035 (Domain Names - Implementation
and Specification).
iv
RFC 1996 (A Mechanism for Prompt Notification of Zone Changes).
v
RFC 1995 (Incremental Zone Transfer in DNS).
vi
RFCs 1001 (Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and
Methods) and 1002 (Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed
Specifications).
vii
RFC 2136 (Dynamic Updates in the Domain Name System).
viii
RFC 2065 (Domain Name System Security Extensions).
ix
RFC 2137 (Secure Domain Name System Dynamic Update).
x
RFC 2065, Section 4.1.4 Transactions and Request SIGs.
xi
This description is based on draft version 6. For the current draft version, see
http://www.ietf.org/ids.by.wg/dhc.html.
xii
For the current draft version, see http://www.ietf.org/ids.by.wg/dhc.html.
xiii
RFC 2138 (Remote Authentication Dial-In User Service)
xiv
RFC 1309 (Technical Overview of Directory Services Using the X.500 Protocol)
xv
RFC 1777 (Lightweight Directory Access Protocol)
Copyright © 2000, Lucent Technologies NetworkCare
This is an unpublished work protected under the copyright laws. All rights reserved.
WP.EN.INTEGRATE.0100
Integrating DNS, DHCP, and WINS NetworkCare Whitepaper " 8