Context
An Azure Firewall network rule names an allowed FQDN, yet a client intermittently cannot connect. One possible cause is that the client and firewall resolved the name differently. Aligning their DNS view is essential when the rule's permitted destination addresses are derived from DNS.
Identify the exact rule type
Distinguish an FQDN in a network rule from an application rule. Their inspection and matching behavior differs. Record protocol, destination port, rule collection, policy hierarchy, target hostname, and the actual denied destination address.
Do not replace a protocol-specific application rule with a broad network allow merely because both accept a hostname in configuration. Select the rule type that matches the service's protocol and intended security boundary, then troubleshoot its documented behavior.
Trace the client's resolver path
Inspect the DNS servers configured in the VNet and guest, including custom forwarders and any application-level resolver. A recent VNet DNS change may not have been adopted by every running client yet. Verify the resolver used by the process rather than relying only on the VNet's saved setting.
Microsoft recommends enabling Azure Firewall DNS proxy and configuring clients to use it for FQDN filtering in network rules. This helps the client and firewall use a consistent resolution path. Enabling the proxy without updating the clients leaves part of that configuration incomplete.
Compare DNS answers with denied flows
For a bounded incident interval, collect the hostname's answer set, TTL, resolver identity, lookup time, and the destination address used by the failed connection. Compare these with firewall DNS and rule evidence where logging is configured.
A name can legitimately resolve to several addresses or change over time. Two independent resolvers can therefore return different usable answers. A static test hours after the incident may miss the mismatch that affected the original request.
Include negative caching when diagnosing a newly created or repaired record. A resolver can continue reporting a previous negative result until its applicable cache behavior changes. Repeated client retries do not necessarily force the firewall and client to obtain a new answer simultaneously.
Inspect policy inheritance and upstream DNS
Review DNS settings in the effective firewall policy, including inherited settings and intentional child overrides. The visible standalone firewall settings may not describe the effective policy configuration.
Confirm the proxy can reach its configured upstream DNS servers and that the upstream forwarding graph has no loop. Test public names, private names, and deliberate exceptions separately. A rule correction that breaks private endpoint resolution can improve one destination while disabling another essential dependency.
An illustrative rotating-address failure
A third-party service rotates destination addresses. Application VMs use a corporate resolver, while the firewall resolves through a different upstream path. Both receive legitimate answers at different times, but the client's selected address is absent from the firewall's current permitted set.
The team aligns the supported DNS proxy path and verifies actual connections across answer changes. It preserves narrow destination and port scope. Adding every observed address permanently would have hidden the inconsistency and created a growing, stale allow list.
Quick diagnostic map
| Evidence | Hypothesis | Next check |
|---|---|---|
| Allowed FQDN; denied resolved address | Resolution mismatch | Client and firewall DNS paths |
| Proxy enabled; some clients still fail | Client configuration incomplete | Effective guest resolver |
| Parent policy differs from local setting | Inherited configuration | Effective policy DNS settings |
| New record still appears nonexistent | Negative cache or authority issue | Resolver response and TTL context |
A focused operator exercise
Use a test hostname with controlled address changes and a narrowly scoped network rule. Record the client's resolver, returned addresses, actual connection destination, and firewall outcome before and after each change. Keep test TTLs and observation times explicit.
Repeat with the intended DNS proxy configuration and verify private-name resolution as well. Exercise an upstream resolver outage in nonproduction and observe application recovery. The acceptance receipt should demonstrate consistent resolution and permitted traffic, plus deliberate rejection of an unapproved destination.
Keep DNS ownership in firewall operations
Assign responsibility for the upstream resolver, proxy configuration, client adoption, and policy review. These components often have different owners, so a single saved firewall change is not a complete rollout.
Monitor resolution failures and denied-flow trends without recording unnecessary sensitive query content. Add effective DNS checks to new subnet and VM provisioning so future clients inherit the intended path.
Frequently asked questions
Is enabling DNS proxy alone sufficient?
No. Verify clients use the supported proxy path and that the effective firewall policy and upstream DNS are correct.
Should I replace an FQDN rule with permanent IP addresses?
Only when the destination contract supports that design. Dynamic services can change addresses; investigate DNS consistency before maintaining a manual list.
Continue the investigation
- Azure DNS Private Resolver: Trace a Forwarding Loop
- Azure Private Endpoint DNS: Explain Why Clients Still Resolve Publicly
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Firewall & Perimeter Security to discuss implementation, validation and operational handover.