AWS Network Firewall and FQDN

This is a common ask and the short answer is "no". But read on if you're interested as to why that is.

HTTP and HTTPS are interesting protocols because part of the protocol is (in a couple of different ways - Host header or in the certificate) to include the hostname of the intended destination in the protocol. Therefore, if you can capture that information (easy in HTTP; harder in HTTPS and will get even more difficult as TLS 1.3 gains adoption because it's designed to hide more of the certificate information) then you can (in the firewall) make a decision based on that information. Excellent stuff.

Note that if this information wasn't available the only thing the firewall has to go on is the destination IP address. Mapping that back to a FQDN is time consuming (reverse DNS lookups take time); may not work (not all sites have up to date or even accurate reverse DNS lookups); and doesn't work for services that host multiple sites on a single IP address. And that is the case for pretty much everything except for HTTP and HTTPS. There will be exceptions but go with that for now.

The mapping between the FQDN and the IP address is done at the host where the connection originates. And usually that process (DNS) is completely decoupled from the network filtering process (the firewall). The firewall has zero knowledge of what the host did to resolve the FQDN to the IP address. Absolutely none.

Could you build a system where your DNS resolver communicates the DNS query, the resolved IP and the originating host IP to the firewall? Yes, you could. It still wouldn't be perfect - if a host looked up two DNS records which both go to the same IP address and then connected to both of them how would the firewall know which session to allow or drop? That's an edge case but the real-world implications make this process much harder. And things like DNSSEC and DNS-over-HTTPS will make it nearly impossible.

Assuming the resolver can find that information it needs to communicate to the firewall before the originating host tries to connect. That's not too difficult in a small network and it's even easier if the DNS resolver and the firewall are a single device at the edge. But in large networks it simply doesn't scale. Now you need the DNS resolver to communicate to a fleet of (perhaps) distributed firewalls (because you don't know which firewall instance is going to receive the session).

And: It could even be seconds or minutes before the host tries to connect - what if that information has timed out? How much memory do you need to reserve on the firewalls to track everything?

In short, it's not something that can easily be done at scale at there are many ways it can fail.

To answer your question at the end (in long form again): Be careful trying to lock down your network so that only device X can talk to device Y for a specific set of protocols. While you can do that you will end up in a situation where your business, developers or anyone else trying to do something will need to wait for you (or your team) to change the network in order to for them to do their job. Don't let "security" be a blocker to the business.

Sure, set up security groups so that only internal (to your network) hosts can connect to certain instances. That makes sense. But don't write NACLs and firewall rules which are so specific such that when a host changes IP address (this happens all the time!) that you need to spend hours troubleshooting and then get an emergency change control approval so that you can fix things and everyone can go back to work. Ask me how I learned this lesson... (or not - you can guess).

I realise I'm preaching now - apologies. But this is a huge topic as it delves into the risk the business and security teams are willing to tolerate versus the speed at which they wish to carry on working.

Well worth engaging with your local AWS account team - they can bring in Solutions Architects who are specialists in networking, security, compliance, etc. to work out what the "best" solution is for you.