Certbot rfc2136 authenticator and bind's views

[unioncos]

see Dns-01 challenge - something has changed

The rfc2136 authenticator may not work in a multi-view setup of bind as after bind 9.10 bind has changed views. no longer can the internal and external views both use the same dynamic directory zone file

The solution was found at https://serverfault.com/questions/764619/bind-9-10-in-view-directive-doesnt-work

The solution looks like this in the named.conf

view “internal” {

zone example.com {
    type slave;
    file "slaves/example.db";
    masters { 192.168.1.1; };
};

};

view “external” {

zone example.com {
    in-view "internal";
};

};

[joohoi]

Thanks for opening the thread. Your analysis are pretty much right, however the rfc-2136 plugin does work for multi horizon setup (as your example above points out).

The Certbot plugin indeed interacts with the Bind using DNS UPDATE as its name suggests.

When communicating with the DNS server, it tries to update the zone that’s configured in the DNS server software. In case of multi horizon setup, this view may be internal or external, or anything in between (as there’s no hard limits how many different facets the DNS server might have).

If we assume that the server has been configured to serve different results for internal view, and different ones for exrternal view, the Certbot plugin (or nsupdate in that matter) tries to modify the zone in the view of the source address. In the typical case this might be the internal view. The issue arises if the internal view is modified (or doesn’t have the TSIG key configuration in place) and Let’s Encrypt tries to retrieve the validation token from another view (in our case, it would probably be the external) which of course doesn’t have this modification.

The configuration snippet posted above as an example adheres to multi horizon setup scheme, but in fact provides just the default single horizon functionality, as the served zone is exactly the same for both views.

All in all, this is not a bug in Certbot plugin, but merely a technical limitation of multi horizon setup in BIND.

[unioncos]

It should also be noted that as shown in the example - the internal zone can and should be any working zone setup, it is not limited to be a slave and can be any setup following the docs at https://certbot-dns-rfc2136.readthedocs.io/en/latest/

zone example.com {
type “any working setup”;
file “var/named/dynamic/example.db”;
};

var/named/dynamic/example.db is the example for a Centos 7 dynamic DNS setup out of the box and usually that can be - and usually is - the managed keys directory also - on Centos 7 and the key can and probably should be put there also. It may be slightly different on other Linux Distributions

The RFC2136 DNS authenticator may report “the peer does not know the key we used”, or it may report it “cannot find the base domain” in the log both of which will result in a failure of cert update or delivery

In a working example, NSUPDATE will appear to work - just simply will not actually do the update . . . and it may report a “TSIG error”

Finally it should be noted the example from the serverfault site was initially a bug that was fixed and no longer exists in BIND 9.11

Finally, when BIND is setup as a SOA DNS using forwarder servers like Google’s public DNS servers you may still need to use a propagation delay and restart the local DNS (named) on Centos 7 so the changes are flushed into the zone file and propagated out tot he forwarder DNS so the text files are seen when the RFC2136 authenticator comes back to look at the end of the propagation delay period

This can be seen via a DIG command for the TXT files during the propagation period wait. Centos 7’s version of BIND comes set up as a Dynamic DNS, but a timing delay may still cause the RFC2136 DNS authenticator to fail if not manually flushed to the zone file during a prorogation delay period and BIND (named) restarted before thee period is up…

A “rndc sync” command will flush the changes to the zone file, and the restart of named will propagate it to the forwarder DNS for view via DIG and the RFC2136 authenticator to discover and see

If you are using any other DNS provider with an API - or are using Google’s Cloud Service this above may not be necessary

A script can be written to automate this and set up to run via cron using tmux. See also https://unix.stackexchange.com/questions/387666/run-commands-in-tmux-from-terminal