Module 10: Domain Name System (DNS)

Which would be easier to remember when visiting a website: portal.example.com or 192.0.2.80?

People prefer meaningful names, but network traffic needs an Internet Protocol (IP) address as its destination. The Domain Name System (DNS) connects the two.

DNS is often compared to a phone book. You look up a person’s name to find a phone number. A computer looks up a DNS name to find an IP address or another piece of information associated with that name.

The domain name and Internet Protocol version 4 (IPv4) address used here are reserved for documentation and do not identify real systems.

In This Module

• What DNS does and how resolver and authoritative roles differ
• How a lookup moves through the DNS hierarchy
• The core address and alias records, caching, and time to live
• How to test DNS and interpret common failures

DNS in One Sentence

A client asks a DNS server a specific question about a name, and the server returns a DNS record as its answer.

For example:

Question: What is the IPv4 address for www.example.com?
Answer:   Return the A record for www.example.com.

DNS can store many kinds of records, not just IP addresses. It can identify mail servers, aliases, authoritative name servers, and the locations of network services.

DNS does not carry the later web, email, or login traffic. After DNS returns an address, the application makes a separate connection to that address.

DNS lookup returns an address -> Application connects to that address

The DNS Server Your Client Uses

Your computer is configured with one or more DNS server addresses. Those addresses often arrive through the Dynamic Host Configuration Protocol (DHCP), as described in Module 9.

The configured server might be:

• A home router that forwards DNS requests
• A resolver operated by an internet provider
• A public recursive DNS service
• A Windows or Linux DNS server operated by an organization
• A DNS service supplied by a cloud or virtualization platform

The server that accepts a client’s request and finds the answer is called a recursive resolver. It performs the lookup work and caches results for reuse.

An authoritative DNS server is different. It stores the official DNS records for a domain or zone. A recursive resolver asks authoritative servers for information when the answer is not already cached.

DNS role	Main job
Client	Asks a DNS question
Recursive resolver	Finds the answer and caches it
Authoritative server	Holds the official records for its zone

Role-Specific: DNS and Active Directory

Active Directory Domain Services relies on DNS. Domain-joined Windows clients use DNS records to locate domain controllers and services.

Those clients should use the organization’s Active Directory-aware DNS servers, not a public resolver directly. The internal DNS servers can resolve internal names and forward public questions when necessary.

Reading a Domain Name

DNS names form a hierarchy. In everyday use, you normally see:

www.example.com

The same name can be written in its complete, absolute form with a dot at the end:

www.example.com.

The final dot represents the DNS root, the top of the DNS hierarchy. Browsers and ordinary commands usually let you omit it. In DNS configuration files and some troubleshooting tools, the trailing dot makes it explicit that the name is complete and that no local DNS suffix should be added.

Read the complete name from right to left:

Part	Meaning
.	DNS root
com	Top-level domain
example.com	Registered domain
www	A label beneath example.com

The owner of example.com controls the DNS records below that name. The label www does not have to identify one physical server; it identifies whatever DNS records the domain owner configured for that name.

One Lookup from Client to Answer

Suppose a browser needs the IPv4 address for www.example.com.

1. The browser asks the operating system to resolve the name.
2. The operating system checks its local DNS cache.
3. If no usable answer is cached, the operating system asks its configured recursive resolver.
4. The recursive resolver checks its own cache.
5. If necessary, the resolver asks a root DNS server where to find information about .com.
6. A .com top-level-domain server identifies the authoritative servers for example.com.
7. An authoritative server for example.com supplies the requested record.
8. The recursive resolver caches the answer and returns it to the client.

The browser can then connect to the returned address.

Client
  -> Recursive resolver
     -> Root: Who handles .com?
     -> .com server: Who handles example.com?
     -> Authoritative server: What is www.example.com?
  <- Answer returned to client

This full path does not occur for every lookup. Recursive resolvers answer many requests from cache and may already know which authoritative servers to contact.

Common DNS Record Types

DNS stores information in resource records. Begin with three types:

Record	What it identifies
A (Address)	An IPv4 address for a name
AAAA	An Internet Protocol version 6 (IPv6) address for a name
CNAME (Canonical Name)	Another DNS name used as an alias

DNS supports both IP versions. An A record supplies an IPv4 address, while an AAAA record supplies an Internet Protocol version 6 (IPv6) address. A name can have one type or both. DNS is resolving the name to the requested record; it is not translating an IPv4 address into an IPv6 address.

An A record might be read as:

server.example.com -> 192.0.2.20

A CNAME points to another name rather than directly to an address:

www.example.com -> webhost.example.net

The resolver must then find the address records for webhost.example.net.

One name can have more than one A or AAAA record. Multiple answers may be used for redundancy or traffic distribution, so receiving several addresses is not automatically a problem.

Optional: Role-Specific Record Types

These records appear frequently in email, directory, identity, and DNS administration:

Record	What it identifies
MX (Mail Exchange)	The mail servers that accept email for a domain
NS (Name Server)	The authoritative DNS servers for a zone
PTR (Pointer)	A name associated with an IP address in reverse DNS
SRV (Service)	The host and port providing a particular service
TXT (Text)	Text used for verification, email policies, and other published data

