Class notes · Professor Messer, CompTIA A+ 220-1201 Core 1 · Objective 2.4

Quick reference: the short version of this lesson is the DNS cheat sheet, part of Section 2.

Learning objectives

By the end of these notes you should be able to:

Explain why DNS matters, and describe it as a distributed, hierarchical database.
Describe the role of root servers, top-level domains and country-code TLDs.
Use dig and nslookup to query DNS records.
Explain resource records in general, and why DNS changes need care.
Describe A and AAAA records, and explain TTL.
Describe CNAME records and why they’re useful for administration.
Describe MX records and how mail delivery uses them together with A records.
Describe TXT records and their use for verification.
Explain DKIM, SPF and DMARC, and how they work together to fight email spoofing and spam.

1. Why DNS matters

DNS (Domain Name System) is one of the most critical services on any network. It lets us provide IP addresses when all we remember is a fully qualified domain name (FQDN).

Worked example — the basic lookup. You type www.professormesser.com into a browser:

A DNS resolution happens behind the scenes.
It translates the name into the IP address of that web server.
You never had to remember or type an IP address — only the name.

DNS does far more than this basic lookup too, as this lesson explores.

2. The DNS hierarchy

2.1 A distributed database

DNS is a distributed database: it’s scattered across the internet, with different portions held on different servers, on different networks, around the world. Together, this hierarchy can resolve the IP address for any fully qualified domain name on the internet.

2.2 Root servers

At the top of the hierarchy sit 13 root server clusters. Each “cluster” is far more than one machine — in reality, over 1,000 servers make up that root server system between them. The root servers direct queries down to the servers responsible for top-level domains.

2.3 Top-level domains (TLDs)

Type

Examples

Generic top-level domains (gTLDs)

.com, .org, .net

Country-code top-level domains

.us (United States), .ca (Canada), .uk (United Kingdom)

There are roughly 275 country codes in use for TLDs.

2.4 The hierarchy, visually

                          root
                           |
                  \+--------\+--------\+
                 .com              .uk  (and other TLDs)
                  |
            professormesser
                  |
    \+-------------\+-------------\+
   www                        mail
    |                           |

(the web server) (the mail server)

You can add further layers too, e.g.: katie.east.professormesser.com judy.west.professormesser.comEach layer — TLD, domain, subdomain, host — lets an organisation structure its DNS in a way that makes sense for it, while remaining accessible to anyone in the world.

3. Querying DNS: dig and nslookup

3.1 dig

dig is a common DNS query tool on Linux and macOS (a version is also installable on some Windows systems).

dig www.professormesser.comThe output shows:

The command used.
The question being asked.
The answer(s) returned.

Worked example — three answers. Querying www.professormesser.com returns three separate IP addresses. This is deliberate: multiple redundant web servers exist, so if one address becomes unavailable, the others can still be used.

3.2 nslookup

nslookup is the equivalent tool built into Windows:

nslookup professormesser.comQuerying the same domain with nslookup returns the same three IP addresses.

4. Resource records

Every answer a DNS server gives comes from an entry in its database, called a resource record (RR). Resource records can hold IP addresses, certificate information, email routing details, host aliases and more.

Caution: DNS configuration is not something to experiment with casually. A single mistake in a DNS server’s records can make one or more of your services suddenly unreachable from the rest of the internet. Always keep a backup, and know how to revert quickly if a change causes a problem.

Two ways to edit records:

A raw text configuration file, directly on the DNS server.
A web-based front end, which many hosted DNS providers offer — the same underlying records, presented as a form for adding, editing or removing entries.

A DNS server’s configuration commonly includes an SOA record at the top (defining authority for the zone), along with MX, A and CNAME records, among others — each covered in the sections below.

5. A and AAAA records

Record

IP version

Also known as

IPv4

Address record

AAAA

IPv6

“Quad A” record

Both define the IP address for a hostname.

Worked example — reading an A record.

www.professormesser.com IN A 162.159.246.164- IN — internet.

A — this is an address record.
162.159.246.164 — the address returned when someone asks for www.professormesser.com.

Worked example — adding one through a web front end. Fields typically requested:

Field

Example

Host name

www

IP address

162.159.246.164

TTL (time to live)

15 minutes

TTL is how long a resolver (and the requesting user’s device) will remember that answer before asking again. After 15 minutes here, the record times out, and the next request re-queries the DNS server. This is deliberate: it lets an administrator change the IP address at any time, knowing the change will be visible everywhere within, at most, one TTL period.

AAAA records are added the same way — host name, IPv6 address, and a TTL.

6. CNAME records

Sometimes one physical server plays several roles: a web server, a DNS server, an NTP server and a mail server all at once. Instead of giving every service the same name, you can use canonical names (CNAMEs) that all point back to one underlying host.

Worked example:

