357 lines
12 KiB
Plaintext
357 lines
12 KiB
Plaintext
|
||
|
||
Network Working Group Yakov Rekhter
|
||
Internet Draft Cisco Systems
|
||
Expiration Date: January 1997 July 1996
|
||
|
||
|
||
Interaction between DHCP and DNS
|
||
draft-ietf-dhc-dhcp-dns-01.txt
|
||
|
||
|
||
1. Status of this Memo
|
||
|
||
This document is an Internet-Draft. 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 learn the current status of any Internet-Draft, please check the
|
||
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
|
||
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
|
||
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
|
||
ftp.isi.edu (US West Coast).
|
||
|
||
|
||
2. Abstract
|
||
|
||
DHCP provides a powerful mechanism for IP host autoconfiguration.
|
||
However, the autoconfiguration provided by DHCP does not include
|
||
updating DNS, and specifically updating the name to address and
|
||
address to name mappings maintained by DNS.
|
||
|
||
This document specifies how DHCP clients and servers should use the
|
||
Dynamic DNS Updates mechanism to update the DNS name to address and
|
||
address to name mapping, so that the mappings for DHCP clients would
|
||
be consistent with the IP addresses that the clients acquire via
|
||
DHCP.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 1]
|
||
|
||
|
||
|
||
|
||
|
||
Internet Draft draft-ietf-dhc-dhcp-dns-01.txt July 1996
|
||
|
||
|
||
3. Interaction between DHCP and DNS
|
||
|
||
DNS [RFC1034, RFC1035] maintains (among other things) the information
|
||
about mapping between hosts' Fully Qualified Domain Names (FQDNs)
|
||
[RFC1594] 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.
|
||
|
||
DHCP [RFC1541] provides a mechanism by which a host (a DHCP client)
|
||
could acquire certain configuration information, and specifically 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.
|
||
|
||
Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS
|
||
information to be updated DNS over a network.
|
||
|
||
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 gets 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.
|
||
|
||
|
||
4. Models of operations
|
||
|
||
When a DHCP client acquires a new address, both the A RR (for the
|
||
client's FQDN) and the PTR RR (for the acquired address) have to be
|
||
updated. Therefore, we have two separate Dynamic DNS Update
|
||
transactions. Acquiring an address 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, upon
|
||
some introspection one could realize that not all permutations make
|
||
sense. This document covers the possible design permutations:
|
||
|
||
(1) DHCP client updates the A RR, DHCP server updates the PTR
|
||
RR
|
||
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 2]
|
||
|
||
|
||
|
||
|
||
|
||
Internet Draft draft-ietf-dhc-dhcp-dns-01.txt July 1996
|
||
|
||
|
||
(2) DHCP server updates both the A and the PTR RRs
|
||
|
||
One could observe that 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.
|
||
|
||
|
||
4.1. Client FQDN Option
|
||
|
||
To update the IP address to FQDN mapping a DHCP server needs to know
|
||
FQDN of the client to which the server leases the address. To allow
|
||
the client to convey its FQDN to the server this document defines a
|
||
new option, called "Client FQDN".
|
||
|
||
The code for this option is TBD. Its minimum length is 2.
|
||
|
||
|
||
|
||
Code Len Flags RCODE1 RCODE2 Domain Name
|
||
+------+------+------+------+------+------+--
|
||
| TBD | n | 0/1 | | | ...
|
||
+------+------+------+------+------+------+--
|
||
|
||
|
||
|
||
The Flags field allows a DHCP client to indicate to a DHCP server
|
||
whether the client wants the server to be responsible for updating
|
||
the FQDN to IP address mapping (if Flags is set to 1), or whether the
|
||
client wants to take this responsibility (if Flags is set to 0).
|
||
|
||
The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
|
||
a DHCP client the Response Code from Dynamic DNS Updates.
|
||
|
||
The Domain Name part of the option carries FQDN of a client.
|
||
|
||
|
||
|
||
4.2. DHCP Client behavior
|
||
|
||
If a client wants to be responsible for updating the FQDN to IP
|
||
address mapping for the FQDN and address(es) used by the client, then
|
||
the client shall include the Client FQDN option in the DHCPREQUEST
|
||
message originated by the client. The Flags field in the option shall
|
||
be set to 0. Once the client's DHCP configuration is completed (the
|
||
client receives a DHCPACK message, and successfully completed a final
|
||
check on the parameters passed in the message), the client shall
|
||
originate an update for the A RR (associated with the client's FQDN).
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 3]
|
||
|
||
|
||
|
||
|
||
|
||
Internet Draft draft-ietf-dhc-dhcp-dns-01.txt July 1996
|
||
|
||
|
||
The update shall be originated following the procedures described in
|
||
[DynDNS].
|
||
|
||
|
||
If a client does not want to be responsible for updating the FQDN to
|
||
IP address mapping for the FQDN and address(es) used by the client,
|
||
then the client shall include the Client FQDN option in the
|
||
DHCPREQUEST message originated by the client. The Flags field in the
|
||
option shall be set to 1.
|
||
|
||
|
||
Whether the client wants to be responsible for updating the FQDN to
|
||
IP address mapping, or whether the client wants to delegate this
|
||
responsibility to a server is a local to the client matter. The
|
||
choice between the two alternatives may be based on a particular
|
||
security model that is used with the Dynamic DNS Update protocol
|
||
(e.g., only a client may have sufficient credentials to perform
|
||
updates to the FQDN to IP address mapping for its FQDN).
|
||
|
||
If a client releases its address lease prior to the lease expiration
|
||
time, and the client is responsible for updating its A RR(s), the
|
||
client should delete the A RR (following the procedures described in
|
||
[DynDNS]) associated with the leased address before sending DHCP
|
||
RELEASE message.
|
||
|
||
|
||
4.3. DHCP Server behavior
|
||
|
||
When a server receives a DHCPREQUEST message from a client, if the
|
||
message contains the Client FQDN option, and the server replies to
|
||
the message with a DHCPACK message, the server shall originate an
|
||
update for the PTR RR (associated with the address leased to the
|
||
client). The server shall originate the update before the server
|
||
sends the DHCPACK message to the client. The update shall be
|
||
originated following the procedures described in [DynDNS]. The RCODE
|
||
from the update [DynDNS] should be carried to the client in the
|
||
RCODE1 field of the Client FQDN option in the DHCPACK message. The
|
||
RCODE2 field should be set to 0.
|
||
|
||
In addition, if the Client FQDN option carried in the DHCPREQUEST
|
||
message has its Flags field set to 1, then the server shall originate
|
||
an update for the A RR (associated with the FQDN carried in the
|
||
option). The server shall originate the update before the server
|
||
sends the DHCPACK message to the client. The update shall be
|
||
originated following the procedures described in [DynDNS]. The RCODE
|
||
from the update [DynDNS] should be carried to the client in the
|
||
RCODE2 field of the Client FQDN option in the DHCPACK message.
|
||
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 4]
|
||
|
||
|
||
|
||
|
||
|
||
Internet Draft draft-ietf-dhc-dhcp-dns-01.txt July 1996
|
||
|
||
|
||
When a server receives a DHCPREQUEST message from a client, and the
|
||
message contains the Client FQDN option, the server shall ignore the
|
||
value carried in the RCODE field of the option.
|
||
|
||
|
||
If a server originates updates for both the A and PTR RRs, then the
|
||
order in which the updates are generated is not significant.
|
||
|
||
|
||
If a server detects that a lease on an address that the server leases
|
||
to a client expires, the server should delete the PTR RR associated
|
||
with the address. In addition, if the client authorized the server to
|
||
update its A RR, the server should also delete the A RR. The deletion
|
||
should follow the procedures described in [DynDNS].
|
||
|
||
If a server terminates a lease on an address prior to the lease
|
||
expiration time, the server should delete the PTR RR associated with
|
||
the address. In addition, if the client (that leased the address)
|
||
authorized the server to update its A RR, the server should also
|
||
delete the A RR. The deletion should follow the procedures described
|
||
in [DynDNS].
|
||
|
||
|
||
5. Updating other RRs
|
||
|
||
The procedures described in this document cover updates only to the A
|
||
and PTR RRs. Updating other types of RRs is outside the scope of this
|
||
document.
|
||
|
||
|
||
|
||
6. Security Considerations
|
||
|
||
Security issues are not discussed in this document.
|
||
|
||
|
||
7. References
|
||
|
||
[RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
|
||
RFC1034, 11/01/1987
|
||
|
||
[RFC1035] P. Mockapetris, "Domain names - implementation and
|
||
specification", RFC1035, 11/01/1987
|
||
|
||
[RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541,
|
||
10/27/1993
|
||
|
||
[RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 5]
|
||
|
||
|
||
|
||
|
||
|
||
Internet Draft draft-ietf-dhc-dhcp-dns-01.txt July 1996
|
||
|
||
|
||
Answer Answers to Commonly asked ``New Internet User'' Questions",
|
||
RFC1594, 03/11/1994
|
||
|
||
[DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
|
||
in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
|
||
09.txt
|
||
|
||
|
||
|
||
8. Acknowledgements
|
||
|
||
Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms
|
||
(Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron),
|
||
and Michael Patton (BBN) for their review and comments.
|
||
|
||
|
||
9. Author Information
|
||
|
||
|
||
Yakov Rekhter
|
||
cisco Systems, Inc.
|
||
170 Tasman Dr.
|
||
San Jose, CA 95134
|
||
Phone: (914) 528-0090
|
||
email: yakov@cisco.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Yakov Rekhter [Page 6]
|
||
|
||
|