mirror of
https://github.com/certera-io/certera.git
synced 2026-04-25 11:15:55 +03:00
[GH-ISSUE #14] DNS Root Queries #15
Labels
No labels
bug
feature-request
feature-request
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/certera#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @blastagator on GitHub (Oct 20, 2020).
Original GitHub issue: https://github.com/certera-io/certera/issues/14
Is there a reason the server is configured to require direct query of root servers for DNS validation? I edited the config file to only have my router IP address but validation still fails (status shows it is trying to query a root). I have my network configured to block all unencrypted DNS unless it is to my router which queries cloudflare through an encrypted connection.
I can make a firewall exception for the VM Certera is running on but would rather avoid it if possible. Thanks!
@certeraio commented on GitHub (Oct 20, 2020):
The reason is because it increases the consistency of validation. If after setting the DNS entry and telling Let's Encrypt to validate it, it may fail if DNS hasn't sufficiently propagated. If other sources confirm the DNS entry exists, we can be more certain that the validation from LE will succeed. Should be easy to have a flag/config to disable this altogether. You may run across more failed DNS validation attempts, but I suppose that's up to you, right? (not trying to be pedantic, just realistic/honest).
@blastagator commented on GitHub (Oct 20, 2020):
Ah. Is it setup to require multiple validations or does it move on to root if the initial query to the defined DNS fails? I was considering re-enabling my NAT rule that forces port 53 to my router to see if that works as a workaround.
Also, two thumbs up for making this. I'm still working through setup but this seems to do what I want. I'm trying to migrate a bunch of local resources to LE certs instead of a manually run private CA.
@certeraio commented on GitHub (Oct 20, 2020):
The DNS servers Certera uses are configured here in case you wish to change it: https://github.com/certera-io/certera/blob/master/src/Certera.Web/config.json#L16
If you remove the entire entry, I believe those same values are used by default in the code. I think you may be able to set it as
"IPs": []to truly skip the extra DNS validation step (though it may still have a delay in total time, which may help in allowing LE to have sufficient time for propagation).The only validation that matters is LE's. The DNS servers in the config are there for increased "confidence" before telling LE to validate. If the first of the custom DNS checks passes, it goes on to tell LE to validate. It doesn't wait until all DNS servers have been checked.
I'm glad you've found it useful. I never did like having the obtain & apply cert as a single step like other LE clients do. I believe this makes LE much more useful for a wider range of things. I hope to find time one day to truly make Certera what it should be: a certificate exchange hub. That'd solve a lot of pain/challenges with certs when dealing with 3rd parties.
@blastagator commented on GitHub (Oct 20, 2020):
I adjusted https://github.com/certera-io/certera/blob/master/src/Certera.Web/config.json#L16 but it looks like I had a typo. I fixed the typo and everything seems to be working now as expected. How embarrassing!
Apologies for the issue, I hope the closed thread helps someone else who stumbles into the same silly mistake.