On Sunday, December 04, 2005 11:58:25 PM -0500 "Bernie Volz (volz)" <volz@xxxxxxxxx> wrote:
If you're going to have multiple DHCP servers, such as failover pairs, doing the DNS updates, you need to have those servers agree on how they will identify the clients. This is not JUST for DNS updates. Failover partners need to use the same identifiers for clients.
The document I read identifies several possible situations in which DHCID records are used to coordinate between updaters which are not DHCP failover partners. It discusses a scenario in which multiple clients may attempt to issue updates for the same name (and, presumably, in which more than one client is authorized to issue such an update; otherwise, there would be no problem), and one in which a client moves between subnets served by different DHCP servers, both of which are authorized issue updates for the client's FQDN.
You can plausibly argue that the two DHCP servers in the second scenario, while not failover partners, are nonetheless part of the same administrative domain and require coordination. Such an argument seems a little weak to me, but if that were the only issue, I could live with it.
I suppose you can also argue that two clients configured to use the same name will (by design) not produce the same DHCID RR's even if they use the same type, and therefore there's not a problem if they use different types. That I'll definitely buy.
However, what about a scenario where both a client and the DHCP server on its home network are authorized to do the updates. When the client is at home, it lets the server do the update. When it is off-site at an IETF meeting, the IETF DHCP server has no authorization to update the client's fqdn, so the client must do so itself. Now, if the client and its home DHCP server disagree on which type to use, then the update may fail.
The rules are pretty clearly described in the RFC: For DHCPv4: 1. Use the DUID if the client identifier option is provided by the client and it is a DUID and the server supports it. This is a new RFC that is in the RFC-editor queue so no clients and servers yet support this. 2. Otherwise, use the client identifier option if provided by the client, 3. Otherwise, use htype and chaddr.
The rules are clear, but require that all possible updaters have the same view of the world. Consider the client I described above, which identifies itself with a DUID. So, as far as the client knows, it should follow rule 1 and use the DUID to form a DHCID record. Unfortunately, the client's home DHCP server doesn't support DUID's, so it skips rule 1 and follows rule 2, using the client identifier.
It gets worse when you start adding new types after DHCID support is widely deployed. In fact, you arguably have that problem already, since a client supporting this option doesn't know whether its home server even supports the DHCID RR, as opposed to using the TXT record method.
If you think my example involving both a client and a server is contrived, consider a client which always does its own updates. When such a client is updated, it may begin supporting new DHCID record types. It may begin supporting DUID's, or even be required to switch from non-DUID client identifiers to DUID's because it now supports IPv6. In each of these cases, the client will fail to perform an update because its new DHCID value is different from the old one. You can require the client to give up its lease and remove the record prior to shutting down, but such a requirement is fragile because a client may shut down unexpectedly, with no chance to send a DDNS update first.
In short, as long as the only authorized updaters are a set of carefully coordinated DHCP servers which never receive configuration changes or software upgrades, everything works. Once you introduce clients (which by their nature are unpredictable) or support for new DHCID types, the negotiation problem becomes an issue. It's possible to work around by performing an extra query to determine what DHCID type is in use, but you seem to want to avoid that.
-- Jeff _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf