draft-ietf-dhc-dhcp-dns-12.txt

DHCP服务器源码

DHC Working Group                                               M. Stapp
Internet-Draft                                                Y. Rekhter
Expires: September 2000                              Cisco Systems, Inc.
                                                          March 10, 2000


                    Interaction between DHCP and DNS
                    <draft-ietf-dhc-dhcp-dns-12.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2000.

Copyright Notice

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   DHCP provides a powerful mechanism for IP host configuration.
   However, the configuration capability provided by DHCP does not
   include updating DNS, and specifically updating the name to address
   and address to name mappings maintained in the DNS.

   This document specifies how DHCP clients and servers should use the
   Dynamic DNS Updates mechanism in RFC2136[5] to update the DNS name
   to address and address to name mappings so that the mappings for
   DHCP clients will be consistent with the IP addresses that the
   clients acquire via DHCP.







Stapp & Rekhter          Expires September 2000                 [Page 1]

Internet-Draft      Interaction between DHCP and DNS          March 2000


Table of Contents

   1.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.    Models of Operation  . . . . . . . . . . . . . . . . . . . .  3
   4.    Issues with DDNS in DHCP Environments  . . . . . . . . . . .  4
   4.1   Name Collisions  . . . . . . . . . . . . . . . . . . . . . .  5
   4.2   Multiple DHCP servers  . . . . . . . . . . . . . . . . . . .  6
   4.3   Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . .  6
   4.3.1 Format of the DHCID RRDATA . . . . . . . . . . . . . . . . .  6
   4.4   DNS RR TTLs  . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.    Client FQDN Option . . . . . . . . . . . . . . . . . . . . .  8
   5.1   The Flags Field  . . . . . . . . . . . . . . . . . . . . . .  9
   5.2   The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 10
   5.3   The Domain Name Field  . . . . . . . . . . . . . . . . . . . 10
   6.    DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 10
   7.    DHCP Server behavior . . . . . . . . . . . . . . . . . . . . 12
   8.    Procedures for performing DNS updates  . . . . . . . . . . . 14
   8.1   Adding A RRs to DNS  . . . . . . . . . . . . . . . . . . . . 14
   8.2   Adding PTR RR Entries to DNS . . . . . . . . . . . . . . . . 15
   8.3   Removing Entries from DNS  . . . . . . . . . . . . . . . . . 15
   8.4   Updating other RRs . . . . . . . . . . . . . . . . . . . . . 16
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
   10.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
























Stapp & Rekhter          Expires September 2000                 [Page 2]

Internet-Draft      Interaction between DHCP and DNS          March 2000


1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119[6].

2. Introduction

   DNS (RFC1034[1], RFC1035[2]) maintains (among other things) the
   information about mapping between hosts' Fully Qualified Domain
   Names (FQDNs) RFC1594[4] and IP addresses assigned to the hosts. The
   information is maintained in two types of Resource Records (RRs): A
   and PTR. The A RR contains mapping from a FQDN to an IP address; the
   PTR RR contains mapping from an IP address to a FQDN.  The Dynamic
   DNS Updates specification (RFC2136[5]) describes a mechanism that
   enables DNS information to be updated over a network. 

   DHCP RFC2131[3] provides a mechanism by which a host (a DHCP client)
   can acquire certain configuration information, along with its IP
   address(es). However, DHCP does not provide any mechanisms to update
   the DNS RRs that contain the information about mapping between the
   host's FQDN and its IP address(es) (A and PTR RRs). Thus the
   information maintained by DNS for a DHCP client may be incorrect - a
   host (the client) could acquire its address by using DHCP, but the A
   RR for the host's FQDN wouldn't reflect the address that the host
   acquired, and the PTR RR for the acquired address wouldn't reflect
   the host's FQDN.

   The Dynamic DNS Update protocol can be used to maintain consistency
   between the information stored in the A and PTR RRs and the actual
   address assignment done via DHCP. When a host with a particular FQDN
   acquires its IP address via DHCP, the A RR associated with the
   host's FQDN would be updated (by using the Dynamic DNS Updates
   protocol) to reflect the new address. Likewise, when an IP address
   is assigned to a host with a particular FQDN, the PTR RR associated
   with this address would be updated (using the Dynamic DNS Updates
   protocol) to reflect the new FQDN.

   Although this document refers to the A and PTR DNS record types and
   to DHCP assignment of IPv4 addresses, the same procedures and
   requirements apply for updates to the analogous RR types that are
   used when clients are assigned IPv6 addresses via DHCPv6.

