9.  DNS Update Considerations

   DHCP servers (and clients) can use "DNS update" as described in
   RFC 2136 [RFC2136] to maintain DNS name mappings as they maintain
   DHCP leases.  Many different administrative models for DHCP-DNS
   integration are possible.  Descriptions of several of these models,
   and guidelines that DHCP servers and clients should follow in
   carrying them out, are laid out in RFC 4704 [RFC4704].

   The nature of the failover protocol introduces some issues concerning
   DNS updates that are not part of non-failover environments.  This
   section describes these issues and defines the information that
   failover partners should exchange in order to ensure consistent
   behavior.  The presence of this section should not be interpreted as
   a requirement that an implementation of the DHCPv6 failover protocol
   also support DNS updates.

   The purpose of this discussion is to clarify the areas where the
   failover and DHCP DNS update protocols intersect for the benefit of
   implementations that support both protocols, not to introduce a new
   requirement into the DHCPv6 failover protocol.  Thus, a DHCP server
   that implements the failover protocol MAY also support DNS updates,
   but if it does support DNS updates it SHOULD utilize the techniques
   described here in order to correctly distribute them between the
   failover partners.  See RFC 4704 [RFC4704] as well as RFC 4703
   [RFC4703] for information on how DHCP servers deal with potential
   conflicts when updating DNS even without failover.

   From the standpoint of the failover protocol, there is no reason why
   a server that is utilizing the DNS update protocol to update a DNS
   server should not be a partner with a server that is not utilizing
   the DNS update protocol to update a DNS server.  However, a server
   that is not able to support DNS update or is not configured to
   support DNS update SHOULD output a warning message when it receives
   BNDUPD messages that indicate that its failover partner is configured
   to support the DNS update protocol to update a DNS server.  An
   implementation MAY consider this an error and refuse to accept the
   BNDUPD message by returning the status DNSUpdateNotSupported in an
   OPTION_STATUS_CODE option in the BNDREPLY message, or it MAY choose
   to operate anyway, having warned the administrator of the problem in
   some way.

9.1.  Relationship between Failover and DNS Update

   The failover protocol describes the conditions under which each
   failover server may renew a lease to its current DHCP client and
   describes the conditions under which it may grant a lease to a new
   DHCP client.  An analogous set of conditions determines when a
   failover server should initiate a DNS update, and when it should
   attempt to remove records from the DNS.  The failover protocol's
   conditions are based on the desired external behavior: avoiding
   duplicate address and prefix assignments, allowing clients to
   continue using leases that they obtained from one failover partner
   even if they can only communicate with the other partner, and
   allowing the secondary DHCP server to grant new leases even if it is
   unable to communicate with the primary server.  The desired external
   DNS update behavior for DHCPv6 failover servers is similar to that
   described above for the failover protocol itself:

   1.  Allow timely DNS updates from the server that grants a lease to a
       client.  Recognize that there is often a DNS update "lifecycle"
       that parallels the DHCP lease lifecycle.  This is likely to
       include the addition of records when the lease is granted and the
       removal of DNS records when the lease is subsequently made
       available for allocation to a different client.

   2.  Communicate enough information between the two failover servers
       to allow one to complete the DNS update lifecycle even if the
       other server originally granted the lease.

   3.  Avoid redundant or overlapping DNS updates where both failover
       servers are attempting to perform DNS updates for the same
       lease-client binding.

   4.  Avoid situations where one partner is attempting to add resource
       records (RRs) related to a lease binding while the other partner
       is attempting to remove RRs related to the same lease binding.

   While DHCPv6 servers configured for DNS update typically perform
   these operations on both the AAAA and the PTR RRs, this is not
   required.  It is entirely possible that a DHCPv6 server could be
   configured to only update the DNS with PTR records, and the DHCPv6
   clients could be responsible for updating the DNS with their own AAAA
   records.  In this case, the discussions here would apply only to the
   PTR records.

