VPN Endpoint Allowlist: The DNS Refresh You Forgot

Typing vpn.example.com into a firewall exception feels like subscribing to DNS. What usually happens is a translation at load time, after which the rule holds addresses and nothing refreshes them. Two components now share the job: the resolver that answers and the firewall that stores. Most endpoint outages start where that handoff was never designed.

A Hostname in a Rule Is Not a Live Subscription

Some tools resolve a name when the configuration loads; others keep a hostname and re-resolve on their own schedule; still others accept only addresses. The visible configuration rarely states which. Documentation examples usually assume the load-time case, which is why the difference surprises people during a migration. Read the implementation's behaviour before assuming an address change will be noticed, because a stale allowlist looks exactly like a working one until the endpoint moves.

A rule that names the right host can still permit the wrong address. That gap is the myth, not a spelling mistake.

Cache TTL Is Not Your Firewall's Timer

DNS records carry a time to live, and resolvers cache answers for that period. The DNS specification defines that caching behaviour, but it governs DNS data, not a firewall's separate address store. A short TTL does not create a refresh job where none exists. Caching also happens at more than one layer, so the answer a terminal sees may not be the one the firewall saw.

Ask three questions of the actual product: when it resolves, where it stores the result, and what triggers an update. If the answer is only at boot, a long-lived session can outlive the address it was admitted to.

dig +short vpn.example.com
resolvectl query vpn.example.com

Design Refresh and Failure as One Policy

A maintained exception needs explicit answers: what triggers a refresh before the client chooses a new address, how the permitted set changes without opening a broad temporary window, and when obsolete entries are removed. Write those answers next to the rule.

Choose the failure behaviour deliberately. Keeping the old address may preserve a session and leave a stale permit; clearing the set may strand recovery. Neither should be an accidental result of a failed lookup. Write the chosen behaviour into the runbook so the next operator does not improvise under pressure.

Keep bootstrap DNS narrow as well. An unconditional public-resolver exception is a direct DNS path for everything it matches, not only for the endpoint's name.

Prove the Endpoint Change, Not the First Connect

Use the client's supported manager if it already coordinates resolution and blocking. On a site-managed PF host, keep the site's ownership and recovery plan instead of copying hostname-table syntax from another platform with different lifecycle behaviour.

With an approved, harmless test, compare the address the client selects with the active permitted set before and after a controlled change. Cover a failed lookup, deleting an entry that is no longer valid, and, where supported, a different address family. The intended tunnel should recover while unrelated direct traffic stays under policy. A successful first connection proves only that the initial translation happened to be correct.