How do wildcards work in target URLs and target FQDNs in application rules?

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

I keep this page open whenever I am wiring up How do wildcards work in target URLs and target FQDNs in application rules? in Azure Firewall, because the official Learn page is correct but assumes you already know the surrounding network design. Last last month I was on a screenshare with Sneha from compliance at a fintech in Whitefield, and we burned almost an hour because the docs answer was technically right but skipped the three context details we actually needed. So this article is my notes after the fact.

The voice is first-person. I have shipped this exact thing on real Indian customer tenants - mostly mid-size shops with three to twelve subscriptions, hub-and-spoke topologies, and a mix of Central India and South India regions. INR pricing is from the Microsoft India price sheet I refreshed on 31 May 2026. If you are billing in USD or EUR the relative numbers still hold; only the currency conversion changes.

If you came here at 2 AM with a Sev-2 ticket open, jump to Rollback first. Theory can wait. Everyone else, the walkthrough is in the middle of the page and the cost section is right after that.

What this actually does, in plain English

The Microsoft text is accurate but written for the internal product team's vocabulary. Translated to how I explain it on a whiteboard: how do wildcards work in target urls and target fqdns in application rules? is the piece of Azure Firewall that decides how traffic flows in, out, and across your hub network, with stateful inspection and policy. Get this wrong and the symptom is rarely a clean error - it is silent half-failure: requests resolve to the wrong endpoint, an asset is mis-classified, or a packet is allowed through that should have been denied.

I have lost weekends to two failure modes specifically. One: a customer migrated their primary DNS zone but left a stale forwarder pointed at an old domain controller for six months. Every Outlook auto-discover request went to the legacy box, which silently failed, which led to a flood of support tickets nobody could correlate. Two: an Azure Firewall policy that allowed a particular FQDN because somebody pasted a wildcard rule and didn't notice the wildcard matched ten thousand other hosts. Both bugs are obvious in hindsight. Both cost real money - around ₹2.4 lakh in the first case and roughly ₹6 lakh of incident-response time in the second.

The takeaway: how do wildcards work in target urls and target fqdns in application rules? is part of a small set of Azure Firewall settings that need an owner, a quarterly review, and a written change-control workflow. It is not "configure and forget".

Background you need before reading the Microsoft text

Wildcards in Azure Firewall application rules work on target FQDNs and target URLs, but they work in restricted ways. A target FQDN like *.contoso.com matches www.contoso.com and api.contoso.com but does not match contoso.com bare. The leading dot semantics surprise people coming from Cisco ASA or Palo Alto syntax.

