RFC 4703

Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients

📅 published October 2006, from ietf

RFC 4703: Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients ✨

Okay bestie, this is RFC 4703 🎀, and it's a Standards Track doc, so it's an actual protocol spec and not just a vibe. It was written by M. Stapp and B. Volz from Cisco Systems, Inc. and it dropped in October 2006 🍓. Nothing is listed as obsoleted or updated in its header, so it's standing on its own. The whole thing is about what happens when DHCP clients end up with the same FQDN, and how to sort that out with the DHCID DNS record 💅.

Status of This Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006) 💜.

Abstract 🦋

Okay so DHCP is the thing that hands out host configuration, and that includes dynamically assigned IP addresses and fully qualified domain names 🌸. To keep the name-to-address and address-to-name mappings in the DNS accurate, those dynamically assigned addresses and FQDNs need DNS updates 🧚. This doc identifies situations where FQDN conflicts can pop up between DHCP clients and servers, and it describes a strategy for using the DHCID DNS resource record (RR) to resolve those conflicts 👑. It's giving problem-solving era ✨.

Table of Contents 🗂️

1. Introduction ....................................................3
2. Terminology .....................................................3
3. Issues with DNS Update in DHCP Environments .....................4
   3.1. Client Misconfiguration ....................................4
   3.2. Multiple DHCP Servers ......................................5
4. Use of the DHCID RR .............................................5
5. Procedures for Performing DNS Updates ...........................6
   5.1. Error Return Codes .........................................6
   5.2. Dual IPv4/IPv6 Client Considerations .......................6
   5.3. Adding A and/or AAAA RRs to DNS ............................7
        5.3.1. Initial DHCID RR Request ............................7
        5.3.2. DNS UPDATE When FQDN in Use .........................7
        5.3.3. FQDN in Use by Another Client .......................8
   5.4. Adding PTR RR Entries to DNS ...............................8
   5.5. Removing Entries from DNS ..................................9
   5.6. Updating Other RRs ........................................10
6. Security Considerations ........................................10
7. Acknowledgements ...............................................11
8. References .....................................................11
   8.1. Normative References ......................................11
   8.2. Informative References ....................................11

1. Introduction 🌷

So "The Client FQDN Option" [8] describes how [4] clients and servers work when they use the DHCPv4 client FQDN option 💖. Then "The DHCPv6 Client FQDN Option" [9] covers how [5] clients and servers work with the DHCPv6 client FQDN option 🫶. With the client FQDN option, DHCP clients and servers can negotiate the client's FQDN and decide who's responsible for updating the client's A and/or AAAA RRs 🤝. This doc points out where FQDN conflicts can happen between DHCP clients and servers, and it lays out a strategy for using the DHCID DNS resource record [2] to fix them 🔥.

Whether a site lets all, some, or none of its DHCP servers and clients make DNS updates ([3], [10]) into the zones it controls is totally up to local admin policy 🎀. This doc doesn't require any particular policy and doesn't propose one 🙅‍♀️. The options are super wide. On one end, only the DHCP servers get credentials the DNS servers accept. On the other end, every single DHCP client gets credentials that let it change its own FQDN 🦋. Compliant implementations MAY support some or all of these possibilities 💅. Also, this spec only covers DHCP client and server processes, so it doesn't apply to other processes that start DNS updates 🙈.

2. 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 [1] 🔑.

This doc assumes you already know the DNS terminology from [6] and the DHCP terminology from [4] and [5] 🧠.

FQDN stands for Fully Qualified Domain Name, and it's the full name of a system, not just its hostname 🌈. For example, "venera" is a hostname, and "venera.isi.edu" is an FQDN ✨. See [7] for more.

DOCSIS stands for Data-Over-Cable Service Interface Specifications, and it's defined by CableLabs 📡.

3. Issues with DNS Update in DHCP Environments 🌊

