CNAME config and rfc2136 authenticator config

Server
1

The dns rfc2136 authenticator sends a jnl file - but does not commit it to the zone - then the entire thing fails on a TXT record not found, however I am trying to use a CNAME setup as shown at Renew using dns-01 challenge

I posted at https://github.com/certbot/certbot/issues/6322 and have nsupdate working - but the certbot and / or dns rfc2136 authenticator does not write the jnl file to the zone

I do not see how it would work without committing the TXT files to the zone file.

The dns rfc2136 authenticator appears to need a standalone zone file as a SOA which is called _acme-challenge.xxxx.tld

At https://community.letsencrypt.org/t/how-to-do-this-for-dns-01-challenge/70813/4 https://community.letsencrypt.org/u/sahsanu says someone else here has this working and suggested I make a new post

2

It does not. I have a normal zone file, perfectly augmented with a TXT record by the RFC 2136 certbot plugin.

Also, I don't think the RFC 2136 authenticator itself sends a specific file. A jnl file is, as far as I know, just a journal file used by bind.

Perhaps you could post more information about how you're configuration is set and what you're doing and how it fails?

1 Like
3

nsupdate creates a jnl file and the dns rfc2136 authenticator uses nsupdate according to sydneyli at github.

It does not comitt to the zone so the TXT entries never happen into the zone. I can using a terminal window flush the waiting jnl file while certbot is waiting for propagation

