Problem with CAA records

Help
1

Hi there, I have a problem with creating a certificate.
I use mailcow which automatically should create a certificate for my domains that I host there and I am also using my own DNS service (don't ask why ^^)

Before moving over some other domains it worked perfectly fine but now I am getting this error when scanning for CAA records:

{'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: Rechecking CAA for "miggi.email" and 7 more identifiers failed. Refer to sub-problems for more information', 'status': 403, 'subproblems': [{'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for miggi.email: DNS problem: server failure at resolver looking up CAA for miggi.email', 'status': 403, 'identifier': {'type': 'dns', 'value': 'miggi.email'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autodiscover.damota.de: DNS problem: server failure at resolver looking up CAA for autodiscover.damota.de', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autodiscover.damota.de'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autoconfig.miggi-dns.com: DNS problem: server failure at resolver looking up CAA for autoconfig.miggi-dns.com', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autoconfig.miggi-dns.com'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autodiscover.miggi-dns.com: DNS problem: server failure at resolver looking up CAA for autodiscover.miggi-dns.com', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autodiscover.miggi-dns.com'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autoconfig.migueldamota.com: DNS problem: server failure at resolver looking up CAA for autoconfig.migueldamota.com', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autoconfig.migueldamota.com'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autodiscover.miggi.cloud: DNS problem: server failure at resolver looking up CAA for autodiscover.miggi.cloud', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autodiscover.miggi.cloud'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for autoconfig.damota.de: DNS problem: server failure at resolver looking up CAA for autoconfig.damota.de', 'status': 403, 'identifier': {'type': 'dns', 'value': 'autoconfig.damota.de'}}, {'type': 'urn:ietf:params:acme:error:caa', 'detail': 'Error finalizing order :: rechecking caa: During secondary validation: While processing CAA for mail.damota.de: DNS problem: server failure at resolver looking up CAA for mail.damota.de', 'status': 403, 'identifier': {'type': 'dns', 'value': 'mail.damota.de'}}]}

I hope someone could help me and how I can get around this. Firstly, I haven't got any CAA records but then I added 0 issue "letsencrypt.org" and it is still not working.

2

Well, this is probably the key to things, so we're going to have to ask some questions, even if not "why". What's the DNS software that you're using? It doesn't look to echo the case of the query in its responses, which is not necessarily a problem but isn't very common and might be contributing to issues. I don't have time now to dig in further than that right now, but look at DNSViz and Unboundtest for some tools to help identify what weirdness your DNS server is or isn't replying with.

3 Likes
3

Hi @petercooperjr. Thanks for your quick response.

When I use dig CAA miggi-dns.com or some base domain, the response is correct. Is there a way to have more debugging output like what is the response or something similar?

4

Also when I use tools like this https://www.entrust.com/resources/tools/caa-lookup it is also returning the correct response

5

And the DNS service is a custom one, I programmed it myself. And as I already said, it was working before adding those other domains.

6

The DNSViz site warned about the case of the returned info from your auth DNS servers. I don't have that much time right now either but I agree with @petercooperjr that this can cause problems.

For example:

# Note lower-case response to mixed case query (using your auth DNS server)

dig A MIGGI.email @ns1.miggi-dns.com
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> A MIGGI.email @ns1.miggi-dns.com

;; QUESTION SECTION:
;miggi.email.                   IN      A
;; ANSWER SECTION:
miggi.email.            3600    IN      A       152.53.118.158


# Compare to this (using an auth DNS server for this domain)

 dig A LETSENCRYPT.org @vera.ns.cloudflare.com
; <<>> DiG 9.18.30-0ubuntu0.22.04.2-Ubuntu <<>> A LETSENCRYPT.org @vera.ns.cloudflare.com

;; QUESTION SECTION:
;LETSENCRYPT.org.               IN      A
;; ANSWER SECTION:
LETSENCRYPT.org.        113     IN      A       100.28.201.155
LETSENCRYPT.org.        113     IN      A       34.234.106.80
2 Likes
7

Ah I see, that makes sense. I'll have a look at it. Thanks for now!

2 Likes
8

Implementing DNS is a lot more complicated than one would expect at first. There are many aspects to ensure that you are not just giving success responses right, but giving correct "not-found" responses. (You don't need a CAA record, but you need to return a successful response that you don't have one if that's the case.) And then there are things like the case-echoing, which is often expected but not really in an RFC.

In addition to looking at Unboundtest, you might want to look at the ISC EDNS Compliance Checker, which tests some common DNS server issues. (Though I don't have the detailed knowledge of what all the tests are actually checking for.)

5 Likes
9

Really old thread reply by dev about this case sensitive behavior

3 Likes
10

That's exactly what I also tried, having no CAA records but it still didn't work and I got the same error as above

11

I think something might be wrong with our secondary DNS resolvers. Investigating

4 Likes
12

We've found an issue where a percentage of DNS queries in our secondary DNS resolvers were failing, which has been mitigated. Thanks for pointing this out.

5 Likes
13

Thank you! It is working now

14

DNS is case insensitive so it doesn’t care about if you write it like letsencrypt.org or LetSENCtyPt.OrG. At least they should all point to the same record when querying for the same type

15

Yes, queries should be case-insensitive. Echoing the requested case in the response can help mitigate certain attacks, since an attacker can't just spam replies in lowercase but needs to also intercept what case the query was in. See the DNS 0x20 Draft. The resolver that Let's Encrypt uses (Unbound, with the use-caps-for-id options set) tries to figure out that an authoritative server doesn't echo the case and work around it (like many recursive resolvers do nowadays; see Google's for another example), but in general echoing the case back in the response should help make things easier on systems trying to resolve your name.

4 Likes
16

Preserving the case of the DNS request in the response is REQUIRED by DNS standards:

While ASCII label comparisons are case insensitive, [STD13] says case
MUST be preserved on output

A nameserver that does not preserve case is not standards compliant.

4 Likes
17

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