Could LE be fixed to specifically query the primary NS (i.e. the NS named in the SOA record) when using RFC 2136 DNS authentication? If that were done there wouldn't be any need to wait for propagation which can be quite slow at times.
LetsEncrypt does this.
You can use https://unboundtest.com/ to mimic what LetsEncrypt sees.
3 Likes
Then why does it say:
Waiting 150 seconds for DNS changes to propagate
and then fail when my slaves take > 150 seconds to update?
You can use https://unboundtest.com/ to mimic what LetsEncrypt sees.
which confirms that it's using my slave servers to try to resolve the TXT RR and not the primary server from the SOA RR.
Let's Encrypt/unbound chooses one of the nameservers randomly, which may or may not be the primary NS.
Because Let's Encrypt validates from multiple vantage points, queries have a high chance of hitting multiple nameservers (if the zone has more than one).
Let's Encrypt has no idea what method you use to access your nameserver. There's only a single DNS-01 challenge, so your proposed method would have to apply to all DNS validations.
I personally think LE is unlikely to do this for a number of reasons (resilience, availability of nameservers in different scenarios, ease of implementation), but yeah sure this is a valid feature request.
4 Likes
This may be true for your particular environment. But there's no guarantee it would be true everywhere. In many configurations, the real DNS primary is hidden/stealth and the nameserver returned in the SOA MNAME is just an authoritative slave like the rest.
Slow might be annoying when you're initially setting things up because it takes longer to debug problems. But it should be inconsequential in the grand scheme of a cert update once every 60-90 days. And if faster propagation is a priority, you as the domain owner have many options to make that better.
6 Likes
If your dns-01 challenge keeps failing for 30 days, well, that would be a problem 
2 Likes
We should also note that in many cases there may be better solutions available.
For example, you could look into fixing the issue that's causing the slow propagation in the first place. Many NS systems push data to secondaries, having data available everywhere fairly quickly.
If that's not possible, you can also delegate the DNS authentication using CNAMEs to a different zone. On that different zone you could for example have a single dedicated NS that only handles the ACME challenge TXT records. That option is also mentioned in official docs. This essentially gives you the "query only a single NS" option.
So overall there are often better ways to solve this issue that do not require new features on LE's side.
5 Likes
I'd like to point out that the concept of primary and secondaries is not how the Internet sees authoritative nameservers. They are all equally authoritative. You can configure your systems to work in that way (or in any other way that you like), but that is not what is expected by the Internet.
Furthermore, the listed primary can be fictitious or unreachable from the Internet [private/protected IP].
So, there is no one-size-fits-all way to address that and anything else is overcomplicating a very simple protocol.
Here is a real live snippet of one of my domains:
primary name server = internal-master
[Obviously an FQDN that can't even be resolved externally/globally]
My advice: If you can't synchronize your DNS servers in a timely manner, then you may need to look for another DSP [DNS Service Provider] that can - there are plenty of good ones out there.
7 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.