DHCP-DNS Interaction Bernie Volz IETF-61, DHC WG

Current Drafts draft-ietf-dhc-fqdn-option-07 (no change, ready for WG Last Call) draft-ietf-dhc-ddns-resolution-08 (revised) draft-ietf-dhc-dhcpv6-fqdn-00 (revised) draft-ietf-dnsext-dhcid-rr-08 (no change)  Not updated since last IETF  Will resubmit as needed to keep alive  Ready for IESG, but will check with DNSEXT WG Chairs and request they review above drafts

draft-ietf-dhc-ddns-resolution-08 Revised to incorporate A/AAAA updates  Is the procedure correct and optimum?  Is it clearly presented?  Please carefully review sections 6.2 and 6.3 Submit for WG Last Call

6.3.1 Initial DHCID RR Query When a DHCP client or server intends to update an A or AAAA RR, it performs a DNS query with QNAME of the target name and with QTYPE of DHCID. If the query returns NXDOMAIN, the updater can conclude that the name is not in use and proceeds to Section If the query returns NOERROR but without an answer, the updater can conclude that the target name is in use, but that no DHCID RR is present. This indicates that some records have been configured by an administrator. Whether the updater proceeds with an update is a matter of local administrative policy. If the DHCID rrset is returned, the updater uses the hash calculation defined in the DHCID RR specification [4] to determine whether the client associated with the name matches the current client's identity. If so, the updater proceeds to Section Otherwise the updater must conclude that the client's desired name is in use by another host and proceeds to Section If any other status is returned, the updater MUST NOT attempt an update.

6.3.2 DNS UPDATE When Name Not in Use The updater prepares a DNS UPDATE query that includes as a prerequisite the assertion that the name does not exist. The update section of the query attempts to add the new name and its IP address mapping (an A or AAAA RR), and the DHCID RR with its unique client-identity. If the update operation succeeds, the A or AAAA RR update is now complete (and a client updater is finished, while a server would then proceed to perform a PTR RR update). If the update returns YXDOMAIN, the updater can now conclude that the intended name is in use and proceeds to Section

6.3.3 DNS UPDATE When Name in Use The updater next attempts to confirm that the DNS name is not being used by some other host. The updater prepares a UPDATE query in which the prerequisite is that the desired name has attached to it a DHCID RR whose contents match the client identity. The update section of the UPDATE query contains: 1. A delete of any existing A RRs on the name if this is an A update or an AAAA update and the updater does not desire A records on the name. 2. A delete of the existing AAAA RRs on the name if the updater does not desire AAAA records on the name or this update is adding an AAAA and the updater only desires a single address on the name. 3. An add of the A RR that matches the DHCP binding if this is an A update. 4. An add of the AAAA RR that matches the DHCP binding if this is an AAAA update. If the update succeeds, the updater can conclude that the current client was the last client associated with the domain name, and that the name now contains the updated A or AAAA RR. The update is now complete (and a client updater is finished, while a server would then proceed to perform a PTR RR update). If the update returns NXRRSET, the updater must conclude that the client's desired name is in use by another host and proceeds to Section

6.3.4 Name in Use by another Client At this juncture, the updater can decide (based on some administrative configuration outside of the scope of this document) whether to let the existing owner of the name keep that name, and to (possibly) perform some name disambiguation operation on behalf of the current client, or to replace the RRs on the name with RRs that represent the current client. If the configured policy allows replacement of existing records, the updater submits a query that deletes all RRs for the name and adds the A or AAAA and DHCID RRs that represent the address and client-identity of the new client. DISCUSSION: The updating entity may be configured to allow the existing DNS records on the domain name to remain unchanged, and to perform disambiguation on the name of the current client in order to attempt to generate a similar but unique name for the current client. In this case, once another candidate name has been generated, the updater should restart the process of adding an A RR as specified in this section.

draft-ietf-dhc-dhcpv6-fqdn-00 Revised individual submission  FQDN option is per IA_* and applies to all addresses in binding Ready for WG Last Call?

Please, Let’s get these documents done and to the IESG!