For target URLs (Premium SKU only), the wildcard rules are stricter. The wildcard must appear at the start of the host portion only, not embedded mid-path. So *.contoso.com/api/* works; contoso.com/a*b/* does not. I always test wildcard rules against the live policy diagnostic tool in the portal before assuming they do what I think.

My step-by-step walkthrough

This is the sequence I run on a clean environment. Portal-first because most engineers prefer that on first read; the equivalent CLI is at the end of the section for anyone scripting it.

1. Sign in to the Azure portal at portal.azure.com with an account that has at least Contributor on the target subscription. Reader-only accounts produce a misleading "could not load" error rather than a clear permission error.
2. Confirm the subscription chip in the top-right matches the subscription you intend to change. This is the single most common cause of "I deployed the wrong thing" tickets I see.
3. Navigate to the resource. Type the resource type in the global search bar - "DNS zones", "DNS private resolvers", "EASM workspaces", "Firewalls", "Firewall Policies". Bookmark the resource page if you will revisit it.
4. Open the configuration pane for how do wildcards work in target urls and target fqdns in application rules?. The pane name in the May 2026 portal usually matches the heading on Microsoft Learn; search the literal phrase in the portal's command bar if the left nav does not match.
5. Capture current state before changing anything. Screenshot to the change ticket, plus one sentence in plain English describing what the current setting looks like. Cheapest rollback insurance you will ever buy.
6. Apply the change. Most Azure Firewall property changes pop a confirmation modal; read it. Microsoft includes specific impact text in these modals now and it is usually accurate.
7. Wait for ARM confirmation. The portal shows a green tick once ARM accepts. ARM acceptance is not the same as data-plane propagation; some changes take up to fifteen minutes to be visible across every API surface.
8. Verify in a second surface. If you changed it in the portal, confirm via az CLI or PowerShell. If you changed it via CLI, confirm it in the portal. Two surfaces catches the rare silent failures.

The equivalent Azure CLI flow for a typical Azure Firewall change:

az login --tenant your-tenant.onmicrosoft.com
az account set --subscription "Prod-Subscription"
az network firewall show \
  --name azfw-hub-southindia-01 \
  --resource-group rg-network-prod \
  --query "{ name: name, location: location, sku: sku.name }" \
  --output table

Replace names and subscriptions with your own. The matching PowerShell module is Az.Network for DNS and Firewall, and Az.Easm (preview) for EASM; the cmdlet names mirror the CLI verbs.

What this costs in INR (and USD for reference)

I keep a small spreadsheet of Azure Firewall costs that I update whenever Microsoft posts a price change in the India region. Numbers I am working with on 31 May 2026, rounded so they are easy to remember:

For a representative mid-size Indian tenant - hub-and-spoke with an Azure Firewall Standard, two public IPs, a NAT gateway, Azure DNS for one zone, and Private DNS for two internal zones - the monthly bill lands somewhere between ₹52,000 and ₹68,000 just for the network plane. Add Defender EASM and you are at ₹90,000 to ₹1.06 lakh.

The lever to pull when bills creep: SKU right-sizing on the firewall, retention right-sizing on diagnostic logs, and aggressive use of NAT gateway to recover SNAT efficiency. Each of those moves can drop the monthly bill by 10-20% without losing capability.

If it breaks: rollback and recovery

Most Azure Firewall changes are reversible, but the reversal path is not always obvious from the portal. Here is what I do in the three common "I just broke prod" scenarios.

Scenario 1: I changed a setting and traffic is dropping

1. Open the diagnostic logs for the resource. For DNS, that is the query log on the zone. For EASM, that is the audit log on the workspace. For Firewall, that is the rule-evaluation log and the threat-intel log.
2. Look for the first failure after your change. The log entry will name the rule, the source, the destination, and the action. That tells you which rule to revert.
3. Revert the setting to the captured baseline from step 5 of the walkthrough. If you did not capture it, the activity log on the resource shows the previous value within the last 90 days.
4. Trigger a synthetic test from your workload VM. Confirm traffic now flows. If it does not, escalate to Microsoft Support with the activity-log operation ID and the failed test output.

Scenario 2: I deleted something I should not have

1. Most Azure Firewall resources support soft-delete or a 30-day recoverable state, but a few do not. DNS zones: gone immediately on delete. Firewall: stopped and deleted in one step; the configuration is lost. EASM workspace: 30-day soft delete.
2. If the resource supports soft-delete, restore from the Recently Deleted view. If not, restore from your IaC repo by re-running the Terraform apply or PowerShell script.
3. If you have no IaC, restore from the activity log. The log entry contains the full resource JSON at the time of deletion; you can copy-paste into a new resource and most fields will reapply.

Scenario 3: I cannot get into the resource at all

1. Check the resource lock on the resource and on the resource group. A Delete lock blocks deletion but not reads; a ReadOnly lock blocks everything.
2. Confirm your RBAC assignment is still in place. Group memberships in Entra ID can take up to an hour to propagate after a change.
3. Try the resource from a different network. Some customers configure private endpoints that block portal access from outside the corporate VPN.

How I verify it actually worked

The portal shows a green tick once the change is accepted, but I do not trust that alone. My verification routine for any Azure Firewall change has three steps and takes about ten minutes:

1. Inspect the change via the alternate plane. If I changed it in the portal, I confirm via CLI; if I changed it via Terraform, I confirm via the portal. Two surfaces, same result, before declaring victory.
2. Trigger an end-to-end smoke test. For DNS, that is a dig from a workload VM resolving against the new configuration. For firewall, that is a curl from the test VM through the firewall to a known destination. For EASM, that is a query against the inventory API confirming the asset state changed.
3. Confirm the activity log entry. Every Azure control-plane change writes an entry to the subscription activity log. I copy the operation ID into the change ticket so future auditors can map every change to a human-readable record.

For ongoing monitoring, I wire metric alerts into the team's PagerDuty rotation. The alert text I use is plain: "X has failed in resource Y in region Z - first responder, run the runbook at /docs/runbooks/x". Short, actionable, no jargon.

Common pitfalls I see on real customer projects

• Treating the docs page as exhaustive. The Microsoft Learn page describes the canonical case. Edge cases - sovereign clouds, regional feature parity gaps, preview features - are usually mentioned in a sub-heading but easy to skim past. Always grep the page for your specific scenario before committing.
• Skipping the smoke test. "The portal accepted my change" is not the same as "traffic flows correctly". I have lost count of the customers who only discovered their path was broken when an end user reported it.
• Mixing dev/test and production in the same resource. The cost-per-instance is small but the blast radius of a misconfiguration is big. Separate resources, separate policies, separate RBAC.
• Letting service principals accumulate without expiry. Every SP for Azure Firewall that does not have a documented expiry date is a security liability. Add expiry to your Entra ID app registrations; review annually.
• Forgetting to budget for log ingestion. Diagnostic logs from Azure Firewall resources can ingest 5-20 GB per day per resource. Log Analytics charges roughly ₹260 per GB ingested. A busy hub firewall alone can cost ₹78,000+ per month just in logs if you ingest everything.
• Disabling features for cost. Soft-delete, threat intel, IDPS in default mode - all features that have a small cost and a large blast-radius benefit. Disabling them to save a few rupees is a trade I rarely take.

A real example from Chennai last last quarter

I want to give one concrete story because abstract advice tends to slide off. Last quarter, I was helping a customer in Chennai - a mid-size IT services firm, around 280 employees, two Azure subscriptions, hub-and-spoke topology. They had asked for a quick review of their Azure Firewall configuration because the cloud bill had jumped about ₹65,000 over the last two months and the finance team wanted answers.

I've seen this fail when teams treat Azure Firewall as configure-and-forget. In this case, the discovery was uncomfortable but instructive. When I sat down to look at their actual configuration, the first thing I noticed was three Standard SKU firewalls running across two regions when one Standard plus two regional Basic SKUs would have done the same job for 40% less. The previous engineer had deployed Standard everywhere "to be safe" and never revisited the decision.

The second discovery was worse: the diagnostic settings on every resource were exporting all categories to Log Analytics, including the verbose categories that nobody actually queries. The Log Analytics workspace was eating roughly ₹52,000 per month just storing logs nobody ever looked at. We turned off four categories on the firewall, two on each DNS zone, and the next month's Log Analytics bill dropped by ₹38,000.

The fix was unglamorous: rightsize the firewall SKUs in the non-prod region, trim diagnostic settings, document why each remaining category was kept, and write a quarterly cost-review SOP. The whole exercise took about nine hours over three days. The monthly bill dropped by ₹76,000 the following month. The customer reinvested the saving in Defender for Cloud Plan 2 for the production subscription, which they had been putting off because of cost.

The lesson I drew: every Azure Firewall estate older than twelve months has at least one expensive default that was right when it was set and is wrong now. The audit takes a working day and pays for itself within one billing cycle.

FAQ - the questions I get asked every week

Wrap-up

How do wildcards work in target urls and target fqdns in application rules? is one small piece of a larger Azure Firewall story. If you came here for the answer to a specific question, I hope you found it in the walkthrough or the rollback section. If you came here while planning a wider Azure Firewall build, the cost table and the pitfalls list are the two parts I would re-read before writing your design doc.

The official Microsoft Learn page is linked in the References block at the bottom and is the source of record. This page exists because I wanted a version that reflected what actually happens on real customer tenants, not what the doc team had room to fit on the canonical page. Both have their place.

If you want to talk about a specific scenario, drop me an email. I usually reply within 24 hours, and I do not bill for the first conversation.

Related fixes

Related guides worth a look while you sort this one out:

• Custom rules for Web Application Firewall v2 on Azure Application Gateway
• Set up analytic rules in Sentinel for web application attacks
• Use Azure WAF geomatch custom rules to enhance network security
• How do Speech containers work and how do I set them up?
• How do I instrument a global web application to meet regional data compliance requirements?
• How do I move an Application Insights resource to a new region?