Background

I run various services that require TLS and use Lets Encrypt to obtain certificates. The web host that registers my domains provides DNS services but there is no API meaning that all of my Lets Encrypt certificate requests and renewals require that I manually create the _acme-challenge DNS TXT record.

Looking for opportunity to reduce maintenance and improve my homelab, DNS resolution and TLS are so fundamental that it makes sense to invest the time to implement a robust solution. The solution I ended up implementing is BIND9 hosting multiple zones with an internal view for zones that I only want resolvable by internal hosts and an external view for the zones that are required to be resolvable by the Internet.

For additional context I use BIND as an authoritative DNS only, I have not configured BIND as a recursive resolver for my general DNS queries. For non-authoritative DNS queries I rely on pfSense and specify a domain override to direct queries for the zones that I host to my local BIND server.

I chose BIND not only because it’s a great DNS but also because certbot has an integration for BIND using the dns-rfc2136 plugin.

At a high level the dns-rfc2136 plugin will enable certbot to communicate with the the BIND server using UDP port 53, create the required TXT record, receive the certificate, remove the TXT record and undertake any required actions such as restarting the httpd, dovecot or postfix services to ensure the new certificates are loaded.

BIND Configuration

When it comes to setting up BIND to support the dns-rfc2136 plugin there are a few options. I host multiple zones some of which I do not want to expose publicly. In order for certbot to verify that you own the domain for which you are requesting a certificate there is a requirement that the TXT record be resolvable publicly.

The best method to limit exposure of your internal DNS records is to create a zone file specifically for the _acme-challenge subdomain combined with requesting only wildcard certificates.

In the case of the subdomain lan.adamgould.com.au, we can create a zone file specifically for _acme-challenge.lan.adamgould.com.au and request a wildcard certificate for *.lan.adamgould.com.au. By using this approach we dont expose identifying records such as sensitive-system.lan.adamgould.com.au. Note that there is an element of risk here in that a wildcard certificate can be used to legitimise any hostname so the use of wildcards should be weighed against the risk of potential misuse.

Creating the Zone File

The zone file itself only requires the bare minimum of information. Note that the SOA and NS records are crucial, without these certbot will be unable to locate the _acme-challenge.lan.adamgould.com.au subdomain.

; Zone file for _acme-challenge.lan.adamgould.com.au.
$ORIGIN _acme-challenge.lan.adamgould.com.au.

; Default TTL for the zone
$TTL 3H

; SOA Record
@	IN 	SOA	ns1.adamgould.com.au. dnsmaster.adamgould.com.au. (
					0000000001	; serial
					1D		; refresh
					1H		; retry
					1W		; expire
					3H )		; minimum
	
; Name Servers
	IN	NS	ns1.adamgould.com.au.

If using a Red Hat Linux derivative also verify that the ownership, permissions and SELinx policy is correct.

-rw-r--r--. 1 named named system_u:object_r:named_conf_t:s0 409 Apr 30 20:36 _acme-challenge.lan.adamgould.com.au

Publishing the Zone

With the zone file created we now need to tell BIND that we want to publish the zone.

BIND has the concept of views. Each view within BIND is a completely independent copy of the zone with governing ACL’s that dictate who can access the zone.

When a guest queries the DNS server the ACL’s are processed in order and will stop processing at the first match - the same concept as how firewall rules process traffic.

We have the requirement that the _acme-challenge.lan.adamgould.com.au be able to be queried internally in order for certbot to write and remove the TXT record as well as externally for Lets Encrypt to verify the presence of the TXT record. This presents a problem in that the hosts internal to my network exist in one ACL group and the rest of the world exist in another ACL.

Starting with BIND 9.10.0 a new zone option, “in-view”, was added that lets multiple views refer to the same in-memory instance of a zone.

The configuration below shows the definition of the ACLs in named.conf

...
acl "internal" {
	192.168.2.0/24;
	192.168.3.0/24;
	192.168.4.0/24;
	192.168.5.0/24;
	localhost;
};

acl "external" {
	any;
};

This exert shows the application of the ACLs as well as the use of the in-view option to enable both ACL groups to have a common view of the zone.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
view "internal-view" {
	match-clients { internal; };

	zone "_acme-challenge.lan.adamgould.com.au" {
	      type master;
	      file "/var/named/_acme-challenge.lan.adamgould.com.au";
	      allow-query { external; };
	      allow-transfer { none; };
	};
view "external-view" {
	match-clients { external; };

	zone "_acme-challenge.lan.adamgould.com.au" {
	      in-view "internal-view";
	};

Configuring the Zone to Allow Updates

The zone has been setup and is accessible to both the internal and external views. We now need to implement a mechanism to enable certbot to be able to update the respective zone.

BIND supports the use of transaction signature (TSIG) which will fulfil this need. TSIG provides a shared secret as a secure means of authentication to allow certbot to make updates to the respective zone.

We can use the tsig-keygen utility to create the required stanza and shared secret as follows.

1
2
3
4
5
6
[adam@bind ]$ tsig-keygen -a hmac-sha512 lets-encrypt

key "lets-encrypt" {
	algorithm hmac-sha512;
	secret "M6B9bkcmC5An8OYIr6XUw9oE393YizFV5bpvemdJ8L5J2sAd6FQgdb8o5a6bTJ2oL1L4zAVRkN9F9rWn5TOjgQ==";
};

Now that we have created the shared secret we now need to create a grant policy in named.conf. The following extract shows the inclusion of the tsig stanza. Note that we have been intentionally restrictive by constraining access to only the _acme-challenge.lan.adamgould.com.au subdomain.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
...
key "lets-encrypt" {
	algorithm hmac-sha512;
	secret "M6B9bkcmC5An8OYIr6XUw9oE393YizFV5bpvemdJ8L5J2sAd6FQgdb8o5a6bTJ2oL1L4zAVRkN9F9rWn5TOjgQ==";
};

zone "_acme-challenge.lan.adamgould.com.au" {
	type master;
	file "/var/named/_acme-challenge.lan.adamgould.com.au";
	allow-query { external; };
	allow-transfer { none; };
	update-policy {
	grant lets-encrypt name _acme-challenge.dmz.adamgould.com.au. txt;
	  };
	};

With that complete all that is left is to configure certbot

Configuring Certbot

The that the following steps are required to be undertaken on the host from which you will be running certbot.

To enable certbot to communicate with BIND we need to install the dns-rfc2136 plugin.

dnf install certbot python3-certbot-dns-rfc2136 -y

With certbot installed we can now create the configuration file we will pass to certbot to communicate with the BIND server. I created a file named certbot-bind-credentials.conf in the /etc/letsencrypt/ directory with the following content.

1
2
3
4
5
dns_rfc2136_server = "192.168.7.8"
dns_rfc2136_port = "53"
dns_rfc2136_name = "lets-encrypt"
dns_rfc2136_secret = "M6B9bkcmC5An8OYIr6XUw9oE393YizFV5bpvemdJ8L5J2sAd6FQgdb8o5a6bTJ2oL1L4zAVRkN9F9rWn5TOjgQ=="
dns_rfc2136_algorithm = "HMAC-SHA512"

Note the highted lines above must match the values used in the TSIG shared secret or certbot error stating that The peer didn't know the key we used

With the above in place we can now use certbot to request the desired certificates

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/certbot-BIND-credentials.conf --preferred-challenges=dns --email=[email protected] --agree-tos -v -d *.lan.adamgould.com.au -d .lan.adamgould.com.au

Background#

BIND Configuration#

Creating the Zone File#

Publishing the Zone#

Configuring the Zone to Allow Updates#

Configuring Certbot#