Please query the authoritative DNS(SEC) with dns-01

No spoofing with DNSSEC and DANE. We use both.

2 Likes

Then all that is left is to sync them quicker - or wait longer.
Try using some (FREE) global DNS providers.
Like: https://cloudns.net/

Or
Incorporating a delegated zone solely for these types of DNS requests/updates.
[which can even be from a completely different domain]

1 Like

Conclusion: You can't create a Letsencrypt certificate if there is an update.

And that's not a bug, that's a relevant security feature, as explained:

2 Likes

Unlike MX records where you can use cost preference, DNS servers are all equal.
The concept of Master/Slave doesn't apply to client requests.
[they are either authoritative or they are not]

1 Like

Conclusion: You can't create a Letsencrypt certificate if there is an update.

The update is mandated by Letsencrypt's dns-01 procedure, as the token must appear in the DNS. You cannot serve the token from the DNS without a DNS update.

If some parts of the Internet see one thing, and some parts see another (as would happen if different authoritative servers disagree for the same domain), then you're not really fulfilling that requirement.

The requirement is fulfilled when the third parties update their cache. However, they are not authoritative, so you should not read them during the dns-01 procedure, and the requirement must aknowledge this fact.

If you query the master DNS, in the case of DNSSEC, then the requirement is fulfilled.

And you simply can't initiate the validation until the update has completed.

Have a look at: cr.yp.to/djbdns/axfr-notes.html
If you can implement that (as we all do), then this feature request is unnecessary.

2 Likes

You don't understand the basics.

It's your job to wait with the confirmation if you know your zone updates are so slow.

Nothing else, it's not a Letsencrypt problem.

Wait one day with the confirmation, then it will work.

2 Likes

My zone updates comply with the relevant RFCs. The fault is yours that you both ignore the RFCs and query the cache of third party DNSs.

I rest my case. There is nothing more I can do here.

Have a look at: cr.yp.to/djbdns/axfr-notes.html
If you can implement that (as we all do), then this feature request is unnecessary.

Exactly which RFCs are being violated?

What case?

That couldn't be farther from the truth.
LE does NOT use any caching DNS systems.
They walk the DNS tree and find your authoritative servers and they are out-of-sync!

2 Likes

You are not aknowledging the difference between master DNS and zone slaves, and the SOA refresh time dictated by the master. They are all authoritative, but the master is the single origin of all changes. To have fresh data, as in the case of dns-01, you need to query the master, not the zone slaves.

No one does that anymore - get with the program.
The mere fact that you still refer to them as "master" and "slave" says it all.

3 Likes

And yet LE is to blame - LOL

The three RFCs you mention fail to show how LE is in any kind of violation:

RFC 1912 "Common DNS Operational and Configuration Errors"
This memo does not specify an Internet standard of any kind.

RFC 2308 "Negative Caching of DNS Queries (DNS NCACHE)"
Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol.

RFC 4035 "Protocol Modifications for the DNS Security Extensions"
Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol.

1 Like

Letsencrypt queries never the cache of third party DNS.

As already told, Letsencrypt uses Unbound, Unbound checks the authoritative name servers directly.

And the RFC is unrelevant.

Zone update = 1 minute -> confirm after 2 minutes
Zone update = 1 hour -> confirm after 2 hours.

2 Likes

If you try to serve it under a different hostname, the RR qualifies as out-of-zone data and it will be ignored (not included in the DNSSEC signed zone).

On acme-dns, it is a dedicated DNS server to walk around the problem discussed in this thread.

My request here is to check whether the master DNS uses DNSSEC. In this case, you can trust its answers. There is no need to install acme-dns, or any additional ACME-dedicated DNS. And there is no need to wait hours for dns-01 to complete.

When the hostname is from a different domain.
But what about this example:
_acme-challenge.your.domain CNAME _acme-challenge.singlesub.your.domain
Where that singlesub zone is delegated to a single DNS server.
[to the "main", "master", "primary", "originating" DNS]

