Hello geek companions! I am back on writing again an article again. In this article I am presenting you I am going to talk about making your local zone dynamic.

Having a DNS master where you can edit your zone, adding, deleting or updating your records and so on is great, but what if we provision a new host which uses DHCP in the first instance as part of an automated deployment and you want that new hostname to be available on your DNS straight away? How great would that be?

We need an automation so that a new DNS record is created on the zone after a new IP address is leased to that host or device. Dynamic zones can achieve this, but how we can make a zone dynamic? We can use something called DDNS (Dynamic DNS).

First let’s do a refresh on a few terms that will help out to understand better what I am trying to explain here:

  • DNS master: it is a server or service that allows you to manage DNS zones, either manually editing zones or via browser.
  • DHCP server: It is a server or service that leases IPs to clients with a start date and an end date (lease duration)
  • DDNS server: it is a server or service that can send DNS update requests to a DNS server mastering a zone, which converts the zone into semi-dynamic or dynamic. These requests can be authenticated using TSIG keys and ACL’ed for better security.
  • DNS recourse record: it is an entry on a DNS zone, i.e. www.example.com or extranet.example.com
  • DNS slave: it a server or service that relies on communication with its master to serve the latest zone data, when queried by other servers further down the chain (i.e DNS resolvers)
  • DNS resolver: it is server or service that recurses upstream over different endpoints, depending of which resource of which zone you are trying to resolve. For example, you can use Google’s 8.8.8.8 while forwarding queries for your local domain to a different target.

This article only covers the system configuration between the DHCP server, DDNS server and the DNS master. Further infrastructure is out of the scope of this article.

I do not want to overcomplicate things, so I will just point you to what I think is decent and nice diagram below, showing what the system should look like, but not without mentioning the DCHP and DDNS services are running on the same box in my case. The diagrams shows them as separate entities for clarity.

First, to allow dynamic updates on a zone, the DNS master which governs the zone must permit dynamic updates on it, but this is too insecure just as it sounds. The DNS master (PowerDNS) can whitelist given IPs plus establishing a shared secret (TSIG key) both itself and the DDNS server knows, so update requests can be authenticated and processed. Let’s get the ball rolling!

PowerDNS authoritative master

On our PowerDNS master we must enable DNS updates by commenting out the default dnsupdate parameter:

#################################
# dnsupdate     Enable/Disable DNS update (RFC2136) support. Default is no.
#
# dnsupdate=no
dnsupdate=yes

To secure the communication between the DDNS server and the DNS master we must configure what IPs to allow as updater or updaters:

#################################
# allow-dnsupdate-from  A global setting to allow DNS updates from these IP ranges.
#
# allow-dnsupdate-from=127.0.0.0/8,::1

allow-dnsupdate-from=x.x.x.x,127.0.0.1

We need to restart the pdns service to activate the two changes we have made:

sudo service pdns restart

To create a TSIG key on our PowerDNS master and activate for a specific zone:

pdnsutil generate-tsig-key  hmac-md5
Create new TSIG key  hmac-md5 kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=
pdnsutil import-tsig-key  hmac-sha256 kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys=
pdnsutil activate-tsig-key   master

Kea DHCP-DDNS

Once the DNS master is set up to process update requests, the DDNS server needs to be prepared to forward zone update requests, based upon DHCP lease change events.

This is where Kea DHCP-DDNS comes into action (aka D2). D2 must have a catalogue of servers from which to select. In fact, D2 has two such catalogues, one for forward DNS zones and one for reverse DNS zones; these catalogues are referred to as DDNS Domain Lists. Each list consists of one or more named DDNS Domains. Additionally, each DDNS Domain has a list of one or more DNS masters that manage the DNS data for that domain.

To enable DDNS on our Kea server, first we must edit /usr/local/etc/kea/keactrl.conf (by default). We must add something like below:

# Start DHCP DDNS server?
dhcp_ddns=yes

Then you need to work out the dhcp-ddns config file, which is by default located in /usr/local/etc/kea/kea-dhcp-ddns.conf. An template is provided below:

// DHCP DDNS configuration starts here. This is a very simple configuration
// that simply starts the DDNS daemon, but will not do anything useful.
// See Section 11 for examples and details description.
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
  "tsig-keys": [
        {
                "name": "",
                "algorithm" : "hmac-sha256",
                "secret" : "”
        }
  ],
  "forward-ddns": {
        "ddns-domains": [
            {
                "name": ".",
                "key-name": "",
                "dns-servers": [
                    {
                        "hostname": "",
                        "ip-address": "",
                        "port": 53
                    }
                ]
            }
        ]
    },
   "reverse-ddns": {
        "ddns-domains": [
            {
                "name": ".",
                "key-name": "",
                "dns-servers": [
                    {
                        "hostname": "",
                        "ip-address": "",
                        "port": 53
                    }
        	]
            },

            {
		"name": ".",
                "key-name": "",
                        "port": 53
	            }
		]
	    },

	    {
                "name": ".",
                "key-name": "",
                "dns-servers": [
                    {
                        "hostname": "",
                        "ip-address": "",
                        "port": 53
                    }
                ]
            }


    	]
    }
},

