Backend interview prep

Start

DNS Interview Questions (Top 15 Questions with Answers)

Master DNS Interview Questions with production-ready explanations covering DNS resolution, recursive and authoritative servers, record types, TTL, caching, private DNS, split-horizon DNS, DNS failover, Route 53, Azure DNS, Cloud DNS, troubleshooting, and enterprise architecture.

Module Navigation

Previous: Load Balancers QA | Parent: Networking Learning Path | Next: CDN QA

Introduction

DNS stands for Domain Name System.

DNS translates human-readable domain names into IP addresses.

Example:

www.example.com

↓

203.0.113.20

Without DNS, users would need to remember IP addresses for every website or application.

DNS is used by:

  • Websites
  • APIs
  • Microservices
  • Databases
  • Kubernetes services
  • Load balancers
  • Email systems
  • Hybrid cloud networks
  • Private applications

Major cloud DNS services include:

Cloud Provider DNS Service
AWS Amazon Route 53
Azure Azure DNS and Azure Private DNS
Google Cloud Cloud DNS

A typical DNS resolution flow is:

User
  │
  ▼
Browser Cache
  │
  ▼
Operating System Cache
  │
  ▼
Recursive DNS Resolver
  │
  ▼
Root DNS Server
  │
  ▼
Top-Level Domain Server
  │
  ▼
Authoritative DNS Server
  │
  ▼
IP Address Returned

DNS is critical for:

  • Service discovery
  • Traffic routing
  • High availability
  • Failover
  • Global applications
  • Private cloud communication
  • Disaster recovery

This guide contains 15 production-focused DNS interview questions covering DNS resolution, records, caching, TTL, private DNS, split-horizon DNS, cloud DNS, security, troubleshooting, failover, and enterprise architecture.

Learning Roadmap

DNS Fundamentals
       │
       ▼
DNS Resolution
       │
       ▼
DNS Record Types
       │
       ▼
Caching and TTL
       │
       ▼
Private DNS
       │
       ▼
DNS Routing and Failover
       │
       ▼
DNS Security
       │
       ▼
Enterprise Architecture

DNS Fundamentals

1. What is DNS?

DNS is a distributed naming system that maps domain names to network resources.

Example:

api.company.com

↓

10.20.10.25

DNS can map a name to:

  • IPv4 address
  • IPv6 address
  • Mail server
  • Load balancer
  • Alias
  • Service endpoint
  • Text metadata

Benefits:

  • Human-readable names
  • Service abstraction
  • Easier migration
  • Load balancing
  • Failover
  • Centralized naming

DNS separates application names from physical IP addresses.

2. Why is DNS important in cloud networking?

Cloud resources frequently change because of:

  • Auto Scaling
  • Container restarts
  • Kubernetes rescheduling
  • Multi-region failover
  • Load balancer replacement
  • Blue-green deployment
  • Disaster recovery

Applications should not depend on hardcoded IP addresses.

Bad design:

Application

↓

Connect to 10.10.2.45

Better design:

Application

↓

Connect to database.internal.company.com

DNS provides a stable name even when the underlying destination changes.

DNS Resolution

3. How does DNS resolution work?

Suppose a user requests:

www.example.com

The typical lookup flow is:

Browser
   │
   ▼
Browser DNS Cache
   │
   ▼
Operating System Cache
   │
   ▼
Recursive Resolver
   │
   ▼
Root DNS Server
   │
   ▼
.com TLD Server
   │
   ▼
Authoritative DNS Server
   │
   ▼
IP Address Returned

Detailed steps:

  1. Browser checks its cache.
  2. Operating system checks its DNS cache.
  3. Request goes to a recursive resolver.
  4. Resolver asks a root server.
  5. Root server points to the .com TLD server.
  6. TLD server points to the authoritative DNS server.
  7. Authoritative server returns the DNS record.
  8. Resolver caches the response.
  9. IP address is returned to the client.

4. What is the difference between recursive and authoritative DNS servers?

Recursive DNS Resolver

The recursive resolver performs the lookup on behalf of the client.

Responsibilities:

  • Queries other DNS servers
  • Caches responses
  • Returns the final answer

Examples:

  • Internet service provider DNS
  • Enterprise DNS resolver
  • Public DNS resolver
  • Cloud-provided resolver

Authoritative DNS Server

The authoritative server stores the official DNS records for a domain.

Example:

example.com

A Record

203.0.113.20

Comparison:

Recursive Resolver Authoritative Server
Searches for the answer Stores the official answer
Used by clients Used by domain owners
Caches responses Hosts DNS zones
Queries other DNS servers Responds from configured records

5. What are root and TLD DNS servers?

Root DNS servers

Root servers sit at the top of the DNS hierarchy.

They direct queries to the correct top-level-domain server.

Example:

www.example.com

↓

Root Server

↓

.com Server

TLD servers

TLD stands for Top-Level Domain.

Examples:

  • .com
  • .org
  • .net
  • .in
  • .io

The TLD server identifies the authoritative name servers for a domain.

DNS hierarchy:

Root
  │
  ▼
Top-Level Domain
  │
  ▼
Authoritative Domain
  │
  ▼
Host Record

DNS Records

6. What are the common DNS record types?

Record Purpose
A Maps a name to an IPv4 address
AAAA Maps a name to an IPv6 address
CNAME Maps one name to another name
MX Identifies mail servers
TXT Stores text-based metadata
NS Identifies authoritative name servers
SOA Stores DNS-zone authority information
PTR Reverse lookup from IP to name
SRV Defines service location and port
CAA Specifies allowed certificate authorities

Examples:

A

api.example.com

↓

203.0.113.25

AAAA

api.example.com

↓

2001:db8::25

MX

example.com

↓

mail.example.com

7. What is the difference between A, AAAA, CNAME, and alias records?

A record

Maps a name to an IPv4 address.

app.example.com

↓

203.0.113.10

AAAA record

Maps a name to an IPv6 address.

app.example.com

↓

2001:db8::10

CNAME record

Maps one hostname to another hostname.

www.example.com

↓

app.example.net

A CNAME does not directly contain an IP address.

Alias record

Some cloud DNS providers support proprietary alias-style records that map a DNS name to a cloud resource.

Example:

example.com

↓

Cloud Load Balancer

Alias records are useful for:

  • Load balancers
  • CDN distributions
  • Cloud storage websites
  • Root-domain routing

A standard CNAME usually cannot be placed at the zone apex because the apex must also contain records such as NS and SOA.

8. What are NS and SOA records?

NS record

NS stands for Name Server.

It identifies the authoritative DNS servers for a domain.

Example:

example.com

↓

ns1.dns-provider.com

ns2.dns-provider.com

SOA record

SOA stands for Start of Authority.

It contains zone-level information such as:

  • Primary name server
  • Administrative contact
  • Serial number
  • Refresh interval
  • Retry interval
  • Expiration interval
  • Negative caching TTL

The SOA record helps DNS servers manage zone synchronization and caching behavior.

Caching and TTL

9. What is DNS TTL?

TTL stands for Time to Live.

TTL determines how long a DNS response may be cached.

Example:

api.example.com

203.0.113.20

TTL = 300 Seconds

Resolvers may cache the answer for five minutes.

Lower TTL

Advantages:

  • Faster DNS changes
  • Faster failover
  • Useful during migration

Disadvantages:

  • More DNS queries
  • Higher DNS load
  • Less caching efficiency

Higher TTL

Advantages:

  • Better cache efficiency
  • Fewer DNS queries
  • Reduced resolver load

Disadvantages:

  • Slower propagation of changes
  • Longer failover time

A suitable TTL depends on how frequently the record changes.

10. What is DNS caching, and where does it occur?

DNS responses may be cached at several layers:

Browser Cache
      │
      ▼
Operating System Cache
      │
      ▼
Local Network Resolver
      │
      ▼
Recursive DNS Resolver

Benefits:

  • Faster resolution
  • Lower latency
  • Reduced DNS traffic
  • Lower authoritative-server load

A stale result may remain until its TTL expires.