9.2.  Exchanging DNS Update Information

   In order for either server to be able to complete a DNS update or to
   remove DNS records that were added by its partner, both servers need
   to know the FQDN associated with the lease-client binding.  In
   addition, to properly handle DNS updates, additional information is
   required.  All of the following information needs to be transmitted
   between the failover partners:

   1.  The FQDN that the client requested be associated with the lease.
       If the client doesn't request a particular FQDN and one is
       synthesized by the failover server or if the failover server is
       configured to replace a client-requested FQDN with a different
       FQDN, then the server-generated value would be used.

   2.  The FQDN that was actually placed in the DNS for this lease.  It
       may differ from the client-requested FQDN due to some form of
       disambiguation or other DHCP server configuration (as described
       above).

   3.  The status of any DNS update operations in progress or completed.

   4.  Information sufficient to allow the failover partner to remove
       the FQDN from the DNS, should that become necessary.

   These data items are the minimum necessary set to reliably allow two
   failover partners to successfully share the responsibility to keep
   the DNS up to date with the leases allocated to clients.

   This information would typically be included in BNDUPD messages sent
   from one failover partner to the other.  Failover servers MAY choose
   not to include this information in BNDUPD messages if there has been
   no change in the status of any DNS update related to the lease.

   The partner server receiving BNDUPD messages containing the DNS
   update information SHOULD compare the status information and the FQDN
   with the current DNS update information it has associated with the
   lease binding and update its notion of the DNS update status
   accordingly.

   Some implementations will instead choose to send a BNDUPD message
   without waiting for the DNS update to complete and then will send a
   second BNDUPD message once the DNS update is complete.  Other
   implementations will delay sending the partner a BNDUPD message until
   the DNS update has been acknowledged by the DNS server, or until some
   time limit has elapsed, in order to avoid sending a second BNDUPD
   message.

   The FQDN option contains the FQDN that will be associated with the
   AAAA RR (if the server is performing a AAAA RR update for the
   client).  The PTR RR can be generated automatically from the IPv6
   address value.  The FQDN may be composed in any of several ways,
   depending on server configuration and the information provided by the
   client in its DHCP messages.  The client may supply a hostname that
   it would like the server to use in forming the FQDN, or it may supply
   the entire FQDN.  The server may be configured to attempt to use the
   information the client supplies, it may be configured with an FQDN to
   use for the client, or it may be configured to synthesize an FQDN.

   Since the server interacting with the client may not have completed
   the DNS update at the time it sends the first BNDUPD message about
   the lease binding, there may be cases where the FQDN in later BNDUPD
   messages does not match the FQDN included in earlier messages.  For
   example, the responsive server may be configured to handle situations
   where two or more DHCP client FQDNs are identical by modifying the
   most-specific label in the FQDNs of some of the clients in an attempt
   to generate unique FQDNs for them (a process sometimes called
   "disambiguation").  Alternatively, at sites that use some or all of
   the information that clients supply to form the FQDN, it's possible
   that a client's configuration may be changed so that it begins to
   supply new data.  The server interacting with the client may react by
   removing the DNS records that it originally added for the client and
   replacing them with records that refer to the client's new FQDN.  In
   such cases, the server SHOULD include the actual FQDN that was used
   in subsequent DNS update options in any BNDUPD messages exchanged
   between the failover partners.  This server SHOULD include relevant
   information in its BNDUPD messages.  This information may be
   necessary in order to allow the non-responsive partner to detect
   client configuration changes that change the hostname or FQDN data
   that the client includes in its DHCPv6 requests.

9.3.  Adding RRs to the DNS

   A failover server that is going to perform DNS updates SHOULD
   initiate the DNS update when it grants a new lease to a client.  The
   server that did not grant the lease SHOULD NOT initiate a DNS update
   when it receives the BNDUPD message after the lease has been granted.
   The failover protocol ensures that only one of the partners will
   grant a lease to any individual client, so it follows that this
   requirement will prevent both partners from initiating updates
   simultaneously.  The server initiating the update SHOULD follow the
   protocol in RFC 4704 [RFC4704].  The server may be configured to
   perform a AAAA RR update on behalf of its clients, or not.
   Ordinarily, a failover server will not initiate DNS updates when it
   renews leases.  In two cases, however, a failover server MAY initiate
   a DNS update when it renews a lease to its existing client:

   1.  When the lease was granted before the server was configured to
       perform DNS updates, the server MAY be configured to perform
       updates when it next renews existing leases.

   2.  If a server is in PARTNER-DOWN state, it can conclude that its
       partner is no longer attempting to perform an update for the
       existing client.  If the remaining server has not recorded that
       an update for the binding has been successfully completed, the
       server MAY initiate a DNS update.  It may initiate this update
       immediately upon entry into PARTNER-DOWN state, it may perform
       this in the background, or it may initiate this update upon next
       hearing from the DHCP client.

   Note that, regardless of the use of failover, there is a use case for
   updating the DNS on every lease renewal.  If there is a concern that
   the information in the DNS does not match the information in the DHCP
   server, updating the DNS on lease renewal is one way to gradually
   ensure that the DNS has information that corresponds correctly to the
   information in the DHCP server.