There are two DNS update situations that need special attention in DHCP environments 🚨. The first is when more than one DHCP client has been configured with the same FQDN. The second is when more than one DHCP server has been given authority to make DNS updates in a zone 👀. In those cases, DNS records can get changed in inconsistent ways unless the updaters have a way to detect weird situations 😭. If DNS updaters can spot these situations, site admins can configure how the updaters behave, so the site's policies actually get enforced 💜. This spec describes a mechanism that lets updaters detect these situations, and it suggests that DHCP implementations use this mechanism by default 🫶.

3.1. Client Misconfiguration 🎀

Admins may want a one-to-one relationship between active DHCP clients and FQDNs, plus consistency between a client's A, AAAA, and PTR RRs 💖. Clients that aren't represented in the DNS, or clients that accidentally share an FQDN with another client, might act inconsistently or fail to reach network resources 😬. Whether an admin configures each DHCP client with an FQDN or the DHCP server hands out the clients' FQDNs, the consistency of the DNS data depends entirely on how accurate that configuration step is 🧐. Sites that deploy [10] can set up credentials for each client and its assigned FQDN in a more error-resistant way, because both the FQDN and the credentials have to match 🔐.

Here's an example 🍿. Two DHCP clients on the "example.com" network are both configured with the hostname "foo". Both clients are allowed to make their own DNS updates. The first client, client A, gets its config through DHCP. It adds an A RR to "foo.example.com", and its DHCP server adds a PTR RR for its assigned IP address 🌸. Then the second client, client B, boots up. It also gets its config through DHCP, and it starts updating "foo.example.com" too 😳.

At this point, the "example.com" admins might want to set a policy about DHCP clients' FQDNs 🧚. If the policy says each client that boots should replace any existing A RR that matches its FQDN, then Client B can go ahead, but Client A might run into problems 💀. In this case, Client B replaces the A RR tied to "foo.example.com". Client A has to have some way to recognize that the RR for "foo.example.com" now holds info for Client B, so it can avoid changing that RR 🙅‍♀️. For example, when Client A's assigned IP address expires, it should not remove an RR that reflects Client B's DHCP-assigned IP address 🚫.

If the policy says the first DHCP client with a given FQDN should be the only client tied to that FQDN, then Client B needs a way to figure out whether it's not the client associated with "foo.example.com" 🕵️‍♀️. Maybe Client A booted first, so Client B should pick another FQDN. Or maybe B booted on a new subnet and got a new IP address, in which case B should update the DNS with its new IP address 🌈. To enforce the site's policy, B either has to keep persistent state about the last IP address it was assigned (on top of its current IP address), or it has to have some other way to detect that it was the last updater of "foo.example.com" 💅.

3.2. Multiple DHCP Servers 🖥️

DHCP servers can be set up to make A and/or AAAA RR updates for their clients 🦋. If one DHCP server manages all of the DHCP clients at a site, it can keep a database of the FQDNs in use, and it can check that database before giving an FQDN to a client 💖. But that kind of database is necessarily proprietary, and the approach stops working once more than one DHCP server is deployed 😭.

When multiple DHCP servers are deployed, they need a way to coordinate the identities of DHCP clients 🤝. Here's an example 🍓. DHCPv4 Client A boots and gets an IP address from Server S1. It presents the hostname "foo" in a Client FQDN option [8] in its DHCPREQUEST message 📨. Server S1 updates the FQDN "foo.example.com" and adds an A RR with the IP address assigned to A 🌷. Then the client moves to another subnet, served by Server S2. When Client A boots on the new subnet, Server S2 assigns it a new IP address and tries to add an A RR with that new address to the FQDN "foo.example.com" 🚀. At this point, unless there's some communication mechanism S2 can use to ask S1 (and every other DHCP server that updates the zone) about the client, S2 has no way to know whether Client A is currently tied to the FQDN, or whether A is actually a different client configured with the same FQDN 🤷‍♀️. If the servers can't tell these situations apart, they can't enforce the site's naming policies 😤.

4. Use of the DHCID RR 🧩

Okay so the fix for both of these problems is for the updater (a DHCP client or a DHCP server) to be able to figure out which DHCP client is associated with an FQDN 🔍. That way admins get the chance to configure how the updater behaves 👑.

