Part 17 – Getting Started with DNS

Getting Started with DNS

Table Of Contents
  1. Getting Started with DNS
  2. Resources

Introduction

Welcome to Part 17 of the Network Fundamentals study notes! If you haven’t already, we recommend watching the video first.

We’ve all typed a web address into a browser and had a page load. But computers communicate using IP addresses — not names. Something must be translating one to the other. That something is the Domain Name System, or DNS. Think of it like a phone book: you know the name, DNS gives you the number.

The Domain Namespace

A domain name like www.networkdirection.net is actually a structured hierarchy — though we don’t always think of it that way. There’s also a trailing dot at the end that browsers hide from us: www.networkdirection.net.

This full name is called the FQDN — Fully Qualified Domain Name. Reading it from right to left:

  • . (dot) — the root domain. The very top of the hierarchy, always present but usually invisible.
  • net — the Top Level Domain (TLD). Other TLDs include .com, .org, and country-specific ones like .co.uk or .net.au.
  • networkdirection — the second-level domain. This is the name you register.
  • www — a hostname. In this case, it identifies the web server within the domain. Some names have additional subdomains between the second-level domain and the hostname.

Zones and Records

A DNS server stores its information in zones. Each zone is a database for a particular domain — for example, a zone for networkdirection.net. Inside each zone are records, which hold the actual information.

If a DNS server has a zone for a domain, it is authoritative for that domain — it believes it knows everything about it. If you query an authoritative server for a record that doesn’t exist in its zone, it will tell you confidently that the record doesn’t exist. A non-authoritative server is willing to admit it might not have the full picture, and will go looking elsewhere for the answer.

Common Record Types

  • A record (Host record) – the most common type. Maps a hostname to an IPv4 address. For example: www → 203.0.113.10.
  • PTR record (Pointer record) – the reverse of an A record. Maps an IP address back to a hostname. Used in reverse lookup zones, which are named after subnets. The FQDN in a reverse zone is written backwards and ends with in-addr.arpa.
  • CNAME record (Canonical Name / Alias) – maps one name to another. For example, web → www. This is useful because if the A record ever changes, you only need to update it in one place — all CNAME records pointing to it automatically follow.
  • MX record (Mail Exchanger) – advertises the IP addresses of your mail servers to the internet. When an external mail server wants to send you email, it looks up the MX record to find where to deliver it.

How a DNS Lookup Works

When a client needs to resolve a name, it sends a query to its configured DNS server using UDP port 53. The query contains the FQDN it’s looking for. The DNS server checks its zone:

  • If the record exists, it returns the IP address to the client.
  • If the record doesn’t exist (and the server is authoritative for the domain), it tells the client the record doesn’t exist.
  • If the server isn’t authoritative and doesn’t have the answer cached, it goes looking — more on that below.

Once the client gets a response, it stores it in its local DNS cache for performance, so it won’t need to ask the server again for a while.

TTL – Time to Live

Each DNS record has a TTL value — how long (in seconds) a client or server should cache the record before discarding it. Once a cached record expires, the next request triggers a fresh lookup. A shorter TTL means changes propagate faster; a longer TTL reduces DNS traffic.

On Windows, you can view your DNS cache with ipconfig /displaydns and clear it with ipconfig /flushdns. Flushing is useful when a DNS record has changed and you want to pick up the new value immediately without waiting for the TTL to expire.

Resolving Internet Names: Recursive and Iterative Queries

Your local DNS server knows about your own domains, but what about looking up something on the internet — like blog.cloudflare.com? Your server isn’t authoritative for cloudflare.com, so it needs to find someone who is. This involves two types of query:

Recursive Query

When your client asks your DNS server for an answer, that’s a recursive query. Your client is saying “I need the answer — go find it for me.” The DNS server takes on the responsibility of doing all the work and returning the final answer (not hints — the actual IP).

Iterative Query

When your DNS server then queries other servers to find the answer, those are iterative queries. Each server it contacts either gives the answer or sends back a referral — the address of another server that might know more. Your DNS server keeps doing the legwork until it has the answer, then passes it back to the original client.

Forwarders and Root Hints

Your DNS server needs to know where to start when it can’t answer a query itself. There are two options:

  • Forwarders – you configure your DNS server with the IP address of one or more upstream DNS servers (e.g. your ISP’s servers, or public servers like 8.8.8.8). Unresolved queries are sent straight there.
  • Root hints – if no forwarders are configured, the server falls back to the root hints process. DNS servers come pre-loaded with the IP addresses of 13 root servers distributed around the world. These servers are authoritative for the root namespace and know where to find the servers for every TLD.

A full internet resolution using root hints works like this: your server asks a root server → the root server refers it to the TLD server (e.g. for .com) → the TLD server refers it to the authoritative server for cloudflare.com → that server returns the answer. Your server caches the result and sends it to the original client.

Troubleshooting DNS

If DNS isn’t working, work through these steps:

  1. Check the DNS server setting on the client — run ipconfig /all on Windows to confirm a DNS server is configured.
  2. Ping the DNS server — if it’s not responding, it can’t help.
  3. Flush the cache — run ipconfig /flushdns to clear stale entries.
  4. Bypass DNS temporarily — add a manual entry to the hosts file on Windows (or use ip host <name> <ip> on a Cisco router) to test connectivity without DNS. Keep in mind this is for testing only — don’t leave manual entries in place permanently as they’ll mask future problems.

For querying DNS directly, use nslookup on Windows or dig on Unix/Linux. These tools let you send manual DNS queries and see exactly what your server returns.

Resources

Test your knowledge with the Introduction to Networking quizzes.