Skip to main content

Command Palette

Search for a command to run...

DNS and AWS Route 53

Published
8 min readView as Markdown

1. First, what is DNS (simple but deep)

DNS = Domain Name System

Humans remember names
Machines understand IP addresses

Example
You type: www.myapp.com
Browser needs: 52.66.123.10

DNS is the system that converts domain name → IP address

Think of DNS like phone contacts

  • Name = www.myapp.com

  • Number = server IP

Without DNS, you would have to remember IPs for every website.


2. What is AWS Route 53

Route 53 is AWS’s DNS service

It does 3 main things:

  1. Domain registration

  2. DNS management

  3. Traffic routing + health checks

Why name Route 53?

  • DNS uses port 53

  • “Route” means routing traffic


3. Why companies use Route 53 (real reasons)

Companies don’t use Route 53 just because it’s AWS. They use it because:

  • Highly available (AWS global infrastructure)

  • Very fast DNS resolution

  • Easy integration with AWS services

  • Advanced traffic routing (huge deal in DevOps)

  • Health checks + failover

If your app is down, DNS can redirect traffic automatically.


4. Core components of Route 53 (must know)

4.1 Domain

Example:

mycompany.com

You can:

  • Buy domain from Route 53

  • Or buy from GoDaddy and manage DNS in Route 53


4.2 Hosted Zone

Hosted Zone = DNS records container for a domain

Two types:

  1. Public Hosted Zone

    • For internet facing apps

    • Example: myapp.com

  2. Private Hosted Zone

    • Only inside VPC

    • Used for internal services

    • Example: database.internal

Think:

Hosted Zone = DNS configuration file

4.3 DNS Records (very important)

These tell DNS where to send traffic

Common record types:

A Record

  • Domain → IPv4
myapp.com → 13.234.56.78

AAAA Record

  • Domain → IPv6

CNAME

  • Domain → another domain
www.myapp.com → myapp-alb.amazonaws.com

Alias Record (AWS special)

  • Points to AWS resources

  • No extra cost

  • Faster than CNAME

Used with:

  • ALB

  • CloudFront

  • S3 static website

  • API Gateway

This is what you’ll use most in AWS.

MX Record

  • Email routing

TXT

  • Verification, SPF, DKIM

5. How Route 53 actually works (flow)

When user opens your website:

  1. User types www.myapp.com

  2. Browser asks local DNS resolver

  3. Resolver queries Route 53

  4. Route 53 checks hosted zone records

  5. Returns IP or ALB endpoint

  6. Browser connects to server

This whole process happens in milliseconds.


6. When to use Route 53 (real scenarios)

Scenario 1: EC2 hosted website

  • EC2 has public IP

  • Create A record

  • Map domain → EC2 IP

But problem:

  • EC2 IP can change

Better:

  • Put ALB in front

  • Use Alias record → ALB


Scenario 2: Load Balanced application (most common)

Architecture:

User → Route 53 → ALB → EC2 / ECS / EKS

Why:

  • DNS handles routing

  • ALB handles load balancing


Scenario 3: High availability (Multi-region)

Example:

  • App running in Mumbai and Singapore

Route 53:

  • Checks health

  • If Mumbai fails

  • Automatically routes to Singapore

No manual work.


Scenario 4: Blue-Green deployment

  • Old version → 90% traffic

  • New version → 10% traffic

Change DNS routing policy
Gradually shift traffic


7. Routing policies in Route 53 (very important for interviews)

7.1 Simple Routing

  • One record

  • One resource

  • No health check

Used for basic apps.


7.2 Weighted Routing

  • Split traffic by percentage
Version A → 80%
Version B → 20%

Used in:

  • Canary releases

  • A/B testing


7.3 Latency-based Routing

  • Route user to nearest region

  • Based on AWS latency data

Used for global apps.


7.4 Failover Routing

  • Primary + Secondary

  • Health check decides

Used for disaster recovery.


7.5 Geolocation Routing

  • Based on user location

  • Country or continent

Used for:

  • Legal compliance

  • Content control


7.6 Geoproximity Routing

  • Route traffic based on distance

  • Can bias traffic

Advanced global routing.


7.7 Multivalue Answer

  • Returns multiple healthy IPs

  • Simple load balancing at DNS level


8. Health Checks (power feature)

Route 53 can:

  • Ping your endpoint

  • Check HTTP status

  • Monitor specific path

If health check fails:

  • Route 53 stops sending traffic there

This is DNS-level auto healing.


9. Route 53 with AWS services (practical use)

With ALB

  • Alias record → ALB DNS name

With CloudFront

  • Domain → CDN

  • Best for performance

With S3 static website

  • Direct domain mapping

  • No EC2 needed

With API Gateway

  • Clean API URLs

10. Security aspects

  • IAM controls who can edit DNS

  • Supports DNSSEC

  • Private hosted zones for internal apps