For this purpose, a DHCID RR, specified in [2], is used to link client identification info to an FQDN and to the A, AAAA, and PTR RRs tied to that FQDN 💜. When a client or server adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that specifies a unique client identity, based on data from the client's DHCP message 🎀. In this model, only one client is associated with a given FQDN at a time 💖.

By attaching this ownership info to each FQDN, cooperating DNS updaters can tell whether their client is currently associated with a particular FQDN, and then carry out the properly configured admin policy 🫶. Plus, DHCP clients that already have FQDNs can switch from one DHCP server to another without losing those FQDNs 🦋.

The specific algorithm that uses the DHCID RR to signal client ownership is explained below 🌈. But here's the thing: the algorithm only works if all the updating entities cooperate. This approach is advisory only. It's not a substitute for DNS security, and DNS security doesn't replace it either 🙈.

5. Procedures for Performing DNS Updates 🚀

(part 1 ends here, bestie. more coming soon 💖)

5.1. Error Return Codes ✨

Okay so certain RCODEs from [3] basically mean "the DNS server cannot do an update rn": FORMERR, SERVFAIL, REFUSED, and NOTIMP. 💀 If one of these comes back, the updater MUST terminate its update attempt. No cap, it stops right there.

Other RCODEs [13] can mean the key being used has problems. In that case you might try a different key if you have one, or just terminate the operation. 🔑

Some errors can point to a misconfiguration on the updater's side or on the DNS server's side, so the updater MAY attempt to signal to its administrator that an error has occurred, e.g., through a log message. 📝

5.2. Dual IPv4/IPv6 Client Considerations 🌈

At the time this document was published, only a small minority of DHCP clients support both IPv4 and IPv6. 🙈 We expect, however, that things will shift over time, and more sites will have dual-stack clients showing up. IPv6 clients need updates of AAAA RRs, and IPv4 clients need updates of A RRs. Admins running mixed setups will probably want a single FQDN to hold both A and AAAA RRs from the same client, which is so relatable. 🫶

Sites that want a single FQDN to contain both A and AAAA RRs MUST make use of DHCPv4 clients and servers that support using the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers. This DUID is then used in computing the RDATA of the DHCID RR by both DHCPv4 and DHCPv6 for the client. See [11].

Otherwise, a dual-stack client using the older-style DHCPv4 client identifiers (see [4] and [12]) will only be able to have either its A or AAAA records in DNS under a single FQDN, because the DHCID RR conflicts that result. It's giving collision drama. 💔

5.3. Adding A and/or AAAA RRs to DNS 🎀

When a DHCP client or server wants to update A and/or AAAA RRs, it starts with the UPDATE request in Section 5.3.1. That's the main character opener. 👑

As the update sequence below can result in loops, implementers SHOULD limit the total number of attempts for a single transaction. Nobody wants an infinite loop era. 🔁

5.3.1. Initial DHCID RR Request 🦋

The updater prepares a DNS UPDATE request that includes, as a prerequisite, the assertion that the FQDN does not exist. The update section of the request tries to add the new FQDN, its IP address mapping (A and/or AAAA RRs), and the DHCID RR with its unique client identity. ✨

If the UPDATE request succeeds, the A and/or AAAA RR update is complete. A client updater is finished at this point, while a server would then go on to perform a PTR RR update. 🎉

If the response to the UPDATE returns YXDOMAIN, the updater can now conclude that the intended FQDN is in use, and it moves on to Section 5.3.2. 👀

If any other status is returned, the updater SHOULD NOT attempt an update (see Section 5.1). Don't push it, bestie. 🙅‍♀️

5.3.2. DNS UPDATE When FQDN in Use 💅

The updater next tries to confirm that the FQDN isn't being used by some other client. It does this by preparing an UPDATE request with two prerequisites. The first is that the FQDN exists. The second is that the desired FQDN has a DHCID RR attached to it whose contents match the client identity. ✅

