Different CAAs returned from two DNS servers

Feature Requests
21

FWIW, LetsEncrypt uses unbound to resolve DNS.

A similar configuration is here: https://unboundtest.com/

Imagine this scenario:

  1. One of the DNS servers fails, so it doesn't accept updates but still serves old content.

IMHO, that is not the type of scenario a CA should be concerned with. From an external perspective, the DNS could be purposefully set up that way.

5 Likes
22

Hey @outofforest, this has been a relatively interesting thread – thanks for all your input(s)! I want to give a cudos to @Osiris (reserved but deserved) for focusing on the importance of DNS consistency, @9peppe for bringing RFC 6844 into the conversation (really cool), and @Nummer378 for that much-needed dose of reality on how recursive resolvers actually work. (amen) Pay attention!

Okay, so here's my 2 cents.:

It's not Let's Encrypt or ACME that's the problem. The real issue is that your authoritative DNS servers are having a bit of an identity crisis. If they're giving out conflicting CAA records, certificate issuance is going to fail. And that's not a bug, folks – it's actually a security feature! RFC 8659 explains it all.

Here's why this happens:

Let's Encrypt doesn't go for a "majority rules" system when it checks your DNS. It picks one authoritative server for each query. So, if that one server happens to say "CAA 0 ;" (which basically translates to "no certificates allowed!"), the issuance process is dead in the water – no matter what the other servers might be saying. Again, this is a deliberate security measure, not some random glitch. (figure it out.)

So, how do you fix this mess? Here's a possibility:

Keep your authoritative DNS servers in sync.  If they're sending mixed messages, Let's Encrypt gets confused and throws in the towel. If keeping them perfectly in sync is a major headache, maybe consider simplifying things and having fewer servers handle CAA records.

Think twice about using "CAA 0 ;" as a default.  If you don't want to allow certificate issuance, just don't return a CAA record at all.  It's just as secure, and you'll avoid a lot of these conflicts.

Be patient with DNS propagation.  If your ACME client is trying to validate records before they've fully spread across the internet, you're setting yourself up for failure.  Give those DNS changes some time to settle before you try again.

Now, you might be wondering, "Couldn't Let's Encrypt just change how they do this?" That would involve rewriting a lot of resolver logic and, more importantly, getting RFC 8659 rewritten – which is a pretty monumental task, to say the least. So, the most practical solution is to make sure your DNS servers are all on the same page.

Hope this helps!
RIP

6 Likes