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
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
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
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
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
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
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
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
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/
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/
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)
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>.
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.
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, California 94063
United States of America
Cisco Systems, Inc.
200 Beaver Brook Road
Boxborough, Massachusetts 01719
United States of America
Phone: +1 978 936 0000