The update section of the UPDATE request contains:

  1. A delete of any existing A RRs on the FQDN, if this is an A update or an AAAA update and the updater does not desire A records on the FQDN, or if this update is adding an A and the updater only desires a single IP address on the FQDN.
  2. A delete of the existing AAAA RRs on the FQDN, if the updater does not desire AAAA records on the FQDN, or if this update is adding an AAAA and the updater only desires a single IP address on the FQDN.
  3. An add (or adds) of the A RR that matches the DHCP binding, if this is an A update.
  4. Adds of the AAAA RRs that match the DHCP bindings, if this is an AAAA update.

Whether A or AAAA RRs get deleted depends on the updater or the updater's policy. For example, if the updater is the client, or it's configured as the only DHCP server for the link the client is on, the updater may find it beneficial to delete all A and/or AAAA RRs and then add the current set of A and/or AAAA RRs (if any) for the client. Clean slate energy. 🧹

If the UPDATE request succeeds, the updater can conclude that the current client was the last client associated with the FQDN, and that the FQDN now contains the updated A and/or AAAA RRs. The update is complete. A client updater is finished, while a server would then proceed to perform a PTR RR update. 🏆

If the response to the UPDATE request returns NXDOMAIN, the FQDN is no longer in use, and the updater goes back to Section 5.3.1. Fresh start! 🌸

If the response to the UPDATE request returns NXRRSET, there are two possibilities. Either there are no DHCID RRs for the FQDN, or the DHCID RR doesn't match. In either case, the updater moves on to Section 5.3.3. 🤷‍♀️

5.3.3. FQDN in Use by Another Client 🙈

The FQDN appears to be in use by another client, or it isn't associated with any client at all. So the updater SHOULD either choose another FQDN and restart the update process with this new one, or terminate the update with a failure. 🚫

Techniques that might be considered for disambiguating FQDNs include adding some suffix or prefix to the hostname portion of the FQDN, or randomly generating a hostname. Get creative, it's giving name-brand energy. 🍓

5.4. Adding PTR RR Entries to DNS 🧚

The DHCP server submits a DNS UPDATE request that deletes all of the PTR RRs associated with the client's assigned IP address, and then adds a PTR RR whose data is the client's FQDN (possibly disambiguated). The server MAY also add a DHCID RR as specified in Section 4. If it does, it would include a delete of all of the DHCID RRs associated with the client's assigned IP address, and then add a DHCID RR for the client. 💜

There's no need to validate the DHCID RR for PTR updates, since the DHCP server (or servers) only assigns an address to a single client at a time. Sorted. 💁‍♀️

5.5. Removing Entries from DNS 🗑️

The most important thing when removing DNS entries is making sure that whoever is removing an entry is only removing an entry that they added, or one an administrator explicitly gave them responsibility for. Respect the boundaries, babe. 🚧

When an address' lease time or valid lifetime expires, or a DHCP client issues a DHCPRELEASE [4] or Release [5] request, the DHCP server SHOULD delete the PTR RR that matches the DHCP binding, if one was successfully added. The server's UPDATE request SHOULD assert that the domain name (PTRDNAME field) in the PTR record matches the FQDN of the client whose address has expired or been released, and should delete all RRs for the FQDN. 🌙

The entity handling the A or AAAA records for this client (either the client or the server) SHOULD delete the A or AAAA records that were added when the address was assigned to the client. However, the updater should only remove the DHCID RR if there are no A or AAAA RRs remaining for the client. Don't leave the DHCID hanging if there's nothing left to point to! 🥺

To do this A or AAAA RR delete, the updater prepares an UPDATE request. It contains a prerequisite asserting that the DHCID RR exists, whose data is the client identity described in Section 4, and an update section that deletes the client's specific A or AAAA RR. 🔍

If the UPDATE request succeeds, the updater prepares a second UPDATE request. This one contains three prerequisites and an update section that deletes all RRs for the FQDN. The first prerequisite asserts that the DHCID RR exists, whose data is the client identity described in Section 4. The second prerequisite asserts that there are no A RRs. The third prerequisite asserts that there are no AAAA RRs. Triple-checked, no cap. ✅✅✅