When troubleshooting DNS changes, verify:

  • Browser cache
  • Operating-system cache
  • Local resolver cache
  • Recursive resolver cache
  • CDN cache
  • Application DNS cache

Applications such as JVM services may also cache DNS results based on runtime configuration.

Private DNS

11. What is private DNS?

Private DNS resolves names only inside an approved private network.

Example:

database.internal.company.com

↓

10.20.5.25

The name is not publicly resolvable.

Use cases:

  • Internal APIs
  • Databases
  • Kubernetes services
  • Private load balancers
  • Shared services
  • Hybrid cloud resources
  • Private endpoints

Architecture:

Private Application
        │
        ▼
Private DNS Resolver
        │
        ▼
Private DNS Zone
        │
        ▼
Private Resource

Cloud services include:

  • Route 53 Private Hosted Zones
  • Azure Private DNS
  • Google Cloud private zones

12. What is split-horizon DNS?

Split-horizon DNS returns different answers for the same name depending on where the request originates.

Example:

External request:

api.company.com

↓

203.0.113.20

Internal request:

api.company.com

↓

10.20.1.20

Architecture:

Internet User
      │
      ▼
Public DNS Zone
      │
      ▼
Public Load Balancer

Internal User
      │
      ▼
Private DNS Zone
      │
      ▼
Internal Load Balancer

Benefits:

  • Private internal routing
  • Reduced public exposure
  • Reuse of consistent hostnames
  • Better performance
  • Easier application configuration

Risks:

  • Incorrect zone association
  • Inconsistent records
  • Difficult troubleshooting
  • Different answers between environments

Routing and Availability

13. How can DNS provide traffic routing and failover?

Managed DNS services can route traffic using policies such as:

  • Simple routing
  • Weighted routing
  • Latency-based routing
  • Geographic routing
  • Geoproximity routing
  • Failover routing
  • Multi-value routing

Weighted routing

90% Traffic

↓

Version A

10% Traffic

↓

Version B

Used for:

  • Canary deployment
  • Blue-green release
  • Gradual migration

Latency routing

User

↓

Region with Lowest Expected Latency

Failover routing

Primary Region Healthy?

Yes → Primary

No → Secondary

DNS failover usually depends on:

  • Health checks
  • Routing policy
  • Low enough TTL
  • Secondary endpoint readiness

DNS failover is not always instantaneous because resolvers may cache previous answers.

Security and Troubleshooting

14. What are common DNS security risks and troubleshooting steps?

Common DNS security risks include:

  • DNS spoofing
  • Cache poisoning
  • DNS hijacking
  • Unauthorized record changes
  • Domain takeover
  • DNS tunneling
  • Misconfigured zone delegation
  • Exposed private records
  • DDoS attacks
  • Expired domain registration

Security controls:

  • DNSSEC
  • Multi-factor authentication
  • Role-based access
  • Change approval
  • Audit logging
  • Registrar lock
  • Restricted zone permissions
  • DNS filtering
  • Monitoring unusual query patterns
  • DDoS protection

Troubleshooting flow:

Application Cannot Resolve Name
             │
             ▼
Check Hostname Spelling
             │
             ▼
Query DNS Resolver
             │
             ▼
Check Record Type and Value
             │
             ▼
Check Zone and Delegation
             │
             ▼
Check TTL and Cache
             │
             ▼
Check Private Zone Association
             │
             ▼
Check Firewall for Port 53
             │
             ▼
Test Authoritative Server

Useful commands:

nslookup api.example.com

dig api.example.com

dig NS example.com

dig +trace example.com

host api.example.com

Common causes of DNS failures:

  • Missing record
  • Incorrect record value
  • Expired domain
  • Wrong name-server delegation
  • Private zone not associated
  • Port 53 blocked
  • Stale cache
  • Incorrect search domain
  • DNS resolver unavailable
  • Conflicting public and private records

Enterprise Architecture

15. How would you design enterprise DNS architecture?

An enterprise DNS design should support:

  • Public applications
  • Private applications
  • Hybrid networks
  • Multiple cloud providers
  • Regional failover
  • Central governance
  • Security monitoring