Then the amount of required updates is just the one [initial change].

1 Like

There are broken configurations on the Internet. Some slaves never refresh, they behave like master, serving inconsistent data. It would not be appropriate from LE not to check slaves too, in general.

2 Likes

I've actually been messing with this as well. I too have a primary DNS server somewhere and am using TransIP's as slaves. What you need to do is make sure that the zone used to verify the ACME challenges only has one nameserver. In my case I was trying to request certs for subdomains and did the following:

  • Delegate a subzone to one specific nameserver (the "master"), by means of an NS record in the parent zone. Example: acme-le IN NS ns1.example.net.
  • Then also add CNAMEs to the parent zone for every subdomain you want a cert for, e.g. _acme-challenge.mysub IN CNAME mysub.acme-le.example.net.
  • Now, actually create the subzone and enable/configure DNSSEC. I simply used a "blank" zone with just SOA and NS records at this point.
  • Next, you need to make sure that there's a chain of trust between the parent and sub zones. Using the key-signing key (KSK) from the sub zone you can generate a DS record you need to put in the parent zone: dnssec-dsfromkey -2 acme-le.key
  • Sign both these zones, reload the DNS server and verify that you can query records from both zones without errors.
  • Modify the LetsEncrypt auth hook to update the records of the subzone. For mysub.example.net you would have it add a record mysub IN TXT "challengevalue" (and resign the subzone).
  • I personally also set a TTL of between 1 and 10 for these records, to make sure any DNS servers inbetween my server and LE always "refresh" them. If it's already/still cached then the TTL will have expired since the last time you ran LE and it will request it again (unless it's a really broken resolver). If it's not cached then it will have to query somewhere upstream and will eventually query your nameserver regardless.
  • LE will first look up _acme-challenge.mysub.example.net and will notice the CNAME. It will then look for a TXT record at mysub.acme-le.example.net instead. Since this zone only has one NS and a low TTL, every recursive resolver will always ask the "master" for the record.

Obviously you can skip the NS delegation if you want to use an entirely different domain for actually holding the TXT records. Just point the CNAME(s) there and follow the rest as described.

Alternatively, if you don't want to mess with subzones or CNAMEs you could modify the LE auth hook. Instead of just "naively" sleeping X seconds inside the hook, simply run dig in a loop: while ! (dig mysub.acme-le.example.net TXT @8.8.8.8 | grep -q -- "$CERTBOT_VALIDATION"); do sleep 5; done
Of course you should probably add something to break the loop after some time.

--
Now, I do want to express that I disagree with the others who say LetsEncrypt queries the authoritative nameserver(s) directly. A couple of days ago all my DNS-based requests started failing consistently with a SERVFAIL error, although my DNS server worked just fine. Like, I could do dig @server and it would return either NXDOMAIN or NOERROR (with accompanying record). Even looking up the LE TXT records gave no issues. Four DNS servers failing at the exact same time is extremely unlikely, 3 of which are from a major provider.

I did some looking into it and I found that at least Google seems to verify that every query complies with DNSSEC and if not, returns SERVFAIL. In my case the TXT records I added to the zones weren't signed, but once I shifted the scripts around to support signing them, I could immediately request my certs without issue. Of course it could be possible that LetsEncrypt itself also requires DNSSEC compliance, but I doubt that because it's not really feasible that everyone complies.

3 Likes

Yes, we do. :slightly_smiling_face:

3 Likes

Which RFCs was Let's Encrypt failing to abide by again? And not the three @rg305 already debunked please..

If a DNS client crawls the DNS tree and it comes across a multiple of authorative DNS servers for a zone, it randomly picks one. It does not query every single nameserver to check if one of those nameservers has a higher SOA serial number. So it does not know if it's talking to the primary DNS server or one of the secondary nameservers. Or are like, all DNS clients out there not abiding to a certain RFC according to you by this behaviour?

6 Likes

Alright, then just disregard my last 2 paragraphs. :>

2 Likes