I am running my own nameserver with glue records to public ips and using Google public servers 8.8.8.8 and 8.8.4.4 as resolvers in the /etc/resolv.conf file. This is Centos7 on an Open VZ platform with BIND 9.9.4. The link in the OP ( https://github.com/certbot/certbot/issues/6322 ) shows the config and more details on what is going wrong

If I do not use a separate zone file I get a “no SOA response” error and it replaces all my subdomain setups (subdomain.mydomain.com) in the zone file with $ORIGIN - and in essence trashes the zone file

4

Hi @unioncos! Continuing the thread from https://github.com/certbot/certbot/issues/6322 here. If we can narrow down the issue here, we can file a more specific ticket and get a fix in for the problem!

I still suspect this could be a DNS configuration issue. BIND’s .jnl files shouldn’t have to be flushed after every update, since BIND definitely uses the journal to scan for updates.

I’d be happy to continue helping debug-- would you be willing to email me (sydney@eff.org) what domain you’re trying to validate? There is also a PGP key on my staff page if you would like.

5

As I said - it works ONLY if I flush the jnl file and restart BIND before the 60 second propagation period ends

A simple " rndc sync " will update the zone file and a " rndc sync -clean " updates and deletes the jnl file - and both work - so I have not looked at the code for the authenticator but I cannot see how it is a config issue - it works if I do

nsupdate -k ddns-key.txt -v update_dns1.txt

where those files have the line commands needed

The only issue I can try is to run BIND as user named and group named and not user root and group named as it currently runs

6

Running daemons as root is a bad idea anyway.

7

My mistake - it is running as named - however the owner is root for the /var/named and /etc/named directory

Of course a simple restart of BIND during the 60 second propagation period also works and the dry-run is successful - but I cannot do that when cron calls the renew

HOWEVER, it still leaves the TXT challenge itself in the zone file AND a jnl file in /var/named that will clean the challenge and jnl file if I do a " rndc sync -clean "

Thus the problem appears is first actually placing the challenge in the zone file and then second requiring a restart to "push" the propagation upstream to the Google public nameserver it seems

I still cannot see how this is not a bug in the dns rfc2136 authenticator code - it seems it should do this

I suppose I could use certbot manual mode and shell scripts that restart BIND - does anyone have this working for the dns-01 challenge using BIND ??

8

I still cannot understand why your bind does things with journal files and has this troubles et cetera, while my bind configuration works perfectly with the RFC2136 authenticator in certbot.

What is your zone file configuration in named.conf?

9

The /etc/named.conf is correct, it was apparently the GROUP WRITE permission on the zone file.

I changed the permission on the zone file to include GROUP WRITE permission and it is now working for dry-run, but still leaves the jnl file behind growing.

The zone file I use is a separate " _acme-challenge.xxxxxxx.com " file and it is its own SOA zone file for xxxxxxx.com which in its zone file has;

_acme-challenge.xxxxxxx.com. 14400 IN CNAME xxxxxxx.com.

If I use the xxxxxxx.com zone file directly the dns_rfc2136 authenticator program trashes the zone file by changing all subdomains to $ORIGIN

I will write a cron job to do a " rndc sync -clean " on a 3 or 4 month schedule

Where do I put the certbot certonly command so certbot renew will use it or do I have to create a separate cron job for certbot certonly ??

10

certbot renew renews that certificates that you previously obtained with certbot certonly. If you specified hook scripts, certbot renew will use those during the renewal too.

11

@unioncos Can you pastebin everything? In particular, your zone files, BIND configuration, Certbot logs, and BIND logs. Without changing or redacting things (except for secret key values, if those get logged).

I don't know how to debug BIND or dynamic updates, but I think more information is needed for anyone to be able to figure out what's going on.

Random theory:

Could a CNAME record to something with an SOA record confuse _query_soa's search for the right zone cut?

12

I got the first wildcard cert manually by editing the zone file with the challenge TXT's sent as certbot waited using certonly and not the dns rfc2136 authenticator - so my guess is it won't work and will fail because it is a manual mode without shell or hook scripts as shown in the conf file excerpt below

Now that I have the rfc2136 authenticator working the command I got it working with was / is

certbot certonly --dry-run --dns-rfc2136 --dns-rfc2136-credentials /path to/credentials.ini -d "*.xxxxxxx.com" -d xxxxxxx.com --server https://acme-v02.api.letsencrypt.org/directory

so I can remove the --dry-run option switch and it will work

The xxxxxxx.com /etc/letsencrypt/renewal/xxxxxxx.com.conf file looks like this

Options used in the renewal process

[renewalparams]
account = xxxxxxxxxxxxxxxxxxxxxxxxx
manual_public_ip_logging_ok = True
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = manual
installer = apache
pref_challs = dns-01,

So how do I put those command line switches in to edit those parameters ??

I have read How to regenerate renewal config file? and Check renew configuration

So I no longer need the installer and manual is now dns-rfc2136

The links above do not show an answer and in fact there is an issue to provide a command line feature to modify the conf file but no solution I have found

I tried running a --force-renewal instead of the --dry-run command switch but it started the manual process again so I cancelled it

So . . . will this work below ??

[renewalparams]
account = xxxxxxxxxxxxxxxxxxxxxxxxx
manual_public_ip_logging_ok = True
server = https://acme-v02.api.letsencrypt.org/directory
authenticator = dns-rfc2136 --dns-rfc2136-credentials /path to/credentials.ini
pref_challs = dns-01,

Or how is is edited to now use the rfc2136 authenticator with the path to credential switch and wildcard option if needed

13

As I said - it is working now and the issue was a GROUP WRITE permission needed on the zone file

HOWEVER, it still does not work unless I restart BIND while the propagation is waiting

nsupdate setup also commonly called "dynamic updates" as a feature of BIND does not gracefully tell on itself if it is not working.

The page at Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation does not give any clues on the fact both nsupdate and dnspython are needed for the certbot-dns-rfc2136 authenticator to work

A journal file ( .jnl ) by the same name of the zone with a .jnl extention will be delivered to the directory and it contains the update - in this case the TXT challenges

BUT

if there are no write permissions for the GROUP (usually named or bind ) to the zone file - it will just leave it there and the rfc2136 authenticator will just keep going eventually to a "no TXT Record found" fail because the zone file never got written the challenge TXT's

A restart of BIND or a " rndc sync -clean " will flush the waiting journal file changes to the zone file and propagate them out at the same time ONLY if BIND is restarted if doing the rndc sysc -clean command, and if this is done while certbot is waiting - the rfc2136 authenticator actually - is waiting its default 60 second wait then a DIG will show the TXT challenges delivered to the zone.

It should be noted that no log at least on my system showed the .jnl file waiting - or not able to deliver the TXT challenges into the zone file itself.

The letsencrypt log was on little help as to WHY it was writing the challenges and then finding no challenges

It should also be noted that the BIND directory itself - in my case - /var/named - needed the group write permission also and I actually changed them to 770 with execute before NSUPDATE itself would work to even deliver the .jnl file

Once the .jnl file showed up, adding the GROUP WRITE permission to the ZONE file allowed the rfc2136 authenticator to write to the ZONE file and the DIG showed the TXT challenges while the 60 second propagate was waiting and then it worked

The CNAME set up was from as shown at Renew using dns-01 challenge and it apparently is working as a cert is delivered in the dry-run even though the zone file bing used is not the zone for the domain of the cert and is a different one from the domain the cert is obtained as called for - hence the need for the CNAME in that zone file the cert is being issued for.

Someone should modify the documentation page at Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation to warn and advise of these permissions road block issues

Two pages at Agile Testing: Dynamic DNS updates with nsupdate (new and improved!) and Agile Testing: Dynamic DNS updates with nsupdate and BIND 9 helped me make sure nsupdate was actually working even though for Ubuntu - however the permissions issue did not present itself because I was running that testing as root and it always worked whereas the rfc2136 authenticator was running as user named and needed the group named to have write permission on the file

HOWEVER, it still does not work unless I restart BIND while the propagation is waiting

The documentation should warn of how this dns rfc2136 authenticator works

14

I think we need more conformation of other uses if this actually is a bug in the authenticator with every user or just you before we start adding warnings and how-to's to the documentation.

15

See post CNAME config and rfc2136 authenticator config as she is who stated that is how the rfc2136 authenticator works and you will find it at the github link

It is not a bug so much as it is and important configuration issue not revealed

16

The system will not accept an edit of post 11

I did a --force-renewal in place of --dry-run and it edited the The xxxxxxx.com /etc/letsencrypt/renewal/xxxxxxx.com.conf file for me.

I got the first wildcard cert manually by editing the zone file with the challenge TXT's sent as certbot waited using certonly and not the dns rfc2136 authenticator

HOWEVER

I still have to RESTART BIND while the propagation is waiting or it sees only ONE TXT challenges and uses it twice to fail

AND

then the zone file group write permission is erased

17

A final "GO FIGURE"

If I move the zone file to /var/named/dynamic, and edit the named.conf path also for the file, restart and do a certonly dry-run, I cannot see the TXT challenges in a DIG, the .jnl file appears and does not appear to write to the zone file, that is I cannot see the TXT entries; and I get a " dry-run successful " response, and the .jnl still remains not cleaned - but it appears to work.

It strips the group write permission from the file and STILL appears to work - I got this appearance to work and when I ran the forced renewal it did not work and instead read the same first TXT challenge twice and failed - until I did a restart of BIND while the 60 second propagation was waiting

Since I have certbot renew configured as a cron job, and the renewal domain.conf file now properly configured for the rfc2136 authenticator, I am going to leave it and see if it truly is working when it comes time to try to automatically renew it in 2 months

Running the forced renewal auto edited the /etc/letsencrypt/renewal/xxxxxxx.com.conf file to change it and add

authenticator = dns-rfc2136
dns_rfc2136_credentials = /path to/credentials.ini

Apparently CentOS 7 is out of the box set up for dynamic updates with nsupdate using the /var/named/dynamic directory and that is where the zone file should be placed

1 Like
18

For those who find their way here from trying to get the rfc2136 authenticator working for a wildcard certificate here is what sydney ( sydneyli ) wrote a few days after the above solution was made

“” Although nsupdate is useful for testing that your DDNS is set up correctly, the authenticator does not depend on it being installed to work properly. dnspython is explicitly listed as a dependency, and should be pulled automatically, via whatever installation method you chose for the Certbot plugin.

. . .

Just to be clear, Certbot’s RFC2136 authenticator does not directly touch your zone files; it follows RFC2136’s client API (just as nsupdate does) to tell a RFC2136-compatible DNS server to perform the proper updates. I also don’t think information on how to properly set up Dynamic DNS for BIND for a particular operating system belongs in Certbot’s documentation!""

So the issue is not setup information for Dynamic DNS so much as knowing what you have got in your BIND nameserver config out of the box. (also known as “named” in many distributions ) Simple troubleshooting info would be helpful on the documentation page though.

SINCE Certbot’s RFC2136 authenticator does not directly touch your zone files; it follows RFC2136’s client API to tell a RFC2136-compatible DNS server to perform the proper update. It requires a properly configured Dynamic Domain Nameserver (DDNS) to function properly. Many servers today run a variant of the Linux operating system which runs BIND as a nameserver.

However only a few come configured as DDNS systems and you may need to configure whatever version of BIND you are running to do “dynamic updates”. A good way to do this is to configure your name server to allow nsupdate to work properly. How you do that is beyond the scope of this page, however many RedHat based Linux distributions will have a /var/named/dynamic directory indicating it is already configured to be a DDNS. ( CentOS, Fedora, Mageia, RHEL ) Others have it in /var/lib/named/var/named/dynamic/ If you do an internet search for " /var/named/dynamic directory " you will find leaders to how to use that out of the box feature. If you have an another non RedHat based distribution then you will have to make sure nsupdate is set up and working to indicate the server can accept dynamic updates. One key issue is the zone file and directory will need to have a GROUP WRITE permission usually.

Since Certbot’s RFC2136 authenticator does not directly touch your zone files, it uses instead “DNSPYTHON” in conjunction with its coding which is written in Python to make the DNS challenges, and this is why nsupdate needs to be working as both use the RFC2136’s client API to tell a RFC2136-compatible DNS server to perform the proper update

It is recommended that you run dry-runs with the command=> certbot certonly --dry-run --dns-rfc2136 --dns-rfc2136-credentials /path to/credentials.ini -d “*.yourdomain.com” -d yourdomain.com --server https://acme-v02.api.letsencrypt.org/directory . . . . from a terminal window as root preferably . . .

which will log the run and report any errors for you and allow you to get Certbot’s RFC2136 authenticator working

when the dry-run returns successful, then remove the --dry-run or use a --force-renewal in its place that will modify the configuration files so a certbot renew can use the same successful run to renew the certificate when the time comes to do so

So . . . although nsupdate is useful for testing that your DDNS is set up correctly, the authenticator does not depend on it being installed to work properly. dnspython is explicitly Certbot’s RFC2136 authenticator dependency, and should be pulled automatically, via whatever installation method you chose for the Certbot plugin as for say an install via YUM will do. Since dnspython is difficult to troubleshoot directly — then if nsupdate is working - often Certbot’s RFC2136 authenticator will then work properly too

Dynamic Update uses a .jnl file extension of the same name as the zone which may or may not get written to the zone file, and then Certbot’s RFC2136 authenticator cleans up the challenge by removing the same TXT challenge it wrote or sent into the .jnl file

Certbot’s RFC2136 authenticator by default will wait 60 seconds for a propagation of the TXT challenge to complete and during this period you should or might be able to do a " DIG your domain TXT " to see the challenge strings waiting. If not, they are not likely propagating, however with the RedHat based Linux distributions and use of the /var/named/dynamic directory, you actually may not see the DIG work and the dry-run may still complete because of how the RedHat based Linux distributions DDNS is configured to also read the .jnl file. in the /var/named/dynamic directory

If there are not propagating a restart of BIND while the propagation is waiting will flush the TXT to the zone file and force a propagation and then it may work signalling and telling you that there is likely a permissions issue somewhere

Also the .jnl file may be left behind and has on occasion been know to prevent updates so a " rndc sync -clean " will also flush the jnl updates to the zone file and remove the jnl file itself afterwards

If these two things above do not work then usually the DNS or DDNS configuration or key setup is incorrect

Do Internet searches for how to configure your specific Linux distribution, and be sure it is for your Linux distribution or which ever OS you have. Setting up a working DDNS is different for each one

1 Like
20

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.