DNS Delete-Confirm Mechanism with Multi-DHCP-Servers

[I-D.ietf-dhc-addr-registration] describes a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The client will send a DNS registration request to the DHCPv6 server after successfully assigning a self-generated IPv6 address on one of its interfaces. The DHCPv6 server then registers the client's IPv6 address to FQDN binding towards a configured DNS server, with a valid-lifetime. The client must extend the registration before it expires. If the DHCPv6 server does not receive such a refresh after the valid-lifetime has passed, it SHOULD remove the IPv6-address-to-FQDN bindings in DNS. Multiple DHCPv6 servers working in an administrative domain is encouraged since it could bring higher availability, load balancing ability and other benefits. However in the context of Multiple servers within a single network, problems may arise when performing DNS update. This document specifies a mechanism to ensure servers could coordinate with each other and update DNS correctly.

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 .

[I-D.ietf-dhc-addr-registration] describes a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. When there are multiple address registration DHCPv6 servers within an administration domain, the client can send DNS registration request to multiple servers, and the servers can work correctly in registering DNS. When the client wants to extend its registered DNS entry, it will send an extension request to the registration servers. However, when one of the registration servers which received the initial registration request does not receive the extension request, it will remove the client's IPv6-address-to-FQDN bindings in DNS once its original valid-lifetime has passed, without verifying with the client.

After the servers update DNS correctly, the client SHOULD extends this by sending a new ADDR-REGISTRATION-REQUEST message to a DHCPv6 address registration server. After receiving the refresh message, the DHCPv6 address registration server update the address registration entry. Before the servers that missed the extension remove the entry prematurely (i.e., when it expired originally), the server MUST send an ADDR-REGISTRATION-CONFIRMATION message to the client to confirm whether the entry should be removed. The ADDR-REGISTRATION-VALIDATION message MUST be sent back to the server to indicate whether the server should remove the address registration entry or not.

| | | | | | | ADDR-REGISTRATION-CONFIRMATION | |<----------------------------------------------| | | |Register | | |address | | ADDR-REGISTRATION-VALIDATION |in DNS |---------------------------------------------->| ]]>

Two new DHCPv6 messages between the client and the server: DHCPv6 ADDR-REGISTRATION-CONFIRMATION Message and DHCPv6 ADDR-REGISTRATION-VALIDATION Message are defined.This section describes the structures of these messages.

Before the servers that missed the extension remove the entry prematurely, the DHCPv6 server sends an ADDR-REGISTRATION-CONFIRMATION message to a client to whether or not remove the entry. The format of the ADDR-REGISTRATION-REQUEST message is described as follows:

Identifies the message type. The transaction ID for this message exchange. Options carried in this message. The ADDR-REGISTRATION-CONFIRMATION message MUST contain server identifier option and MUST contain the IA_NA option and the DHCPv6 FQDN option [RFC4704]. The IA_NA option MUST contain the IPv6 address of the server. When the client receives the ADDR-REGISTRATION-CONFIRMATION message.

When received the ADDR-REGISTRATION-CONFIRMATION message from the server, the client determines whether to remove the entry and sent ADDR-REGISTRATION-VALIDATION message to the server. The format of the ADDR-REGISTRATION-VALIDATION message is described as follows:

Identifies the message type. The transaction ID for this message exchange. Options carried in this message. If the binding entry is valid, ADDR-REGISTRATION-VALIDATION MUST contain the IA_NA option and the DHCPv6 FQDN option [RFC4704]. The IA_NA option MUST contain at least one IA Address option. The valid-lifetime field of the IA Address option MUST be set to the period for which the client would like to register the binding in DNS. If the binding entry is invalid, the client MUST NOT put any option in the ADDR-REGISTRATION-VALIDATION message.

If there are multiple DHCPv6 servers within an administration domain, when the client extends the configuration, one of the server MAY miss the extension and remove the binding entry by mistake. Before the server removes the binding entry, the server MUST send ADDR-REGISTRATION-CONFIRMATION to confirm whether or not to remove the binding entry.

For every successful binding registration, the address registration server MUST record the IPv6-address-to-FQDN bindings and associated valid-lifetimes in its storage. The address registration client MUST refresh the registration before it expires (i.e. before the valid-lifetime of the IA address elapses) by sending a new ADDR-REGISTRATION-REQUEST to the address registration server. If the address registration server does not receive such a refresh and the valid-lifetime will pass, the address registration server sends ADDR-REGISTRATION-CONFIRMATION to the client. If the binding entry is valid, ADDR-REGISTRATION-VALIDATION MUST contain the IA_NA option and the DHCPv6 FQDN option. If the binding entry is invalid, the client MUST NOT put any option in the ADDR-REGISTRATION-VALIDATION message.

When the server receives the ADDR-REGISTRATION-VALIDATION message, if the option is null, then remove the IPv6-address-to-FQDN binding entry in DNS, also the local record. But if the option contain the IA_NA option and the FQDN option, the server MUST refresh the registration.

TBD

This document defines two new DHCPv6 message, the ADDR-REGISTRATION-CONFIRMATION message (TBA1) and ADDR-REGISTRATION-VALIDATION message (TBA2) described in Section 4.