mail.example.com (the real server, with its own A record) chat.example.com CNAME → mail.example.com ftp.example.com CNAME → mail.example.com www.example.com CNAME → mail.example.comEvery request for chat., ftp. or www.example.com really connects to mail.example.com.

Why this matters for administration: if the underlying server’s IP address ever changes, you only update the one A record (mail.example.com) — every CNAME pointing to it automatically follows, with no changes needed to the CNAME records themselves.

7. MX records

MX (Mail Exchanger) records are among the most critical on any domain — they make sending and receiving email possible.

Structure:

example.com IN MX mail.example.com- IN — internet.

MX — mail exchanger record.
The name of the mail server responsible for that domain.

7.1 How mail delivery uses MX and A together

Worked example — sending mail to james@professormesser.com:

The sending mail server looks up the MX record for professormesser.com.
It finds the mail server’s name, e.g. mail.example.com.
It performs a second lookup — this time for the A record of mail.example.com.
That returns an IP address, e.g. 123.12.41.41.
The sending server now knows exactly where to deliver the message.

7.2 Worked example — a different domain’s MX record

A web-based DNS front end might show:

Field

Example

Host

mail

Target

mail.hover.com.cust.hostedemail.com

This routes mail for that domain to a third-party hosted email provider, rather than a self-managed server.

Every domain has its own MX records, configured (via a raw file or a web front end) with a record type, host name, target name, and a TTL — just like the other record types.

8. TXT records

TXT (text) records are human-readable entries anyone can query from a DNS server. They’re used for:

Verification — proving you control a domain, for example when setting up a service that needs to confirm domain ownership.
Reducing spam — several specific TXT-based mechanisms exist for this, covered in sections 9–11.

Worked example — viewing TXT records:

dig professormesser.com TXTor, on Windows:

nslookup -type=txt google.comQuerying professormesser.com this way might show, for example, one TXT record used for a service verification (such as a “stripe verification” entry), and another used as an SPF record.

9. DKIM — DomainKeys Identified Mail

DKIM adds a digital signature to outgoing email, so recipients can confirm a message genuinely came from your domain.

Where

What’s stored

DNS TXT record

The public key — you’ll see v=DKIM in the record

Your email server

The matching private key

How it works:

Your outgoing mail is digitally signed using your private key.
A receiving mail server sees the signature.
It looks up your public key from your DNS TXT record.
It verifies the signature using that public key.
If it checks out, the recipient knows the message really did come from your official mail server.

Adding a DKIM record through a web front end:

Field

Example

Host name

Usually provided by your email service

Text content

The public key

TTL

e.g. 15 minutes

10. SPF — Sender Policy Framework

Organisations often send email from several different sources: an internal mail server, plus perhaps a third-party bulk-mail provider. SPF lets you publish which servers are allowed to send mail on your behalf.

How it works:

Your domain’s SPF TXT record lists every legitimate outgoing mail server.
A receiving server checks a message’s origination server against that list.
If the origination server is on the list, the message is treated as legitimate for that check.
If it isn’t, the message likely didn’t really come from your organisation.

Adding an SPF record:

Field

Example

Record type

TXT

Host name

All hosts, shown as @

Content

The list of approved outgoing mail servers

11. DMARC — Domain-based Message Authentication, Reporting and Conformance

SPF and DKIM checks can each pass or fail. DMARC tells receiving mail servers what to do when they fail, on your domain’s behalf:

Policy option

Effect on a failing message

Deliver it anyway

Quarantine

Send it to spam/quarantine

Reject

Drop it entirely

Reporting: a DMARC record can also include an email address, so receiving servers send back a report of how messages from your domain were handled. This lets you build a picture of how many messages got through, and how many were flagged.

Worked example — reading a DMARC record:

A DMARC TXT record specifies that messages failing validation should be put into quarantine (spam), and that reports of that disposition should be sent to a specified reporting email address for later analysis.

11.1 How SPF, DKIM and DMARC fit together

Sender publishes: SPF -> which servers may send mail for this domain DKIM -> a public key to verify message signatures DMARC -> what to do if SPF or DKIM checks fail, and where to report it

Receiver, for each incoming message:

Check SPF: did it come from an approved server?
Check DKIM: does the signature verify with the published public key?
Apply the sender’s DMARC policy to anything that failed (accept / quarantine / reject)
Optionally send a report back to the sender’s DMARC reporting address

12. Security perspective

DNS changes need care and a rollback plan. A single bad record can take a service off the internet; always keep a backup configuration.
TTL is a trade-off. A short TTL (like the 15-minute example) makes changes propagate fast — useful during migrations or incident response — but increases query load. A long TTL reduces load but slows how fast a fix (or an attacker’s redirection) spreads.
SPF, DKIM and DMARC together are the main defence against email spoofing. Any one alone is weaker: SPF alone can be bypassed by forwarding; DKIM alone doesn’t say who’s allowed to send; DMARC ties both together and defines the consequence.
A domain with no DMARC record is easy to spoof convincingly. Attackers can send mail that appears to come from a real domain, and the receiving server has no policy telling it what to do about failures.
DKIM’s private key must stay private. If it leaks, an attacker can forge validly signed mail from your domain until the key is rotated.
Resource records are often the first thing checked in a phishing investigation — verifying SPF/DKIM/DMARC results on a suspicious message, and checking whether a domain’s MX or A records were recently and unexpectedly changed.

