Cloud Networking
Intermediate 14 min read Cloud Networking

DNS in Cloud Networking

Naming, resolution and routing policies in the cloud

Cloud DNS is the directory of your network: public domains, private zones for VPC-internal names, health-based routing, and CDN/LB integration. Getting resolution wrong is a silent application failure.

DNSCloud DNSRoute 53Azure DNSprivate hosted zonesplit-horizon
Prerequisites: VPC Basics
Before we start

What you will learn

  • Use managed DNS (Route 53 / Cloud DNS / Azure DNS)
  • Design private hosted zones for internal services
  • Chain DNS to load balancers and CDNs correctly
In 60 seconds

Managed cloud DNS holds your zones and answers queries. Public zones serve the internet; private hosted zones resolve names inside VPCs. Routing policies (weighted, latency, failover) steer traffic where you want.

Introduction

What is this?

AWS Route 53, Azure DNS, and GCP Cloud DNS are managed authoritative DNS. Public zones: alias records to load balancers/CDN. Private hosted zones: scoped to a VPC (Route 53 private zones, Cloud DNS 'fully qualified' zones peering, Azure private DNS zones). Records: A/AAAA, CNAME, TXT, MX, SRV. Routing policies: weighted, latency-based, geolocation and health-check based failover. Resolution integrates with endpoints (private DNS for PrivateLink) so internal names map to private IPs.

Motivation

Why do you need it?

  • DNS is the user-visible contract; downtime or misresolution = user-visible failures.
  • Private DNS is what makes internal service discovery (and endpoint names) work.
  • Routing policies are free and instant — global failover at DNS level.
  • Interviews love asking how DNS + LB + CDN compose.
Think about it

Mental model

Imagine

A city phone book redesigned per district

Think of

Public vs private DNS

One directory answers the public; each district gets its own private phone book for internal numbers. Routing policies are like operators who send you to the right branch based on your location.

Mechanics

How it works

  • You create a hosted zone (public or private); NS records point domain delegations at it.
  • Alias/A records resolve to LB/CDN endpoints; private zones resolve to private IPs within VPCs.
  • Routing policies pick an answer set: weighted (A/B traffic), latency (nearest measured), failover (active/passive with health checks).
  • Health checks run probes and flip DNS when a target fails.
  • DNSSEC and TLSA strengthen trust where required.

DNS layers in a cloud app.

User query
Public hosted zone
Routing policy
LB / CDN
Private zone
Real world

In production

  • A global SaaS uses a latency-based Route 53 record that points app.example.com to the nearest region's ALB.
  • A VPC-internal microservice addresses other services via private hosted zones with stable service names.
  • An enterprise uses Azure Private DNS zones so private endpoints resolve to private IPs automatically.
Guidelines

Best practices

  • Prefer Alias/CNAME to LB/CDN so DNS changes stay in one place.
  • Use health checks on routing records; never point at a dead target.
  • Version TTL: short for traffic-shaping records, longer for static.
  • Keep private-zone authorities per-VPC and document which VPCs may resolve it.
Watch out

Common mistakes

  • Hardcoding IPs in app config instead of DNS names.
  • Local DNS caches outliving TTL — degradation after failover looks like 'it's still broken'.
  • Public and private zone name collisions resolving confusingly.
  • Forgetting DNSSEC when a partner requires it.
Root cause analysis

Common issues

Error
App can't resolve an internal service
Root cause

Private zone not associated with the app's VPC

Fix

Associate the private zone with the VPC and verify resolution from within.

Error
Failover not working during LB degradation
Root cause

Health check passes 200 but app is failing, or TTL caching

Fix

Make the check app-meaningful (e.g. /healthz with app state) and lower TTLs for critical records.

When things break

Debugging tips

  • dig +norecurse against the zone's NS to see the authoritative answer.
  • Check TTL before claiming 'DNS hasn't propagated'.
  • Private zones: verify the VPC is associated with, and resolver is in, the right scope.
  • Health-check flapping? Look at the probe source IPs and your WAF/LB allowlists.
Interviews

Interview checkpoint

Practice

Hands-on lab

Using a Private Hosted Zone Locally
25 min · intermediate
In progress
Objectives
  • Create records in a private hosted zone (simulated)
  • Point internal services at arbitrary names
  • Verify resolution through DNS tooling

Using a Private Hosted Zone Locally

25 min · intermediate

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

What routing policy sends users to the region with the best measured latency?

Go deeper

Official documentation

AWS — Route 53
docs
Azure — Private DNS
docs
GCP — Cloud DNS
docs