Architecture:

Internet Users
      │
      ▼
Public Authoritative DNS
      │
      ▼
Global Load Balancer / CDN
      │
      ▼
Public Applications

Private architecture:

Cloud Applications
        │
        ▼
Cloud DNS Resolver
        │
        ▼
Private DNS Zones
        │
        ▼
Internal Services

Hybrid DNS:

On-Premises DNS
       │
       ▼
Conditional Forwarder
       │
       ▼
Cloud DNS Resolver Endpoint
       │
       ▼
Private Cloud Zone

Multi-cloud design:

Enterprise DNS Governance
          │
    ┌─────┼────────────┐
    ▼     ▼            ▼
AWS DNS Azure DNS Google Cloud DNS

Recommended controls:

  • Separate public and private zones
  • Centralized domain ownership
  • Standard naming conventions
  • Conditional forwarding
  • Redundant resolvers
  • DNSSEC for public zones where appropriate
  • Role-based access
  • Audit logging
  • Automated record management
  • Health checks
  • Failover policies
  • TTL standards
  • Domain-expiration monitoring
  • Disaster-recovery testing
  • Infrastructure as Code

Production Scenario

Enterprise Banking Platform

Requirements:

  • Public mobile APIs
  • Private microservices
  • AWS and Azure workloads
  • On-premises Oracle systems
  • Multi-region failover
  • Strong DNS security

Public flow:

Mobile User
      │
      ▼
api.bank.com
      │
      ▼
Public DNS
      │
      ▼
Global Load Balancer
      │
      ▼
Primary Region

Failover:

Primary Region Unhealthy
          │
          ▼
DNS Health Check Fails
          │
          ▼
Secondary Region Returned

Private flow:

Spring Boot Service
        │
        ▼
customer-api.internal.bank.com
        │
        ▼
Private DNS
        │
        ▼
Internal Load Balancer

Hybrid flow:

Cloud Application
       │
       ▼
Cloud DNS Resolver
       │
       ▼
Conditional Forwarding
       │
       ▼
On-Premises DNS
       │
       ▼
Oracle Service

Benefits:

  • Stable application names
  • Private service discovery
  • Multi-region failover
  • Hybrid connectivity
  • Centralized governance
  • Reduced public exposure

DNS Resolution Flow

Client
  │
  ▼
Recursive Resolver
  │
  ▼
Root Server
  │
  ▼
TLD Server
  │
  ▼
Authoritative Server
  │
  ▼
DNS Answer

DNS Record Flow

Application Name
      │
      ▼
DNS Record
      │
      ▼
IP Address or Hostname
      │
      ▼
Destination Service

Private DNS Flow

Private Client
      │
      ▼
Cloud DNS Resolver
      │
      ▼
Private Hosted Zone
      │
      ▼
Private Load Balancer

DNS Failover Flow

Client Request
      │
      ▼
DNS Health Evaluation
      │
 ┌────┴──────────┐
 ▼               ▼
Primary Healthy  Primary Unhealthy
 │               │
 ▼               ▼
Primary IP     Secondary IP

DNS Troubleshooting Flow

DNS Failure
    │
    ▼
Check Local Cache
    │
    ▼
Check Resolver
    │
    ▼
Check Zone
    │
    ▼
Check Record
    │
    ▼
Check Delegation
    │
    ▼
Check Network and Port 53
    │
    ▼
Check Authoritative Response

Common DNS Mistakes

✗ Hardcoding IP addresses
✗ Setting TTL too high before migration
✗ Setting TTL unnecessarily low permanently
✗ Incorrect CNAME configuration
✗ Using a CNAME at the zone apex without provider support
✗ Missing NS delegation
✗ Forgetting private-zone association
✗ Creating conflicting public and private records
✗ Exposing internal names publicly
✗ Blocking TCP or UDP port 53
✗ Not monitoring domain expiration
✗ No access control on DNS changes
✗ No DNS query logging
✗ Depending on one DNS resolver
✗ Assuming DNS failover is instantaneous