SRV records are especially important in Active Directory. Windows clients use them to find domain controllers and services such as the Lightweight Directory Access Protocol (LDAP) and Kerberos.

DNS Uses User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) Port 53

Traditional DNS supports both UDP port 53 and TCP port 53.

Most ordinary queries begin with UDP because a short question and answer fit naturally in a datagram. If a UDP response is marked as truncated, the client can retry using TCP. DNS zone transfers and some other operations also use TCP.

A firewall that permits only UDP port 53 can therefore cause some DNS requests to work while others fail.

Caching and Time to Live (TTL)

DNS would be slow and place unnecessary load on authoritative servers if every request repeated the full lookup path. Clients and recursive resolvers therefore cache answers.

Each record has a time to live (TTL) expressed in seconds. The TTL tells a cache how long it may reuse that record before requesting a fresh copy.

TTL 300 = cache the record for up to 300 seconds

Caching explains why a DNS change may not appear everywhere immediately. One resolver may have the old answer cached while another has already requested the new one.

An answer stating that a name does not exist can also be cached for a period of time. Correcting a missing record therefore may not appear immediately to every client.

On Windows, this command clears the local computer’s DNS client cache:

ipconfig /flushdns

It does not clear a browser’s private cache or the cache on a recursive resolver elsewhere on the network.

Query DNS

Windows

PowerShell provides Resolve-DnsName:

Resolve-DnsName example.com -Type A -DnsOnly

Look for:

Output field	Meaning
Name	The name returned in the answer
Type	The DNS record type
TTL	Remaining cache lifetime in seconds
IPAddress	The returned address for an A or AAAA record

Windows also includes nslookup:

nslookup example.com

The output identifies the DNS server that answered and the records it returned. Resolve-DnsName normally provides more structured output, while nslookup remains common across many older support procedures.

Linux

Use dig:

dig example.com A

The output contains several sections. Start with:

• status, which reports whether the query succeeded
• QUESTION SECTION, which shows the name and record type requested
• ANSWER SECTION, which contains matching records
• SERVER, which identifies the DNS server that answered

Ask for another record type by changing the final argument:

dig example.com NS

Common DNS Failure Clues

Result or symptom	Likely meaning
Connecting by IP works, but connecting by name fails	DNS configuration or resolution is likely involved
Non-Existent Domain (NXDOMAIN)	The DNS server reports that the requested name does not exist
Server Failure (SERVFAIL)	The resolver could not complete the lookup
Query times out	The DNS server may be unreachable, blocked, or not responding
Corrected record still returns an old value	A client or resolver may still have the previous answer cached
Internal name fails while public names work	The client may be using the wrong DNS server

Some organizations intentionally return different answers for the same name depending on whether the client is inside or outside the network. Before treating different answers as an error, confirm which DNS server each client queried.

A Short Troubleshooting Order

1. Use ipconfig /all or the Linux resolver configuration to identify the DNS server the client is using.
2. Query a known public name to confirm that the resolver answers at all.
3. Query the failing name and requested record type.
4. Read the response status rather than looking only for an address.
5. If clients disagree, compare their DNS server addresses and the TTL values in their answers.
6. Confirm whether the name is supposed to exist only on an internal network.

Optional Lab: Compare DNS Answers in NETLAB

This exercise makes no configuration changes.

1. On the Windows 11 virtual machine named WINCLIENT, run:

   ipconfig /all
   Resolve-DnsName example.com -Type A -DnsOnly
   Resolve-DnsName example.com -Type NS -DnsOnly

2. Record WINCLIENT’s configured DNS server and identify the A and NS records returned.

3. On the Linux Mint virtual machine named LINUXBOX, run:

   nmcli device show | grep IP4.DNS
   dig example.com A
   dig example.com NS

4. Identify the DNS server, response status, and answer section in each dig result.

5. Compare the answers from both virtual machines.

Record order and TTL values may differ because of caching. Both clients should still receive valid records for the same requested types.

Further Learning

• Request for Comments (RFC) 1034: Domain Names—Concepts and Facilities explains the DNS hierarchy, resolvers, authoritative data, and caching.
• RFC 1035: Domain Names—Implementation and Specification defines DNS messages, common records, and UDP/TCP transport.
• Internet Assigned Numbers Authority (IANA) DNS Parameters maintains the authoritative registry of DNS record types and other protocol values.
• Microsoft DNS queries and lookups documentation explains recursive and iterative lookups in Windows environments.
• Microsoft Resolve-DnsName documentation documents record queries and command options.
• BIND 9 dig documentation documents the Linux lookup tool used in this module.

Main Takeaways

• The Domain Name System (DNS) returns records associated with names, including the addresses applications use to connect.
• Recursive resolvers locate answers from authoritative DNS servers.
• Resolvers cache answers according to their time-to-live values.

Continue to Module 11: HTTP and TLS to see how the Hypertext Transfer Protocol (HTTP) and Transport Layer Security (TLS) use the addresses returned by DNS.