Introduction

DNS is usually innocent until proven guilty.

Unfortunately, it is also blamed for almost everything.

“The website doesn't work.”

“DNS.”

“The application is slow.”

“Probably DNS.”

Sometimes DNS really is the problem. More often, people are using “DNS” as a sophisticated way of saying I have no idea what's wrong yet.

How DNS works

A recursive resolver receives a query from a client and finds the answer on the client's behalf.

If the answer is not cached, the resolver can work through the DNS hierarchy: root servers, TLD servers and authoritative servers.

The authoritative server is the source of truth for the zone. The recursive resolver is the system doing the work for the client.

Mixing those roles up makes DNS architecture harder to understand than it needs to be.

Records you actually use

A records map names to IPv4 addresses.

AAAA records map names to IPv6 addresses.

CNAME creates an alias to another name.

MX records identify mail servers.

TXT records are used for many purposes including SPF-related information and domain verification.

NS records identify authoritative name servers.

You do not need to memorize every DNS record ever invented. Know the common ones and understand what they are supposed to accomplish.

Caching and TTL

DNS caching is one of the reasons changes are not always immediate.

TTL tells resolvers how long an answer may be cached.

A short TTL provides faster change propagation but creates more DNS traffic. A long TTL reduces query load but makes changes slower to roll out.

This is why changing DNS five minutes before a migration and expecting the entire internet to know about it immediately is not a strategy.

Split DNS

Internal users may need a different answer than external users.

For example, app.example.com could resolve to a private address internally and a public address externally.

Split DNS can be implemented through separate internal and external zones or resolver policies.

It is often cleaner than making NAT perform tricks that DNS could have handled properly.

DNS troubleshooting methodology

Start with the client.

Check which DNS server it is actually using. Then query that server directly.

Use:

dig example.com

dig @10.0.0.53 example.com

dig A example.com

dig AAAA example.com

dig +trace example.com

If the resolver returns the expected IP address, DNS has probably done its job. Move on to routing, TCP, TLS or the application.

If the resolver returns SERVFAIL, NXDOMAIN or times out, now you have a DNS problem worth investigating.

The AAAA trap

A very common modern failure is an incorrect or unreachable IPv6 path.

The application gets both A and AAAA records. The operating system attempts IPv6. IPv6 connectivity is broken. The application may fall back to IPv4, or it may experience delays depending on the application and network behavior.

So when troubleshooting modern connectivity, always check both.

DNS did not necessarily break anything. DNS may simply have revealed that your IPv6 deployment was never actually finished.

What actually matters

Good DNS troubleshooting separates resolution from connectivity.

Ask three questions:

1. Did I get an answer? 2. Is the answer correct? 3. Can I actually reach the address?

Those are three different problems.