Network security question: How are people restricting outbound connections based on DNS names?
For example: Server A wants to connect to cdn.network.com, and that can resolve to a huge range of IPs, so not feasible to allow list all possible outbound connections.
I vaguely remember some dns proxy / firewall magic where it tracks the answer and opens up the IP.
Oct 7, 2026, 10:05 AM@thedarktangent you can do SNI header sniffing on TLS connections and then implement some firewall or tcp connection based drops. If there are tools that already do this, I don’t know.
@thedarktangent dnsmasq has --ipset and --nftset options. e.g., nftset=/cdn.network.com/4#inet#filter#allow4 adds every A record answered for that domain (and its subdomains) to an nftables set.
Unbound has an ipset module that does basically the same thing. It has to be compiled in with --enable-ipset, and you tag the zones with local-zone: "network.com" ipset.
There are a couple others but these are two solid DNS projects.
@hrbrmstr My concern there is that the CDN is basically a class A of v4 addresses and an equally giant amount of v6. Over time the table could hold hundreds or thousands of allowed addresses.
@thedarktangent ipset is pretty efficient
@hrbrmstr What I meant was that over time the rule would become less and less effective. Soon it would allow my server to connect out to hundreds or thousands of IP addresses on a public CDN network, when it really needs to only talk to a single IP for a few seconds.
@thedarktangent @hrbrmstr the nftset can have an expiry time associated with it, entries not touched get pruned.
For eg a curl “one and done” lookup+connect, set the timeout to say 5s, long enough for the 3-way handshake to end up in conntrack, then you can drop the entry, established connections are usually allowed to continue.
@thedarktangent I can't speak for other commercial platforms, but the Juniper SRX series can configure rules based on address-book entries that are dns-names.
You basically just do this:
set security address-book global address cdn0 dns-name cdn.network.com
and then you can reference cdn0 in any security policy.
As much as I hate to admit I know this, but I am pretty sure Fortinet can do this as well.
Wouldn't surprise me if most vendors had something similar.
No idea how you do this in any of the OSS options.
@nuintari @thedarktangent I have seen several (most? all?) of these platforms suffer from having stale data in those DNS lookups and/or pulling a subset of the CDN IPs in the lookup (whatever the DNS server gives it), being at the mercy of round robin DNS. Makes for some interesting troubleshooting.
Oct 7, 2026, 11:24 AM@thedarktangent DNS Response Policy Zones (RPZ)
Oct 7, 2026, 11:39 AM@ckure @thedarktangent yes, this. You can set all sorts of magical things via policy, including rewriting responses, not just making them "fail". Supports wildcards too!
@ckure I'm not sure how an RPZ would help?
I would still need a way to allow only TCP connections from my server to the current cdn.network.com resolved address.
Something like
1 - "allow traffic from my server out to cnd.network.com"
2 - "Block everything else"
And do this based on current name resolution for cdn.network.com. The only thing I can think of that could do this easily is if the thing doing name resolution can also add and remove rules dynamically.
Oct 7, 2026, 1:15 PM@thedarktangent maybe I misunderstood the problem. If you don’t want resolution you set RPZ for cdn.network.com to resolve to a blocked landing page IP, return NXDOMAIN, etc
If you’re looking for this to also involve packet filtering, yes my option doesn’t do that. But if you can enforce DNS through your RPZ resolver, no one except those in an “allow” policy will be able to resolve an IP for that name.
@ckure But nothing to stop someone from connecting directly to any IP address they want?
Oct 7, 2026, 8:47 PM@thedarktangent right, RPZ is like a DNS firewall. Intercepts requests and uses a policy to return customized results (blocked or rewritten responses). No layer 3 protection inherent to it. If you can connect to the IP and send eg host header, you’ll bypass the RPZ bc you’re not resolving its name
@thedarktangent it sounds like you’re describing the job of an outbound web proxy, which works based on domains.
And before “well I shall simply bypass the proxy” if this is well-architected either all traffic gets forced through the proxy, or the firewall simply does not accept connections from not-proxy, causing applications that are not proxy-aware (not uncommon for malware) to simply splat against firewall egress rules.
Many of these do most of the filtering based on category (eg “banking” or “malware”. “Unknown” is really powerful for catching new stuff) but should allow per-domain (sometimes per-full-URL) blocking in addition.
@thedarktangent I use squid proxy with a default deny policy. Adding "dstdomain" entries to an allow list. Machines that need that inspection get an egress firewall rule (or reduced routing, or both) so all they can do is use the proxy.
I do not do SSL inspection at any site I do this for.
Target application has to support using an http proxy though.
@thedarktangent Sounds like something pihole would do.
Oct 11, 2026, 3:31 AM@thedarktangent oh, are you literally asking for dynamic firewall rules that punch holes in your default deny outbound policy based on responses from dns servers?
Oct 11, 2026, 4:05 AM@thedarktangent the only thing I can think of that might be what you're looking for is a duct tape and bailing wire combo of:
Query logging
RPZ entries to make cdn.example.com *sticky* rather than round robin
Dynamic RPZ zone updates
A RPZ zone file "Grove tender" that prunes stale entries
Dynamic firewall hole punching
1) Assuming a default deny outbound policy, an isolated host does a DNS lookup, that doesn't exist in the RPZ zone. Make default policy to *not provide an answer*.
2) something monitoring query log sees the isolated host ask a question, performs the lookup against root servers, and just adds whatever that answer is to the RPZ zone as an override via nsupdate.
3) firewall hole gets punched for those IPs for some reasonable TTL
4) isolated host retries DNS query, now succeeds, and is handed RPZ overridden records, and makes an outgoing connection to a known IP.
5) RPZ Grove tender does lookups of overridden records against the root servers to catch changes in DNS and make the RPZ match. Old firewall holes punched get closed.
6) any connection to an IP that bypasses DNS is ... either suspicious, something with a hard coded IP, or possibly is cert pinning with an IP subject Alt name?
That (I think?) answers your "my firewall allowlist will be huge" problems, by funneling connections to a slowly moving CDN target.
I don't know of any products that do this out of the box, but I'm also blatantly ignoring the elephant in the room of "why do you trust DNS in the first place?" and "why do you want DNS responses to punch holes in your firewall?"
Oct 11, 2026, 4:09 AM@thedarktangent IMO a firewall policy that is configured by an untrustworthy source is no different than an allow all policy, but I can't threat model on your behalf.
@xabean The short answer to your questions are essentially “Because of the changes to web PKI certificate lifetimes everyone will need to automate with ACME. When using Let’s Encrypt that requires your server to make outbound connections to (essentially) the internet. How do I restrict CertBot to only talk to the DNS name for let’s encrypt and only to deal with the challenge?”
Oct 11, 2026, 7:37 AM@thedarktangent @xabean And how to restrict the web server to only accept from let’s encrypt ip addresses?
Oct 11, 2026, 9:17 AM@adamshostack @thedarktangent @xabean I've created an ACME gateway for this. Configure local ACME clients to use the gateway's URL, the gateway takes care of the issuance for you, regular API calls from internal client.
Gateway uses dns-01 validation so you can issue for "internal only" names as well if you use .intra.example.com for that.
Requires DNS API to set up and tear down the TXT RR.
https://codeberg.org/Sp1l/CertPortal if you're interested. It's being used at a 10k+ employee org for all internal certs.
The project has other features too
@brnrd @adamshostack @xabean
The problem using DNS–01 validation scheme is that now all of my various servers will have permission to directly update DNS entries. TLS – 01 allows things to at least stay all on the same server and not spanning multiple.
Oct 11, 2026, 6:41 PM@thedarktangent @brnrd @adamshostack @xabean For this problem space, I've personally CNAME'd the _acme-challenge FQDNs to a consolidated zone, running on a standalone PowerDNS server, and the ACME hook scripts create/delete the TXT records in that database. This supports wildcard certificates, too, FWIW.
Anecdotally, that ACME-validation-only DNS server doesn't even need an IPv4 address.
Oct 11, 2026, 6:48 PM(footnote for anyone wondering why not needing an IPv4 address is a good thing: public-facing DNS servers generally need their own public IP, and IPv4 addresses are a scarce resource, so not needing one for a niche, infrequently-needed utility service is beneficial)
Oct 11, 2026, 8:01 PM@jima @thedarktangent @adamshostack @xabean I know about this ACME feature but haven't had to use it yet.
Using CNAMEs allows for very granular permissions for users if you sub-divide the CNAME targets into sub-domains that a specific user gets to add the TXT records to
Oct 11, 2026, 8:08 PM@brnrd @thedarktangent @adamshostack @xabean Oooh I hadn't even THOUGHT ABOUT the RBAC potential of this! 🫢
Oct 11, 2026, 6:44 PM@brnrd Thanks, this is an interesting contribution!
I haven't particularly needed *this* angle, but I know some people who might benefit from it, and I'll keep it in mind.
@thedarktangent opnsense aliases do this if I understand your question correctly https://docs.opnsense.org/manual/aliases.html
@thedarktangent The only sandboxing tool that I am aware of which is capable of egress filtering based on DNS name is NoNo
https://nono.sh/docs/cli/features/networking