Title: DHCP-DNS Interaction
1DHCP-DNS Interaction
- Bernie Volz
- IETF-61, DHC WG
2Current 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
3draft-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
46.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
6.3.2. 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
6.3.3. Otherwise the updater must conclude that
the client's desired name is in use by another
host and proceeds to Section 6.3.4. If any other
status is returned, the updater MUST NOT attempt
an update.
56.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.
66.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.
76.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.
8draft-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?
9Please,Lets get these documents done and to the
IESG!