CAA override/ignore for new certificates

Hello,

suddently certbot tries to check the CAA entries for generating a certficate.

I also tried to add following line to my nameservers but it also does not work.
domain.com. 3600 IN CAA 0 issue "letsencrypt.org"

Is it possible to disable CAA check?

Thanks.

The only way to avoid CAA checking is to remove the CAA records.

What's the actual error you see?

And please share your actual domain name.

1 Like

I never had an CAA record.

I have the problem with cega-official.at domain.
I also tried https://letsdebug.net/

Failed authorization procedure. cega-official.at (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for cega-official.at - the domain's nameservers may be malfunctioning, www.cega-official.at (http-01): urn:ietf:params:acme:error:dns :: DNS problem: SERVFAIL looking up CAA for www.cega-official.at - the domain's nameservers may be malfunctioning

Your authoritative nameservers are misbehaving. They are not supposed to answer ”SERVFAIL" if you don't have any CAA records.

Did you switch authoritative nameservers?

~ $ dig caa cega-official.at
                                                           ; <<>> DiG 9.16.11 <<>> caa cega-official.at
;; global options: +cmd                                    ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40595
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:                                      ; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;cega-official.at.              IN      CAA

;; Query time: 280 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Mar 14 10:10:23 CET 2022
;; MSG SIZE  rcvd: 45
                                                           ~
1 Like

Yes, it looks like.
It seems that my nameserver software is buggy.

It looks like it doesn't always answer the same way.

This time it correctly answered NOERROR while sending no records.

~ $ for ns in $(dig +short ns cega-official.at); do dig @$ns caa cega-official.at; done

; <<>> DiG 9.16.11 <<>> @ns1.zunter.com. caa cega-official.at
; (1 server found)                                         ;; global options: +cmd
;; Got answer:                                             ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53164
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available          
;; QUESTION SECTION:                                       ;cega-official.at.              IN      CAA
                                                           ;; AUTHORITY SECTION:
cega-official.at.       3600    IN      NS      ns1.zunter.com.
cega-official.at.       3600    IN      NS      ns3.zunter.com.
cega-official.at.       3600    IN      NS      ns2.zunter.com.
                                                           ;; Query time: 110 msec
;; SERVER: 83.64.82.202#53(83.64.82.202)
;; WHEN: Mon Mar 14 10:21:41 CET 2022
;; MSG SIZE  rcvd: 98                                      

; <<>> DiG 9.16.11 <<>> @ns3.zunter.com. caa cega-official.at
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 473
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:                                       ;cega-official.at.              IN      CAA

;; AUTHORITY SECTION:
cega-official.at.       3600    IN      NS      ns1.zunter.com.
cega-official.at.       3600    IN      NS      ns3.zunter.com.
cega-official.at.       3600    IN      NS      ns2.zunter.com.

;; Query time: 63 msec
;; SERVER: 213.47.190.121#53(213.47.190.121)
;; WHEN: Mon Mar 14 10:21:41 CET 2022
;; MSG SIZE  rcvd: 98


; <<>> DiG 9.16.11 <<>> @ns2.zunter.com. caa cega-official.at                                                         ; (1 server found)
;; global options: +cmd                                    ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18228
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cega-official.at.              IN      CAA

;; AUTHORITY SECTION:
cega-official.at.       3600    IN      NS      ns1.zunter.com.
cega-official.at.       3600    IN      NS      ns3.zunter.com.
cega-official.at.       3600    IN      NS      ns2.zunter.com.

;; Query time: 36 msec                                     ;; SERVER: 91.250.98.52#53(91.250.98.52)
;; WHEN: Mon Mar 14 10:21:41 CET 2022                      ;; MSG SIZE  rcvd: 98

1 Like

Strange. Do you have any idea how to solve this that certbot can create a certificate?

You need to solve the issue with your nameservers or switch them with some others.

There are some more issues if you want to use DNSSEC: cega-official.at | DNSViz

2 Likes

Strange.
My authoritive nameservers seems to answer correctly on CAA requests.
But when I try it through google or other non-authoritative nameservers, they return ServerFailure.

Where can this behavior come from?

I don't know. But I notice that your nameservers don't answer on TCP, only on UDP.

1 Like

Yes, I only implemented UDP. TCP is only be used for zone transfers.
All other domains I run, have no problems.

It has always done so, at least the last few years.

Anyway, you should enable DNS using TCP too, as sometimes the UDP packages are just too large or something similar, requiring TCP. Not just for zone transfers.

3 Likes

No it does not. Your nameservers [ns1.zunter.com, ns3.zunter.com, ns2.zunter.com] do not answer authoritatively (flag not set) when asked for a record (apparently) not present in the zone.

When asked for an existing record:

dig A cega-official.at @ns1.zunter.com

; <<>> DiG 9.16.22-Debian <<>> A cega-official.at @ns1.zunter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2885
;; flags: qr **aa** rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cega-official.at.              IN      A

;; ANSWER SECTION:
cega-official.at.       3600    IN      A       91.250.98.52

And when asked for any non-existing record (such as AAAA, or CAA):

dig AAAA cega-official.at @ns1.zunter.com

; <<>> DiG 9.16.22-Debian <<>> AAAA cega-official.at @ns1.zunter.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17710
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cega-official.at.              IN      AAAA

;; AUTHORITY SECTION:
cega-official.at.       3600    IN      NS      ns1.zunter.com.
cega-official.at.       3600    IN      NS      ns3.zunter.com.
cega-official.at.       3600    IN      NS      ns2.zunter.com.

Notice the missing AA (Authoritative Answer) flag. Resolvers treat this as if you weren't hosting the zone* (dig seems to report this as BAD (HORIZONTAL) REFERRAL when using +trace) and therefore won't use your answer.

There are additional weirdnesses/bad configurations going on (such as the namservers not supporting EDNS), but above is probably the major issue right now.

*The non-existent response matches what you would expect if you wanted to refer to another nameserver (authority section mentioning who's authoritative, but we're already talking to the nameservers we're getting referred to....)

4 Likes

Thanks.

I know, EDNS is not supported by my namerservers.

But for some other domains it works correctly. Only for this domain and one more I do not get authoritative answers.
Do you think that it comes from that Google still delivers cached information?
Otherwise my nameserver is buggy (but I do not understand why it works for other domains).
In meantime I tried to enable TCP, but this does not solve the issue.

1 Like

No, it's not a caching issue. Let's Encrypt always queries the authoritative nameservers directly.

The validator bots probably get very, very confused when they cannot see an AA flag anywhere.

3 Likes

Ok thanks, then the nameserver seems to be buggy. :frowning:

2 Likes

WTF, I solved it. :slight_smile:

Because this thread was unnecessary, is it possible to delete the whole thread?

There are other (required) reasons to use TCP.

How?

3 Likes

There was a stupid issue in the source code.

Because this thread was unnecessary, is it possible to delete the whole thread?

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