PluginError: Unable to determine base domain for domain.com using names: [u'domain.com', u'com'].
Unable to determine base domain for domain.com using names: [u'domain.com', 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.
According to the code of the plugin, it’s looking for an authoritative SOA record for domain.com 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
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 domain.com using names: [u’domain.com’, u’com’].
Unable to determine base domain for domain.com using names: [u’domain.com’, 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 letsencrypt.org I basically get the same error:
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.