I am starting a small SaaS company that uses a check for DNS record before creating service. Letsencrypt cert happens during service creation. It would be best to ensure that if our check succeeds, letsencrypt will succeed in finding this domain record as well. This should be easily solvable if letsencrypt uses a specific primary secondary nameserver. If we use the same servers, I can directly query this server for the record.
Which DNS IP does letsencrypt use for http challenge?
I agree with @danb35’s answer: Let’s Encrypt doesn’t use anyone else’s recursive resolver but goes right to the source (making its own queries to the authoritative nameservers for the particular domain in question).
Would love to get verification as to what DNS server it connects to in order to verify the TXT record.
I am getting this error:
Failed authorization procedure. 45woodburn.faure.ca (dns-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.45woodburn.faure.ca, cloud.45woodburn.faure.ca (dns-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.cloud.45woodburn.faure.ca
Partly looks like an error “connecting” to the DNS erver, partly looks like a missing DNS entry. Very confusing that it says “The server could not connect to the client to verify the domain”. I sincerely hope it does not try to connect to the client running the script (instead of the authoritative DNS server), which would be a big security hole.
_acme-challenge.45woodburn.faure.ca. 900 IN TXT “gZ-Aj6S3XRB73AIBEmaTdzhtBjWdihMDbSiAUSoU-9g”
certbot and my hook scripts are running on a different box than my primary DNS server.
Another issue may be a propagation one… i have 6 NS servers, but only one of them will be updated within seconds. Any way I can specify which of the 6 servers listed in the “whois record” that certbot should use?
It sends a query to one of your authoritative DNS servers, choosing in some typical DNS way; i don’t know which one. (Arbitrary, randomly, or possibly something influenced by latency or reliability.)
Nah, it’s just a confusing error message. I would guess that “The server could not connect to the client to verify the domain” is just a boilerplate error message that dates to before Let’s Encrypt supported DNS-01 challenges. It’s not actually trying to connect to your client. Ignore that part and focus on “DNS problem: NXDOMAIN looking up TXT for _acme-challenge.cloud.45woodburn.faure.ca”.
That’s absolutely a problem. It means Let’s Encrypt has about a 5/6 chance of getting an NXDOMAIN and failing!
Indeed, let alone a few seconds, some or all of your other 5 DNS servers still aren’t serving that TXT record. They’re also showing a different SOA serial number:
It should be possible to update Linode’s nameservers within a couple seconds. (Though, again, there may be a degree of caching.) Is ns.certainkey.ca failing to NOTIFYaxfr1.linode.com - axfr5.linode.com?
Through standard DNS mechanisms, yes. You could make _acme-challenge.cloud.45woodburn.faure.ca. a separate zone delegated only to ns.certainkey.ca.. You could make a separate zone with a different name, e.g. acme-challenges.faure.ca., make _acme-challenge.cloud.45woodburn.faure.ca. a CNAME record to cloud.45woodburn.acme-challenges.faure.ca. or somesuch and update that record.
The current setup should be fine if you’re able to ensure that all 6 nameservers are updated before Let’s Encrypt attempts to validate it, though.
One is picked randomly from the set of authoritative servers. Edit: updated to clarify, we pick a recursive resolver from a set that we run in our environment with a low max TTL (60s presently) at random. This is what the code I linked is responsible for.
The recursive resolver (Unbound in this case) picks an authoritative nameserver based on the delegations in place in the relevant zones. I believe this determination is made at random initially and then later by latency/reliability but I’m not positive.
Well, I tried a few options to force a sync of the changes with no success. I have attempted the final suggestion to setup a separate zone, but I have to wait 24 hours for linode to update to the latest serial.
I am having troubles getting it going. The error that I am getting is:
“Failed authorization procedure. cloud.45woodburn.faure.ca (dns-01): urn:acme:error:connection :: The > server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up TXT > for _acme-challenge.cloud.45woodburn.faure.ca”
I set it up like mnordhoff sugested, separate zone, removed slave DNS and set the cacheing to 0.
The new zone looks like this:
I do know that when updating a domain via Linode's control panel, it waits until the next quarter hour to move the changes to the published info (essentially, to ns1.linode.com), and my experience is that it usually takes a couple of minutes before that propagates to ns2-ns5. I'm not sure if it's any different when updating via the API, but I doubt it.