draft-ietf-dhc-dhcp-dns-00.txt   draft-ietf-dhc-dhcp-dns-01.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: August 1996 February 1996 Expiration Date: January 1997 July 1996
Interaction between DHCP and DNS Interaction between DHCP and DNS
draft-ietf-dhc-dhcp-dns-00.txt draft-ietf-dhc-dhcp-dns-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 25 skipping to change at page 2, line 25
could acquire certain configuration information, and specifically its could acquire certain configuration information, and specifically its
IP address(es). However, DHCP does not provide any mechanisms to IP address(es). However, DHCP does not provide any mechanisms to
update the DNS RRs that contain the information about mapping between 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 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 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 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 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 acquired, and the PTR RR for the acquired address wouldn't reflect
the host's FQDN. the host's FQDN.
Dynamic DNS Updates [DynDNS] is a mechanism that enables to update Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS
DNS information over a network. information to be updated DNS over a network.
Use of the Dynamic DNS Updates protocol enables to maintain The Dynamic DNS Update protocol can be used to maintain consistency
consistency between the information stored in the A and PTR RRs and between the information stored in the A and PTR RRs and the actual
the actual address assignment done via DHCP. When a host with a address assignment done via DHCP. When a host with a particular FQDN
particular FQDN acquires its IP address via DHCP, the A RR associated acquires its IP address via DHCP, the A RR associated with the host's
with the host's FQDN would be updated (by using the Dynamic DNS FQDN would be updated (by using the Dynamic DNS Updates protocol) to
Updates protocol) to reflect the new address. Likewise, when an IP reflect the new address. Likewise, when an IP address gets assigned
address gets assigned to a host with a particular FQDN, the PTR RR to a host with a particular FQDN, the PTR RR associated with this
associated with this address would be updated (using the Dynamic DNS address would be updated (using the Dynamic DNS Updates protocol) to
Updates protocol) to reflect the new FQDN. reflect the new FQDN.
4. Models of operations 4. Models of operations
When a DHCP client acquires a new address, both the A RR (for the 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 client's FQDN) and the PTR RR (for the acquired address) have to be
updated. Therefore, we have two separate Dynamic DNS Update updated. Therefore, we have two separate Dynamic DNS Update
transactions. Acquiring an address via DHCP involves two entities: a transactions. Acquiring an address via DHCP involves two entities: a
DHCP client and a DHCP server. In principle each of these entities DHCP client and a DHCP server. In principle each of these entities
could perform none, one, or both of the transactions. However, upon could perform none, one, or both of the transactions. However, upon
some introspection one could realize that not all permutations make some introspection one could realize that not all permutations make
sense. This document restricts the possible design permutations to sense. This document covers the possible design permutations:
the following cases:
(1) DHCP client updates the A RR, DHCP server updates the PTR (1) DHCP client updates the A RR, DHCP server updates the PTR
RR RR
(2) DHCP server updates both the A and the PTR RRs (2) DHCP server updates both the A and the PTR RRs
One could observe that the only difference between these two cases is 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 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 by a DHCP server. The IP address to FQDN mapping is updated by a DHCP
server in both cases. server in both cases.
4.1. Client FQDN Option 4.1. Client FQDN Option
To update the IP address to FQDN mapping a DHCP server needs to know 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 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 the client to convey its FQDN to the server this document defines a
new option, called "Client FQDN". new option, called "Client FQDN".
The code for this option is TBD. Its minimum length is 2. The code for this option is TBD. Its minimum length is 2.
Code Len Flags Domain Name Code Len Flags RCODE1 RCODE2 Domain Name
+-----+-----+-----+-----+-----+-----+-- +------+------+------+------+------+------+--
| TBD | n | 0/1 | d1 | d2 | d3 | ... | TBD | n | 0/1 | | | ...
+-----+-----+-----+-----+-----+-----+-- +------+------+------+------+------+------+--
The Flags field allows a DHCP client to indicate to a DHCP server The Flags field allows a DHCP client to indicate to a DHCP server
whether the client wants the server to be responsible for updating 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 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). 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. The Domain Name part of the option carries FQDN of a client.
4.2. DHCP Client behavior 4.2. DHCP Client behavior
If a client wants to be responsible for updating the FQDN to IP 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 address mapping for the FQDN and address(es) used by the client, then
the client shall include the Client FQDN option in the DHCPREQUEST the client shall include the Client FQDN option in the DHCPREQUEST
message originated by the client. The Flags field in the option shall 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 be set to 0. Once the client's DHCP configuration is completed (the
client receives a DHCPACK message, and successfully completed a final client receives a DHCPACK message, and successfully completed a final
skipping to change at page 3, line 42 skipping to change at page 4, line 4
4.2. DHCP Client behavior 4.2. DHCP Client behavior
If a client wants to be responsible for updating the FQDN to IP 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 address mapping for the FQDN and address(es) used by the client, then
the client shall include the Client FQDN option in the DHCPREQUEST the client shall include the Client FQDN option in the DHCPREQUEST
message originated by the client. The Flags field in the option shall 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 be set to 0. Once the client's DHCP configuration is completed (the
client receives a DHCPACK message, and successfully completed a final client receives a DHCPACK message, and successfully completed a final
check on the parameters passed in the message), the client shall check on the parameters passed in the message), the client shall
originate an update for the A RR (associated with the client's FQDN). originate an update for the A RR (associated with the client's FQDN).
The update shall be originated following the procedures described in The update shall be originated following the procedures described in
[DynDNS]. [DynDNS].
If a client does not want to be responsible for updating the FQDN to 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, IP address mapping for the FQDN and address(es) used by the client,
then the client shall include the Client FQDN option in the then the client shall include the Client FQDN option in the
DHCPREQUEST message originated by the client. The Flags field in the DHCPREQUEST message originated by the client. The Flags field in the
option shall be set to 1. option shall be set to 1.
A client that delegates the responsibility for updating the FQDN to
IP address mapping to a server does not receive any indications
(either positive or negative) from the server whether the server was
able to perform the update. The client may use DNS query to check
whether the mapping is updated.
Whether the client wants to be responsible for updating the FQDN to Whether the client wants to be responsible for updating the FQDN to
IP address mapping, or whether the client wants to delegate this IP address mapping, or whether the client wants to delegate this
responsibility to a server is a local to the client matter. 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 4.3. DHCP Server behavior
When a server receives a DHCPREQUEST message from a client, if the When a server receives a DHCPREQUEST message from a client, if the
message contains the Client FQDN option, and the server replies to message contains the Client FQDN option, and the server replies to
the message with a DHCPACK message, the server shall originate an the message with a DHCPACK message, the server shall originate an
update for the PTR RR (associated with the address leased to the update for the PTR RR (associated with the address leased to the
client). The server shall originate the update only after the server client). The server shall originate the update before the server
sends the DHCPACK message to the client. The update shall be sends the DHCPACK message to the client. The update shall be
originated following the procedures described in [DynDNS]. 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 In addition, if the Client FQDN option carried in the DHCPREQUEST
message has its Flags field set to 1, then the server shall originate 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 an update for the A RR (associated with the FQDN carried in the
option). The server shall originate the update only after the server option). The server shall originate the update before the server
sends the DHCPACK message to the client. The update shall be sends the DHCPACK message to the client. The update shall be
originated following the procedures described in [DynDNS]. 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.
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 If a server originates updates for both the A and PTR RRs, then the
order in which the updates are generated is not significant. order in which the updates are generated is not significant.
[Discussion: should it be possible to configure a server to perform If a server detects that a lease on an address that the server leases
updates for the FQDN to IP address mapping, even when a client to a client expires, the server should delete the PTR RR associated
indicates to the server that the client wants to update this mapping 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].
[Discussion: how should the duration of the lease be reflected in the
DNS updates ? At the minimum we can set TTL on the A and PTR RRs to
the value of the lease time. What else ?]
[Discussion: when a server detects that a lease on an address that
the server leases to a client expires, should the server delete the
PTR RR associated with the address ?]
[Discussion: if a server terminates a lease prior to the lease If a server terminates a lease on an address prior to the lease
expiration time, should the server update the associated PTR RR ? expiration time, the server should delete the PTR RR associated with
Should the A RR be updated, and if yes, then by whom ? ] 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 5. Updating other RRs
The procedures described in this document cover updates only to the A 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 and PTR RRs. Updating other types of RRs is outside the scope of this
document. document.
6. Applicability to IPv6 6. Security Considerations
The procedures described above are directly applicable to an IPv6
client. The only difference is that instead of updating its A RR(s)
the client has to update its AAAA RR(s).
7. Security Considerations
Security issues are not discussed in this document. Security issues are not discussed in this document.
8. References 7. References
[RFC1034] P. Mockapetris, "Domain names - concepts and facilities", [RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
RFC1034, 11/01/1987 RFC1034, 11/01/1987
[RFC1035] P. Mockapetris, "Domain names - implementation and [RFC1035] P. Mockapetris, "Domain names - implementation and
specification", RFC1035, 11/01/1987 specification", RFC1035, 11/01/1987
[RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541, [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541,
10/27/1993 10/27/1993
[RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
Answer Answers to Commonly asked ``New Internet User'' Questions", Answer Answers to Commonly asked ``New Internet User'' Questions",
RFC1594, 03/11/1994 RFC1594, 03/11/1994
[DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
06.txt, Feb 1996 09.txt
9. Acknowledgements 8. Acknowledgements
Many thanks to Ralph Droms for his review and comments. 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.
10. Author Information 9. Author Information
Yakov Rekhter Yakov Rekhter
cisco Systems, Inc. cisco Systems, Inc.
170 Tasman Dr. 170 Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: (914) 528-0090 Phone: (914) 528-0090
email: yakov@cisco.com email: yakov@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/