I am using LetsEncrypt for internal domain certs. I do not want to expose my DNS server to the entire internet. If LetsEncrypt could knock before it queries for my txt record, I could open my firewall temporarily for LetsEncypt source IP to validate.
1 Like
Can't you implement a script to allow the firewall temporarily just before the renewal/issuance and close it again after your ACME client is finished?
3 Likes
Let's Encrypt only cares about the authoritative nameservers for your domain, it doesn't matter if you use a different one for internal use.
2 Likes
I'm assuming the authorative DNS servers are internal (but somehow accessible from the public internet too).But you're right, assumptions are the mother of all...
4 Likes
A firewalled authoritative DNS whose IP address is in a public DNS record makes no sense to me.
3 Likes
It doesn't to me too, but that's the only situation I can imagine from OPs request based on the info we have.
4 Likes
Most people seem to be fine with having authoritative DNS servers publicly accessible, even if they don't have any other servers public.
But if you need to, the way is to do whatever scripting (to do "port knocking" or whatever actions need to happen to open up the firewall) yourself, as part of the renewal process, in order to have the DNS server (and web server too if using HTTP-01 or TLS-ALPN-01) be open to the world only for the time actively being renewed, and lock the ports back up again after. For instance, certbot offers --pre-hook and --post-hook for this purpose.
6 Likes
It's more like all part of a public infrastructure starting from the root . zone, what's the point in being part of this public delegation graph but refusing queries?
You can make your isolated and private DNS, if you want.
2 Likes
-
Certbot has pre/post hooks designed for that.
-
Your suggestion is not fundamentally different from the suggestions for LetsEncrypt to publish a list of their interrogating server IPs. ISRG has made a clear stance they will not publish their IPs, and their arguments in support of that position apply equally to this use case.
-
For DNS-01 challenges, you can delegate acme-challenge records to an secondary DNS server , such as acme-dns, running on the public internet. For HTTP-01 challenges, you can implement redirects on your firewall.
4 Likes
1: I will have to research what pre/post hooks can do. Thank you for making me aware of this.
2: I'm not sure I agree with what you've said here. LetsEncrypt does not publish a source IP list, because of this I have to expose my internal DNS server to the entire internet. I want to limit my services exposure as much as possible. So to get around the issue, LetsEncrypt could knock, I could see the knock source, and temporarily open the port for that source, keeping my internal DNS server unavailable to the public internet.
3: This looks like a useful workaround, however this is not something I can do with our security policies.
2 Likes
This is pretty much what I would like to do, but I would like to restrict it to the source IP found in a successful knock. Your suggestion leaves my DNS server available to the entire internet for the duration specified in the hook script, not bad, but a knock would be better.
1 Like
It's useful to use LetsEncrypt for internal domains. I can auto-renew certs with a CA that is already trusted my most devices. Rather than using my own CA where there needs to be a mechanism to install the trusted certs to every service / device that will access the resource.
1 Like
Yes but that temporarily opens up my internal DNS server to the entire internet. We take security very seriously and would like to do better.
1 Like
well... you should use the acme-dns solution.
one dns stays closed, the other stays open. the closed one is used by your clients, the open one is just to validate (but it's the dns in the public system)
3 Likes
I haven't looked into this, I'll check it out. Thanks for the info and the time.
1 Like
Depending on where the authorative DNS servers of the domain are located, this might not be possibe. It could be the DNS servers of the TLD refer to the authorative DNS server directly which could already be behind the firewall. And the TLD DNS servers cannot provide a CNAME for the _acme-challenge subdomain.
Why would the first impede on your security? There are millions of DNS servers on the public internet. Or are you running ancient versions of a DNS server, full of remotely exploitable bugs? Only in that case I would slightly agree, but I'd rather say to take down that DNS server entirely. On the other hand, if your DNS server is up to date and you also respond quickly on exploit reports, I wouldn't know why exposing a DNS server to the public internet would be a problem.
4 Likes
Right. So it's time to suggest a split horizon dns system. Which is a real pain.
2 Likes
So I've just read the README.md for this. Its useful, however its just casing the problem around. I still have to expose a service to the entire internet. This is what I am unable to do.
1 Like
You have to expose something, either http, tls, or dns.
Your choice what you expose.
You can expose a different dns server than your internal one, but it must be the set of authoritative ones referred in your SOA and NS records. This is what split horizon means: internal clients see a dns, the rest of the internet sees another.
3 Likes
There seem to be some logical fallacies here, and I don't want to get into that.
Even if I am running the latest greatest DNS service there is, if its available on the internet there is a chance a bad actor can find a way to exploit it. If a bad actor can somehow, some way hack the service, they may now have access to do things in my internal network. Even if its in a DMZ, or a subnet by itself, there is still a risk no matter how small. I'd like to keep that risk as small as possible. If my DNS server only needs to be accessed by LetsEncrypt to verify a txt record, then only LetsEncrypt should be able to connect and verify.
1 Like