This chapter covers Azure Firewall design, focusing on FQDN (Fully Qualified Domain Name) rules, a critical component for securing outbound traffic in Azure. For the AZ-305 exam, understanding how to design and implement Azure Firewall with FQDN rules is essential, as it appears in approximately 15-20% of questions related to network security and hybrid connectivity. You will learn the internal mechanisms, configuration steps, and common pitfalls to design a robust firewall architecture that meets enterprise security requirements.
Jump to a section
Azure Firewall with FQDN rules is like a corporate mailroom that inspects all incoming and outgoing packages. The mailroom has a list of approved senders and recipients (FQDN rules) and a list of blocked ones. When a package arrives, the mailroom clerk checks the sender's address against the approved list. If the sender is approved, the package is delivered; if not, it is rejected. However, the clerk does not open the package to see what's inside—they only look at the label. This is analogous to Azure Firewall's application rules for FQDN filtering, which inspect the HTTP/S Host header or TLS SNI extension to determine the destination domain, without decrypting the payload. The mailroom also has a separate security team (network rules) that can inspect the package's dimensions and weight (source/destination IP and port). But for FQDN rules, the key point is that the clerk must have a way to resolve the sender's name to a physical address (DNS resolution). If the sender's name is not in the directory, the package cannot be processed. Similarly, Azure Firewall uses DNS proxy to resolve FQDNs to IP addresses before applying rules. This separation of concerns—label inspection vs. content inspection—mirrors how Azure Firewall handles FQDN rules at Layer 7 versus network rules at Layers 3/4.
What is Azure Firewall and Why FQDN Rules Matter
Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service with built-in high availability and unrestricted cloud scalability. FQDN rules are a type of application rule that allow or deny outbound traffic based on the destination's fully qualified domain name (e.g., *.windowsupdate.com). This is crucial because modern applications often use many IP addresses behind a single domain, making IP-based rules impractical. FQDN rules enable granular control over outbound access to SaaS applications, Azure services, and internet resources.
How FQDN Rules Work Internally – Step Through the Mechanism
When a virtual machine in a subnet protected by Azure Firewall initiates an outbound HTTP/HTTPS request to www.example.com, the following occurs:
DNS Resolution: The VM first resolves www.example.com to an IP address via DNS. Azure Firewall can act as a DNS proxy (if configured) to forward DNS requests to Azure DNS or custom DNS servers. The firewall caches the DNS response for the TTL period (default 300 seconds for Azure DNS).
Packet Arrival: The VM sends the TCP SYN packet to the destination IP. The firewall intercepts this packet because it is the default gateway for the subnet (via a user-defined route, UDR, pointing to the firewall's private IP).
Session Establishment: The firewall performs stateful inspection. It checks the packet's source IP, destination IP, source port, destination port, and protocol against its network rules (if any). If a network rule matches, the packet is processed; otherwise, the firewall continues to application rules.
FQDN Resolution: For application rules, the firewall needs to know the FQDN. For HTTP traffic, the firewall inspects the HTTP Host header in the first packet's payload. For HTTPS traffic, the firewall inspects the TLS Server Name Indication (SNI) extension in the ClientHello message. The firewall extracts the FQDN from these fields.
Rule Matching: The firewall compares the extracted FQDN against the configured FQDN tags (e.g., AzureBackup, WindowsUpdate) and custom FQDN rules. If a matching rule is found with action Allow, the connection is permitted. If a matching rule is found with action Deny, the connection is dropped. If no rule matches, the connection is dropped by default (implicit deny).
Session Tracking: The firewall maintains a state table for each connection. Subsequent packets belonging to the same session are allowed without re-inspection, based on the 5-tuple (source/destination IP, source/destination port, protocol) until the session ends or a timeout occurs (e.g., 4 minutes for idle TCP connections).
Key Components, Values, Defaults, and Timers
FQDN Tags: Predefined sets of Microsoft-managed FQDNs for common Azure services. Examples: AzureBackup, WindowsUpdate, AzureKubernetesService. These tags are automatically updated by Microsoft and cannot be modified. They simplify rule creation for common scenarios.
Custom FQDN Rules: User-defined rules with fields: Name, Source IPs (or CIDR), Destination FQDNs (e.g., *.contoso.com), Protocols (e.g., http:80, https:443), and Action (Allow/Deny).
DNS Proxy: When enabled, the firewall uses its own IP as the DNS server for the protected subnets. This ensures that the firewall can resolve FQDNs consistently and cache results. Default DNS proxy timeout: 5 seconds.
TLS Inspection: Azure Firewall does not perform TLS termination/decryption. It relies on the SNI field in the ClientHello. If the client does not send SNI (e.g., older clients or non-TLS traffic), the firewall cannot extract the FQDN and will fall back to network rules or deny the traffic.
Default Action: Implicit deny for all traffic that does not match any rule. To allow outbound internet access, you must explicitly create allow rules.
Rule Collection Order: Rules are evaluated in order of priority (lowest number = highest priority) within a rule collection group. Network rules are evaluated before application rules. Once a match is found, no further rules are evaluated.
Configuration and Verification Commands
To deploy Azure Firewall with FQDN rules, you typically use Azure CLI, PowerShell, or ARM templates. Example Azure CLI commands:
# Create a firewall
az network firewall create --name MyFirewall --resource-group MyRG --location eastus
# Create a public IP for the firewall
az network public-ip create --name MyFirewallIP --resource-group MyRG --location eastus --allocation-method Static --sku Standard
# Configure the firewall
az network firewall ip-config create --firewall-name MyFirewall --name MyConfig --public-ip-address MyFirewallIP --resource-group MyRG --vnet-name MyVNet
# Add an application rule collection
az network firewall application-rule create --collection-name MyAppRules --firewall-name MyFirewall --name AllowWindowsUpdate --resource-group MyRG --action Allow --source-addresses 10.0.1.0/24 --protocols http=80 https=443 --target-fqdns *.windowsupdate.com --priority 200To verify, use:
# List all application rules
az network firewall application-rule list --firewall-name MyFirewall --resource-group MyRG -o table
# Show firewall diagnostics (requires Log Analytics)
az monitor diagnostic-settings show --name MyDiagSetting --resource /subscriptions/.../.../MyFirewallHow FQDN Rules Interact with Related Technologies
Azure DNS: The firewall uses Azure DNS (or custom DNS) to resolve FQDNs. If DNS resolution fails, the connection is denied. Ensure DNS is properly configured in the virtual network.
Network Rules: If both network and application rules match, the network rule takes precedence because it is evaluated first. However, if a network rule allows traffic to any IP on port 443, but an application rule denies the specific FQDN, the network rule will allow the traffic because application rules are not evaluated after a network rule match. To enforce FQDN-based control, you must ensure that no overly permissive network rules exist.
Azure Policy: You can use Azure Policy to enforce firewall deployment and rule configurations across subscriptions.
Azure Firewall Manager: Centralized management of firewall policies across multiple Azure Firewalls. Policies can include application rules, network rules, and threat intelligence settings.
Threat Intelligence and FQDN Rules
Azure Firewall can integrate with Microsoft Threat Intelligence to alert or deny traffic to/from known malicious IPs and FQDNs. This is configured in the firewall policy under Threat Intelligence settings. When enabled, the firewall compares the destination FQDN against the threat intelligence feed. If a match is found, the action (Alert/Deny) is applied before any rule evaluation. This is a critical feature for enterprise security and is tested on the exam.
Performance and Scale Considerations
Throughput: Azure Firewall supports up to 100 Gbps (Standard SKU) and 250 Gbps (Premium SKU) with multiple public IPs and scaled-out instances.
Concurrent Connections: Up to 2 million for Standard, 5 million for Premium.
Rule Limits: Maximum 10,000 application rules per firewall policy. Rule collection groups can have up to 20,000 rules.
Latency: FQDN resolution adds minimal latency (typically <5 ms). DNS proxy caching reduces repeated lookups.
SNAT Ports: Each outbound connection uses a SNAT port. Azure Firewall uses Source Network Address Translation (SNAT) for outbound traffic. The number of available SNAT ports per public IP is 64,000 (Standard SKU). For high-scale scenarios, use multiple public IPs or a NAT gateway in front of the firewall.
Premium Features Related to FQDN Rules
Azure Firewall Premium adds: - TLS Inspection: Terminates inbound TLS connections, decrypts traffic, applies rules, and re-encrypts. This allows inspection of the full HTTP/HTTPS payload, not just the SNI. However, this is for inbound traffic only; outbound TLS inspection is not supported. - IDPS: Intrusion Detection and Prevention System that can inspect traffic for malicious patterns, even in encrypted traffic (if TLS inspection is enabled). - Web Categories: Predefined categories (e.g., SocialMedia, AdultContent) that can be used in application rules to allow/deny based on URL categorization.
Common Exam Scenarios
Scenario 1: A company wants to allow outbound access only to *.microsoft.com and *.azure.com for VMs in a subnet. Solution: Create an application rule collection with those FQDNs and action Allow. Ensure no network rules allow traffic to all IPs on port 443.
Scenario 2: A VM needs to connect to an Azure SQL database using a private endpoint. Since the traffic stays within the Azure backbone and does not traverse the firewall, FQDN rules are not needed. The exam may test that private endpoints bypass the firewall.
Scenario 3: A VM must access example.com but the FQDN resolves to multiple IPs that change frequently. FQDN rules are ideal because they work regardless of IP changes.
Traps to Avoid
Trap 1: Thinking that FQDN rules can inspect HTTPS traffic content. They only see the SNI; they cannot see the full URL or payload without TLS inspection (Premium).
Trap 2: Assuming that FQDN rules apply to all protocols. They only apply to HTTP/HTTPS (ports 80/443). For other protocols (e.g., SSH, RDP), use network rules with IP addresses.
Trap 3: Forgetting to configure DNS proxy. Without it, the firewall may not resolve FQDNs correctly, leading to denied connections.
Trap 4: Overlooking that network rules take precedence. If a network rule allows 0.0.0.0/0 on port 443, FQDN rules will not be evaluated for that traffic.
Best Practices
Use FQDN tags for common Microsoft services to reduce rule management overhead.
Combine FQDN rules with network rules for a defense-in-depth approach.
Enable DNS proxy to ensure consistent DNS resolution.
Use Azure Firewall Manager for centralized policy management across multiple firewalls.
Monitor firewall logs in Azure Monitor for denied traffic and adjust rules accordingly.
Regularly review and prune unused rules to maintain performance.
Configure DNS Proxy
Enable DNS proxy on the Azure Firewall to ensure that DNS queries from protected subnets are forwarded through the firewall. This allows the firewall to resolve FQDNs consistently and cache results. Without DNS proxy, the firewall may not see DNS queries and may not be able to resolve FQDNs for rule matching. To enable, set `dns-proxy-enabled` to `true` in the firewall policy. The firewall will then listen on port 53 for DNS queries from the virtual network. Ensure the virtual network's DNS server is set to the firewall's private IP address.
Create Application Rule Collection
Define a rule collection that groups FQDN rules together. Each rule collection has a priority (lower number = higher priority). Within the collection, rules are evaluated in order. Specify the action (Allow or Deny) for the collection. For example, create a collection named 'Allow-Microsoft' with priority 200 and action Allow. Then add rules that specify source IPs (e.g., 10.0.1.0/24), destination FQDNs (e.g., *.microsoft.com), and protocols (http:80, https:443).
Add FQDN Rules with Tags
Use FQDN tags to simplify rule creation for common Azure services. For instance, to allow outbound access to Azure Backup, add a rule with destination FQDN tag 'AzureBackup'. The firewall automatically updates the IP addresses behind the tag. This reduces maintenance. For custom domains, use explicit FQDNs with wildcards (e.g., *.contoso.com). Ensure the rule is placed in the correct collection and priority order.
Verify Rule Evaluation Order
Understand that Azure Firewall evaluates network rules before application rules. If a network rule matches a packet, application rules are not evaluated. For FQDN rules to work, ensure no network rule allows the traffic to all IPs on the same port. For example, if a network rule allows outbound to any IP on port 443, FQDN rules will not be applied. To enforce FQDN-based control, either remove such network rules or restrict them to specific IPs.
Monitor and Troubleshoot
Use Azure Firewall logs to see which rules are being matched and which traffic is denied. Enable diagnostic settings to send logs to Log Analytics, Storage Account, or Event Hubs. Key logs: AzureFirewallApplicationRule (for application rule hits), AzureFirewallNetworkRule (for network rule hits), and AzureFirewallDnsProxy (for DNS proxy queries). Common issues: DNS resolution failures (check DNS server configuration), SNI not present (use TLS inspection only for inbound), and rule priority misconfiguration.
Enterprise Scenario 1: Secure Outbound Internet Access for a Financial Services Company
A large financial services company migrated its workloads to Azure and needed to restrict outbound internet access to only approved Microsoft and partner services. They deployed Azure Firewall in a hub-and-spoke topology. The hub virtual network contained the firewall, and all spoke virtual networks were peered to the hub. User-defined routes (UDRs) in each spoke pointed default traffic (0.0.0.0/0) to the firewall's private IP. The security team created application rule collections with FQDN tags for AzureBackup, WindowsUpdate, and AzureActiveDirectory. They added custom FQDN rules for their SaaS partners (e.g., *.salesforce.com). Network rules were kept minimal—only for DNS (port 53) and NTP (port 123). The firewall handled up to 5 Gbps of outbound traffic with 500,000 concurrent connections. Performance was stable, but they learned to monitor SNAT port exhaustion. They added three public IPs to the firewall to increase available SNAT ports to 192,000. A common misconfiguration was forgetting to update UDRs when new spokes were added, causing traffic to bypass the firewall. They automated UDR deployment using Azure Policy.
Enterprise Scenario 2: Healthcare Provider with Strict Compliance Requirements
A healthcare provider needed to comply with HIPAA regulations, which required logging all outbound traffic and preventing access to malicious domains. They deployed Azure Firewall Premium with threat intelligence-based filtering and FQDN rules. They enabled DNS proxy to ensure all DNS queries were logged. They created application rules to allow only specific medical SaaS applications (e.g., *.epic.com, *.cerner.com). They used web categories to block social media and adult content. The firewall logs were sent to Azure Sentinel for security analysis. One challenge was that some legacy medical devices did not support SNI in TLS, so the firewall could not identify the FQDN for those connections. They had to fall back to network rules with static IPs for those devices, which required manual updates when IPs changed. They also faced performance issues when the firewall had to inspect many concurrent connections from IoT devices. They scaled up to a Premium SKU with multiple instances.
Enterprise Scenario 3: E-commerce Platform with Dynamic IPs
An e-commerce platform used a CDN that frequently changed its origin IPs. They relied on FQDN rules to allow outbound traffic to their CDN provider (e.g., *.cloudfront.net). The firewall's DNS proxy resolved the FQDN and cached the IPs. However, during a DDoS attack, the CDN changed IPs rapidly, causing the firewall's cache to become stale. Connections were denied until the TTL expired. They mitigated this by reducing the DNS TTL on their custom DNS server to 60 seconds. They also implemented a secondary firewall in a different region for redundancy. This scenario highlights the importance of understanding DNS caching behavior with FQDN rules.
AZ-305 Exam Focus: Azure Firewall Design and FQDN Rules
The AZ-305 exam tests your ability to design network security solutions, including Azure Firewall. The relevant objective is "Design a network infrastructure solution" (AZ-305: Design network solutions), specifically the sub-objective "Design a network security solution" (AZ-305: Design network security). Questions often present a scenario with specific requirements (e.g., allow outbound to only certain domains, meet compliance, handle high throughput) and ask you to choose the correct design.
Common Wrong Answers and Why Candidates Choose Them
Choosing Network Security Groups (NSGs) over Azure Firewall: Candidates often pick NSGs because they are free and simpler. However, NSGs do not support FQDN rules; they only filter based on IP addresses and ports. For FQDN-based filtering, Azure Firewall is required. The exam tests this distinction.
Selecting Azure Firewall Standard when Premium is needed: Candidates may choose Standard to save costs, but if the scenario requires TLS inspection or IDPS, Premium is necessary. The exam often includes a requirement for "inspect encrypted traffic" or "detect intrusions."
Assuming FQDN rules work for all protocols: Many candidates think FQDN rules can filter any outbound traffic, but they only work for HTTP/HTTPS (ports 80/443). For other protocols, network rules with IP addresses are required.
Forgetting DNS proxy configuration: A common trap is that without DNS proxy, the firewall may not resolve FQDNs correctly. The exam may present a scenario where traffic is denied because DNS resolution fails, and the correct answer is to enable DNS proxy.
Specific Numbers, Values, and Terms That Appear on the Exam
Default SNAT port count per public IP: 64,000 (Standard SKU).
Maximum concurrent connections: Standard: 2 million, Premium: 5 million.
Rule limits: 10,000 application rules per policy.
FQDN tag examples: AzureBackup, WindowsUpdate, AzureKubernetesService, AzureActiveDirectory.
DNS proxy timeout: 5 seconds.
TLS inspection: Only available in Premium SKU and only for inbound traffic.
Web categories: Premium feature.
Edge Cases and Exceptions the Exam Loves to Test
Traffic to Azure PaaS services via private endpoints: Private endpoints bypass the firewall because traffic stays within the Microsoft backbone. The exam may test that FQDN rules are not needed for such traffic.
FQDN rules with wildcards: The exam tests that wildcards are allowed (e.g., *.contoso.com) and that they match any subdomain.
Multiple public IPs for SNAT: To avoid SNAT port exhaustion, you can add multiple public IPs to the firewall. The exam may ask how to handle high-scale outbound traffic.
Threat intelligence integration: The exam may test that threat intelligence rules are evaluated before custom rules.
How to Eliminate Wrong Answers Using the Underlying Mechanism
When evaluating answer choices, ask: (1) Does the solution support FQDN filtering? (2) Does it require TLS inspection? (3) Is DNS proxy configured? (4) Are network rules too permissive? For example, if an answer suggests using NSGs with FQDN rules, eliminate it because NSGs do not support FQDNs. If an answer suggests Azure Firewall Standard for TLS inspection, eliminate it because only Premium supports TLS inspection. By understanding the mechanism, you can quickly identify incorrect options.
Azure Firewall FQDN rules filter outbound HTTP/HTTPS traffic based on the domain name extracted from the Host header (HTTP) or SNI field (TLS).
FQDN rules only apply to ports 80 and 443; other protocols require network rules with IP addresses.
Network rules are evaluated before application rules; a matching network rule prevents application rule evaluation.
FQDN tags are predefined Microsoft-managed sets of FQDNs for common Azure services and cannot be customized.
DNS proxy must be enabled and the virtual network's DNS server set to the firewall's private IP for consistent FQDN resolution.
Azure Firewall Standard supports up to 2 million concurrent connections and 64,000 SNAT ports per public IP.
Azure Firewall Premium adds TLS inspection (inbound only), IDPS, and web categories.
Threat intelligence rules are evaluated before custom rules and can alert or deny traffic to malicious domains.
Private endpoints bypass Azure Firewall; traffic to PaaS services via private endpoints does not go through the firewall.
Wildcards are allowed in FQDN rules (e.g., *.contoso.com) and match any subdomain.
These come up on the exam all the time. Here's how to tell them apart.
Azure Firewall Standard
Supports FQDN rules based on SNI inspection for outbound HTTPS.
Maximum concurrent connections: 2 million.
No TLS inspection capability.
No IDPS (Intrusion Detection/Prevention).
No web categories for URL filtering.
Azure Firewall Premium
Supports FQDN rules plus TLS inspection for inbound traffic.
Maximum concurrent connections: 5 million.
TLS termination and inspection for inbound traffic (re-encrypts).
Includes IDPS for threat detection in both plaintext and encrypted traffic (if TLS inspection is on).
Includes web categories for filtering by content type (e.g., social media, adult).
Mistake
Azure Firewall can filter outbound HTTPS traffic by inspecting the full URL.
Correct
Azure Firewall (Standard) only inspects the TLS SNI field in the ClientHello message, which contains the domain name, not the full URL. Premium SKU can perform TLS inspection for inbound traffic, but not outbound. Full URL inspection for outbound HTTPS is not supported.
Mistake
FQDN rules work for any protocol, including SSH and RDP.
Correct
FQDN rules only apply to HTTP/HTTPS (ports 80/443). For other protocols like SSH (port 22) or RDP (port 3389), you must use network rules with IP addresses. The firewall cannot extract an FQDN from non-HTTP traffic.
Mistake
FQDN tags are user-configurable and can be customized.
Correct
FQDN tags are predefined by Microsoft and cannot be modified or created. They cover common Azure services like Azure Backup and Windows Update. For custom domains, you must create explicit FQDN rules.
Mistake
Azure Firewall automatically resolves FQDNs without any configuration.
Correct
The firewall can resolve FQDNs using its own DNS resolution, but for consistent behavior, you should enable DNS proxy and set the virtual network's DNS server to the firewall's private IP. Without DNS proxy, the firewall may not have visibility into DNS queries.
Mistake
Network rules are evaluated after application rules.
Correct
Network rules are evaluated before application rules. If a network rule matches a packet, application rules are not evaluated. This means that to enforce FQDN-based control, you must ensure that no network rule allows traffic to all IPs on the same port.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Azure Firewall's FQDN rules only inspect HTTP/HTTPS traffic (ports 80/443). For SSH (port 22) or other protocols, you must use network rules with IP addresses. The firewall extracts the FQDN from the HTTP Host header or TLS SNI field, which is only present in HTTP/HTTPS traffic. For exam scenarios, if the requirement is to filter by domain name for non-HTTP traffic, the correct solution is to use a third-party NVA or Azure Firewall with a different approach (not supported natively).
FQDN tags are predefined sets of FQDNs managed by Microsoft for common Azure services (e.g., AzureBackup, WindowsUpdate). They simplify rule creation and are automatically updated. Custom FQDN rules are user-defined for any domain (e.g., *.contoso.com). Both are used in application rule collections. On the exam, remember that FQDN tags cannot be created or modified, and they are only for Microsoft services.
Possible reasons: (1) A network rule with higher priority matches and denies the traffic before application rules are evaluated. (2) DNS resolution fails—the firewall cannot resolve the FQDN to an IP. Ensure DNS proxy is enabled and the virtual network's DNS server points to the firewall. (3) The client does not send SNI in TLS (e.g., old browser), so the firewall cannot extract the FQDN and falls back to network rules. (4) The traffic uses a protocol other than HTTP/HTTPS. Check firewall logs for details.
Azure Firewall Standard cannot inspect the full URL of outbound HTTPS traffic because it does not perform TLS decryption. It only sees the domain from the SNI. To block specific URLs (e.g., example.com/blocked), you need a web proxy or a next-generation firewall that can decrypt TLS. Azure Firewall Premium can inspect inbound HTTPS traffic but not outbound. For outbound, consider using a third-party NVA or Azure Web Application Firewall (WAF) in front of a reverse proxy.
When DNS proxy is disabled, the firewall does not act as a DNS server. It relies on the DNS resolution performed by the client or the virtual network's DNS server. However, the firewall may still resolve the FQDN itself if needed, but it does not cache DNS responses from client queries. This can lead to inconsistent behavior. It is recommended to enable DNS proxy to ensure the firewall has a consistent view of DNS resolutions and can cache them for performance.
Each outbound connection uses a SNAT port. Azure Firewall Standard provides 64,000 SNAT ports per public IP. If you exceed this, connections may fail due to port exhaustion. To scale, add multiple public IPs to the firewall (up to 250 in Standard). Alternatively, use a NAT gateway in front of the firewall (but this changes the architecture). Monitor SNAT port usage in Azure Monitor. The exam may test that you need to add public IPs for high-scale outbound scenarios.
Yes, if the traffic goes through the firewall (e.g., via forced tunneling). For example, a VM accessing Azure SQL Database over the internet can be filtered using FQDN rules with the SQL database's FQDN. However, if you use a private endpoint, the traffic bypasses the firewall entirely because it stays within the Azure backbone. On the exam, remember that private endpoints do not go through the firewall.
You've just covered Azure Firewall Design and FQDN Rules — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?