Best Practices Checklist

✓ Use DNS Names Instead of Hardcoded IPs
✓ Separate Public and Private Zones
✓ Use Consistent Naming Standards
✓ Choose TTL Based on Change Frequency
✓ Lower TTL Before Planned Migration
✓ Use Health-Checked Failover
✓ Deploy Redundant DNS Resolvers
✓ Enable DNS Query Logging
✓ Protect DNS Administration with MFA
✓ Apply Least-Privilege Access
✓ Enable Audit Logging
✓ Monitor Domain Expiration
✓ Use DNSSEC Where Appropriate
✓ Use Conditional Forwarding for Hybrid Networks
✓ Avoid Conflicting DNS Zones
✓ Automate DNS Changes with Infrastructure as Code
✓ Test Disaster Recovery
✓ Monitor Resolution Latency
✓ Document Zone Ownership
✓ Review DNS Records Regularly

Quick Revision

Topic Key Point
DNS Maps names to network resources
Recursive Resolver Finds DNS answers for clients
Authoritative Server Stores official DNS records
Root Server Directs queries to TLD servers
TLD Server Directs queries to authoritative servers
A Record Name to IPv4
AAAA Record Name to IPv6
CNAME Name to another hostname
MX Mail server
NS Authoritative name server
SOA Zone authority information
TTL DNS cache duration
Private DNS Internal name resolution
Split-Horizon DNS Different internal and external answers
DNS Failover Returns a secondary endpoint when required
DNSSEC Protects DNS response authenticity
Best Practice Secure, redundant, automated public and private DNS

Interview Follow-Up Questions

Interviewers may ask:

  1. What happens when a DNS record is not available in cache?
  2. What is the difference between recursive and authoritative DNS?
  3. Why can a CNAME not normally be used at the zone apex?
  4. What is the difference between an A record and an alias record?
  5. How does TTL affect DNS failover?
  6. Why may DNS changes appear differently to different users?
  7. What is negative DNS caching?
  8. What is split-horizon DNS?
  9. How do private DNS zones work?
  10. How do cloud and on-premises DNS systems integrate?
  11. What is DNSSEC?
  12. How do you troubleshoot an NXDOMAIN response?
  13. Why does DNS use both UDP and TCP port 53?
  14. How would you design DNS for a multi-region application?
  15. How would you prevent unauthorized DNS-record changes?

Interview Tips

During DNS interviews:

  • Define DNS as a distributed system that maps names to network resources.
  • Explain the complete resolution flow from client cache to authoritative server.
  • Clearly differentiate recursive resolvers and authoritative servers.
  • Be ready to explain A, AAAA, CNAME, MX, NS, SOA, PTR, TXT, and SRV records.
  • Explain how TTL and caching affect performance, migration, and failover.
  • Discuss private DNS and split-horizon DNS for internal applications.
  • Explain DNS routing policies such as weighted, latency-based, geographic, and failover routing.
  • Mention that DNS failover is affected by cached responses and is not necessarily immediate.
  • Include DNSSEC, access control, audit logging, domain-expiration monitoring, and query logging in security answers.
  • Use dig, nslookup, authoritative queries, and delegation checks during troubleshooting.

Summary

DNS provides the naming and service-discovery foundation for public, private, hybrid, and multi-cloud applications.

Key concepts include:

  • DNS Fundamentals
  • DNS Resolution
  • Recursive Resolvers
  • Authoritative DNS
  • Root and TLD Servers
  • DNS Record Types
  • A and AAAA Records
  • CNAME and Alias Records
  • NS and SOA Records
  • DNS TTL
  • DNS Caching
  • Private DNS
  • Split-Horizon DNS
  • DNS Routing Policies
  • DNS Failover
  • DNS Security
  • Enterprise DNS Architecture

Mastering these 15 DNS interview questions prepares you for Cloud Engineer, Network Engineer, DevOps Engineer, Site Reliability Engineer, Platform Engineer, Cloud Security Engineer, Kubernetes Engineer, Technical Lead, Solution Architect, and Enterprise Architect interviews.