The road back to the old building
Not everything moves on the first weekend, and some of it should not. Campux's point-of-sale batch job — the one you refused to migrate in Class Three, with its licence nailed to a physical machine — stays in the office for a final year. But the storefront it feeds now lives in Azure, so the two must talk. You need a road between the office and the cloud, private and encrypted, and you need it sized to the traffic that will actually cross it rather than the traffic you fear.
The road is a site-to-site VPN, and it runs on a resource called a VPN gateway.
- S2S VPN
- A site-to-site VPN: an encrypted IPsec tunnel across the public internet between your on-premises network and an Azure VNet, terminated on each side by a gateway, so the two networks reach each other by private address.
The honesty this section is named for is about sizing. A VPN gateway is a real resource that sits in a dedicated GatewaySubnet, comes in tiers that differ by throughput and tunnel count, bills by the hour for as long as it exists, and takes a genuinely long time — tens of minutes — to provision.1 Choose the tier by the bandwidth the bridge will actually carry and the number of connections it must hold, not by the biggest number on the page. Campux's bridge carries a nightly batch reconciliation and some administrative traffic — a modest tier, sized to that, is the correct and cheaper answer. Over-buying gateway throughput is the network version of the oversized VM from Class Eleven.
ExpressRoute: when the cheque is worth writing
The VPN's road runs over the public internet — encrypted, but sharing the same congested motorway as everyone else. ExpressRoute is the other option: a private, dedicated connection into Azure arranged through a connectivity provider, which never touches the public internet at all.
- ExpressRoute
- A private, dedicated circuit between your network and Azure, provisioned via a partner. Higher bandwidth, more consistent latency, and no public internet in the path — at a materially higher cost and a longer lead time to install.
The engineering question is never "which is better" — it is "when is the cheque worth writing." ExpressRoute earns its cost when you have sustained, high-bandwidth traffic between on-premises and Azure, when you need predictable latency a shared internet path cannot promise, or when a regulator or contract forbids sensitive traffic from crossing the public internet even encrypted. Absent one of those, a site-to-site VPN is the right tool, and reaching for ExpressRoute "to be safe" buys a monthly circuit charge and weeks of provider lead time to solve a problem you do not have.
| Question | Site-to-site VPN | ExpressRoute |
|---|---|---|
| Path | Encrypted over the public internet | Private, dedicated — never the internet |
| Bandwidth / latency | Modest; best-effort internet | High; consistent, provider-backed |
| Cost & lead time | Low; live in tens of minutes | High; weeks to provision via a partner |
| Reach for it when | A modest or temporary bridge | Sustained bandwidth, predictable latency, or a no-internet mandate |
Azure DNS: hosting the directory
A road moves packets by address; people and applications work by name, and something must translate. That something is DNS, and Azure will host your domain's public directory for you.
- DNS zone
- The authoritative record of a domain's names — the mapping of store.campux.co to an address, and every other record for that domain. A public zone answers the internet; a private zone answers only inside linked networks.
Hosting a public DNS zone on Azure works the way domain delegation always has, and the one step people miss is the handoff. When you create the zone, Azure assigns it four name servers. The domain does not actually resolve through Azure until you go to wherever you bought the domain — the registrar — and point its delegation at those four name servers. Create the zone, add your records, forget the delegation, and nothing happens: the internet still asks the old name servers. Inside the zone you manage record sets — an A record to an address, a CNAME to another name, and so on — and this is the ordinary, public half of naming.
The private half — the privatelink zones from Class Fourteen — is where hybrid makes DNS genuinely hard, and that is the next section.
Why the office and the cloud disagree on names
Here is the question that trips every hybrid deployment and appears in this class's second situation: a name resolves correctly from inside Azure, and wrongly — or not at all — from the office, even though the VPN is up and packets flow. The road is fine. The directories disagree.
Both sides must agree on the name.
Inside a VNet, Azure provides a resolver at a fixed, special address — 168.63.129.16 — and that resolver can see the private DNS zones linked to the VNet, so campuxstore.blob.core.windows.net resolves to its private endpoint IP exactly as Class Fourteen intended.2 Your on-premises resolvers cannot see that Azure-only resolver or those private zones at all. So the office asks public DNS, gets the public IP (or a refusal, if public access is disabled), and the application fails — while the same lookup from a VM in Azure succeeds. Nothing is broken; the two networks simply consult different directories.
- Private Resolver
- The Azure DNS Private Resolver: a managed resolver placed in your VNet that on-premises DNS servers can forward to, so a query from the office is answered by the Azure-side directory — including the private zones — without hard-coding anything.
The fix, therefore, is not on the road; it is in the directories. You give on-premises DNS a way to ask the Azure side — an Azure DNS Private Resolver in the VNet, or a forwarding VM — and configure a conditional forwarder on the office resolvers for the relevant zones.3 Now a lookup from the office is forwarded across the bridge to the Azure resolver, which answers from the private zone, and both sides finally agree. Whenever hybrid DNS "half works," this asymmetry — who can see which zone — is the first thing to check.
Campux's bridge, with an expiry
The last year of the POS system on-premises
Campux builds a site-to-site VPN from the HQ firewall to the production VNet, terminated on a modestly-sized VPN gateway in the GatewaySubnet. Not ExpressRoute: the bridge is temporary — one year until the POS licence is renegotiated — and carries a nightly batch, not a torrent, so a provider circuit and its monthly cheque would be paying for reliability and bandwidth the job never uses. This is Class Five's discipline exactly: the bridge is a transition state with an end date, not a destination.
Then the harder half. The storefront in Azure reaches its storage over a private endpoint, so its name lives in a privatelink private DNS zone that only the VNet can see. For the on-premises POS job to reach anything in Azure by name, Campux stands up an Azure DNS Private Resolver in the VNet and points the office DNS servers at it with a conditional forwarder. Now the office and the cloud resolve the same names to the same private addresses — the deliberate DNS gotcha from Class Fourteen, this time solved across the bridge before it bites. When the licence is resolved and the POS job finally migrates, the VPN and the resolver come down together, and the bridge closes as planned.
The official module, and a CAMPUX overview
Host your domain on Azure DNS
learn.microsoft.com/training/modules/host-domain-azure-dns/
The bridge: Create a VPN gateway in the portal (docs tutorial)
learn.microsoft.com/azure/vpn-gateway/tutorial-create-gateway-portal
A short walkthrough of the hybrid bridge and why the office and the cloud disagree on names will live here. Video to be added.
Host a DNS zone the CLI way
The VPN gateway from §1 takes tens of minutes and bills heavily, so it is not a quick lab — but the DNS half is fast, cheap, and where the real hybrid pain lives. You will host a public zone, add a record, and read the name servers you would have to delegate to.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. (Locally: install the Azure CLI and run az login.)
Create a group and a public DNS zone for a domain you do not need to actually own for this exercise:
az group create --name rg-campux-lab --location westeurope az network dns zone create --resource-group rg-campux-lab \ --name campux-lab.example
What just happened: Azure created the authoritative directory for that name and assigned it four name servers. The domain will not resolve on the real internet until you delegate to them at a registrar — the step everyone forgets.Add an A record in the zone:
az network dns record-set a add-record --resource-group rg-campux-lab \ --zone-name campux-lab.example --record-set-name store --ipv4-address 203.0.113.10
On screen: you just mapped store.campux-lab.example to an address. This is a record set — the ordinary, public half of naming.Read the name servers Azure assigned — the delegation target:
az network dns zone show --resource-group rg-campux-lab \ --name campux-lab.example --query nameServers
The lesson: these four names are what you would enter at your registrar to make the zone authoritative on the internet. Without that handoff, the zone exists but no one on the internet consults it.Tear down:
az group delete --name rg-campux-lab --yes --no-wait
Host a DNS zone by hand
Now do it by clicking — the zone's overview is where the name servers are shown, and the record-set panel is where naming happens. Use a throwaway resource group.
Go to portal.azure.com and sign in.
In the search bar at the top, type DNS zones, select it, then click + Create.
Basics tab: subscription, a throwaway resource group, and the zone name campux-lab.example. Review + create.On screen: a public DNS zone by default — the kind reachable from the internet, as opposed to the private zones linked to a VNet you met in Class Fourteen.
Open the zone and read the Overview: the four Name servers are listed there.On screen: this is the delegation target. In a real setup you copy these to your registrar; until then the zone is authoritative only in Azure's eyes.
Click + Record set, add an A record named store pointing at an address, and save.On screen: the record set editor exposes the TTL — how long resolvers cache the answer. A high TTL means a change takes time to spread, which is exactly why DNS failover is never instant.
Tear down: delete the throwaway resource group.
Portal wording drifts; if a label here does not match your screen, the anchors are the DNS zones service, the zone's Name servers on Overview, and the Record set editor. The .example domain is reserved for documentation and will never resolve publicly — perfect for a throwaway lab.
See why the two sides disagree
Open the pieces that decide who can resolve what, and read the split that §4 is about.
Open a Private DNS zone from the Class Fourteen work (or any privatelink.* zone) and read its Virtual network links.On screen: only the linked VNets can resolve this zone. That list is precisely who agrees with Azure on the private names — and the office is not on it.
On a VNet, open DNS servers under Settings.On screen: "Default (Azure-provided)" means resolution uses 168.63.129.16, which sees the linked private zones. Setting custom DNS servers here is how you point a VNet at your own resolver instead.
Search DNS Private Resolver in the top bar and open the service (create one only if you want to — it bills).On screen: inbound and outbound endpoints. The inbound endpoint is the address your on-premises DNS forwards to; it is the bridge that lets the office borrow Azure's directory, the fix for §4's disagreement.
The problem wearing a networking costume
A migrated app in the office cannot reach a service in Azure — it keeps resolving the wrong address. You trace it to DNS, wire conditional forwarding so on-premises and cloud names resolve consistently across the link, and the mysterious "works in Azure but not from the office" ticket closes. Half of hybrid networking, you learn, is really a name-resolution problem wearing a networking costume.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
A. A site-to-site VPN tunnels IPsec-encrypted traffic across the public internet. B is the trap: ExpressRoute is the opposite — a private, dedicated circuit that never touches the internet, which is the whole reason it costs more. C connects a PaaS service into a VNet, not two networks; D is naming, not a transport. If the words "encrypted" and "over the internet" appear together, it is a VPN.
C. ExpressRoute earns its higher cost and lead time when the traffic is heavy and sustained, the latency must be predictable, or a rule forbids the public internet even encrypted. A is the "to be safe" reflex that buys a monthly circuit for a problem you do not have; B is exactly the case a VPN handles well and cheaply — Campux's bridge. D confuses transport with naming: DNS resolves across a VPN just as well, given the resolver setup of §4.
Delegate to the assigned name servers, Azure-provided DNS sees linked private zones, and a private zone answers only for linked VNets. The two false statements are the hybrid traps: on-premises resolvers do not automatically see Azure private zones — that asymmetry is §4's whole problem, fixed with a private resolver — and a public zone resolves over the ordinary internet, no VPN required. Believing either is how a hybrid rollout "half works."
HYBRID PLAN — Campux POS bridge
1. Site-to-site VPN from HQ to the production VNet over IPsec.
2. VPN gateway deployed into a dedicated GatewaySubnet.
3. On-prem apps reach Azure resources by private IP over the tunnel.
4. On-prem servers will resolve Azure private DNS names automatically
once the tunnel is up.
Line four. The tunnel carries packets, not directory knowledge. On-premises resolvers still consult their own DNS, which cannot see Azure's private zones — so a name in a privatelink zone resolves to a public IP or fails, even with the VPN perfectly up. Lines one to three are correct: IPsec VPN, the required dedicated GatewaySubnet, private-IP reachability over the tunnel.
Consider the consequence. Shipped as written, packets flow but the POS job cannot find anything by name, and the team burns a day debugging the "broken VPN" that is not broken. The fix is a DNS Private Resolver in the VNet plus a conditional forwarder on the office resolvers — the naming half the plan forgot. Reaching resources needs both a road and a shared directory.
The road works; the directories differ. That the VPN is up and private IPs ping is the clue, not a contradiction — connectivity is fine. Resolution differs because the two sides ask different DNS. From the Azure VM, Azure-provided DNS at 168.63.129.16 can see the private zone and returns the private endpoint IP. From the office, the machine asks the corporate resolver, which has never heard of that private zone and returns the public IP instead.
Name the asymmetry precisely. Private DNS zones are visible only to the virtual networks linked to them and to the Azure resolver inside those VNets. On-premises resolvers are simply not in that circle, and a VPN does not put them in it — the tunnel moves packets, not zone visibility.
The fix lives in DNS, not the network. Stand up an Azure DNS Private Resolver in the VNet (or a forwarding VM), then configure the office resolvers with a conditional forwarder for the relevant zones — privatelink.blob.core.windows.net and friends — pointing at the resolver's inbound endpoint. Now the office query is forwarded across the bridge, answered from the private zone, and both sides agree. When hybrid DNS "half works," this is almost always the shape of it.
Grant the instinct, then size it. Wanting the bridge to be reliable is reasonable; ExpressRoute is simply the wrong instrument for this particular bridge. It is built for sustained, high-bandwidth, latency-sensitive connectivity — none of which a once-a-night batch job needs.
Price the mismatch in the director's terms. ExpressRoute means a connectivity provider, weeks of lead time, and a monthly circuit charge — for a connection that will be torn down in a year and is idle most of every day. A site-to-site VPN is live within the hour, costs a fraction, and comfortably carries a nightly reconciliation. Paying for ExpressRoute here is paying for reliability the workload cannot use.
Tie it to the decision already made. Class Five settled that this bridge is a transition state with an end date, not a destination. The connection should match: a VPN for the temporary year, and if a future workload ever genuinely needs sustained bandwidth to Azure, ExpressRoute gets revisited on its own merits. "Rock solid" for this traffic is a well-sized VPN, not an over-bought circuit.
Five things worth carrying out of this class
- A site-to-site VPN is an encrypted tunnel over the internet, terminated on a gateway in a GatewaySubnet. Size it to real traffic.
- ExpressRoute is a private, dedicated circuit — worth its cost only for sustained bandwidth, predictable latency, or a no-internet mandate.
- Azure DNS hosts public zones; the step people forget is delegating to the four assigned name servers at the registrar.
- Inside a VNet, Azure DNS at 168.63.129.16 sees linked private zones. On-premises resolvers do not — that asymmetry is the hybrid DNS problem.
- Fix hybrid resolution in DNS, not the network: a Private Resolver plus a conditional forwarder makes both sides agree on the name.
- Gateway provisioning genuinely takes a while — commonly on the order of half an hour or more — and the SKU sets both throughput and how many tunnels it can hold. Treat the exact minutes and per-SKU numbers as things that drift and belong on the current pricing and specs pages; the durable point is that a gateway is a real, hourly-billed resource you size to the traffic, not a switch you flip for free. ↩
- 168.63.129.16 is a fixed, Azure-wide virtual IP for the platform's DNS and health services — the same address in every VNet. It is one of the few magic numbers worth memorising, because "is the VNet using 168.63.129.16 or a custom resolver?" is the first question when private-zone resolution misbehaves inside Azure. ↩
- The Azure DNS Private Resolver is the managed way to bridge on-premises and Azure resolution; before it existed, teams ran a DNS forwarder on a small VM for the same purpose, and you will still see that pattern in older estates. Either way the idea is identical — give on-premises DNS something in the VNet to forward to. It bills while it runs, so in a lab, create it only to look and then delete it. ↩