9.4.  Deleting RRs from the DNS

   The failover server that makes a lease PENDING-FREE SHOULD initiate
   any DNS deletes if it has recorded that DNS records were added on
   behalf of the client.

   A server not in PARTNER-DOWN state "makes a lease PENDING-FREE" when
   it initiates a BNDUPD message with a binding-status of FREE,
   FREE-BACKUP, EXPIRED, or RELEASED.  Its partner confirms this status
   by acking that BNDUPD message, and upon receipt of the BNDREPLY
   message the server has "made the lease PENDING-FREE".  Conversely, a
   server in PARTNER-DOWN state "makes a lease PENDING-FREE" when it
   sets the binding-status to FREE, since in PARTNER-DOWN state no
   communications with the partner are required.

   It is at this point that it should initiate the DNS operations to
   delete RRs from the DNS.  Its partner SHOULD NOT initiate DNS deletes
   for DNS records related to the lease binding as part of sending the
   BNDREPLY message.  The partner MAY have issued BNDUPD messages with a
   binding-status of FREE, EXPIRED, or RELEASED previously, but the
   other server will have rejected these BNDUPD messages.

   The failover protocol ensures that only one of the two partner
   servers will be able to make a lease PENDING-FREE.  The server making
   the lease PENDING-FREE may be doing so while it is communicating in
   NORMAL state with its partner, or it may be in PARTNER-DOWN state.
   If a server is in PARTNER-DOWN state, it may be performing DNS
   deletes for RRs that its partner added originally.  This allows a
   single remaining partner server to assume responsibility for all of
   the DNS update activity that the two servers were undertaking.

   Another implication of this approach is that no DNS RR deletes will
   be performed while either server is in COMMUNICATIONS-INTERRUPTED
   state, since no leases are moved into the PENDING-FREE state during
   that period.

   A failover server SHOULD ensure that a server failure while making a
   lease PENDING-FREE and initiating a DNS delete does not somehow leave
   the lease with an RR in the DNS with nothing recorded in the lease
   state database to trigger a DNS delete.

9.5.  Name Assignment with No Update of DNS

   In some cases, a DHCP server is configured to return a name to the
   DHCP client but not enter that name into the DNS.  This is typically
   a name that it has discovered or generated from information it has
   received from the client.  In this case, this name information SHOULD
   be communicated to the failover partner, if only to ensure that they
   will return the same name in the event the partner becomes the server
   with which the DHCP client begins to interact.

10.  Security Considerations

   DHCPv6 failover is an extension of a standard DHCPv6 protocol, so all
   security considerations from Section 23 of [RFC3315] and Section 15
   of [RFC3633] related to the server apply.

   The use of TCP introduces some additional concerns.  Attacks that
   attempt to exhaust the DHCP server's available TCP connection
   resources can compromise the ability of legitimate partners to
   receive service.  Malicious requestors who succeed in establishing
   connections but who then send invalid messages, partial messages, or
   no messages at all can also exhaust a server's pool of available
   connections.

   DHCPv6 failover can operate in secure or insecure mode.  Secure mode
   (using Transport Layer Security (TLS) [RFC5246]) would be indicated
   when the TCP connection between failover partners is open to external
   monitoring or interception.  Insecure mode should only be used when
   the TCP connection between failover partners remains within a set of
   protected systems.  Details of such protections are beyond the scope
   of this document.  Failover servers MUST use the approach documented
   in Section 9.1 of [RFC7653] to decide whether or not to use TLS when
   connecting with the failover partner.

   The threats created by using failover directly mirror those from
   using DHCPv6 itself: information leakage through monitoring, and
   disruption of address assignment and configuration.  Monitoring the
   failover TCP connection provides no additional data beyond that
   available from monitoring the interactions between DHCPv6 clients and
   the DHCPv6 server.  Likewise, manipulating the data flow between
   failover servers provides no additional opportunities to disrupt
   address assignment and configuration beyond that provided by acting
   as a counterfeit DHCP server.  Protection from both threats is easier
   than with basic DHCPv6, as only a single TCP connection needs to be
   protected.  Either use secure mode to protect that TCP connection or
   ensure that it can only exist with a set of protected systems.

   When operating in secure mode, TLS is used to secure the connection.
   The recommendations in [RFC7525] SHOULD be followed when negotiating
   a TLS connection.

   Servers SHOULD offer configuration parameters to limit the sources of
   incoming connections through validation and use of the digital
   certificates presented to create a TLS connection.  They SHOULD also
   limit the number of accepted connections and limit the period of time
   during which an idle connection will be left open.

   Authentication for DHCPv6 messages [RFC3315] MUST NOT be used to
   attempt to secure transmission of the messages described in this
   document.  If authentication is desired, secure mode using TLS SHOULD
   be employed as described in Sections 8.2 and 9.1 of [RFC7653].