// Logging configuration starts here. Kea uses different loggers to log various
// activities. For details (e.g. names of loggers), see Chapter 18.
"Logging":
{
  "loggers": [
    {
        // This specifies the logging for D2 (DHCP-DDNS) daemon.
        "name": "kea-dhcp-ddns",
        "output_options": [
            {
                // Specifies the output file. There are several special values
                // supported:
                // - stdout (prints on standard output)
                // - stderr (prints on standard error)
                // - syslog (logs to syslog)
                // - syslog:name (logs to syslog using specified name)
                // Any other value is considered a name of a time
                "output": "syslog:kea-dhcp4"

                // This governs whether the log output is flushed to disk after
                // every write.
                // "flush": false,

                // This specifies the maximum size of the file before it is
                // rotated.
                // "maxsize": 1048576,

                // This specifies the maximum number of rotated files to keep.
                // "maxver": 8
            }
        ],
        // This specifies the severity of log messages to keep. Supported values
        // are: FATAL, ERROR, WARN, INFO, DEBUG
        "severity": "INFO",

        // If DEBUG level is specified, this value is used. 0 is least verbose,
        // 99 is most verbose. Be cautious, Kea can generate lots and lots
        // of logs if told to do so.
        "debuglevel": 1
    }
  ]
}
}

Conflict resolution

What happens if two devices claim the same FQDN at the same time? Which one should be the one that prevails? It is no hard decision because IETF guys already thought about it many years ago. It resolves clashing on two different devices claiming over at the same time to be the same hostname or FQDN (RFC 4703).

To make it possible, the RFC requires each DNS update for a given FQDN to be accompanied by a DHCID RR (resource record) that basically identifies the client to whom the name belongs. Furthermore, any DNS updater (DDNS server in our case) that wishes to update or remove the entry for a FQDN, they will only succeed if their client matches that of the DHICD RR.

This below is an example of a successful update:

2020-07-28 20:43:16.248 dhcplp01 x.x.x.x kea-dhcp-ddns info INFO  [kea-dhcp-ddns.d2-to-dns] DHCP_DDNS_ADD_SUCCEEDED DHCP_DDNS Request ID 000101FA969F2208B9ACB2CB8BDF87A60F4B3D0D7FD5DA8494D34584AB90E9884E710D: successfully added the DNS mapping addition for this request: Type: 0 (CHG_ADD)
Forward Change: yes
Reverse Change: yes
FQDN: [your_client.example.com.]
IP Address: [x.x.x.x]
DHCID: [000101FA969F2208B9ACB2CB8BDF87A60F4B3D0D7FD5DA8494D34584AB90E9884E710D]
Lease Expires On: 20200729204316
Lease Length: 86400

On the DNS master’s end, two entries are created with the same FQDN but with different types of records:

Name                    Type    Content         TTL
your_client.example.com	A	10.0.13.59	86400
your_client.example.com	DHCID	000101FA969F2208B9ACB2CB8BDF87A60F4B3D0D7FD5DA8494D34584AB90E9884E710D 86400

Below the lines correspond to a successful DNS entry removal:

2020-07-30 04:02:56.977 dhcplp01 x.x.x.x kea-dhcp-ddns info INFO  [kea-dhcp-ddns.d2-to-dns] DHCP_DDNS_REMOVE_SUCCEEDED DHCP_DDNS Request IDq 000101FA969F2208B9ACB2CB8BDF87A60F4B3D0D7FD5DA8494D34584AB90E9884E710D: successfully removed the DNS mapping addition for this request: Type: 1 (CHG_REMOVE)
Forward Change: yes
Reverse Change: yes
FQDN: [your_client.example.com.]
IP Address: [x.x.x.x]
DHCID: [000101FA969F2208B9ACB2CB8BDF87A60F4B3D0D7FD5DA8494D34584AB90E9884E710D]
Lease Expires On: 20200730040247
Lease Length: 86400

All done!

Thank you so much for reading this article. I hope you found it helpful in some way. If it is true, I’d be very grateful if you shared it on your social networks or perhaps just sending it directly to anyone who you think might me interested.

Thanks again!