DNS Foundations Study Guide

Learning objectives

• Distinguish a domain name, recursive resolver and authoritative server.
• Read common A, AAAA, CNAME, MX, TXT, NS, PTR and SOA records without treating every record as an address.
• Explain what a positive cache entry and TTL change—and what they do not change.
• Choose a suitable DNS command on Windows, PowerShell or Linux and interpret the important fields.
• Separate name-resolution failure from routing, transport and application failure.

Know first

• An IP address identifies a network interface or destination within an IP context.
• A client initiates a request and a server provides a service; one system can play both roles in different interactions.
• A packet carries headers and payload between systems. DNS commonly uses UDP or TCP depending on the exchange.

1. The DNS mental model

An application usually begins with a name such as www.example.test. The application asks the operating system's resolver interface, which normally sends the question to a configured recursive resolver. That resolver may already have a cached answer. If it does not, it follows the DNS namespace toward an authoritative source and returns the resulting records.

The recursive resolver performs work for the client. An authoritative server publishes data for a zone. These roles can exist on the same product in a lab, but they are conceptually different and should not be merged in your explanation.

• Client question → recursive resolver → cached or authoritative answer → client response.
• The root and TLD layers provide delegation; they are not a giant directory containing every host address.
• An authoritative answer describes data in a zone; it does not prove that the resulting service is reachable.

2. Names, labels and the namespace

DNS names are hierarchical. The rightmost label is closest to the root, and each delegation can point toward servers authoritative for a lower part of the namespace. A fully qualified name can be written with a final dot to make the root explicit.

A zone is an administrative portion of the namespace. It may contain records for its own names and delegations to child zones. A domain name is a point in the namespace; a zone is a managed data boundary.

• Name and zone are related but not interchangeable terms.
• Delegation connects layers of authority.
• The same name can have multiple record types.

3. Record types tell you what the answer means

A and AAAA records carry IPv4 and IPv6 addresses. CNAME identifies a canonical name for an alias. MX identifies mail exchangers with preference values. TXT carries text data used by many protocols and verification workflows. NS identifies authoritative name servers. PTR supports reverse-name lookups. SOA describes core zone metadata.

Always read the record type together with the value. A domain can return several records, and an alias can lead to another lookup before an address appears.

• A → IPv4; AAAA → IPv6; CNAME → canonical name.
• MX → mail exchanger; NS → authoritative server; PTR → reverse mapping.
• TXT is generic text data; its meaning depends on the protocol using it.
• SOA contains zone-administration and timing information, not a web-server address.

4. Cache and TTL

Resolvers cache answers so repeated questions can be answered efficiently. The TTL tells a cache how long a record may remain reusable before it must be refreshed. It is a lifetime for cached data, not a guarantee that every observer will see a change at the same instant.

Clearing a client cache removes that client's stored answers. It does not edit the authoritative zone, restart the internet or guarantee that an upstream recursive resolver has also forgotten its own cached copy.

• Ask which cache you are observing: application, operating system or recursive resolver.
• A stale or negative cache can make an otherwise corrected configuration appear unchanged.
• Compare the current answer, its source and its TTL before changing anything.

5. Troubleshoot by boundary

Begin by writing the exact name and record type you expect. Query the configured resolver and record the server, status, answer type, answer value and TTL. Then compare with a second resolver only when the comparison answers a specific question, such as whether one cache is stale.

If an address is returned, DNS has completed part of its job. A failed connection after that point may belong to routing, a firewall, transport, TLS or the application. If a raw address is reachable but the name is not, name resolution becomes the first subsystem to investigate—not the only possible cause.

• Do not use ping as proof that DNS is correct; ping can mix name resolution and ICMP reachability.
• NXDOMAIN means the queried name does not exist in the answer context; an empty answer for one type is not automatically NXDOMAIN.
• Capture before and after evidence when changing cache or configuration.

6. Security boundaries

Spoofing and cache poisoning attempt to make a resolver or client accept false data. DNSSEC adds origin authentication and integrity for signed DNS data, but it does not encrypt the question or hide the queried name by itself.

Encrypted DNS transports such as DNS over HTTPS protect a DNS exchange in transit between a client and the selected resolver. They do not automatically make that resolver trustworthy, and they do not validate unsigned authoritative data. DNS tunnelling uses DNS-shaped traffic as a channel; detection requires context, not a blanket assumption that every unusual TXT query is malicious.

• Integrity, confidentiality and availability are separate properties.
• DNSSEC and encrypted DNS solve different problems.
• Security conclusions require the response, its validation state, the resolver path and surrounding traffic.

Command reference

Quick checks

1. Which value identifies the system that answered your recursive query?

   The resolver/server field, not the address contained in the answer record.

2. Does flushing a client cache change an authoritative record?

   No. It removes locally cached answers and leaves authoritative zone data unchanged.

3. A query returns an A record but HTTPS still fails. Is DNS necessarily broken?

   No. Continue at routing, firewall, transport, TLS and application boundaries using observable evidence.

4. Does DNSSEC encrypt DNS queries?

   No. DNSSEC authenticates signed DNS data; encrypted transports address confidentiality in transit to a resolver.