11. Cost (basic idea)

  • Hosted zone: low monthly cost

  • Queries: pay per million

  • Alias records: free

Usually very cheap unless massive traffic.


12. Real DevOps engineer usage

As a DevOps engineer, you will:

  • Create hosted zones

  • Manage records during deployments

  • Configure failover

  • Set up health checks

  • Integrate DNS with CI/CD

  • Troubleshoot DNS issues

DNS mistakes can take entire production down, so this is taken seriously.


13. Common mistakes beginners make

  • Using EC2 IP instead of ALB

  • Using CNAME at root domain

  • Forgetting TTL impact

  • No health checks

  • Manual DNS changes without planning


14. Interview-level one-liners

  • Route 53 is a highly available DNS and traffic routing service.

  • Alias records are AWS specific and better than CNAME.

  • Route 53 supports multiple routing policies.

  • Health checks enable DNS-based failover.

Common DNS debugging commands

1. nslookup (basic and fast)

What it does

Queries DNS and returns IP for a domain.

When to use

  • Quick check

  • Is DNS resolving or not

  • First step in debugging

Command

nslookup google.com

Sample output meaning

  • Server → DNS resolver used

  • Address → IP returned

Check specific DNS server

nslookup google.com 8.8.8.8

Use this to compare Route 53 vs public DNS.


2. dig (most important command)

This is the industry standard DNS debugging tool.

Basic query

dig google.com

Key sections to read

  • QUESTION SECTION → what you asked

  • ANSWER SECTION → actual DNS record

  • AUTHORITY SECTION → who controls domain

  • Query time → DNS latency

  • SERVER → which DNS replied


Check specific record type

dig google.com A
dig google.com MX
dig google.com TXT

Very useful when email or verification fails.


Check using specific DNS (Route 53 name server)

dig myapp.com @ns-123.awsdns-45.com

Used when:

  • DNS changes not reflecting

  • Want to confirm Route 53 config is correct


3. dig +short (clean output)

Why

When you just want the answer, not full details.

dig +short myapp.com

Output:

13.235.10.22

Used in scripts and quick checks.


4. host (simple and readable)

What it does

Simpler version of dig.

host google.com

Good for:

  • Quick human readable checks

  • Less noisy output


5. Check CNAME chain (very important in AWS)

dig www.myapp.com

Look for:

www.myapp.com. CNAME myapp-alb.amazonaws.com.

If CNAME is broken:

  • Website won’t open

  • SSL may fail


6. Trace full DNS path (advanced but powerful)

dig myapp.com +trace

What this shows:

  • Root servers

  • TLD servers (.com)

  • Authoritative DNS (Route 53)

Used when:

  • Domain not resolving globally

  • Nameserver misconfiguration


7. TTL debugging (cache issues)

Why TTL matters

DNS changes don’t apply instantly because of caching.

Check TTL:

dig myapp.com

Look at number like:

300

Means:

  • DNS cached for 300 seconds

Low TTL = faster changes, slightly more queries.


8. Check Route 53 Alias behavior

Alias records don’t show as CNAME.

dig myapp.com

You’ll see:

A  dualstack.my-alb-123.us-east-1.elb.amazonaws.com

This is normal for ALB alias.


9. Debug health check based routing

If failover not working:

dig myapp.com
  • If primary unhealthy

  • Route 53 stops returning it

Use AWS Console to confirm health check status.


10. Check from different locations (real production issue)

DNS can differ globally.

Use:

dig myapp.com @1.1.1.1
dig myapp.com @8.8.8.8

Helps when:

  • Works in office but not for users

  • ISP cache issues


11. Flush local DNS cache (local system issue)

Linux

sudo systemctl restart systemd-resolved

Ubuntu (older)

sudo service dns-clean restart

Windows

ipconfig /flushdns

Mac

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

12. Common real-world DNS problems + command

Website not opening

dig myapp.com

Check:

  • IP returned?

  • Correct ALB?


SSL certificate error

dig www.myapp.com

Check:

  • CNAME mismatch

  • Wrong CloudFront distribution


Email not working

dig mydomain.com MX

Check:

  • Correct mail servers

  • Priority values


Route 53 change not reflecting

dig myapp.com @ns-xxx.awsdns-xx.com

If correct here but not globally → cache issue.


13. DevOps interview gold lines

  • “I start DNS debugging with dig, not nslookup.”

  • “I check authoritative nameservers directly.”

  • “TTL explains why DNS changes take time.”

  • “Route 53 alias records behave differently from CNAME.”


14. Must-practice mini lab (do this)

  1. Create hosted zone in Route 53

  2. Add A record → ALB

  3. Run:

dig yourdomain.com
dig +trace yourdomain.com

This will make DNS crystal clear.

More from this blog

T

The DevOps Journal

23 posts