Problems with certbot dns challenge - Unable to determine base domain


I’m trying to implement certbot dns-rfc2136 challenge, using a locally owned bind 9 name server.

on web server I have latest certbot 0.22.0. At first it did not recognize the dns-rfc2136 plugin so I had to install the plugin using pip.

On bind name server side I did the following:

Generated a key using:

dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST test.

In the zone config I have:

key “test.” {
algorithm hmac-sha512;
secret “4q4wM/2I180UXoMyN4INVhJNi8V9BCV+jMw2mXgZw/CSuxUT8C7NKKFs AmKd7ak51vWKgSl12ib86oQRPkpDjg==”;
zone “” {
type master;
file “data/external/”;
update-policy {
grant test. name txt;

On the web server I have a credentials.ini file with the following:

Target DNS server
dns_rfc2136_server = 192.168.0.X
TSIG key name
dns_rfc2136_name = test.
TSIG key secret
dns_rfc2136_secret = mg//w2H916hJtdycSZs27MT6gh7GQt3FR9JFAHwX/J7l7KJ0zFCsgGm5 5Ahu/+3CG+bsryv/C1OrwpsQzJjAQw==
TSIG key algorithm
dns_rfc2136_algorithm = HMAC-SHA512

Running certbot with the following command:

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /root/credentials.ini -d

results in this error:

PluginError: Unable to determine base domain for using names: [u’’, u’com’].
Unable to determine base domain for using names: [u’’, u’com’].

I don’t think it’s getting as far as even reaching out to the DNS server, the problem appears to be on the web server end.


@schoen can you see what’s going on?


I think I see an error in your update Policy:

update-policy {
grant key “test.” txt;

Secondly, is the actual domain or did you edit the configuration before posting here?


I’m basically following the docs at

It shows:

update-policy {
grant keyname. name txt;

Which is what I used originally and named restarts fine using it. If I switch to syntax you gave named fails to start.

I’m using an actual domain name that I control, simply replaced it with for privacy reasons. Thanks!


According to the code of the plugin, it’s looking for an authoritative SOA record for on the nameserver and not finding one. That suggests that this nameserver doesn’t claim to be authoritative for that domain.


That’s something to go on but not sure if it’s correct or not. The name server I’m using is the SOA for the domain I’m working with and external SOA tests verify that it is indeed the SOA for this domain


If you tell me the domain name, I can try to investigate.


After a bunch of digging around I thought I found the problem. I took certbot out of the equation and started testing with nsupdate directly and noticed it was having a key/auth problem updating the domain. This was because of having a split config in bind (internal and external). Since I was doing nsupdate from a local web server I was hitting the internal view and it was never seeing the key info for the external domain I was trying to update. After some fiddling with that I am able to properly update the zone using nsupdate w/ the key etc. and I thought that would fix the certbot issue but still facing the exact same problem.

I’m starting to wonder if the key config in bind has any bearing at all on this problem. I tested by putting fake info in the credentials file and it doesn’t even tell me there is an auth problem, it just dumps out the “PluginError: Unable to determine base domain for using names: [u’’, u’com’].
Unable to determine base domain for using names: [u’’, u’com’].” error. It seems to be making this determination before reaching out to the name server with the auth credentials?

From the same web server I can determine the SOA for the domain doing simple host/nslookup commands. If I throw some other domain in there like I basically get the same error:

certbot certonly --dns-rfc2136 --dns-rfc2136-credentials ./credentials.ini -d
PluginError: Unable to determine base domain for using names: [u’’, u’org’].
Unable to determine base domain for using names: [u’’, u’org’].

I wonder if it’s using resolvers on web server to determine the SOA or if it’s using name server info configured in credentials file to lookup against? Even if I switch resolver to use google public DNS the error remains.

I’m really not sure why the python script is having problems figuring out what the SOA is yet.


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