CH13-03: Identity, DNS, Routing, and Inspection

Goal

The previous section explained VPN, ExpressRoute, and hub-spoke connectivity. This section covers the pieces that often decide whether the connection is useful in real life: identity, DNS, routing, and inspection.

A circuit can be healthy while the application is still broken. A tunnel can be up while DNS resolves the wrong address. A route can send traffic to Azure while the return path goes somewhere else. A firewall can block a dependency that the application team did not know existed.

The durable idea is:

Hybrid systems fail most often at the control planes around connectivity: identity, DNS, routing, and inspection.

The Short Version

Hybrid connectivity creates possible reachability. Control-plane decisions decide whether systems can actually use that reachability safely.

Use this mental model:

Application in Azure
  -> identity check
  -> DNS resolution path
  -> routed network path
  -> firewall or inspection point
  -> on-premises dependency

If any part of that chain is wrong, the application can fail even when the network link itself is healthy.

Identity Dependencies

Hybrid systems often depend on more than one identity model.

You may see:

Microsoft Entra ID for Azure users, applications, and workload identities.
Existing directory systems for on-premises authentication.
Service accounts used by legacy applications.
Managed identities used by Azure workloads to access Azure services.
Application credentials, certificates, or secrets used by older systems.
Role and group models that differ between cloud and existing environments.

The architecture needs to answer who or what is calling, how that identity is validated, what it can access, and where authorization is enforced.

For example, an Azure-hosted application might use managed identity to read from Key Vault and Azure Storage, but still need an on-premises service account to call a legacy ERP API. That combination is common during migration. It needs secure secret handling, least privilege, audit logging, and a plan to reduce legacy credential use where possible.

DNS Resolution

DNS is often the quiet center of hybrid architecture.

Applications usually call names, not IP addresses:

erp.internal.contoso.com
sql-prod.corp.local
mystorage.blob.core.windows.net
private endpoint hostnames
internal API names

Hybrid DNS design decides how Azure workloads resolve on-premises names and how on-premises systems resolve Azure private names.

Private endpoints make DNS especially important. A private endpoint gives a supported Azure service a private IP address, but clients must resolve the service name to that private IP address. If an on-premises client resolves the public address while an Azure client resolves the private address, the same application can behave differently from different locations.

A strong design defines DNS forwarding, private DNS zones, resolver ownership, change control, and troubleshooting steps.

Routing and Return Paths

Routing decides where traffic goes next.

In hybrid designs, routing questions include:

Which on-premises prefixes are advertised to Azure?
Which Azure prefixes are advertised to on-premises?
Do spoke VNets send hybrid traffic through the hub?
Does traffic need to pass through Azure Firewall or a network virtual appliance?
Are return paths symmetric and predictable?
Does forced tunneling send outbound traffic through a central inspection path?

Asymmetric routing is a common risk. That means traffic goes one way through one path and returns through a different path. Firewalls and inspection devices may drop traffic when they do not see the full flow. Troubleshooting also becomes harder because each team sees only part of the path.

Routes are not security rules. They shape the path. Firewalls, NSGs, service firewalls, and identity controls decide what is allowed. A working hybrid design needs both.

Inspection and Security Controls

Many organizations require hybrid traffic to pass through inspection points such as Azure Firewall, a network virtual appliance, or on-premises firewalls.

Inspection may be used for:

Controlling outbound internet access.
Logging traffic between Azure and on-premises systems.
Enforcing segmentation between workload spokes.
Applying rules for sensitive production dependencies.
Supporting incident investigation and compliance evidence.

Inspection adds visibility and control, but it also adds a dependency. If the firewall path is undersized, misconfigured, or unavailable, many applications may fail. If rules are too broad, the organization has visibility but weak control. If rules are too narrow without ownership, normal releases become painful.

Example: Healthy Circuit, Broken Application

An Azure-hosted inventory app needs to read from an on-premises database.

The ExpressRoute circuit is up. The gateway is healthy. The network team says the link is fine.

The application still fails.

Investigation finds two issues:

The database hostname resolves to an old IP address from Azure because DNS forwarding was not updated.
After DNS is fixed, traffic reaches the on-premises firewall, but return traffic uses a different route and the firewall drops the flow.

The problem was not simply connectivity. It was DNS plus routing plus inspection.

This is why hybrid troubleshooting should start with a path:

Name resolution
  -> source IP and destination IP
  -> route and next hop
  -> firewall rule and logs
  -> return path
  -> identity and authorization

Ownership Map

Hybrid control planes usually cross teams:

Team	Typical Responsibility
Application team	Dependency list, application configuration, error logs, release timing, and business impact.
Cloud platform team	Azure landing zone, hub-spoke model, private endpoints, Azure monitoring, and workload guardrails.
Network team	VPN, ExpressRoute, route advertisements, gateways, firewalls, and connectivity monitoring.
Identity team	Directory integration, groups, service identities, authentication policies, and credential lifecycle.
DNS team	Forwarding rules, zones, resolver configuration, records, and name-resolution standards.
Security team	Inspection policy, firewall rules, audit requirements, and exception review.

The exact team names may differ. The lesson stays the same: hybrid designs require coordination before incidents happen.

Common Mistakes

Assuming connectivity works because the circuit or tunnel is up.
Forgetting private DNS for Azure private endpoints and hybrid clients.
Creating routes that send traffic through inspection one way but return another way.
Treating firewall rules as someone else's detail until production testing.
Using legacy service accounts from Azure without secret rotation or audit visibility.
Letting DNS, routing, firewall, and identity changes happen independently without change coordination.

If Someone Asks You

What usually makes hybrid Azure designs hard?

A good answer is:

Hybrid designs are hard because the connection is only one part of the path. Applications also depend on identity, DNS, routing, return paths, firewall inspection, private endpoint resolution, authorization, and monitoring. A healthy VPN or ExpressRoute connection does not guarantee the application works. Teams need shared ownership across cloud, network, DNS, identity, security, and application groups.

What You Should Remember

Hybrid reliability depends on identity, DNS, routing, and inspection as much as bandwidth.

Questions to Check Your Understanding

Why can DNS break a hybrid design?
What is asymmetric routing risk?
Which teams must coordinate hybrid access?