3. Models of Operation

   When a DHCP client acquires a new address, a site's administrator
   may desire that one or both of the A RR for the client's FQDN and
   the PTR RR for the acquired address be updated. Therefore, two
   separate Dynamic DNS Update transactions occur. Acquiring an address


Stapp & Rekhter          Expires September 2000                 [Page 3]

Internet-Draft      Interaction between DHCP and DNS          March 2000


   via DHCP involves two entities: a DHCP client and a DHCP server. In
   principle each of these entities could perform none, one, or both of
   the transactions. However, in practice not all permutations make
   sense. This document covers these possible design permutations:

   1.  DHCP client updates the A RR, DHCP server updates the PTR RR
   2.  DHCP server updates both the A and the PTR RRs

   The only difference between these two cases is whether the FQDN to
   IP address mapping is updated by a DHCP client or by a DHCP server.
   The IP address to FQDN mapping is updated by a DHCP server in both
   cases. 

   The reason these two are important, while others are unlikely, has
   to do with authority over the respective DNS domain names. A DHCP
   client may be given authority over mapping its own A RRs, or that
   authority may be restricted to a server to prevent the client from
   listing arbitrary addresses or associating its address with
   arbitrary domain names. In all cases, the only reasonable place for
   the authority over the PTR RRs associated with the address is in the
   DHCP server that allocates the address.

   In any case, whether a site permits all, some, or no DHCP servers
   and clients to perform DNS updates into the zones which it controls
   is entirely a matter of local administrative policy. This document
   does not require any specific administrative policy, and does not
   propose one. The range of possible policies is very broad, from
   sites where only the DHCP servers have been given credentials that
   the DNS servers will accept, to sites where each individual DHCP
   client has been configured with credentials which allow the client
   to modify its own domain name. Compliant implementations MAY support
   some or all of these possibilities. Furthermore, this specification
   applies only to DHCP client and server processes: it does not apply
   to other processes which initiate dynamic DNS updates. 

   This document describes a new DHCP option which a client can use to
   convey all or part of its domain name to a DHCP server.
   Site-specific policy determines whether DHCP servers use the names
   that clients offer or not, and what DHCP servers may do in cases
   where clients do not supply domain names. 

4. Issues with DDNS in DHCP Environments

   There are two DNS update situations that require special
   consideration in DHCP environments: cases where more than one DHCP
   client has been configured with the same FQDN, and cases where more
   than one DHCP server has been given authority to perform DNS updates
   in a zone. In these cases, it is possible for DNS records to be
   modified in inconsistent ways unless the updaters have a mechanism
   that allows them to detect anomolous situations. If DNS updaters can


Stapp & Rekhter          Expires September 2000                 [Page 4]

Internet-Draft      Interaction between DHCP and DNS          March 2000


   detect these situations, site administrators can configure the
   updaters' behavior so that the site's policies can be enforced. We
   use the term "Name Collisions" to refer to cases where more than one
   DHCP client has been associated with a single FQDN. This
   specification describes a mechanism designed to allow updaters to
   detect these situations, and requires that DHCP implementations use
   this mechanism by default.

4.1 Name Collisions

   How can the entity updating an A RR (either the DHCP client or DHCP
   server) detect that a domain name has an A RR which is already in
   use by a different DHCP client? Similarly, should a DHCP client or
   server update a domain name which has an A RR that has been
   configured by an administrator?  In either of these cases, the
   domain name in question would either have an additional A RR, or
   would have its original A RR replaced by the new record. Either of
   these effects may be considered undesirable by some sites. Different
   authority and credential models have different levels of exposure to
   name collisions. 

   1.  Client updates A RR, uses Secure DNS Update with credentials
       that are associated with the client's FQDN, and exclusive to the
       client. Name collisions in this scenario are unlikely (though
       not impossible), since the client has received credentials
       specific to the name it desires to use.  This implies that the
       name has already been allocated (through some implementation- or
       organization-specific procedure) to that client.

   2.  Client updates A RR, uses Secure DNS Update with credentials
       that are valid for any name in the zone. Name collisions in this
       scenario are possible, since the credentials necessary for the
       client to update DNS are not necessarily name-specific.  Thus,
       for the client to be attempting to update a unique name requires
       the existence of some administrative procedure to ensure client
       configuration with unique names.

   3.  Server updates the A RR, uses a name for the client which is
       known to the server. Name collisions in this scenario are likely
       unless prevented by the server's name configuration procedures.
       See Section 9 for security issues with this form of deployment.