If either request fails, the updater MUST NOT delete the FQDN. It may be that the client whose address has expired has moved to another network and obtained an address from a different server, which caused the client's A or AAAA RR to be replaced. Or, the DNS data may have been removed or altered by an administrator. Plot twist, but we don't touch it. 🫣

5.6. Updating Other RRs 🧁

The procedures in this document only cover updates to the A, AAAA, PTR, and DHCID RRs. Updating other types of RRs is outside the scope of this document. Other RR types, not my problem today. 💅

6. Security Considerations 🔐

Okay, this section is serious, so listen up. 🚨 Administrators should be wary of permitting unsecured DNS updates to zones, whether or not those zones are exposed to the global Internet. Both DHCP clients and servers SHOULD use some form of update request authentication (e.g., TSIG [13]) when performing DNS updates. Lock it down, periodt. 🔒

Whether a DHCP client may be responsible for updating an FQDN-to-IP-address mapping, or whether that's the responsibility of the DHCP server, is a site-local matter. The choice between the two may be based on the security model used with the Dynamic DNS Update protocol. For example, only a client may have sufficient credentials to perform updates to the FQDN-to-IP-address mapping for its FQDN. 🗝️

Whether a DHCP server is always responsible for updating the FQDN-to-IP-address mapping (in addition to updating the IP-to-FQDN mapping), regardless of the wishes of an individual DHCP client, is also a site-local matter. The choice between the two alternatives may be based on the security model being used with dynamic DNS updates. In cases where a DHCP server is performing DNS updates on behalf of a client, the DHCP server should be sure of the FQDN to use for the client, and of the identity of the client. Verify, then update. 🕵️‍♀️

Right now it's pretty hard for DHCP servers to be confident in the identities of their clients, since the DHCP protocol itself doesn't have entity authentication. ngl, that's a big deal. There are lots of ways for a DHCP server to come up with an FQDN to use for a client, but only in certain rare circumstances will the server know for certain who the client is. If [14] becomes widely deployed, this may become more customary. Fingers crossed! 🤞

One example of a situation that offers some extra assurance is when the DHCP client is connected to a network through a DOCSIS cable modem, and the Cable Modem Termination System (head-end) of that cable modem ensures that MAC address spoofing simply does not occur. Another example of a configuration that might be trusted is when clients get network access through a network access server using PPP. The Network Access Server (NAS) itself might be getting IP addresses via DHCP, encoding client identification into the DHCP client-id option. In this case, the NAS and the DHCP server might both be operating within a trusted environment. The DHCP server could then be configured to trust that the NAS's user authentication and authorization processing was sufficient, and would therefore trust the client identification encoded within the DHCP client-id. Trust, but make sure the trust is earned. 🫡

7. Acknowledgements 🙏

Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W. Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola, and Glenn Stump for their review and comments. The squad that made this possible. 💖

8. References 📚

8.1. Normative References

Okay, these are the reference docs you need to read before the spec makes sense, bestie 📚✨

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR), RFC 4701, October 2006.
  • [3] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
  • [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

8.2. Informative References

These ones are the extra-credit reading 🤓🎀. Super useful, but not strictly required to get the vibe.

  • [6] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [7] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
  • [8] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
  • [9] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
  • [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
  • [11] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
  • [12] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
  • [13] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
  • [14] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.

Authors' Addresses 💌

Meet the authors, the two brilliant folks who made this whole thing happen 👑

Mark Stapp
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: 978.936.1535
EMail: mjs@cisco.com


Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA  01719
USA

Phone: 978.936.0382
EMail: volz@cisco.com

Copyright (C) The Internet Society (2006).

This doc is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 💜

This doc and the info in it are provided on an "AS IS" basis, and the legal fine print is serious, so here it is in full:

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

The IETF doesn't take a side on whether any IPR or other rights that someone might claim over the tech in this doc are valid or how far they reach, and it also doesn't say it has done any independent digging to find such rights. Whether a license is available is a whole separate question 🙈 For the procedures on rights in RFC docs, check out BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that will be made available, or the results of any attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone interested to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💅

Acknowledgement 🫶

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you're literally keeping the lights on ✨

📦 where this page comes from