Azure Fundamentals for Web Hosting: Custom domains and DNS configuration on Azure

What “custom domain mapping” means in Azure

When you host a website on Azure, the platform gives you a default hostname (for example, an App Service *.azurewebsites.net, a Container Apps *.azurecontainerapps.io, or a VM public IP / DNS label). Mapping your own domain (like example.com and www.example.com) means creating DNS records at your DNS provider that point to the Azure endpoint, and then telling the Azure service to accept that hostname. Most Azure services require domain ownership validation before they will serve traffic for your domain.

In practice you will do three things: (1) prove you control the domain (usually with a TXT record), (2) point the hostname to Azure (CNAME or A record), and (3) verify DNS propagation and that the Azure service reports the hostname as healthy/verified.

DNS record types you will use

• TXT: a text record used for ownership validation (Azure checks for a specific value).
• CNAME: points a hostname (like www.example.com) to another hostname (like myapp.azurewebsites.net). Common for subdomains.
• A: points a hostname to an IPv4 address (like a VM public IP). Common for apex/root domains (example.com).
• ALIAS/ANAME (provider-specific): behaves like a CNAME at the apex/root. Useful when you want the root domain to follow a hostname target but DNS standards don’t allow a CNAME at the zone apex.

Hands-on DNS lab (works for any hosting option)

Lab goal

You will map www.example.com and example.com to an Azure-hosted site, validate ownership with TXT, configure CNAME/A records, and verify propagation. You can apply the same workflow to App Service, Container Apps, or a VM; only the “target” values differ.

Step 0 — Collect the target values from Azure

Before touching DNS, collect these from the Azure resource you are mapping:

• Validation token (TXT value): Azure will show a required TXT record name/value during “Add custom domain”.
• Hostname target (for CNAME): e.g., App Service default hostname (myapp.azurewebsites.net) or Container Apps ingress FQDN.
• IP target (for A record): e.g., a VM’s public IPv4 address, or an App Service “A record IP” if you choose to map apex via A record.

Step 1 — Add the TXT record to validate domain ownership

At your DNS provider (registrar or DNS host), create the TXT record exactly as Azure specifies. Common patterns:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Host/Name: often asuid.www for www.example.com validation, or asuid for apex validation (Azure will tell you the exact label).
• Value: a long token string provided by Azure.
• TTL: set to 300 seconds (5 minutes) during setup to speed iteration.

Wait a few minutes, then use a DNS lookup tool to confirm the TXT record is visible publicly.

# Query TXT record (replace with your host label and domain as needed)  nslookup -type=TXT asuid.www.example.com  # Or using dig  dig TXT asuid.www.example.com +short

Step 2 — Create the traffic-routing record (CNAME or A)

Create the record that sends user traffic to Azure:

• For subdomains (recommended): create a CNAME for www pointing to the Azure-provided hostname target.
• For apex/root domain: use an A record to an IP address, or use ALIAS/ANAME if your DNS provider supports it and your Azure service provides a stable hostname target.

Example records (your values will differ):

• www.example.com → CNAME → myapp.azurewebsites.net
• example.com → A → 203.0.113.10

Step 3 — Verify DNS propagation

Check that public resolvers return the expected answers. If you recently changed records, test both your local resolver and a public resolver.

# CNAME check  nslookup -type=CNAME www.example.com  # A record check  nslookup -type=A example.com  # Query a specific public resolver (Google DNS)  nslookup www.example.com 8.8.8.8

Propagation is not “all or nothing”; different resolvers may update at different times depending on TTL and caching.

Step 4 — Complete validation in Azure and bind the hostname

Return to the Azure portal for your hosting option and complete the “Add custom domain” flow. Azure will check the TXT record (ownership) and the CNAME/A record (routing). Once verified, Azure will attach the hostname to your app/service. If Azure reports validation failures, re-check record names (labels), values, and whether you created them in the correct DNS zone.

Platform-specific mapping steps

Azure App Service (Web App)

App Service supports both CNAME-based mapping (best for www) and A-record mapping (often used for the apex). The portal guides you through the required TXT validation record.

App Service: map www with CNAME (recommended)

• In Azure portal: open your Web App → Custom domains → Add custom domain.
• Enter www.example.com.
• Copy the TXT record details Azure provides (often asuid.www).
• At DNS provider: create the TXT record.
• At DNS provider: create www CNAME → your app’s default hostname (for example myapp.azurewebsites.net).
• Back in Azure: click Validate, then Add.

App Service: map apex/root domain

For example.com, you typically cannot use a CNAME at the apex. Use one of these approaches:

• A record to App Service IP: In the custom domain wizard, Azure shows an IP address for A record mapping. Create @ A → that IP, plus the required TXT record (often asuid).
• ALIAS/ANAME at DNS provider: If your DNS provider supports it, you can point the apex to the App Service hostname while still behaving like an apex record. You still must complete Azure’s TXT validation.

Important: App Service IPs used for A-record mapping can change in some scenarios. Prefer CNAME for subdomains, and consider using a front door/reverse proxy service if you need a more stable apex strategy across environments.

Azure Container Apps

Container Apps exposes an ingress endpoint with an FQDN. Custom domains are typically mapped using CNAME for subdomains, with TXT validation required. For apex domains, you usually rely on ALIAS/ANAME at the DNS provider or route apex to www via redirect.

Container Apps: map www with CNAME

• In Azure portal: open your Container App → Ingress (or Custom domains if available in your blade) → Add custom domain.
• Note the ingress FQDN (the CNAME target) and the required TXT validation record.
• At DNS provider: create the TXT record exactly as specified.
• At DNS provider: create www CNAME → the Container Apps ingress FQDN.
• Back in Azure: validate and add the domain binding.

Container Apps: apex/root domain options

• Preferred operational pattern: use www.example.com as the canonical host and redirect example.com to www (or the reverse) using your application or an edge component.
• If your DNS provider supports ALIAS/ANAME: point @ to the ingress FQDN and complete TXT validation in Azure.
• If you must use an A record: you need a stable IP-based entry point (for example, a load balancer or gateway in front). Container Apps ingress is hostname-based; forcing apex via A record usually implies adding an IP-fronting component.

VM-based hosting (IaaS)

With a VM, DNS typically points directly to the VM’s public IP (A record) or to a DNS name that resolves to that IP (CNAME). The key consideration is whether your VM’s public IP is static or can change.

VM: public IP considerations

• Static public IP recommended: ensure the VM uses a static public IP resource so the address does not change on stop/deallocate or re-provisioning scenarios.
• NSG/firewall already handled elsewhere: DNS mapping won’t help if HTTP/HTTPS ports aren’t reachable, but treat that as a separate verification step.

VM: map apex and www

• Decide the canonical hostname: www or apex.
• At DNS provider: create @ A → VM public IPv4 address.
• For www, choose one:
• • CNAME www → example.com (simple, follows apex A record), or
  • A www → same VM public IP (works everywhere, duplicates the IP).

Unlike App Service/Container Apps, a plain VM does not require Azure-side TXT validation to “accept” the hostname. However, your web server must be configured to respond to the hostnames (virtual hosts / server blocks) and present the correct TLS certificate if you enable HTTPS.

Common pitfalls and how to avoid them

Apex/root domain limitations

DNS standards don’t allow a CNAME at the zone apex (example.com). If your Azure target is a hostname (common for PaaS), you have three practical choices: use an A record (if the platform provides a stable IP for this purpose), use ALIAS/ANAME at the DNS provider, or make www the canonical host and redirect the apex to it.

TTL choices during setup vs steady state

• During setup: use a low TTL (e.g., 300 seconds) so fixes propagate quickly.
• After stable: consider increasing TTL (e.g., 3600 seconds) to reduce DNS query volume and improve resilience to transient DNS provider issues.
• Beware caching: even after you lower TTL, resolvers that cached the old value may keep it until the previous TTL expires.

Record name/host formatting errors

• DNS UIs differ: some want www, others want www.example.com. Entering the full name when the UI expects only the label can create www.example.com.example.com.
• For TXT validation, the host label must match exactly (for example asuid.www vs asuid).
• Don’t add quotes around TXT values unless your DNS provider requires it (most do not).

Conflicting records

You cannot have a CNAME and another record type (A, TXT, MX) on the same exact name. For example, if www is a CNAME, you cannot also have an A record for www. Keep TXT validation records on the specific validation label Azure provides (often asuid.www), not on the same name as the CNAME.

Redirect consistency (www ↔ root)

Pick one canonical host to avoid duplicate content, confusing cookies, and inconsistent links:

• Option A (common): canonical www.example.com, redirect example.com → www.example.com.
• Option B: canonical example.com, redirect www.example.com → example.com.

Where to implement redirects depends on hosting:

• App Service / Container Apps: implement in app middleware or platform routing features available to you; ensure health checks and probes use the canonical host if required.
• VM: implement in the web server (for example, an Nginx/Apache redirect server block) so the redirect happens before application logic.

Propagation vs platform validation timing

It’s common to add records and immediately click “Validate” in Azure. If validation fails, first confirm the record is visible from a public resolver, then retry. If you can see the record publicly but Azure still fails, double-check you created the record in the correct DNS zone (especially if you manage subdomains in separate zones).

Public IP changes (VMs and some IP-based mappings)

If your mapping relies on an A record to an IP address, any IP change will break the domain until DNS is updated and propagated. For VM hosting, use a static public IP. For PaaS, prefer CNAME-based mapping where possible, and be cautious about designs that depend on a single fixed IP unless you intentionally front the app with an IP-stable component.