Problems with CAA records only with Google and Let's Encrypt

Help
21

I created the issues on DNSViz and Zonemaster:

1 Like
22

Glad you could figure it out! There is a lot of nuance to implementing a DNS server correctly (even without DNSSEC, which adds a bunch more complication); it's not for the fainthearted. I highly recommend adding a bunch of tests (if you haven't already) around case-insensitive matching, and around all the possible errors and no-data-no-error responses. I also recommend you implement echoing of the query case in your responses, as I stated earlier it's expected behavior by many resolvers, mainly as it allows for mitigation of some attacks. (It makes it harder for an attacker to just spam UDP response packets with all possible transaction ids if they also need to match the query case.)

I certainly agree that it'd be nice if the DNS tester systems out there did more checking around case insensitivity and case echoing. Might also be nice for there to just be a full standard suite of tests that DNS server implementors should be sure to run against, like the EDNS checker mentioned earlier but for all aspects of DNS. DNS has a lot of aspects, though.

4 Likes
23

I do echo the cases in the question section of the response, right? Should it also happen in the anser/authority/addtional section?

24

Oh, hmm. Well, it looks to me like most servers do, but you may be right that the usual 0x20 mitigation only looks at the question section. You're getting beyond my DNS knowledge again. If an Unboundtest log shows it just querying once and not retrying with lowercase to try to work around a lack of case echoing then it's probably fine.

3 Likes
25

Just my 2c as I came across a similar question while evaluating a new DNS server recently:

  • The 0x20 draft specifically regards matching the name in the question section of the request and the question section of the response. The name in the answer section of the response is (as far as I'm aware) never used for 0x20 validation.

  • Many DNS servers however do respond with matching case in the answer section, though every case of this I've found has been down to DNS compression instead. In short, a DNS packet can reference names from earlier in the packet instead of including the whole string again. If you're looking to absolutely minimize packet size, it's safe to compress case-insensitively, and thus every reference to the qname in a response may end up matching the casing of the first occurrence, which is conveniently usually the qname in the question section, the only place where casing matters for the purposes of 0x20 validation.

The DNS server I was evaluating (CoreDNS) has a more relaxed compression algorithm which only kicks in if a packet is too big, and is case-sensitive, meaning it's only ever going to match the queried name's case in the question section of the response, and never in the answer section. I haven't encountered any issues with this behaviour in evaluation or production.

4 Likes