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
Route53 DNS Verification should prefer the public zone #375
Comments
This may be the root of my issue: terraform-providers/terraform-provider-acme/#11 Is there any kind of work-around for this? |
@ldez Mind if we could get some TLC on this issue? I'm running into issues on both submission and renewal of terraform resources crafted using this repo as it's client mechanism. From what I have observed, I can see the TXT record on dns_challenge get created in the right zone ; however the verification appears to be using the DNS servers from the private zone ... Could you provide some insight on this? Does perhaps the acme provider need to source a newer release of lego? |
Perhaps even a simple exclusion of any private DNS zone for the dns_challenge might be wise --- since it is by definition unverifiable! |
@mengesb If you are able to do some tests for me, it will be great. |
Very willing to run tests. Was hoping to find a way to return the list of hosted zones that are public using your client. Let me know how to do the tests and I'll collect any logs necessary |
Looks like the root issue is here: Before ACME is notified that the record has propagated, there's a precheck done. It seems that it is harvesting the internal dns servers for this precheck, and I'm guessing this might be the source of my problem. I do see some defaults in there in the event that it cannot source |
So the issue is definitely getNameservers! I inserted above L58 I think the best solution here is to add a config var for this that allows the user to specify DNS servers to query; maybe with a key word If we want a very targeted fix, you can use the AWS SDK to harvest the target zone id's NS records. This might be the best default solution for the route53 provider, but it means some structural changes to the code for the In any case -- this process should be documented a bit more clearly as I was confused for a while as to how the internal NS servers were being selected for testing. -- If you would make the changes I can start working on tests. Once your PR is merged it will take me some time to get this dependency updated in the upstream terraform-provisioner-acme repo as you've added a lot of functionality that needs a whole lot of documentation. I'm very amateur to golang so i'm not quite sure how I'd configure something like a config var to help out with |
So it's the issue is solve by using default nameservers, you can use You can take a look to my PR #700. ( I can add an option to skip |
So terraform-provider-acme needs some env var or a way to pass config to lego so that it can skip resolv or use that command line option. Also currently terraform-provider-acme uses lego v1.0.1 I believe; I'm guessing I'd have to update the dep anyway |
@mengesb actually, I think we can implement what's here as a resource-level option and keep it out of the DNS provider configuration path. So in other words we should have everything we need here to add the appropriate support without anything else needed from lego. 🙂 |
Route53 allows for both public and private zones for the same domain. The primary use of the private zone is for internal VPC dns resolution.
When doing DNS validation for LE certificates, lego should try and prefer public zones over private zones, as of right now, it appears to pick the first zone to match, which can be the private zone.
The text was updated successfully, but these errors were encountered: