What a Hostname Access Rule Can Mean at Each Network Layer
A service name can be enforced at DNS, browser, proxy or firewall level. Pick the layer that sees the identity you mean to govern.
Three people ask for the same thing in the same words: block access to one service name. One means that a browser must not open the site, another means that a desktop voice client must not reach its server, and the third means that a group of contractors must not use a particular internal application. The sentence is identical, and the enforcement mechanisms have almost nothing in common.
Choose the layer by the identifier it can actually see, then by the clients it covers. Starting from a firewall command you already know is how rules end up blocking nothing, or blocking too much.
A name is not an identity that every layer can check
Netfilter and similar packet filters see addresses, protocols and ports. They do not see hostnames, and by the time a packet reaches them the name has already been resolved. A rule written against an address is a rule about that address, whatever name a user typed to reach it.
DNS policy sits earlier in the path and sees the query, which is a different object from the connection that follows. It governs the answers a controlled resolver returns, not connections that were already open, and not clients configured to bypass that resolver. A resolved address can also change between the policy review and the next request, which is why a DNS answer is not a durable authorization statement.
Higher layers see more context and cover fewer clients. That trade is the whole subject, and it explains why no single row of the table is ever the right answer. Pick the row that sees the identifier your policy is actually about. Then accept the coverage that row implies.
What each layer can identify
Read the table from the middle column outward: the identifier a layer can see dictates the policy it can honestly enforce.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
A layer belongs in the policy only when the identifier it sees matches the identifier you are governing. The table also explains why a rule written at one layer rarely transfers to another without deciding again what it protects.
Where the obvious rule fails
An address rule is exactly right for a service with a dedicated address that you control, and that ownership should be written into the policy. It is exactly wrong for anything behind a shared content delivery address, where the same rule touches unrelated services and a refreshed DNS answer does not turn the rule into hostname authorization.
A managed browser policy expresses a web restriction more directly than a copied address list, but it applies to the browsers and profiles the management system governs.
That browser rule does nothing about a voice client sending UDP to a different host, and its patterns are defined by that product rather than by wildcard conventions borrowed from somewhere else. A CONNECT proxy likewise receives a host and port for a tunnelled request, and cannot read the path inside the encrypted session. Design the rule around what the protocol exposes. Then write down what it leaves uncovered, because that gap is where the next request will come from.
Choose by the clients, not by the command
Ask which clients the policy must cover and which ones it may miss. A managed browser policy covers what the management system reaches and stops at the browser boundary. A resolver policy covers everything that uses your resolver, which is a broader set, and it fails open for anyone who does not.
For a service you operate, authorization at the application is stronger than any network boundary, because it follows the account rather than the path. A VPN route is reachability and nothing more: being able to send a packet to a service is not permission to use it. Where the identifier that matters is a user or a channel permission, enforce it there and treat the network rule as a second layer.
Write the rule in terms of the resource
A defensible policy names the resource, the identities, the applications in scope and the path that carries them, including both address families in use. It also states what happens to shared infrastructure that the rule will incidentally affect.
That phrasing produces a decision someone can audit later. A rule justified by today's resolved address produces an incident the first time the address changes, and nobody will be able to explain why the block was ever correct.