-
-
Notifications
You must be signed in to change notification settings - Fork 796
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify DNS Servers to Check for DNS Challenge? #1128
Comments
There is a setting for DnsServer in the config file. You can use it to specify the DNS server that is used for preliminary checks used by win-acme to make sure that you are set up correctly for DNS challenges. You can read about it here. |
Just to clarify: by default the authoritative servers are queried for pre-validation and the local DNS servers are only used to find out where those are. |
@WouterTinus Sorry to revisit this... I think the issue I'm having is because I have a split-brain situation. This might be an edge case that win-acme cannot yet handle properly. Here is my setup:
I have hosted zones for both of these domains in Route53. I have a NS record in the example.com zone delegating the inside.example.com subdomain to the separate hosted zone...this is a pretty basic Route53 configuration. I'm working on generating LE certs for internal services on this internal domain...however, because the authoritative servers on the internal network are actually my AD DNS servers, win-acme is fundamentally looking in the wrong place and fails. However, I need win-acme to look at the public side authoritative servers. I have manually specified the NS listed in the SOA record for example.com hosted zone as the 'DnsServer' in settings.config. This works, but with mixed results.
However, I get a valid certificate! |
Ok I turned on verbose mode... Preliminary validation IS checking my local AD DNS servers...even though I've configured a manual authoritative DNS server in settings.config I really could use a settings.config for defining custom DNS servers to use for preliminary validation. Most ACME clients that I've used are hard-coded to use Google DNS, CloudFlare DNS, etc. for doing this validation...although I'm not really sure how win-acme is generating a valid certificate |
Would you mind posting this verbose out output? The manual override is supposed to work already for Prevalidation, in fact that's its only purpose. Either the setting is not picked up or there is some bug. Regarding how it generates a certificate; at the end of the day the PreValidation step is completely non-essential. It helps some users eliminate configuration mistakes and timing issues, but none of it has anything to do with Let's Encrypt. LE does it's own, independent validation, and that is the only one that really counts. |
Oh by the way: reading the code it seems the setting can only be an IP address, not a DNS name. That can be a gotcha. |
I can get verbose output posted shortly...traveling this weekend. So, using the IP address of the authoritative NS for example.com works fine. Prevalidaton works. However, win-acme doesn't seem to bother following to the authoritative NS for certs on the inside.example.com domain. Might I suggest a settings.config override for disabling pre-validation and allow multiple DNS server IPs in the DnsServer setting? Something like this: traefik/traefik#4101 |
Just so we're on the same page: rather than specifying the exact DNS server to query for PreValidation checks, you expect to be able to specify the starting point from where it should start to look for the DNS server to validate against. If that's what your asking for it makes a lot of sense to me.
I think that won't be necessary if we fix the behavior as described above? |
I am also wondering whether we have some partially incorrect logic in how we look up name servers. It looks like we get the name server for root domain and assume that it handles the entire domain. This might not be the case if a domain has customized NS records for subdomains. Instead, it might make more sense to keep traversing the subdomains with NS searches on the parent NS domain until we get to the challenge domain and then do the TXT lookup with that NS record. I could also try to do some reverse engineering on how letsencrypt queries the DNS records when verifying the TXT token. My self-hosted DNS plug-in seems to reveal that they do quite a few lookups when checking a DNS record (I've seen as many as five lookups). I could check out the IP addresses that originate these lookups to see if that gives us any clue about their process. Ideally, we would engineer wacs prevalidation to look as similar as possible to what letsencrypt does in real life. |
There is already logic to find the deepest authoritative server, iirc we start from the full challenge domain and work our way up to the registerable domain. |
I did look more after writing my comment and I was incorrect about how it works. Sorry about that, @WouterTinus. I still wish I had a better picture of what letsencrypt is actually doing in their lookups. They seem to be able to find TXT records in cases where we do not (and same is true with Google DNS and others public DNS servers as well). I can provide examples of domains that do not pre-validate if you need actual cases (I would prefer not to post the domains publicly, but could email you if you are interested). |
Please do, that'd be interesting to take a look at! |
This was released in 2.0.9 |
sorry, but this still does not work correctly. I am using split brain dns for one domain (.nl) but not for .com. even though I specified 8.8.8.8 as the dns server to use, it is still using my local dns server to get the dnsservers for the NL domain, which means those will fail. |
Is it possible to specify which DNS servers are checked for DNS challenge? I have a case where I need to check the public DNS (like Google DNS or CloudFlare) instead of checking the local DNS servers defined on my machine. There are some ACME clients that specifically only check known public DNS servers by default (instead of using the DNS servers defined on the local machine).
The text was updated successfully, but these errors were encountered: