When you pair an Azure App Service with a Private Endpoint, your goal is simple: internal clients should resolve yourcompany.com to the Private Endpoint’s IPv4 address, never the public one. In my recent deployment, a temporary A record in the public zone was created only for domain‑ownership validation and deleted immediately after. The authoritative record lives exclusively in your internal DNS zone, giving you actual split‑horizon resolution. The sections below illustrate how that flow works and where it can go astray.
Author’s note
This article originates from two pull requests I recently submitted to Microsoft’s Azure documentation to clarify Private Endpoint configuration and its limitations PR #126574 and a follow-up PR #126580. The material captures nuances that, in practice, remain less than obvious.
1. Definitions
| Term | Meaning |
|---|---|
| Public DNS |
The outward-facing DNS infrastructure reachable by the entire Internet. Records reside with your registrar or public DNS provider. |
| Private DNS |
A DNS zone whose visibility is limited to your internal network (for example, Azure Private DNS).
It enables split-horizon resolution. |
| A record | Maps a hostname directly to an IPv4 address. Simple, but brittle when the target IP is dynamic. |
| TXT record | Stores free-form text used for domain validation (e.g., Azure, Google), SPF, DKIM, and other metadata. It does not affect name resolution. |
| Domain Validation |
A one-time procedure in which you add a temporary A or TXT record to prove ownership of the domain to Azure (or another provider). After verification, the record can be safely removed from public DNS. |
| Split-horizon DNS | A setup in which the same domain name resolves to different records depending on whether the query originates inside or outside the network, allowing you to expose public records externally while serving private records internally. |
| Split-horizon record | A DNS record that exists only in the internal zone (or differs internally) so that internal clients resolve a private endpoint while external clients receive no record or a different public record. |
2. Domain Name Resolution Journey
| Step | Action |
|---|---|
| 1. Client query |
A device inside your VNet (or a peered network) asks:
“Where is www.yourcompany.com ?” |
| 2. Split-horizont record |
Public DNS now returns no record (NXDOMAIN) because the verification A record was removed.
Your internal DNS zone hosts the record instead, either a CNAME pointing to
<app-name>.azurewebsites.net or an A record for the Private Endpoint’s IP.
|
| 3. Public to Private alias |
Azure’s internal resolver automatically rewrites
<app-name>.azurewebsites.net to .
|
| 4. Private DNS lookup |
Because your VNet is linked to the privatelink.azurewebsites.net Private DNS zone,
the resolver answers with the Private Endpoint’s IP.
|
| 5. TLS connection | The client opens an encrypted session directly to the App Service over the private IP. |
3. A vs CNAME
Why is an internal A record fragile?
- Private Endpoint IP addresses can change during scaling, platform maintenance, or redeployment.
- Updating an A record is manual; stale DNS can cause
HTTP 404TLS handshake failures. - Certificates are still validated by hostname, but the connection cannot be made once the IP drifts.
Preferred approach: internal CNAME
- In your internal DNS zone, create a CNAME:
www.yourcompany.com to <app-name>.azurewebsites.net - Ensure the VNet is linked to the
privatelink.azurewebsites.netzone so that the alias resolves privately. - Future IP changes are absorbed by Azure; no operator action is required.
4. Common Misconfigurations
| Misstep | Result | Correction |
|---|---|---|
Publishing an A record to the Private Endpoint IP |
IP changes silently; clients break. | Use an internal CNAME; let Azure track the IP lifecycle automatically. |
| Forgetting to link the Private DNS zone to all VNets | Some subnets fall back to public DNS, defeating isolation. | Establish VNet links, or use DNS forwarding. |
| Allowing external resolvers to answer internal names | Traffic exits and re-enters the network, complicating firewall rules. | Ensure split-horizon DNS: internal queries are resolved internally. |
5. Unique Default Hostnames
Since November 2024, Azure App Service allows you to opt in to secure unique default hostnames. A newly created web app receives a randomly‑hashed, region‑scoped address such as:
<app>-a6gqaeashthkhkeu.eastus-01.azurewebsites.netWhy did Microsoft introduce the change?
Microsoft explicitly states that the feature mitigates sub‑domain takeover caused by dangling DNS records and prevents accidental name collisions. Key references:
- GA announcement (Apps on Azure Blog, Nov 2024): “Secure unique default hostnames … protect your resources from dangling DNS entries and sub‑domain takeover.” https://techcommunity.microsoft.com/blog/appsonazureblog/secure-unique-default-hostnames-ga-on-app-service-web-apps-and-public-preview-on/4303571
- Public preview blog (May 2024): “Create web apps with unique default hostnames to avoid a high‑severity threat of subdomain takeover.” https://techcommunity.microsoft.com/blog/appsonazureblog/public-preview-creating-web-app-with-a-unique-default-hostname/4156353
- Ignite 2024 recap (Oct 2024): Highlights the new naming convention and its protection against sub‑domain takeover. https://techcommunity.microsoft.com/blog/appsonazureblog/whats-new-in-azure-app-service-at-ignite-2024/4289488
- Microsoft Learn security guidance: Prevent dangling DNS entries and avoid subdomain takeover. https://learn.microsoft.com/azure/security/fundamentals/subdomain-takeover
Impact on the Private Endpoint pattern
The DNS chain itself is unchanged; only the middle CNAME grows longer:
www.yourcompany.com -> <app>-hash.region.azurewebsites.net
<app>-hash.region.privatelink.azurewebsites.net -> 10.x.x.x
- No additional Private DNS zones are required- continue linking
privatelink.azurewebsites.netto your VNets; Azure auto‑populates the A record that maps to the Private Endpoint. - Split‑horizon guidance remains the same – keep the public zone empty, and create or retain an internal CNAME so any future IP rotation is invisible to consumers.
- Automation & monitoring – update scripts or probes that are hard‑coded with the shorter
<app>.azurewebsites.netpattern.
Enable the feature for green‑field apps whenever possible; it strengthens the DNS chain your Private Endpoint relies on with zero extra runtime configuration.
6. Frequently Annoying Questions
Does the Private Endpoint operate as a load balancer?
Not directly. Think of it as a sealed door: traffic passes through Azure’s managed App Service fabric, where Microsoft’s load balancers handle distribution. You gain private access and built‑in redundancy without maintaining a separate LB resource.
Why is the custom domain resolved even when I never added it to my private DNS?
Considering the CNAME approach, CNAME ends at privatelink.azurewebsites.net, and that zone is in your Private DNS setup. Therefore, the domain’s final resolution inherits the private mapping automatically – no duplicate records are needed.
While going with an A record… This means the custom domain was added to your private DNS at some point ;).
Closing Thought
DNS underpins connectivity and can be unforgiving. Treat the Private Endpoint as your application’s insurance number: keep it private, and verify twice before moving on. That extra diligence prevents the 2 a.m. incident call, arguably the most persuasive metric.
The .Net developer 