wiki:DhcpDdnsRequirements

DHCP Server DDNS Requirements

1. Introduction

Kea should be able to update DNS with information about leases allocated. In particular, it should be able to update the forward DNS zone and the reverse DNS zone.

The following are requirements for the default server behaviour. Since the server architecture envisages the use of user-written hooks, it will be possible for the default behaviour to be overridden by use of such hooks. For example, after the server has generated a client name, it should be possible for a hook to modify that name.

2. Requirements

2.1 Specification of DDNS Servers

Typically a site will use the same DNS server(s) for all information. However, it is possible that a site may want to use different DNS servers for names in different zones. The following requirements cover the configuration of DNS servers.

  • 2.1.1 It MUST be possible to specify a server into which the system can insert a forward DNS entry when a lease is granted.
  • 2.1.2 It MUST be possible to specify a server into which the system can insert a reverse DNS entry when a lease is granted.
  • 2.1.3 It MUST be possible to override the choice of server (for both the forward and reverse entries) on a per-zone basis.
  • 2.1.4 It SHOULD be possible to disable the use of a particular server without removing it from the database.
  • 2.1.5 For each DNS server, it MUST be possible to specify the following:
    1. one or more backup servers, to be used if no response is received from the primary server.
    2. a TSIG key.
    3. a domain origin. (This is used as a suffix if the client supplies only a partial domain name.)
    4. a port to which queries should be directed (default to port 53)

2.2 Identification of DNS Names

This section covers the requirements of the server with regards to creating the client names entered into the DNS.

2.2.1 Determination of Client Name (V4)

The following requirements apply only if the client supplies an FQDN option:

  • 2.2.1.3 The contents of the option in the DHCPREQUEST message MUST be used as the FQDN for the client. (RFC 4702 Section 2)
  • 2.2.1.4 An update of the DNS PTR record in the reverse zone MUST only be undertaken if the N bit is clear in the FQDN option. (RFC 4702 Section 2.1)
  • 2.2.1.5 An update of the DNS A record MUST only be undertaken if the S bit is set in the FQDN option and the N bit is clear (RFC 4702 Section 2.1)
  • 2.2.1.6 The server MUST recognize the FQDN given in canonical wire format without compression (E bit set in flags field) (RFC 4702 Section 2.1)
  • 2.2.1.8 In responding when a lease is allocated, the server MUST set the values in returned packet according to RFC 4702 Section 4:
    • The server sets to 0 the "S", "O", and "N" bits in its copy of the option it will return to the client. The server copies the client's "E" bit.
    • If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server initiated DNS updates, the server sets the "N" bit to 1.
    • Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the server to initiate A RR DNS updates, the server sets the "S" to 1. If the server's "S" bit does not match the client's "S" bit, the server sets the "O" bit to 1.

The following requirements apply only if the client does not supply an FQDN option but does supply a Host Name option:

  • 2.2.1.9 If the server supplies a Host Name option, this MUST be used as a non-fully-qualified domain name (i.e. prepended to the domain name associated with the name server).

If neither the client FQDN nor Host Name is supplied:

  • 2.2.1.10 If an entry is to be made into the forward zone, the server MUST generate a partial name. The name MAY of the form "host-a-b-c-d" where "a.b.c.d" is the allocated address. (This is then prepended to the domain name associated with the nameserver.)

In all cases:

  • 2.2.1.11 If the resulting name created after parsing the FQDN and prepending the DNS server domain name (if applicable) is invalid, the server MUST log an error message: the lease allocation MUST proceed (if possible) without the entry of a name into the DNS.

2.2.2 Determination of Client Name (V6)

The following requirements apply only if the client supplies a client FQDN option:

  • 2.2.2.1 The contents of the option in the Solicit with Rapid Commit, REQUEST, RENEW or REBIND message MUST be used as the FQDN for the client. (RFC 4704 Section 5.2)
  • 2.2.2.2 An update of the DNS PTR record in the reverse zone should only be undertake if the N bit is clear in the FQDN option. (RFC 4704 Section 4.1)
  • 2.2.2.3 An update of the DNS AAAA record should only be undertaken if the S bit is set in the FQDN option and the N bit is clear (RFC 4704 Section 4.1)
  • 2.2.2.4 In responding when a lease is allocated, the server MUST set the values in returned packet according to RFC 4704 Section 6:
    • The server sets to 0 the "S", "O", and "N" bits in its copy of the option it will return to the client.
    • If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server-initiated DNS updates, the server sets the "N" bit to 1.
    • Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the server to initiate AAAA RR DNS updates, the server sets the "S" to 1. If the server's "S" bit does not match the client's "S" bit, he server sets the "O" bit to 1.

The following requirements apply only if the client does not supply an FQDN option:

  • 2.2.2.5 The server MUST generate a partial name. The name MAY be created from the IPv6 address, but with colons replaced by hyphens (e.g. 1234:5678::9abc becomes host-1234-5678--9abc. (This is then prepended to the domain name associated with the nameserver.)

In all cases:

  • 2.2.2.6 If the resulting name created after parsing the FQDN and prepending the DNS server domain name (if applicable) is invalid, the server MUST log an error message: the lease allocation MUST proceed (if possible) without the entry of a name into the DNS.

2.3 DNS Operation

These are the requirements concerning the actual update of the DNS.

2.3.1 Performing the DDNS Update

  • 2.3.1.1 If no DNS servers are associated with the allocated address, the server MUST NOT attempt an update of DNS.
  • 2.3.1.2 The update process MUST be performed according to the algorithm described in RFC 4703 Section 5.3 with the following provisos:
    1. It MUST be possible for an administrator to determine whether conflict detection is performed.
  • 2.3.1.3 The update SHOULD be performed asynchronously.

2.3.2 Lease Expiration

  • 2.3.2.1 The server MUST remove lease-related entries in the DNS when the lease expires.
  • 2.3.2.2 The server MUST remove lease-related entries in the DNS when a lease is explicitly released.
  • 2.3.2.3 The server MUST maintain a record of entries made in the DNS across restarts of the server.
  • 2.3.2.4 If explicitly requested the server MUST be able to remove DNS entries created for a lease when a lease expires (or is released) even if the server is no longer responsible for the address range that includes the lease.

2.3.3 Miscellaneous

  • 2.3.3.1 It MUST be possible for the administrator to set whether the server will update the DNS if a lease is renewed but no DNS information has changed.
  • 2.3.3.2 The server MUST update the DNS if a lease is renewed but information (such as FQDN) has changed.

2.4 Management

  • 2.4.1 It SHOULD be possible to list the DNS entries made by a DHCP server.

2.5 Other Requirements

  • 2.5.1 The server SHOULD support GSS-API.
    (Requirements TBC.)
Last modified 5 years ago Last modified on Apr 25, 2013, 1:37:39 PM