Summary

DNS resolves FQDNs to IP addresses, as a distributed, hierarchical database: 13 root server clusters (1,000+ servers), then TLDs (generic and country-code), then domains and subdomains.
dig (Linux/macOS) and nslookup (Windows) query DNS directly.
Resource records (RR) hold the actual data; handle DNS configuration carefully, with backups.
A / AAAA records map a hostname to an IPv4 / IPv6 address; TTL controls how long that answer is cached.
CNAME records point one name at another, so changing the underlying A record updates every alias automatically.
MX records name a domain’s mail server; delivery needs both the MX lookup and a follow-up A record lookup.
TXT records hold human-readable text, used for verification and anti-spam mechanisms.
DKIM signs outgoing mail (private key on the server, public key in DNS) so recipients can verify authenticity.
SPF lists which servers may legitimately send mail for a domain.
DMARC defines what receivers should do when SPF or DKIM fail (accept, quarantine, reject) and where to send reports.

Glossary

Term

Definition

DNS

Domain Name System — resolves domain names to IP addresses

FQDN

Fully qualified domain name

Distributed database

A database spread across many servers and networks

Root server

A top-level DNS server directing queries to TLD servers

TLD

Top-level domain, e.g. .com or a country code like .uk

gTLD

Generic top-level domain

ccTLD

Country-code top-level domain

dig

A DNS query tool for Linux/macOS

nslookup

A DNS query tool built into Windows

Resource record (RR)

An entry in a DNS server’s database

A record

Maps a hostname to an IPv4 address

AAAA record

Maps a hostname to an IPv6 address

TTL

Time to live — how long a DNS answer is cached

CNAME

An alias record pointing one name to another

MX record

Names a domain’s mail server(s)

TXT record

A human-readable text entry in DNS

SOA record

Defines authority and settings for a DNS zone

DKIM

DomainKeys Identified Mail — digitally signs outgoing email

Public / private key

The key pair DKIM uses to sign and verify mail

SPF

Sender Policy Framework — lists a domain’s authorised mail servers

DMARC

Domain-based Message Authentication, Reporting and Conformance

Quarantine

Placing a message in spam/junk rather than delivering or rejecting it

Review questions

Why is DNS described as both “distributed” and “hierarchical”?
Roughly how many servers make up the 13 root server clusters?
Give an example of a generic TLD and a country-code TLD.
A dig query for a web server returns three different IP addresses. Why might that be?
What is a resource record?
Why should you always have a backup before changing DNS records?
What’s the difference between an A record and an AAAA record?
A record has a TTL of 15 minutes. What does that control?
Why would an organisation use CNAME records instead of giving every service its own A record?
Describe the two DNS lookups involved in delivering an email to a domain.
What kind of information is stored in a TXT record, and name two uses.
How does DKIM allow a recipient to verify a message’s authenticity?
What does an SPF record list, and what does it protect against?
What three actions can a DMARC policy specify for a message that fails validation?
Why are SPF, DKIM and DMARC more effective together than any one alone?

Answer key

Distributed because the database is spread across many servers worldwide; hierarchical because it’s organised in layers — root, TLD, domain, subdomain, host.
Over 1,000 servers.
Generic: .com, .org or .net. Country-code: .us, .ca or .uk (any valid example).
The organisation runs redundant web servers, so if one address becomes unavailable, the others still work.
An entry in a DNS server’s database holding information such as an IP address, certificate details, or mail routing information.
A mistake in a DNS record can make a service unreachable from the internet, so you need a quick way to revert the change.
A records map a hostname to an IPv4 address; AAAA records map a hostname to an IPv6 address.
How long a resolver or device caches that answer before it must ask again.
So that changing the underlying server’s IP address only requires updating one A record — every CNAME pointing to it updates automatically, with no changes needed to the CNAMEs themselves.
First, a lookup of the domain’s MX record to find the mail server’s name; second, a lookup of that mail server’s A record to find its IP address.
Human-readable text. Any two of: domain ownership verification, SPF, DKIM.
The message is signed with the sender’s private key; the recipient retrieves the matching public key from the sender’s DNS TXT record and uses it to verify the signature.
The mail servers authorised to send email for that domain. It protects against messages that falsely claim to be from that domain.
Accept, quarantine (spam) or reject.
Because SPF, DKIM and DMARC each check something different — who may send, whether the message was tampered with, and what to do if a check fails — so together they close gaps that any single mechanism leaves open.