DNS problem: SERVFAIL looking up CAA (solved)

Help
1

Hi all,

I’m having troubles renewing a bunch of certificates (subdomains of test.nexoya.io) due to a challenge error.
I am able to renew certificates for other domains.

My domain is:
graphql.test.nexoya.io

I ran this command:
I’m using the V1 REST API

It produced this output:
Renewal fails due to a http-01 challenge error: “DNS problem: SERVFAIL looking up CAA for test.nexoya.io”

What is the typical reason for the API to throw such an error?

Thanks,
Marius

2 Likes
2

In this case, it’s because your DNS service is not working correctly.

$ dig +dnssec +norecurse @dns2.registrar-servers.com test.nexoya.io

; <<>> DiG 9.15.7-Ubuntu <<>> +dnssec +norecurse @dns2.registrar-servers.com test.nexoya.io
; (2 servers found) 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41617
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;test.nexoya.io.                        IN      A

;; AUTHORITY SECTION:
nexoya.io.              3601    IN      SOA     dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1577071590 3600 1801 604800 3601
nexoya.io.              3601    IN      RRSIG   SOA 13 2 3601 20200102000000 20191212000000 15848 nexoya.io. FOVEHT6JV+iw3OECbwr1P0b9PxX9UrmBSU+RXQPmOMqq65U/nJKVQ3uu iugbk2rVRPmuk6dph1uze+apMjAuIw==

;; Query time: 0 msec
;; SERVER: 2610:a1:1025::200#53(2610:a1:1025::200)
;; WHEN: Fri Dec 27 09:42:43 UTC 2019
;; MSG SIZE  rcvd: 221

Because the zone uses DNSSEC, the response has to include some additional records proving that the name and type at issue don’t exist. It does not.

You might be able to work around the bug by creating some kind of DNS records named test.nexoya.io. It could be CAA records (which would have to be correct, of course), or an A record, or a TXT record with a sad face emoticon. Just something. That might inspire the DNS service to behave correctly.

Edit:

Namecheap outsources their DNS servers to a company called Neustar. Intriguingly, this same issue was reported recently regarding another Neustar customer, PayPal.

https://lists.dns-oarc.net/pipermail/dns-operations/2019-December/019514.html

(paypal.com uses two different DNS services – Neustar and a competitor – and the other one works correctly.)

It seems likely that there’s some kind of bug in Neustar’s platform.

Edit:

…It goes without saying that you could also switch to a different DNS service, or ask Namecheap to fix it.

Turning off DNSSEC, if you can do so, would also avoid the issue.

2 Likes
3

Thanks for your feedback @mnordhoff

Does it make sense that an authorization request for “graphql.test.nexoya.io” results in an error for “test.nexoya.io”?

By the way, your dig request for graphql.test.nexoya.io yields results back.

2 Likes
4

CAs will check for CAA records from left to right until they find some. So if graphql.test.nexoya.io doesn't have any CAA records, Let's Encrypt will check for test.nexoya.io, then if necessary nexoya.io and even io.

Thank you for reminding me!

You can also work around this issue by creating CAA records for graphql.test.nexoya.io that don't stop Let's Encrypt from issuing. Then Let's Encrypt won't care if a CAA query for test.nexoya.io is broken or not.

However, your DNS service still needs to be fixed. Even if Let's Encrypt doesn't mind, some resolvers will.

2 Likes
5

The DNS records were updated as per your suggestions and the renewal went through fine.
Thank you for your support - stellar as usual :+1:

6

FYI, Neustar has responded:

https://lists.dns-oarc.net/pipermail/dns-operations/2019-December/019555.html

UltraDNS has identified an issue with NSEC signed zones with empty-non-terminals. We are working to correct this behavior and plan to have a fix deployed shortly after the new year.

7

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