Netregistry DNS CAA Problem - Renewal Doesn't Work Swapping to Different Registar Fixed Issue

Please fill out the fields below so we can help you better.

My domain is:
phpmyadmin.dmweb.hu
svn.dmweb.hu
websvn.dmweb.hu

I ran this command:
./letsencrypt-auto renew

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log


Processing /etc/letsencrypt/renewal/websvn.dmweb.hu.conf

Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for phpmyadmin.dmweb.hu
tls-sni-01 challenge for svn.dmweb.hu
tls-sni-01 challenge for websvn.dmweb.hu
Waiting for verification…
Cleaning up challenges
Attempting to renew cert from /etc/letsencrypt/renewal/websvn.dmweb.hu.conf produced an unexpected error: Failed authorization procedure. phpmyadmin.dmweb.hu (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu, svn.dmweb.hu (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for svn.dmweb.hu, websvn.dmweb.hu (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: SERVFAIL looking up A for websvn.dmweb.hu. Skipping.

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/websvn.dmweb.hu/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: phpmyadmin.dmweb.hu
    Type: connection
    Detail: DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu

    Domain: svn.dmweb.hu
    Type: connection
    Detail: DNS problem: SERVFAIL looking up A for svn.dmweb.hu

    Domain: websvn.dmweb.hu
    Type: connection
    Detail: DNS problem: SERVFAIL looking up A for websvn.dmweb.hu

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My operating system is (include version):
Debian 7.11, Linux vps2 2.6.32-042stab102.9 #1 SMP Fri Dec 19 20:34:40 MSK 2014 i686 GNU/Linux

My web server is (include version):
apache2 2.2.22-13+deb7u8

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know):
yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The DNS record seems fine for me, I have used the same script for renewing the certs a few times without any errors.
Now I couldn’t renew it since a few days, because of this error.
If anyone have some idea, what could be the problem, let me know.
Thank you!

Hi Myke79,

is this the IP of your Server: 84.21.7.22 ? If yes, your DNS should be fine, if not thats the Problem.
Next thing is, does your webserver accept request for the your subdomains? svn, websvn, phpmyadmin

If yes, can everyone come on that sites or do you have any authentication like .htaccess + .htpasswd, if yes please open it for all, renew certificate and put authentication back.

dig svn.dmweb.hu +short
84.21.7.22

dig websvn.dmweb.hu +short
84.21.7.22

dig phpmyadmin.dmweb.hu +short
84.21.7.22

Hi Sm3rT,

Thanks for your reply, the IP address is correct. All the sites was closed to the public, so I changed them to allow everyone to visit the websites and now loading an empty page on them:

https://websvn.dmweb.hu/
https://phpmyadmin.dmweb.hu/
https://svn.dmweb.hu/

Still no luck with the renew:

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: svn.dmweb.hu
    Type: unknownHost
    Detail: No valid IP addresses found for svn.dmweb.hu

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A record(s) for that domain
    contain(s) the right IP address.

  • The following errors were reported by the server:

    Domain: websvn.dmweb.hu
    Type: connection
    Detail: DNS problem: SERVFAIL looking up A for websvn.dmweb.hu

    Domain: phpmyadmin.dmweb.hu
    Type: connection
    Detail: DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu

Just ran again with --test-cert --dry-run, to avoid ratelimits:

./letsencrypt-auto renew --test-cert --dry-run

Again, DNS problems (only the errors pasted here)

Detail: DNS problem: SERVFAIL looking up A for websvn.dmweb.hu
Detail: DNS problem: SERVFAIL looking up CAA for svn.dmweb.hu
Detail: DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu

And again:
Detail: DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu
Detail: DNS problem: SERVFAIL looking up A for svn.dmweb.hu
Detail: DNS problem: SERVFAIL looking up A for websvn.dmweb.hu

It always stops because of a DNS problem.
I’ve checked the dns zone, and still seems fine, I couldn’t renew my certs because of this.

:frowning:

Some news about this issue:
There was a *.dmweb.hu A record in the zone, and for testing purpose I directly inserted the A records for this three subdomain: phpmyadmin, svn, websvn.
Now the error message changed to:

Detail: DNS problem: SERVFAIL looking up CAA for websvn.dmweb.hu
Detail: DNS problem: SERVFAIL looking up CAA for phpmyadmin.dmweb.hu
Detail: DNS problem: SERVFAIL looking up CAA for svn.dmweb.hu

So the wildcard record somehow affected the process.
I tried to add CAA record also into the zone, but my dns hosting provider’s website has no ability to add a CAA record.
Any idea how should I solve it?

Also find a comment from @jsha states:

Right now, the staging server has a stricter setting for CAA that rejects SERVFAILs for CAA, which is not yet rolled out in prod. Since --dry-run uses staging, that's why you only get the error there

So tries to run now without the --dry-run, and finally my certs are renewed successfully. :slight_smile:

Summarize my issues:
Wildcard subdomains not working properly, and the staging server didn't accept the missing CAA record.
For the wildcard problem, I can live with it, but when this CAA change getting into prod, I will not able to renew my certs again.

I have three domains on my LE cert, and all of them have wildcard subdomain CNAME records (*.domain.tld IN CNAME domain.tld). All work without an issue.

The issue isn't the lack of a CAA record, it's your DNS host's refusal to respond to the query for a CAA record. A response saying "there's no CAA record" is fine. A response saying "what's a CAA record?", or no response at all, isn't. If your DNS host can't answer those queries at all, it's broken.

I already contacted with my DNS provider about this, as it is clearly not an issue of the LE system.
About the wildcard…yup, it was working fine with the same setup for me too, but it looks like my provider changed something recently that may broke some standards.
As you can see my errors above was in the A record, until I inserted them one by one, without the wildcard.

with wildcard:
DNS problem: SERVFAIL looking up A for phpmyadmin.dmweb.hu
without the wildcard:
DNS problem: SERVFAIL looking up CAA for phpmyadmin.dmweb.hu

Could someone provide me the exact query, that LE needs? So I can test by hand, and give them (the DNS provider) to solve the issue.

Thank you guys for helping me, it’s a great community here :slight_smile:

I think CAA may be a red herring here. I get repeated SERVFAILs for both A and CAA lookups for this domain:

dig A phpmyadmin.dmweb.hu @8.8.8.8
dig CAA phpmyadmin.dmweb.hu @8.8.8.8

To me this looks like timeouts or misconfiguration of the nameservers hosting your site.

I first installed Let’s Encrypt certificates about 75 days ago - had no problem used certbot-auto --apache certonly. Time to renew and am not able to renew due to SERVFAIL timeout looking up A. Installed latest certbot still no luck. To the best of my knowledge (and having checked) there has been no change in the server or the DNS settings. Server is Ubuntu 14.04 with Apache and serving Owncloud.

Any assistance which may solve this problem will be greatly appreciated - only got about 15 days till expiry.

Thanks jsha, I will investigate this dns issue :slight_smile:

@prich, can you post your domain name?

Hi jsha,

It is not literally my domain but the address is public.
owncloud.precisevalue.com.au

Peter

@prich

$ dig +short precisevalue.com.au ns
ns2.partnerconsole.net.
ns3.partnerconsole.net.
ns1.partnerconsole.net.
$ dig +short partnerconsole.net ns
ns2.netregistry.net.
ns1.netregistry.net.
ns3.netregistry.net.

Another Netregistry DNS issue?

Hi, Thanks for the help so far. It happens that when I was trying earlier there was a problem with Netregistry DNS (under DDOS attack). They say the system is now back up. AND the problem has changed certbot-auto now reports a timeout with the CAA (no longer the A). Additionally it would appear that Netregistry do not support CAA. Where do I go from here?

Let’s Encrypt is committed to checking CAA for every certificate issuance in order to provide a way for people to indicate whether they do not want Let’s Encrypt to issue certificates for their domains.

If your DNS provider doesn’t support CAA records, you need to switch to another DNS provider or get them to fix it. This is built into the Let’s Encrypt CA and there is no way to turn off the checking (and eventually, other CAs are going to start requiring it too!).

To be explicit, you’re not required to have CAA records. It’s totally fine if your DNS servers say “nope, i don’t have any of those”. It becomes a problem when they return an error, or fail to respond at all.

While it’s not yet common for DNS providers to support CAA records, the underlying DNS server software they use has generally supported CAA for a couple years. Moreover, even older software will usually give a valid response to queries for unrecognized types.

It’s relatively rare for them to fail in a way that interferes with Let’s Encrypt validation.

This might be related to Netregistry’s ongoing issues, but they seem to fall into the “don’t respond at all” camp:

$ digr owncloud.precisevalue.com.au @ns1.partnerconsole.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse owncloud.precisevalue.com.au @ns1.partnerconsole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63485
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;owncloud.precisevalue.com.au.  IN      A

;; ANSWER SECTION:
owncloud.precisevalue.com.au. 3600 IN   CNAME   wilkin.precisevalue.com.au.
wilkin.precisevalue.com.au. 3600 IN     A       203.153.251.216

;; Query time: 187 msec
;; SERVER: 203.55.143.4#53(203.55.143.4)
;; WHEN: Tue Apr 18 06:33:28 UTC 2017
;; MSG SIZE  rcvd: 83

$ digr owncloud.precisevalue.com.au caa @ns1.partnerconsole.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse owncloud.precisevalue.com.au caa @ns1.partnerconsole.net
;; global options: +cmd
;; connection timed out; no servers could be reached

[Last i heard, Let’s Encrypt production was less strict and more forgiving about CAA failures than staging, but that might have been tightened up.]

2 Likes

quick question from the sideline: what is digr? An alias for dig +norecursive?

It's just a shell alias i have for dig +norecurse.

alias digr="dig +norecurse"

(You don't actually need to use +norecurse, but i like to.)

1 Like