Record Types and the Four Sections

A is not the only question, and the answer section is not the only answer

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Name the four sections of a DNS message and say what goes in each
▸Explain how a referral is carried when there is no answer to give
▸Read a record type and say what kind of question was asked

Before this lesson — it builds directly on:

How a Name Becomes an Address

It is easy to think of DNS as 'the thing that turns names into IP addresses'. That is its most common use and it is not what it is. DNS is a general system for publishing facts about a name and looking them up. An address is one kind of fact. Which mail servers accept your mail is another. Which servers are authoritative for a domain, what a name is really an alias for, what arbitrary text a domain owner wants to publish — all of these are DNS records, asked for by TYPE. Once you see the type as part of the question, a whole class of confusion disappears — including why looking up a name can succeed while the thing you wanted still fails.

✗ Common misunderstanding: DNS turns names into IP addresses.

Why that's wrong: That is one record type of several. DNS publishes mail routing, delegation, aliases, text and reverse mappings through the same mechanism.

Correct model: DNS answers questions of the form (name, type). An address lookup is the (name, A) case and nothing about the protocol privileges it.

The packets prove it: This lesson's trace asks for MX and receives a mail server name with a preference — no address anywhere in the answer.

Watch these fields in the lab: dns.questionCount · dns.answerCount

Every DNS message has the same four sections, and which ones are empty tells you what kind of message you are holding.

Question: What was asked: name, type, class. Echoed in every response, so an answer is never ambiguous about its question.
Answer: Records that answer the question directly. Empty in a referral and in a negative response.
Authority: Which servers are authoritative. In a referral this is the whole payload; in a negative answer it carries the SOA that sets the negative-caching time.
Additional: Records the server volunteers to save a round trip — usually addresses for servers it just named. This is where glue records live.

Reading the four counts tells you the message type at a glance:

                       Q   AN  AU  AD
  a query              1    0   0   0
  a referral           1    0   1  0-n   ← the value is in AUTHORITY
  an answer            1  1-n   0  0-n
  NXDOMAIN             1    0   1    0   ← AU carries the SOA

A referral and a negative answer both have zero answers. What separates them is the response code and the authoritative bit — which is why reading only the answer section is not enough to tell success from failure.

Watch these fields in the lab: dns.answerCount · dns.authorityCount · dns.additionalCount

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A response has NOERROR, zero answers, and comes from an authoritative server. What happened?

Mail to a domain is bouncing but its website loads fine. What does that suggest?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.