11.  IANA Considerations

   IANA has assigned values for the following new DHCPv6 message types
   in the registry maintained at <http://www.iana.org/assignments/
   dhcpv6-parameters>:

   o  BNDUPD (24)

   o  BNDREPLY (25)

   o  POOLREQ (26)

   o  POOLRESP (27)

   o  UPDREQ (28)

   o  UPDREQALL (29)

   o  UPDDONE (30)

   o  CONNECT (31)

   o  CONNECTREPLY (32)

   o  DISCONNECT (33)

   o  STATE (34)

   o  CONTACT (35)

   IANA has assigned values for the following new DHCPv6 option codes in
   the registry maintained at <http://www.iana.org/assignments/
   dhcpv6-parameters>:

   o  OPTION_F_BINDING_STATUS (114)

   o  OPTION_F_CONNECT_FLAGS (115)

   o  OPTION_F_DNS_REMOVAL_INFO (116)

   o  OPTION_F_DNS_HOST_NAME (117)

   o  OPTION_F_DNS_ZONE_NAME (118)

   o  OPTION_F_DNS_FLAGS (119)

   o  OPTION_F_EXPIRATION_TIME (120)

   o  OPTION_F_MAX_UNACKED_BNDUPD (121)

   o  OPTION_F_MCLT (122)

   o  OPTION_F_PARTNER_LIFETIME (123)

   o  OPTION_F_PARTNER_LIFETIME_SENT (124)

   o  OPTION_F_PARTNER_DOWN_TIME (125)

   o  OPTION_F_PARTNER_RAW_CLT_TIME (126)

   o  OPTION_F_PROTOCOL_VERSION (127)

   o  OPTION_F_KEEPALIVE_TIME (128)

   o  OPTION_F_RECONFIGURE_DATA (129)

   o  OPTION_F_RELATIONSHIP_NAME (130)

   o  OPTION_F_SERVER_FLAGS (131)

   o  OPTION_F_SERVER_STATE (132)

   o  OPTION_F_START_TIME_OF_STATE (133)

   o  OPTION_F_STATE_EXPIRATION_TIME (134)

   IANA has assigned values for the following new DHCPv6 status codes in
   the registry maintained at <http://www.iana.org/assignments/
   dhcpv6-parameters>:

   o  AddressInUse (16)

   o  ConfigurationConflict (17)

   o  MissingBindingInformation (18)

   o  OutdatedBindingInformation (19)

   o  ServerShuttingDown (20)

   o  DNSUpdateNotSupported (21)

   o  ExcessiveTimeSkew (22)

12.  References

12.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2136]  Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, DOI 10.17487/RFC2136, April 1997,
              <http://www.rfc-editor.org/info/rfc2136>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315,
              July 2003, <http://www.rfc-editor.org/info/rfc3315>.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              DOI 10.17487/RFC3633, December 2003,
              <http://www.rfc-editor.org/info/rfc3633>.

   [RFC4703]  Stapp, M. and B. Volz, "Resolution of Fully Qualified
              Domain Name (FQDN) Conflicts among Dynamic Host
              Configuration Protocol (DHCP) Clients", RFC 4703,
              DOI 10.17487/RFC4703, October 2006,
              <http://www.rfc-editor.org/info/rfc4703>.

   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
              Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
              <http://www.rfc-editor.org/info/rfc4704>.

   [RFC5007]  Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
              "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007,
              September 2007, <http://www.rfc-editor.org/info/rfc5007>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              DOI 10.17487/RFC5460, February 2009,
              <http://www.rfc-editor.org/info/rfc5460>.

   [RFC6607]  Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet
              Selection Options for DHCPv4 and DHCPv6", RFC 6607,
              DOI 10.17487/RFC6607, April 2012,
              <http://www.rfc-editor.org/info/rfc6607>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7653]  Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
              Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
              October 2015, <http://www.rfc-editor.org/info/rfc7653>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,
              <http://www.rfc-editor.org/info/rfc8174>.

12.2.  Informative References

   [RFC7031]  Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
              Requirements", RFC 7031, DOI 10.17487/RFC7031,
              September 2013, <http://www.rfc-editor.org/info/rfc7031>.

Acknowledgements

   This document extensively uses concepts, definitions, and other parts
   of an effort to document failover for DHCPv4.  The authors would like
   to thank Shawn Routhier, Greg Rabil, Bernie Volz, and Marcin
   Siodelski for their significant involvement and contributions.  In
   particular, Bernie Volz and Shawn Routhier provided detailed and
   substantive technical reviews of the document.  The RFC Editor also
   caught several important technical issues.  The authors would like to
   thank Vithalprasad Gaitonde, Krzysztof Gierlowski, Krzysztof Nowicki,
   and Michal Hoeft for their insightful comments.

Authors' Addresses

   Tomek Mrugalski
   Internet Systems Consortium, Inc.
   950 Charter Street
   Redwood City, California  94063
   United States of America

   Email: tomasz.mrugalski@gmail.com


   Kim Kinnear
   Cisco Systems, Inc.
   200 Beaver Brook Road
   Boxborough, Massachusetts  01719
   United States of America

   Phone: +1 978 936 0000
   Email: kkinnear@cisco.com