When you enter a domain name such as www.example.com in a browser, your device needs an IP address to connect to the right server. The Domain Name System (DNS) provides this lookup, but the answer may pass through several servers and caches before it reaches your device. Understanding those steps makes it easier to troubleshoot websites and reason about networking.
Key takeaways
- DNS maps domain names to records, including IPv4 addresses (A) and IPv6 addresses (AAAA).
- A recursive resolver looks up answers on a user's behalf; authoritative nameservers publish a domain's DNS records.
- Caches and record TTLs affect how quickly DNS changes are seen.
- A successful DNS lookup does not prove that a website is reachable or that its HTTP service is working.
How DNS works for beginners
DNS is a distributed naming system. Rather than keeping every domain's information in one central database, it delegates responsibility across levels of the DNS hierarchy. Your computer typically asks a recursive resolver to find an answer. That resolver may use a cached answer or query other DNS servers to obtain one.
A simplified lookup for www.example.com works like this:
- The device checks local information. The operating system or application may have a cached result. A local hosts file can also provide a mapping without a DNS query.
- The device asks a recursive resolver. This resolver is often provided by an internet provider, organization, router, or public DNS service. It handles the lookup for the device.
- The resolver follows DNS referrals if necessary. It can ask a root nameserver where to find the relevant top-level domain (TLD), such as
.com. A TLD nameserver then points it toward the domain's authoritative nameservers. - An authoritative nameserver provides the domain's records. For example, it may return an A record for an IPv4 address or an AAAA record for an IPv6 address.
- The resolver returns and caches the result. The device can then use the address to attempt a network connection.
The root and TLD servers generally provide referrals; they do not hold every website's address. The authoritative nameservers for a domain are responsible for its published DNS data.
Recursive resolvers and authoritative nameservers
These server roles are easy to confuse:
| Role | What it does |
|---|---|
| Recursive resolver | Accepts a lookup from a client and works to return an answer, often by using its cache or querying other DNS servers. |
| Authoritative nameserver | Publishes DNS data for a zone, such as records for a domain managed by that zone. |
A recursive resolver may contact root, TLD, and authoritative servers as part of one lookup. In practice, caching often means it does not need to repeat every step for every request. A client usually relies on its configured resolver rather than querying the DNS hierarchy directly.
DNS answers can have different statuses. A name that does not exist may result in NXDOMAIN; a name may exist but have no requested record type; or the lookup may fail because a server cannot be reached. Those outcomes point to different problems.
DNS records: A, AAAA, and CNAME
A DNS response contains records associated with a name and record type. Common types include:
- A: Maps a hostname to an IPv4 address.
- AAAA: Maps a hostname to an IPv6 address.
- CNAME: Makes one DNS name an alias of another name. A resolver follows the alias to find the target's records.
A CNAME does not directly contain an IP address. For example, shop.example.com might be configured as an alias of store.provider.example; the resolver then looks up the target name. A CNAME can affect how many lookups are needed, and its target must ultimately lead to the records a client needs.
A domain can have an A record, an AAAA record, both, or neither for a particular name. Clients and networks differ in their IPv4 and IPv6 connectivity, so checking both record types can help explain why access behaves differently across environments.
Caching and TTL
DNS caching reduces repeated lookups. A resolver, operating system, browser, or network device may cache answers. Each record has a time to live (TTL) that indicates how long the answer may be cached, typically expressed in seconds. When the TTL expires, a resolver can query again for fresh data.
A TTL is not a guarantee that every user will see an update at exactly the same moment. Different resolvers may have cached answers at different times, and local caches or application behavior can also affect what a client sees. If you change a DNS record, check the TTL and query more than one resolver before concluding that a change has propagated everywhere.
Some DNS responses can also be cached when a name or record is absent. This negative caching is one reason a newly added record may not appear immediately if a resolver previously received a response indicating that it was missing.
DNS resolution is not HTTP availability
DNS answers the question, “What DNS information is associated with this name?” It does not confirm that a server is running, that a firewall permits traffic, or that a web application is responding.
A lookup can succeed while a browser still fails because of routing, a blocked port, a server outage, a TLS certificate problem, a reverse proxy, or an HTTP error such as 404 Not Found or 503 Service Unavailable. Conversely, a website might work from one network but not another because they use different resolvers, cached answers, or network routes.
Troubleshoot in stages: first check whether DNS returns the expected records, then test whether the host is reachable on the relevant port, and finally inspect the HTTP or HTTPS response. Each test checks a different part of the path.
Practical DNS troubleshooting commands
Use a terminal to query record types directly. These examples are read-only lookups; replace www.example.com with a hostname you are authorized to investigate.
# Query IPv4 and IPv6 records
dig www.example.com A
dig www.example.com AAAA
# Ask a particular recursive resolver
dig @1.1.1.1 www.example.com A
# Show the delegation path from the DNS root
dig +trace www.example.com A
dig is commonly available on Linux and macOS; it may need to be installed separately on some systems. The +trace option performs an iterative walk through DNS delegation rather than asking a recursive resolver for a single final answer, so it can help identify where a lookup path stops.
For a CNAME lookup, try:
dig www.example.com CNAME
A name that has no CNAME may return no CNAME record, even if its A or AAAA lookup succeeds. To check a basic HTTP response separately, use a client such as curl:
curl -I https://www.example.com/
This sends an HTTP request and is not a DNS-only test. A failed request can have causes beyond DNS, and a successful response does not establish that every page or service on the host is healthy.
On Windows, nslookup is commonly available:
nslookup www.example.com
nslookup -type=AAAA www.example.com
nslookup www.example.com 1.1.1.1
The last command asks the specified DNS server. Compare results from your configured resolver and another resolver to help narrow down whether the issue is local, resolver-specific, or related to the published DNS data. Resolver differences are clues, not proof of a single cause.
Common mistakes and troubleshooting tips
- Assuming a DNS answer means the site is up. Follow a successful lookup with a connection and HTTP test.
- Checking only A records. Query AAAA records too, especially when the issue occurs only on some networks.
- Expecting a DNS change to appear immediately everywhere. Consider TTLs, resolver caches, and negative caching.
- Treating a CNAME as an IP address. It points to another DNS name, which must be resolved in turn.
- Querying one resolver and generalizing from it. Compare the configured resolver with another trusted resolver, and inspect authoritative data when you manage the domain.
- Misreading a missing record. A name can exist without having the particular record type requested. Check the response status and query relevant types.
A useful troubleshooting workflow
- Confirm the exact hostname, including any subdomain such as
www. - Query both A and AAAA records and note the response status and returned data.
- Compare your normal resolver with another resolver; use
dig +traceif you need to inspect delegation. - Check the DNS records and TTL at the authoritative provider if you manage the domain.
- Test the connection and HTTP response separately. If DNS looks correct but the request fails, investigate network reachability, TLS, and the web server.
Conclusion
DNS translates names into structured records through a hierarchy of resolvers and authoritative nameservers. Knowing the difference between those roles, understanding A, AAAA, and CNAME records, and accounting for TTL-based caching makes DNS results easier to interpret. Most importantly, treat name resolution and website availability as separate checks: DNS can point to an address even when the service at that address cannot respond.