Split-Horizon DNS for Azure Private Link | Patterns That Prevent Intermittent Connectivity

The Rahsi Framework™

Azure Private Link is the visible surface.

Split-Horizon DNS is the invisible constitution that decides whether the estate feels calm.

Read Complete article |

Split-Horizon DNS for Azure Private Link | Patterns That Prevent Intermittent Connectivity | The Rahsi Framework™

Split-Horizon DNS for Azure Private Link: Patterns that prevent intermittent connectivity—resolver path, privatelink zones, proof windows. RĀHSI™

aakashrahsi.online

If you're ready to move from scattered tools to strategic clarity and need a partner who builds trust through architecture

This is where we begin

Hire Aakash Rahsi | Expert in Intune, Automation, AI, and Cloud Solutions

Hire Aakash Rahsi, a seasoned IT expert with over 13 years of experience specializing in PowerShell scripting, IT automation, cloud solutions, and cutting-edge tech consulting. Aakash offers tailored strategies and innovative solutions to help businesses streamline operations, optimize cloud infrastructure, and embrace modern technology. Perfect for organizations seeking advanced IT consulting, automation expertise, and cloud optimization to stay ahead in the tech landscape.

aakashrahsi.online

Same app URL. Same FQDN. Same intent.

But the lived outcome still shifts—quietly—because Microsoft’s architecture is expressed through the resolver path:

public CNAME → privatelink → private DNS zone authority → VNet link scope → Azure DNS Private Resolver inbound/outbound → forwarding rulesets → returned IP

I’m not correcting Microsoft. I’m explaining Microsoft’s design philosophy: treat name resolution as designed behavior—operated inside one trust boundary, for one execution context, with evidence you can replay under CVE tempo… including how Copilot honors labels in practice when the narrative moves across governed collaboration surfaces.

If you can answer three questions, you can stabilize most “varies by environment” moments:

1. What exact FQDN is the workload using?
2. Which DNS server answered?
3. Did the query hit the correct private DNS zone—and is the consumer VNet linked?

---

The mental model Microsoft expects you to carry

Private Link usually does not change what the application calls.

It changes what that name resolves to, depending on where you ask from.

That’s the key designed behavior:

• The workload keeps using a public-looking name (for example, a platform service FQDN).
• DNS resolution follows a CNAME chain and lands in a privatelink namespace.
• Inside the trust boundary, that name must resolve to a private IP associated with a private endpoint.
• Outside, the public path may resolve differently, depending on your intended boundary.

So the question is rarely “is Private Link real?”

The question is: is the resolver path aligned to the execution context?

---

Split-horizon DNS, defined the Microsoft-friendly way

Split-horizon DNS means:

the same name can return different answers depending on where you query from.

That’s not “good” or “bad.”

That’s the design.

The correct outcome is:

• Private answer inside the approved networks (trust boundary)
• Intentional public recursion where that is intended

And the estate feels calm when the answer is deterministic for each execution context.

---

The two reference patterns (the ones that scale)

Pattern A: Azure-only (simplest deterministic posture)

This is the cleanest baseline when all consumers are in Azure:

• You create Azure Private DNS zones for the relevant privatelink namespaces.
• You ensure the correct records exist (often via integration/registration from private endpoint creation).
• You link the zone to every consumer VNet that must resolve privately.

What makes it deterministic:

• Zone authority is centralized.
• VNet links define scope.
• Consumers resolve privately without guessing.

Execution context proof:

• Query from the consumer VNet context
• Confirm returned IP is the private endpoint IP
• Confirm the answering DNS server is in the expected path

---

Pattern B: Hybrid enterprise (the serious enterprise layer)

When consumers exist on-prem, in other clouds, or across segmented networks, you need a defined DNS bridge.

That’s where Azure DNS Private Resolver becomes the Microsoft-aligned backbone:

• Inbound endpoint: on-prem DNS can forward to Azure over a known IP target
• Outbound endpoint: Azure can forward to on-prem DNS for corporate domains
• DNS forwarding rulesets: forwarding logic becomes centralized and linkable to VNets

The design intent:

• On-prem → conditional forwarder → inbound endpoint → resolve privatelink zones in Azure
• Azure workloads → outbound endpoint + ruleset → resolve on-prem domains as needed

What makes it deterministic:

• The bridge is explicit
• The rules are versionable
• The scope is link-defined
• The execution context can be replayed

---

Why App Service can feel “different” than your VM tests

A VM test is useful, but it may be the wrong execution context.

If your workload is App Service and it’s VNet integrated:

• the resolver path follows the VNet DNS configuration used by that integration path
• you must validate from the workload’s actual resolver context, not just “a VM somewhere”

Designed behavior rule:

Validate DNS from the same execution context that experiences the outcome.

---

SQL private endpoint as the canonical example (the pattern repeats everywhere)

For many teams, SQL is where this becomes obvious because the name is well-known.

The proof spine looks like this:

• Workload queries: yourserver.database.windows.net
• DNS chain leads toward a privatelink namespace
• Private DNS zone contains a record for the server
• Consumer VNet is linked to that zone
• Result: returned IP is the private endpoint IP

If any one of those links is missing, the resolver path diverges.

Not a “network issue.”

A constitutional mismatch in the resolver path.

---

The troubleshooting flow (the RĀHSI proof spine)

This is the sequence that keeps teams calm under CVE tempo.

Step 1: Resolve the name from the failing execution context

Capture:

• FQDN
• returned IP
• timestamp

Step 2: Identify the answering DNS server

Capture:

• the resolver that answered
• the server path that was used (on-prem DNS, custom DNS, Azure-provided, Private Resolver)

Step 3: Confirm the correct private DNS zone and record exist

Capture:

• privatelink zone value (service-specific)
• record presence for the target resource

Step 4: Confirm the consumer VNet is linked to the private zone

Capture:

• VNet link exists
• link scope is correct for the workload execution context

Step 5 (hybrid): Confirm forwarding intent and Private Resolver path

Capture:

• on-prem conditional forwarders target inbound endpoint IP
• forwarding rulesets exist and are linked to VNets that need them
• outbound forwarding is configured for on-prem domains when required

Step 6: Only then validate route/NSG/firewall posture

Because once DNS is deterministic, transport checks become meaningful evidence.

---

“Never again” rules (CAF-style operations, applied to DNS)

1. One zone, one owner, one authoritative story
2. Treat DNS changes like production changes: version, review, approve
3. Centralize privatelink zones where possible; link consumers intentionally
4. Hybrid needs a defined bridge: Private Resolver + rulesets
5. Every CVE-tempo window ends with a replayable evidence window
6. Evidence must be leader-readable without changing the trust boundary language
7. Narratives must stay consistent with how Copilot honors labels in practice across governed collaboration surfaces

---

The Evidence Window (copy-paste template)

Use this to close any CVE-tempo timebox.

Execution context

• Workload:
• Network scope (VNet/subnet):
• Resolver path (answering server chain):

Name resolution

• FQDN:
• Expected privatelink zone:
• Returned IP:
• Answering DNS server:

Authority + scope

• Private DNS zone:
• Record present:
• Consumer VNet linked:

Hybrid (if applicable)

• Private Resolver inbound endpoint IP:
• Conditional forwarders:
• Forwarding ruleset + linked VNets:

Validation

• Probe results:
• Timestamp + observer:

Closure

• Delta summary:
• Approver:
• Evidence index links:

---