What DNS actually does

Topic: Networking basics

DNS maps hostnames to IP addresses and back. Learn how queries and responses work, what resolvers and authoritative servers do, and when DNS is the cause of 'can't reach host' or slow connections. Use this before debugging connectivity or configuring resolvers.

Intent: How-to

Quick answer

  • DNS turns names (e.g. example.com) into IPs and vice versa; your host asks a resolver, which may ask root, TLD, and authoritative servers in a chain.
  • Caching at resolver and OS shortens lookups; TTL controls how long a cached answer is valid; stub resolvers (e.g. on your host) forward to a recursive resolver.
  • When a name does not resolve, the failure is in the chain (NXDOMAIN, timeout, or wrong answer); use dig or getent to see where it breaks.

Steps

  1. Understand the query path

    Application asks for a name; OS stub resolver sends query to configured resolver (e.g. 8.8.8.8); resolver recurses from root to TLD to authoritative server and returns the answer.

  2. Know record types you will see

    A and AAAA for IPv4 and IPv6 address; CNAME for alias; MX for mail; NS for name server. Most troubleshooting uses A/AAAA and sometimes CNAME.

  3. Understand caching and TTL

    Resolvers and the OS cache answers for the TTL; lower TTL means more fresh lookups but more load; stale cache can cause wrong or missing answers until TTL expires.

  4. Relate DNS to connectivity

    If the name does not resolve, the connection never gets an IP; if the wrong IP is returned (cache poison or misconfig), you reach the wrong host; always verify resolution when debugging.

Summary

DNS translates hostnames to IP addresses (and optionally the reverse) so applications can connect by name. Queries flow from your host to a resolver, then through the hierarchy of authoritative servers. Use this when you need to understand why a name does not resolve or when configuring or debugging resolvers.

Prerequisites

  • None; this is a foundation concept.

Steps

Step 1: Understand the query path

Your application requests a hostname. The OS stub resolver sends a query to the configured recursive resolver (e.g. in /etc/resolv.conf). The resolver, if it does not have a cached answer, queries root servers, then the TLD server, then the authoritative server for the domain, and returns the final answer (e.g. A or AAAA record).

Step 2: Know record types you will see

  • A: IPv4 address.
  • AAAA: IPv6 address.
  • CNAME: Alias to another name (resolution continues).
  • MX: Mail server (used by mail software).
  • NS: Name server for the zone.

For “can’t reach host” or wrong host, focus on A and AAAA (and CNAME if present).

Step 3: Understand caching and TTL

Each answer has a TTL (time to live) in seconds. Resolvers and the OS cache the answer for that duration. Shorter TTL means changes propagate faster but increase load; longer TTL reduces load but can serve stale data. If you changed a record, wait for TTL to expire or flush cache to see the new value.

Step 4: Relate DNS to connectivity

If DNS returns NXDOMAIN or times out, the application never gets an IP and connection fails. If DNS returns the wrong IP (misconfiguration or cache), you connect to the wrong host. When debugging “can’t connect,” always check that the name resolves to the expected IP.

Verification

  • You can explain the path of a DNS query (stub → resolver → hierarchy) and name at least A, AAAA, and CNAME. You know that resolution must succeed and return the right IP before a connection can be made.

Troubleshooting

Name never resolves — Check resolver config (/etc/resolv.conf or netplan); test with dig or getent hosts; ensure firewall allows outbound DNS (UDP/TCP 53) to the resolver.

Wrong IP returned — Stale cache; wait for TTL or flush local/resolver cache; verify authoritative answer with dig @authoritative-server name.

Slow resolution — Resolver far away or overloaded; try a closer or faster resolver; check for unnecessary search domains or timeouts.

Next steps

Continue to