DNS problem: query timed out looking up CAA for sr

Help
1

Hi,

we want to validate schule.sr with DNS, but getting this error: "DNS problem: query timed out looking up CAA for sr"
This is curious, because everything looks fine to us. We couldn’t find any DNS problems.

What did we miss?

2

(Edit: As noted at the end of this post, i was looking at things a little wrong, but i’m essentially correct.)

Okay… I think the problem is that your domain’s nameservers are fine, but the TLD’s are not!

The .sr nameservers fail to respond to CAA queries, impairing CAA DNS lookups for any .sr domain when the resolver doesn’t already have the domain’s delegation cached.

$ dig +short sr ns
ns1.sr.net.
ns2.sr.net.
$ dig +norecurse schule.sr caa @ns1.sr.net.

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse schule.sr caa @ns1.sr.net.
;; global options: +cmd
;; connection timed out; no servers could be reached
$ dig +norecurse schule.sr caa @ns2.sr.net

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse schule.sr caa @ns2.sr.net
;; global options: +cmd
;; connection timed out; no servers could be reached

This is bad.

A resolver can work around it by making a non-CAA query first (e.g. A or NS) to query the .sr nameservers with something they handle correctly, but…

This might be the first time in history QNAME minimisation would solve an interoperability problem. :stuck_out_tongue_closed_eyes:

https://crt.sh/?Identity=%.sr&iCAID=16418

https://unboundtest.com/m/CAA/schule.sr/SLJTANE4
https://unboundtest.com/m/CAA/schule.sr/AZGYAKQC
https://unboundtest.com/m/CAA/schule.sr/GSZHT2M7

@cpu @jsha @roland The .sr ccTLD has broken CAA. Yes really. (AFAICT.) This is bad.

I wrote the post, but then i did “dig +norecurse example.sr @ns1.sr.net” and it took a few retries to work. They may have additional problems. But i haven’t been able to produce any CAA success or reproduce an A failure.

By the way there are no .sr domains on the CAA SERVFAIL lists posted earlier.

Edit: I wrote the above assuming that Boulder didn’t actually do the equivalent of “dig sr caa” – i assumed it stopped at the domain and didn’t check the TLD – but i guess i was wrong.

I assumed it was failing due to the iterative DNS resolution process, which can be worked around.

Anyway, “dig sr caa” is easier to test and naturally also times out.

This is bad.

By the way, CAs can whitelist .sr past September 7. The failure is outside the CA’s infrastructure, the lookup can be retried at least once, and the TLD does not use DNSSEC. Patching Boulder to implement auditor- and BR-compliant whitelisting is an exercise left to [runs away].

Anyone want to try to contact August Imang or Henry M. Nobibux at Telesur?

I hope they can fix their infrastructure fast.

3 Likes
3

For what it’s worth, a quick scan seems to show “dig $TLD caa” succeeds for all other TLDs.

The shell hack i used may have corner cases but it’s probably accurate.

I don’t know if any TLDs have CAA records, but the queries don’t fail.

Edit:

I did a non-hacky scan.

Every TLD except .sr succeeded.

No TLDs had CAA records.

4

Thanks for the detailed analysis @mnordhoff! I will take a look and get in touch with the .sr admins.

2 Likes
5

Did they ever get back on this? I’m getting the same issue, and as far as I can see this is a complete blocker for anyone using a .sr domain with Let’s Encrypt, assuming nobody wants to hack up the code.
Or is there some kind of reasonably easy and maintainable workaround?

6

There's a second thread about this. There has been contact between Let's Encrypt, .sr and their DNS software provider.

2 Likes
7

I got a further e-mail which, if I understand correctly, means that the responsible vendor is actively working on a patch but doesn’t forecast that it will be available before September 8. :frowning_face:

I’m talking to Telesur about workarounds.

@Chris_Graham, @jsha advised me that per

https://letsencrypt.org/docs/caa/#where-to-put-the-record

(which is not necessarily 100% clear on this issue) if you use a separate external nameserver that fully supports CAA, and you explicitly create a CAA record that authorizes Let’s Encrypt to issue for your domain name, that takes priority over a negative record or an error from a higher-level domain. So if you point your nameserver delegation elsewhere and then create an appropriate CAA record, that should allow you to continue to issue certificates despite the error at the TLD level.

8

Thanks guys. I can wait, actually it’s great to see progress is happening.

9

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