🗂️Module 02 — Resource Records, Zone Files & Reading a Domain

seamless.se.		3600	IN	MX	10 aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt1.aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt2.aspmx.l.google.com.
seamless.se.		3600	IN	MX	30 aspmx2.googlemail.com.
seamless.se.		3600	IN	MX	30 aspmx3.googlemail.com.

The order you see will differ — the set is unordered.

Five records, one RRset. Same owner name, same class, same type. And look at the TTL column: 3600 on every single line, not by coincidence but because it is structurally impossible for them to differ.

Read one more thing out of this. The numbers 10, 20, 30 are inside the RDATA — they are part of the MX record's value, not a DNS-level priority. DNS itself has no concept of preference or ordering; the mail client parses those numbers. Every piece of "intelligence" you see in DNS lives in the RDATA and is interpreted by the client, never by DNS. Hold on to that, because it explains why DNS load balancing is as limited as it is.

Now imagine this at 500 hosts. An engineer adds a sixth mail server via the API by sending a single MX record. The API replaces the RRset. Five mail servers vanish from DNS in one call, and nothing errors.

All records sharing the same owner name, class and type. DNS treats it as a single indivisible object — it is cached, transferred, replaced and DNSSEC-signed as a unit.

The practical rule that follows is that every record in an RRset must carry the same TTL, because they are cached as one object and expire together.

The detail that separates a strong candidate: knowing that this is why most DNS APIs are replace-the-whole-set rather than add-one-record, and why a naive automation script that sends a single value silently deletes the rest. It also explains DNSSEC: signatures cover RRsets, not individual records, which is why you cannot pick one address out of a signed set without breaking the signature.

No. RFC 2181 requires the TTLs within an RRset to be identical. If a zone file specifies different values the server will choose one — typically the first or the lowest, depending on implementation — and discard the rest, usually with a warning you will never see because nobody reads zone-load logs.

Different types at the same name are different RRsets and may absolutely have different TTLs, which is why seamless.se can serve A at 60 seconds and MX at 3600 seconds simultaneously.

$ dig seamless.se ANY +noall +answer
seamless.se.		3600	IN	HINFO	"RFC8482" ""

--- the honest way ---
seamless.se.		900	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
seamless.se.		3600	IN	NS	ns-135.awsdns-16.com.
seamless.se.		3600	IN	NS	ns-1490.awsdns-58.org.
seamless.se.		3600	IN	NS	ns-1760.awsdns-28.co.uk.
seamless.se.		3600	IN	NS	ns-722.awsdns-26.net.
seamless.se.		60	IN	A	52.77.52.233
seamless.se.		3600	IN	MX	10 aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt1.aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt2.aspmx.l.google.com.
seamless.se.		3600	IN	MX	30 aspmx2.googlemail.com.
seamless.se.		3600	IN	MX	30 aspmx3.googlemail.com.
seamless.se.		300	IN	TXT	"v=spf1 include:amazonses.com include:_spf.linserv.se include:spf.mandrillapp.com include:_spf.salesforce.com a:mail.workbuster.se include:_spf.google.com ip4:3.1.214.242 ip4:14.142.43.230 ip4:14.99.30.2 ~all"

ANY gave you a joke record. HINFO "RFC8482" is a deliberate placeholder meaning "I am not answering ANY queries; ask for a specific type". Depending on which resolver you hit you may instead get a random handful of records, or a REFUSED. None of those is an inventory.

The loop is the real answer, and notice what it revealed that a single query never could:

• Four NS records, all awsdns — this zone is hosted on AWS Route 53. That one line tells you where to go to make changes, and it tells you Route 53's quirks apply
• AAAA and CAA produced no output at all. Not an error — NODATA. This domain publishes no IPv6 address and no certificate-issuance policy. Both are findings
• The A record TTL is 60 while everything else is 3600. Somebody deliberately made the address agile. That is the signature of a host that gets repointed — a failover target, or a migration in progress
• The SPF record in TXT lists ip4: addresses. Those are mail-sending hosts, and they are a free hint about the organisation's own IP ranges. Part D uses this

Now imagine this at 500 domains. "Ask for each type in turn" is a loop, not a task — which is exactly why the audit script in D5 exists.

You cannot — and recognising that the question contains a false premise is the answer they are looking for. DNS has no listing operation. It answers questions of the form "what is at this exact name, of this exact type", and nothing else.

The practical approaches are: query each type you care about in turn; attempt a zone transfer if you are permitted one; or, most reliably, read the zone from the provider's API or console, because the provider does hold the full list.

The trap in this question is ANY. Candidates reach for it and it has never done what they think. It returns cached fragments, and since RFC 8482 most large operators return a minimal synthetic response instead — partly because ANY was the engine of DNS amplification attacks.

$ dig +noall +answer seamless.se A
seamless.se.		60	IN	A	52.77.52.233

$ dig +noall +comments seamless.se AAAA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44118
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

The second one is the exercise. status: NOERROR with ANSWER: 0 — the NODATA case from Module 01 D2, met in the wild. The name exists, it has records, it has no IPv6 address.

Why this is a finding and not a curiosity. An IPv6-only client cannot reach this site at all without a translation layer, and a growing number of mobile networks are IPv6-only. "No AAAA" is a deliberate choice or an oversight, and the audit tells you which by whether anything else in the zone has one.

And note the TTL of 60 on the A record while the zone's other records sit at 3600. Somebody wanted to be able to move this address quickly. That is worth asking about — it usually means a failover mechanism or an unfinished migration.

$ dig +noall +answer www.seamless.se
www.seamless.se.	3600	IN	CNAME	seamless.se.
seamless.se.		60	IN	A	52.77.52.233

$ dig +noall +comments +answer www.seamless.se MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30277
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

www.seamless.se.	3600	IN	CNAME	seamless.se.

First command — two records came back for one question. You asked for A at www.seamless.se and got a CNAME plus the A at the target. The resolver followed the alias for you and returned the whole chain as evidence. Note the two different TTLs: 3600 on the alias, 60 on the address. They are different RRsets at different names, cached and expiring independently — which means the alias can outlive the address it points at.

Second command is the important one. You asked for MX and got a CNAME back with ANSWER: 1. The server is telling you: this name is an alias, go and ask the target instead. There is no MX record here and there never can be.

That is the whole danger in one screen. If www.seamless.se were the domain receiving mail, its mail would follow this alias to wherever the target points. A CNAME does not politely apply to the record type you were thinking about — it captures the name completely.

A practical tell for audits: any +short output whose first line is a hostname rather than an IP address is a CNAME chain. Chains of three or four are common with CDNs and SaaS vendors, each hop adds latency on a cache miss, and each hop is a third party who can break you.

An alias: it declares that the canonical name of this name is some other name, and the resolver restarts its lookup there.

The restriction is that a name owning a CNAME can own no other record type, because the CNAME redirects the whole name rather than one record type. That in turn makes a CNAME illegal at the zone apex, since the apex must carry SOA and NS.

What I would add to show I understand the mechanism rather than the rule: the danger is silent. Adding a CNAME to a name that already has MX or TXT records does not usually produce an error — it produces mail that stops being delivered and domain-verification records that stop being found. And CNAMEs cost you a second resolution step, so long vendor chains add real latency on every cache miss.

Because the apex is required to carry SOA and NS records, and a CNAME excludes all other types at the same name. It is a structural contradiction, not a policy choice.

In practice you use a provider-specific pseudo-record: Route 53 alias records, or the ALIAS / ANAME / CNAME flattening offered by other providers. These are not DNS features — the authoritative server resolves the target internally and answers with a real A or AAAA, so what goes on the wire is a plain address record and standards compliance is preserved.

The operational catch worth naming: because the provider resolves the target for you, the answer is only as fresh as the provider's own resolution, and the flattening is done from the provider's network location. For a geo-distributed target that can hand your users a suboptimal address, and it is invisible unless you go looking.

$ dig +noall +answer seamless.se NS
seamless.se.		3600	IN	NS	ns-135.awsdns-16.com.
seamless.se.		3600	IN	NS	ns-722.awsdns-26.net.
seamless.se.		3600	IN	NS	ns-1490.awsdns-58.org.
seamless.se.		3600	IN	NS	ns-1760.awsdns-28.co.uk.

$ dig @ns-135.awsdns-16.com seamless.se A +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35503
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

seamless.se.		60	IN	A	52.77.52.233

Four findings from eight lines of output.

1. awsdns means Route 53. Someone hands you this domain and you now know where the records live without asking anyone.

2. Four different top-level domains — .com, .net, .org, .co.uk. That is deliberate, and it is good practice worth recognising. If one TLD's infrastructure has a bad day, three of your four nameservers are still reachable. Providers who put all four nameservers under one domain have quietly given you a shared failure mode.

3. The second query has aa set and no ra. Exactly as predicted in Module 01 B1: an authoritative server marks its answer authoritative and does not offer recursion. This is your ground truth — when you need to know what the zone actually says rather than what a cache remembers, this is the query.

4. The TTL is 60 here too, and it is the full published value rather than a counted-down one, which confirms it: the zone really does publish a 60-second address TTL.

The habit to build. Whenever you are verifying a change, or you suspect a cache, run the NS lookup and then re-run your query against one of the returned servers. Two commands, and you have removed every cache in the world from the investigation.

It names an authoritative server for a zone. NS records appear in two places: inside the zone itself at the apex, and — more importantly — in the parent zone, where they form the delegation.

Operationally it is the first lookup I run on an unfamiliar domain, because the nameserver hostnames identify the DNS provider, which tells me where to make changes and which provider-specific behaviours to expect.

The detail that matters and catches people out: the authoritative set is the one published by the parent, not the one inside the zone. The two are supposed to agree, and when they do not you get a delegation inconsistency that produces intermittent, resolver-dependent failures — the kind where the problem follows some users and not others. Module 03 covers how a resolver actually uses these.

$ dig +noall +answer seamless.se SOA
seamless.se.		900	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

$ dig no-such-name.seamless.se +noall +authority
seamless.se.		900	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

$ sleep 10 ; dig no-such-name.seamless.se +noall +authority
seamless.se.		890	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

You are watching a "no" expire. The TTL went 900 → 890 across a 10-second sleep, exactly like a positive answer would. The resolver has cached the non-existence of no-such-name.seamless.se and is counting it down.

Do the arithmetic that matters. MINIMUM is 86400 — a full day. The SOA record's own TTL is 900. RFC 2308 takes the lesser, so a negative answer for this zone lives 15 minutes, not 24 hours. If you had read only the MINIMUM field you would have told your team to wait a day, and been wrong by a factor of 96.

The operational rule this gives you. After creating a new name, if you get NXDOMAIN, do not repeat the query against the same resolver and do not panic. Query an authoritative server — from B3 — which holds no negative cache. If it has the record, your change landed and you are simply waiting out min(MINIMUM, SOA TTL).

And the rule that prevents the problem entirely: never query a name before you publish it. The NXDOMAIN you cache is your own doing. This is why deployment scripts that "check if the record exists yet" in a tight loop make the wait longer on every resolver they touch.

Seven fields: MNAME, the primary nameserver; RNAME, the responsible email address written as a domain name with the first dot standing in for the @; SERIAL, a version number; then REFRESH, RETRY and EXPIRE, which are the secondary's timers; and MINIMUM, which since RFC 2308 is the negative caching TTL.

EXPIRE is the one worth calling out: when a secondary has been unable to reach the primary for that long it stops answering for the zone entirely, rather than continuing to serve data of unknown age. That is a deliberate choice of a hard failure over a silent one.

Where a strong candidate goes further: the negative TTL is not simply the MINIMUM field — it is the lesser of MINIMUM and the SOA record's own TTL. That distinction decides whether a freshly created record is invisible for fifteen minutes or for a day, and almost every blog post gets it wrong.

Secondaries compare the primary's serial with their own and transfer only when it is higher. If you edit a zone and do not bump the serial, the primary serves the new data and every secondary keeps serving the old — so answers depend on which server a resolver happened to ask.

That produces the worst class of DNS bug: intermittent, user-dependent, and not reproducible on demand.

The nuance worth adding: this only applies where replication is serial-driven, as in BIND primary/secondary. Managed providers such as Route 53 replicate internally and leave the serial at a constant — Route 53 publishes 1 and never changes it. So the right instinct is not "always bump the serial" but "know whether your replication depends on it", and the SOA tells you which world you are in.

$ dig +noall +answer seamless.se MX
seamless.se.		3600	IN	MX	10 aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt1.aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt2.aspmx.l.google.com.
seamless.se.		3600	IN	MX	30 aspmx2.googlemail.com.
seamless.se.		3600	IN	MX	30 aspmx3.googlemail.com.

$ dig +short aspmx.l.google.com A
64.233.181.26

$ dig +noall +answer example.com MX
example.com.		86400	IN	MX	0 .

The first output is a complete mail architecture in five lines. aspmx.l.google.com is Google Workspace, so this organisation's mail is hosted by Google. Preference 10 is the primary pair-of-hands, 20 is the fallback, 30 is the fallback's fallback. A sender walks up that list.

Note the two records at preference 20. Equal preference means the sender picks between them freely — this is deliberate load sharing, and it is the only place in core DNS where a weighting-like behaviour exists at all.

The second command is the habit worth forming. An MX target is only useful if it resolves. Following it one hop confirms the chain is intact; an MX pointing at a hostname with no address record is a silent mail outage that no MX-level check would catch.

The third output is the interesting one. MX 0 . is the null MX from RFC 7505 — a single MX whose target is the root. It is not a mistake or an empty value; it is an explicit, machine-readable declaration: this domain accepts no mail, do not queue and retry for five days, reject immediately.

Why that matters in production. Most organisations own domains that never receive mail — parked brands, redirect domains, internal-only names. Without a null MX, a sender falls back to the domain's A record for delivery, spends days retrying against a web server, and generates support tickets. One record removes the whole class of problem. It is also a small anti-spoofing win: a domain that visibly accepts no mail is a less attractive forgery target.

$ dig +short seamless.se TXT
"v=spf1 include:amazonses.com include:_spf.linserv.se include:spf.mandrillapp.com include:_spf.salesforce.com a:mail.workbuster.se include:_spf.google.com ip4:3.1.214.242 ip4:14.142.43.230 ip4:14.99.30.2 ~all"

$ dig +short _dmarc.seamless.se TXT
"v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]"

The SPF record is an org chart. Six include: mechanisms name six third parties permitted to send mail as this domain — Amazon SES, a Swedish hosting provider, Mandrill, Salesforce, a recruitment platform, and Google Workspace. Each one is a vendor relationship and each one is a party who can send mail as you.

~all is a soft fail, meaning "mail from anywhere else is suspicious but do not reject it outright". -all would be a hard fail. Soft fail is the cautious setting people adopt during rollout and then never tighten.

Now read the DMARC record together with it, because that is where the real posture is. p=reject is the strongest policy — but pct=25 means it is applied to only 25% of failing mail. That combination is the signature of a staged rollout in progress: the operator is ramping up and watching the rua= aggregate reports before going to 100%.

The finding to write down. p=reject; pct=25 reads as "strict" at a glance and is enforcing on a quarter of traffic. If nobody owns finishing the ramp, it sits there for years and everyone believes the domain is protected. Reading pct= is what separates an auditor from someone skimming for the word reject.

Two operational cautions on SPF. There is a hard limit of 10 DNS lookups when evaluating a record, and every include: costs at least one — six includes plus an a: is already close to the ceiling. Exceed it and the result is permerror, which many receivers treat as a failure: your legitimate mail starts bouncing with no change on your side, because a vendor expanded their record. Second, a single string in a TXT record cannot exceed 255 characters, so long records are split into several strings that are concatenated — which is why quoting matters when you write them.

All three are TXT records. SPF sits on the domain itself and lists the hosts permitted to send as it. DKIM sits at <selector>._domainkey.<domain> and publishes a public key that receivers use to verify a signature in the message header. DMARC sits at _dmarc.<domain> and states what to do when the other two fail, plus where to send reports.

The underscore prefixes are deliberate: underscores are legal in DNS names but not in host names, so these can never collide with a real machine.

The operational detail that marks experience: SPF has a hard limit of ten DNS lookups during evaluation, and each include: consumes at least one. Since includes point at vendors' records, a vendor expanding theirs can push you over the limit and start bouncing your mail with no change on your side. Anyone who has run mail for a large organisation has been bitten by this, and mentioning it lands.

Not necessarily — you have to read the pct= tag alongside it. p=reject; pct=25 applies the reject policy to only a quarter of failing messages, which is a rollout in progress rather than a finished deployment.

I would also check the alignment mode and whether rua= reports are actually going somewhere a human reads.

The point I would make explicitly: p=reject is the tag people screenshot for the compliance evidence, and pct= is the tag that says what is really enforced. A staged rollout nobody ever finished looks identical to a completed one unless you read the second tag.

$ dig +short -x 8.8.8.8
dns.google.

$ dig +short -x 52.77.52.233
ec2-52-77-52-233.ap-southeast-1.compute.amazonaws.com.

$ dig +short -x 14.99.30.4
(no output)

Each of the three tells you something different, and none of them is about the domain you started from.

dns.google. — a deliberately curated PTR. Someone chose that name.

ec2-52-77-52-233.ap-southeast-1.compute.amazonaws.com. — an AWS default, and it leaks two facts for free: this is an EC2 instance, and it is in ap-southeast-1, Singapore. You learned the hosting provider and the region without any access to the account. Reverse DNS is one of the most under-used reconnaissance surfaces there is, and Part D uses it deliberately.

14.99.30.4 returns nothing at all — no PTR exists. Common for on-premises and colocated ranges where nobody configured the reverse zone.

Why the empty one is a real finding rather than cosmetic. Receiving mail servers routinely check that a sending IP has a PTR, and that the PTR resolves forward to the same address — the forward-confirmed reverse DNS check. A host with no PTR that tries to send mail gets a deliverability penalty or an outright rejection. If any of the SPF-listed sending ranges from B6 lack PTRs, that is a mail-deliverability problem waiting to be blamed on something else.

_xmpp-client._tcp.jabber.org. 60 IN	SRV	30 30 5222 scarlet.jabber.org.

Priority 30, weight 30, port 5222, target scarlet.jabber.org. A client that speaks XMPP needs no configuration beyond the domain name — it constructs _xmpp-client._tcp.jabber.org, and DNS hands back the host and the port.

Compare that with how HTTP works. There is no SRV for the web; the port is a convention baked into the scheme, 80 or 443. That is why moving a web service to a different port requires telling every client, while moving an XMPP or SIP service is a DNS change. It is a real architectural difference and it explains why service meshes and Kubernetes lean on SRV so heavily.

The naming rule to remember, because you will construct these by hand in Module 08: _service._proto.name, both underscore-prefixed, protocol is _tcp or _udp.

$ dig +noall +answer google.com CAA
google.com.		1341	IN	CAA	0 issue "pki.goog"

$ dig +noall +comments seamless.se CAA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12903
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Google's record says: only pki.goog may issue for this domain. The leading 0 is the flags byte; issue is the property tag.

seamless.se returns NODATA — no CAA record at all. Read that precisely, because the two readings are very different:

• It does not mean certificate issuance is blocked
• It means every publicly trusted CA in the world is permitted to issue for this domain, which is the default when no CAA record exists

This is a finding on nearly every domain audit, and it is one of the cheapest security improvements available: a single record, no user-visible change, no risk of breaking traffic, and it removes hundreds of organisations from the set of people who can mint a valid certificate for you.

The one way it bites you, and it is worth stating so you set it up correctly: add a CAA that names only your current CA, then later try to move to a different one, and the new CA will refuse to issue. The failure appears at renewal time, which is often 3am on a weekend. Add every CA you actually use, including the one your CDN or load balancer provisions certificates through, and use the iodef tag so violations are reported to you rather than silently dropped.

A and AAAA for IPv4 and IPv6 addresses. CNAME for aliases. NS for delegation. SOA for zone metadata and the negative caching TTL. MX for mail routing. TXT for SPF, DKIM, DMARC and ownership proofs. PTR for reverse lookups. SRV for service discovery including a port. CAA for certificate issuance policy.

What makes this answer stand out is grouping rather than listing. Three of them — NS, SOA and the delegation records — describe the zone itself. Three describe hosts. Three are policy records that no packet ever depends on but which break things badly when wrong: TXT for mail authentication, CAA for certificates, PTR for mail reputation. Reciting nine types is memorisation; naming three categories shows you understand what DNS is being used for.

SRV, and it is the only common one that does. Its RDATA is priority, weight, port and target, and the name is structured as _service._proto.name.

Priority works like MX preference — lowest wins — and weight distributes proportionally among equal priorities, which makes SRV the only core record type with genuine weighted load balancing.

The caveat that shows real-world experience: it only works if the client implements it, and most do not. Browsers ignore SRV entirely for HTTP. Where it is genuinely load-bearing is Kubernetes headless services, SIP, XMPP and Active Directory.

$ named-checkzone example.internal db.example.internal
zone example.internal/IN: loaded serial 2026081701
OK

$ named-checkzone -D example.internal db.example.internal
zone example.internal/IN: loaded serial 2026081701
example.internal.	3600 IN SOA	ns1.example.internal. hostmaster.example.internal. 2026081701 7200 900 1209600 900
example.internal.	3600 IN NS	ns1.example.internal.
example.internal.	3600 IN NS	ns2.example.internal.
example.internal.	3600 IN A	192.0.2.20
example.internal.	3600 IN MX	10 mail.example.internal.
*.example.internal.	3600 IN	A	192.0.2.99
api.example.internal.	3600 IN	A	192.0.2.30
api.example.internal.	3600 IN	A	192.0.2.31
mail.example.internal.	3600 IN	A	192.0.2.40
ns1.example.internal.	3600 IN	A	192.0.2.10
ns2.example.internal.	3600 IN	A	192.0.2.11
www.example.internal.	3600 IN	CNAME	example.internal.
OK

-D is the most under-used debugging tool in DNS and you should build a habit around it. It shows you the zone as the server understands it, with every @ expanded, every relative name qualified, and every inherited TTL made explicit.

Which means every ambiguity in your file becomes visible. www IN CNAME @ became www.example.internal. CNAME example.internal. — you can see with your own eyes that the @ resolved to what you intended. And if you had made the trailing-dot mistake, you would see the doubled name sitting right there in the output instead of discovering it from a user report.

The workflow to adopt: edit, named-checkzone, then named-checkzone -D and actually read it. OK only tells you the file parses. The dump tells you it means what you meant.

dns_master_load: broken-apex.zone:13: example.internal: CNAME and other data
dns_master_load: broken-apex.zone:13: example.internal: CNAME and other data
dns_master_load: broken-apex.zone:17: example.internal: CNAME and other data
zone example.internal/IN: loading from master file broken-apex.zone failed: CNAME and other data
zone example.internal/IN: not loaded due to errors.

CNAME and other data — memorise that string. It is the error you will meet whenever a name has a CNAME plus anything else, and BIND reports it three times because three separate records collide with the alias: the two NS records at line 13, and the MX at line 17.

The zone is not loaded. This is a good failure: loud, immediate, and before anything is served. Compare it with the failures in C5 that load cleanly and break in production.

Now the useful part — what you actually do when a vendor says "point your root domain at this hostname". You cannot use a CNAME, so every provider offers a non-standard pseudo-record:

All of them work the same way, and understanding the mechanism tells you the trade-off. They are not on the wire. The authoritative server resolves the target internally and answers your query with a genuine A or AAAA record. Standards compliance is preserved because a normal address record is what leaves the server.

The two consequences that bite. First, the flattening happens from the provider's network position, not yours — so if the target is geo-distributed, your users may get an address chosen for the wrong region. Second, these records are provider-specific and cannot be transferred, so migrating DNS providers means re-creating every one of them by hand, and forgetting one is an apex outage.

*.example.internal.	3600 IN	A	192.0.2.99
api.example.internal.	3600 IN	A	192.0.2.30
api.example.internal.	3600 IN	A	192.0.2.31
www.example.internal.	3600 IN	CNAME	example.internal.

1. anything.example.internal → 192.0.2.99. YES. No such name exists, so the wildcard fires. This is the case everyone expects.

2. api.example.internal → 192.0.2.30 and .31. NO. The name exists with its own A records, so the wildcard is never reached.

3. api.example.internal MX → NODATA. NO — and this is the one that catches people. api has no MX record, so you might expect the wildcard to supply one. It does not. The name api exists, and existence blocks the wildcard for every type. You get NOERROR with ANSWER: 0. Property 1, stated precisely.

4. deep.nested.example.internal → NXDOMAIN. NO. *.example.internal covers one label only. A wildcard does not descend, and *.*.example.internal is not a thing.

5. www.example.internal → follows the CNAME to the apex, 192.0.2.20. NO. www exists as an alias, and that is enough to block the wildcard.

The mental model that gets all five right without memorising anything: the resolver looks for the exact name first. If the name exists in any form at all, the wildcard is out of the picture — regardless of which type you asked for. Only when the name is entirely absent does the wildcard get consulted, and then only for the type you asked for, and only one level down.

Now imagine this at 500 hosts. Someone adds *.example.com A pointing at a marketing landing page. Every mistyped internal hostname now resolves to the marketing site. Health checks that relied on NXDOMAIN to detect a decommissioned service go green forever. And the zone becomes un-auditable, because you can no longer distinguish a name that exists from one that does not.

===== 1. two TTLs in one RRset =====
b-ttl.zone:16: TTL set to prior TTL (3600)
zone example.internal/IN: loaded serial 2026081701
OK

===== 2. MX pointing at a CNAME =====
zone example.internal/IN: example.internal/MX 'www.example.internal' is a CNAME (illegal)
zone example.internal/IN: loaded serial 2026081701
OK

===== 3. the missing trailing dot =====
www.example.internal.			      3600 IN CNAME	www.example.internal.example.internal.

Look at the last line of the first two: OK. Both zones loaded and would be served.

Error 1 — the TTL you wrote was thrown away. You asked for 60 seconds on one address; BIND silently forced it back to 3600 because RFC 2181 forbids differing TTLs inside an RRset. One line of warning in a log nobody reads, and then it serves happily. If that 60-second TTL was your failover plan, your failover plan is now an hour long and you have no idea.

Error 2 — is a CNAME (illegal), followed by OK. The zone loads with a mail configuration that is invalid per RFC 2181. Some senders will follow it, some will refuse. You get partial mail delivery, which is far harder to diagnose than none at all, because the people who can reach you have no reason to report anything.

Error 3 — no warning whatsoever, and the damage is right there in the dump. www.example.internal. is now an alias for www.example.internal.example.internal., a name that does not exist. named-checkzone said OK because the file is syntactically perfect. This is the trailing-dot bug from Module 01 A3, and it is the reason C2 tells you to read the -D dump rather than trust the word OK.

The general lesson, which is worth more than the three specifics. In DNS, OK means "this parses", not "this is correct". The failures that cost you a weekend are never syntax errors — they are semantically valid files that say something you did not mean. That is why the verification step is always query the result, never the file loaded.

The zone's $ORIGIN is appended, so www.example.com written inside the example.com zone becomes www.example.com.example.com.

The file is syntactically valid, so it loads without error and named-checkzone reports OK. You get a working zone containing a name nobody will ever query, and the name you intended does not exist.

How I avoid it, which is the practical half of the answer: write names either fully relative — www — or fully qualified with the dot, and never the half-qualified middle form. Then verify with named-checkzone -D, which dumps every name fully expanded so the doubled name is visible immediately rather than discovered from a user report.

The main one is that NXDOMAIN disappears from the entire zone. Every conceivable name now resolves, so typos succeed, decommissioned services keep answering, and any monitoring that relies on a name failing to resolve goes permanently green.

I would also check what it shadows and what it does not: the wildcard only fires for names that do not otherwise exist, matches a single label, and is type-specific — so api.example.com MX still returns NODATA if api exists with only an A record.

And the operational point I would raise in the review: it makes the zone un-auditable. You can no longer answer "does this name exist" for anything under the domain, which breaks inventory, breaks certificate scoping, and breaks the enumeration techniques you would otherwise use to find out what you own.

seamless.se.		900	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
seamless.se.		3600	IN	NS	ns-135.awsdns-16.com.
seamless.se.		3600	IN	NS	ns-1490.awsdns-58.org.
seamless.se.		3600	IN	NS	ns-1760.awsdns-28.co.uk.
seamless.se.		3600	IN	NS	ns-722.awsdns-26.net.
seamless.se.		60	IN	A	52.77.52.233
AAAA      (none)
seamless.se.		3600	IN	MX	10 aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt1.aspmx.l.google.com.
seamless.se.		3600	IN	MX	20 alt2.aspmx.l.google.com.
seamless.se.		3600	IN	MX	30 aspmx2.googlemail.com.
seamless.se.		3600	IN	MX	30 aspmx3.googlemail.com.
seamless.se.		300	IN	TXT	"v=spf1 include:amazonses.com include:_spf.linserv.se include:spf.mandrillapp.com include:_spf.salesforce.com a:mail.workbuster.se include:_spf.google.com ip4:3.1.214.242 ip4:14.142.43.230 ip4:14.99.30.2 ~all"
CAA       (none)
DNSKEY    (none)

The (none) lines are worth as much as the records, and this is the habit to build: print the absences explicitly. A sweep that only shows what exists lets you skim past three findings.

The seven-line briefing you can now give, without asking anyone anything:

1. DNS is on AWS Route 53 — the awsdns nameservers. You know which console and which API
2. Mail is Google Workspace — aspmx.l.google.com, with a proper three-tier preference ladder
3. No IPv6. IPv6-only clients cannot reach this name
4. No CAA — every publicly trusted CA in the world may issue certificates for this domain
5. No DNSKEY — the zone is not DNSSEC-signed. That matters practically in D3: it rules out one enumeration technique entirely
6. The A TTL is 60 while everything else is 3600 — this address is designed to be moved quickly. Ask why
7. The SPF record names six external senders and three ip4: addresses. Six vendor relationships, and three IPs that belong to the organisation's own mail infrastructure — keep those, D4 uses them

Now imagine this at 500 domains. This is exactly why it becomes the script in D5 rather than something you type.

$ dig zz9x7q2w-nonexistent-probe.seamless.se +noall +comments
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44544
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

$ dig admin-vodafone.seamless.se +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61804
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

admin-vodafone.seamless.se. 30	IN	A	77.83.61.131

$ dig admin-vodafone.seamless.se AAAA +short
(no output)

$ dig admin-vodafone.seamless.se CNAME +short
(no output)

$ dig @ns-135.awsdns-16.com admin-vodafone.seamless.se +noall +comments +answer
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35503
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

admin-vodafone.seamless.se. 30	IN	A	77.83.61.131

The answer: yes, it exists, and it is 77.83.61.131. Now the reasoning, because the reasoning is the transferable part.

Step 1 established the result is trustworthy. A random name returned NXDOMAIN, so there is no wildcard in this zone. Had it returned an address, every subsequent check would have been meaningless and you would need a completely different approach.

Step 2 gave NOERROR with ANSWER: 1. Existence confirmed, plus the address.

Step 3 says the name has an A record and nothing else — no IPv6, not an alias. Worth running because a name that returns nothing for A can still exist as a CNAME or with only a TXT, and stopping at step 2 would have you report "does not exist" for a name that does.

Step 4 is the one people skip, and it is the one that makes the answer defensible. Note aa in the flags and the TTL at the full 30 rather than a counted-down value. This came from Route 53 itself, not from a cache. Step 2 tells you what a resolver believes; step 4 tells you what the zone actually says. When those two disagree you have found a stale cache, and that is a completely different investigation.

Two more things this output tells you for free.

The TTL is 30 seconds — even shorter than the apex's 60. Somebody wants to move this address fast. On a customer-named host like this one, that usually means a manually operated failover.

77.83.61.131 is nowhere near the other addresses in this domain — not the AWS Singapore range, not the on-premises ranges. A separate hosting arrangement, which for a customer-specific host is exactly what you would expect and exactly what you should confirm with whoever owns it.

I query it and read status: rather than looking for an IP address. NOERROR with a non-zero answer count means it exists with that type; NOERROR with zero answers means the name exists but has no record of that type; NXDOMAIN means no such name; SERVFAIL or REFUSED means I learned nothing and must ask elsewhere.

I check more than one type, because a name can exist as a CNAME or with only a TXT record and still return nothing for A.

The two steps that make the answer defensible, and that most candidates omit. First, probe a random name in the same zone to check for a wildcard — with one present, every name "exists" and the whole exercise is void. Second, confirm against an authoritative server rather than a resolver, so a cached negative answer cannot masquerade as a missing record.

--- ns-1490.awsdns-58.org. ---
;; Connection to 205.251.192.135#53(205.251.192.135) for seamless.se failed: timed out.
;; no servers could be reached

--- ns-722.awsdns-26.net. ---
;; Connection to 205.251.194.210#53(205.251.194.210) for seamless.se failed: timed out.
;; no servers could be reached

All four time out, and that is the correct, healthy result. Route 53 does not offer AXFR to the public at all.

Read the mechanics, because they matter. AXFR is a TCP query — a whole zone will not fit in a UDP datagram — so dig opens a TCP connection to port 53 and the server declines to complete it. On a BIND server with allow-transfer restricted you would instead get a clean Transfer failed with a REFUSED, which is a more informative rejection.

When this succeeds, stop and write it up. An open AXFR hands a stranger every name in your zone: internal hostnames, staging systems, backup servers, management interfaces, the lot. It is a decades-old audit finding and it still appears, usually on a forgotten secondary rather than the primary — which is why the loop above tries every nameserver rather than just the first.

And this is why the D5 script tries all of them and prints a finding when one answers. You are not expecting success; you are checking that the answer is "no" everywhere.

Run this one yourself — the log is appended to constantly and any output pasted here would be wrong within a week. What matters is how to read it, and that is the same every time.

The output is one hostname per line, deduplicated, with wildcard prefixes stripped. Expect it to be noisy in three specific ways, and expect each kind of noise to be informative:

• Names that no longer resolve. A certificate was issued once and the name has since been retired. These are not junk — they are a history of what the estate used to run, and retired names sometimes come back pointed at somebody else's infrastructure
• Wildcard entries such as *.seamless.se. That tells you a wildcard certificate exists, which is a different thing from a wildcard DNS record, and it means any subdomain can present a valid certificate
• Names created for a single purpose — one-off customer environments, short-lived demos. These are exactly the names a dictionary never finds, and they are the reason to run this at all

The essential step is to feed every name back through dig and keep the ones that still resolve. CT tells you what was certificated; only DNS tells you what is live. The two lists overlap and neither contains the other.

The blind spot to be honest about. CT only sees names that were given a publicly trusted certificate. Anything on an internal CA, anything served over plain HTTP, and anything that is not a web service at all — a database host, an SSH bastion, a mail relay — is invisible here. Those are often precisely the hosts you most wanted to inventory.

If curl and jq are not installed: sudo apt install -y curl jq.

www.seamless.se.	3600	IN	CNAME	seamless.se.
seamless.se.		60	IN	A	52.77.52.233
mail.seamless.se.	133	IN	CNAME	ghs.googlehosted.com.
ghs.googlehosted.com.	69	IN	A	192.178.129.121
smtp.seamless.se.	3600	IN	CNAME	aspmx.l.google.com.
aspmx.l.google.com.	293	IN	A	64.233.181.26
dev.seamless.se.	133	IN	A	52.76.82.127
demo.seamless.se.	3600	IN	A	195.22.81.226
jira.seamless.se.	300	IN	A	14.99.30.4
confluence.seamless.se.	300	IN	A	14.99.30.4
support.seamless.se.	300	IN	A	14.99.30.4
crm.seamless.se.	300	IN	A	14.142.42.18
gw.seamless.se.		3600	IN	A	195.22.81.194
intranet.seamless.se.	3600	IN	CNAME	ghs.google.com.
sds.seamless.se.	3600	IN	CNAME	seamless.se.

Twelve names found from fifteen guesses, and api, admin and vpn returned nothing at all. Because D2 already proved there is no wildcard, those three absences are real information, not an inconclusive result.

But the list of names is the boring half. Read the addresses and an architecture appears:

Four distinct hosting environments, visible in the IP ranges alone:

• 52.77.x / 52.76.x — AWS Singapore. The public site and dev
• 14.99.30.4 and 14.142.42.18 — a completely different range hosting Jira, Confluence, support and CRM. On-premises or colocated
• 195.22.81.x — a third range, with demo and gw
• Google — mail, smtp and intranet are all CNAMEs into Google's infrastructure

Now the finding that is worth more than the inventory. jira, confluence and support are all on 14.99.30.4 — one single address. Three business-critical internal services share one host or one ingress point. That is a concentration of risk nobody chose deliberately; it accumulated. You cannot see it by reading a list of names, only by sorting the list by address — which is exactly what D4 does.

And connect it back to D1. The SPF record listed ip4:14.99.30.2 and ip4:14.142.43.230. Those are neighbours of the addresses you just discovered. The organisation's own SPF record told you which IP ranges to look at, before you probed anything. That is method 6 in the table, and it is free.

For real work use a proper tool rather than a shell loop — dnsx, massdns or dnsrecon with a wordlist such as SecLists. They run thousands of names concurrently and handle rate limiting. The loop above is here so you can see exactly what those tools do, which is all they do.

14.99.30.4       jira.seamless.se
14.99.30.4       confluence.seamless.se
14.99.30.4       support.seamless.se
14.142.42.18     crm.seamless.se
52.76.82.127     dev.seamless.se
52.77.52.233     www.seamless.se
52.77.52.233     sds.seamless.se
195.22.81.194    gw.seamless.se
195.22.81.226    demo.seamless.se

--- reverse DNS of each distinct address ---
14.142.42.18     
14.99.30.4       
52.76.82.127     ec2-52-76-82-127.ap-southeast-1.compute.amazonaws.com.
52.77.52.233     ec2-52-77-52-233.ap-southeast-1.compute.amazonaws.com.
64.233.181.121   ir-in-f121.1e100.net.
195.22.81.194    gw.seamless.se.
195.22.81.226    

The sorted view makes three things visible that the name list hid completely.

1. 14.99.30.4 serves three business-critical services. Jira, Confluence and the support system are one host. One reboot, one certificate, one firewall rule, one failure. This is the finding of the whole exercise and it is invisible until you sort by address.

2. www and sds are the same address — both aliases to the apex. Consistent, and it tells you sds is not a separate system but another name for the main site.

3. Four independent hosting environments. AWS Singapore, two on-premises ranges, and Google. Each one is a different operational contract, a different change process, and a different person to call.

Now the reverse DNS column, which is a health check in its own right:

• gw.seamless.se reverses cleanly to gw.seamless.se. — forward and reverse agree. This is forward-confirmed reverse DNS and it is what a receiving mail server wants to see
• 14.99.30.4, 14.142.42.18 and 195.22.81.226 have no PTR at all. If any of them ever sends mail, it will be penalised or rejected on reputation grounds. Cross-check against the SPF record from D1 — ip4:14.99.30.2 and ip4:14.142.43.230 are in exactly these ranges
• The AWS defaults leak the region — ap-southeast-1 — for free

The one trap that will make you wrong: a shared address does not always mean a shared host. Behind a CDN, a reverse proxy, a Kubernetes ingress or a cloud load balancer, hundreds of unrelated names legitimately share one address, and the co-location you "found" is an artefact. Before concluding anything, check whether the address belongs to a CDN or load balancer — reverse DNS usually tells you, since a CDN PTR is unmistakable. The 14.99.30.4 finding above holds because the reverse is empty and the range is not a CDN's, which is the sort of qualification that turns a guess into a finding.

I start by saying that DNS has no listing operation, so this is always reconstruction from indirect sources, and the completeness depends entirely on which sources are available to me.

If it is our own domain, I read the zone from the provider's API or console — that is the only complete answer and it ends the exercise. If not: attempt a zone transfer against every nameserver, since one forgotten secondary allowing AXFR gives you the whole zone; query Certificate Transparency logs, which index every name that has ever had a publicly trusted certificate; run a dictionary sweep with a tool like dnsx or massdns; and if the zone is DNSSEC-signed, NSEC walking gives complete enumeration with no guessing.

I would also mine the organisation's own records — SPF ip4: mechanisms, MX targets and NS hostnames all name infrastructure, and reverse DNS across the ranges they reveal finds hosts a dictionary never would.

Two things I would state before starting, and they are what mark out someone who has done this professionally. First, authorisation in writing, since a wide sweep is indistinguishable from reconnaissance in a target's logs. Second, check for a wildcard first — with one present every name resolves, every negative result is meaningless, and the entire exercise has to be approached differently.

Because AXFR returns the complete contents of the zone to whoever asks. That is every internal hostname, every staging and test system, every management interface, every backup host — a free map of the estate, and a target list.

It is not a vulnerability in DNS; it is a configuration that was appropriate for a secondary and got left open to the world. allow-transfer restricted to the secondaries' addresses, ideally with TSIG authentication, is the fix.

The detail that shows field experience: when it appears, it is almost never on the primary. It is on a secondary that someone stood up years ago and nobody has thought about since — which is why you test every nameserver in the NS set, not just the first one your tool picks.

== WILDCARD CHECK ==
no wildcard  (status: NXDOMAIN) -> existence checks are meaningful

== ZONE TRANSFER (AXFR) ATTEMPT ==
refused/timeout on ns-1490.awsdns-58.org.  (expected)
refused/timeout on ns-722.awsdns-26.net.  (expected)
refused/timeout on ns-135.awsdns-16.com.  (expected)
refused/timeout on ns-1760.awsdns-28.co.uk.  (expected)

== NAME -> ADDRESS INVENTORY ==
NAME                               STATUS   RESOLVES TO
www.seamless.se                    ALIAS    CNAME seamless.se. -> 52.77.52.233
mail.seamless.se                   ALIAS    CNAME ghs.googlehosted.com. -> 192.178.209.121
smtp.seamless.se                   ALIAS    CNAME aspmx.l.google.com. -> 192.178.209.27
dev.seamless.se                    A        52.76.82.127
demo.seamless.se                   A        195.22.81.226
jira.seamless.se                   A        14.99.30.4
confluence.seamless.se             A        14.99.30.4
support.seamless.se                A        14.99.30.4
crm.seamless.se                    A        14.142.42.18
gw.seamless.se                     A        195.22.81.194
intranet.seamless.se               ALIAS    CNAME ghs.google.com. -> 142.251.183.121
sds.seamless.se                    ALIAS    CNAME seamless.se. -> 52.77.52.233

== REVERSE DNS OF DISCOVERED ADDRESSES ==
14.142.42.18     
14.99.30.4       
195.22.81.194    gw.seamless.se.
195.22.81.226    
52.76.82.127     ec2-52-76-82-127.ap-southeast-1.compute.amazonaws.com.
52.77.52.233     ec2-52-77-52-233.ap-southeast-1.compute.amazonaws.com.

The Google addresses will differ every run — those CNAMEs resolve into a large rotating pool, which is itself worth noticing.

Four design decisions in this script are worth copying into anything you write:

1. The wildcard check runs before the enumeration and is printed prominently. If a wildcard exists, everything below it is noise, and the reader needs to know that before they read it.

2. The AXFR loop covers every nameserver. As D3 explained, the open one is usually the forgotten secondary, so checking only the first is checking the wrong one.

3. CNAMEs are labelled ALIAS and the target is kept. A flattened +short output would show only the final address and hide the fact that a third party sits in the path. Knowing that mail points into Google's estate is the useful part.

4. The reverse lookup is a separate final section. It is the part that tells you about hosting, region and mail reputation, and it is the part people leave out.

Where to take it next. Emit CSV and commit it to Git, and every run becomes a diff. A new name appearing, an address moving between hosting environments, or a PTR disappearing all become visible in a code review rather than in an incident. That is the point of the whole exercise: not the snapshot, but noticing the change.

$ dig +short admin-vfo.seamless.se A
185.64.27.150

$ dig +noall +authority admin-vfo.seamless.se AAAA
seamless.se.		900	IN	SOA	ns-1490.awsdns-58.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

$ dig +noall +answer admin-vfo.seamless.se NS
(no output)

The second command is the whole exercise, and the answer is in the owner-name column. The SOA that came back belongs to seamless.se, not to admin-vfo.seamless.se.

That single fact tells you admin-vfo.seamless.se is a plain record inside the seamless.se zone. No separate zone, no separate nameservers, no separate administrator. It is a line in the same file as www and jira, and it is changed in the same Route 53 hosted zone.

The third command confirms it from the other direction — no NS records at that name, so nothing has been delegated.

What it would look like if it were a zone. The SOA in the AUTHORITY section would read admin-vfo.seamless.se. rather than seamless.se., and dig NS admin-vfo.seamless.se would return nameservers. Then it would be a genuinely separate administrative unit — possibly run by another team, possibly by the customer themselves.

Why you care in daily work. It answers "who do I ask to change this record". A subdomain-that-is-a-record is yours to change in your own hosted zone. A subdomain-that-is-a-zone belongs to whoever holds those nameservers, and your change has to go through them. Getting this backwards costs a day of chasing the wrong team. Module 03 covers how the delegation itself works.

NAME                                     STATUS     ADDRESS
admin-vfo.seamless.se                    NOERROR    185.64.27.150
admin-vodafone.seamless.se               NOERROR    77.83.61.131
dev.seamless.se                          NOERROR    52.76.82.127
demo.seamless.se                         NOERROR    195.22.81.226
jira.seamless.se                         NOERROR    14.99.30.4

Thirty-five fourth-level probes and not one of them exists. The indented lines never printed, because every www.*, admin.* and api.* under those five names returned NXDOMAIN.

That is a real and useful finding: this estate is flat. Everything lives one label under seamless.se. There is no www.admin-vfo, no api.dev, no nested structure at all. Knowing the shape is flat means the one-level sweep in D5 is sufficient here, and you can stop looking.

Also note admin-vfo and admin-vodafone are different names on different addresses — 185.64.27.150 and 77.83.61.131. Similar naming, separate environments. Do not assume two names that look related point anywhere near each other; the address column is the only thing that tells you.

Why brute force gets expensive fast, and why you should not lead with it. One level with a 5,000-word list is 5,000 queries. Two levels is 5,000 × 5,000 — twenty-five million, which is neither polite nor practical. So the realistic method is: sweep level one, then sweep level two only beneath the names that actually exist, which is what the nested loop above does.

Which is exactly why Certificate Transparency (D3.2) matters more at depth than at level one. CT gives you the full hostname of anything that ever had a public certificate, however deep it sits, with no guessing and no query volume. For a nested estate, run CT first and use the dictionary only to fill gaps.

And the reminder from D2: all of this depends on there being no wildcard. Note too that a wildcard at *.seamless.se would not match www.admin-vfo.seamless.se — wildcards cover one label only, so a fourth-level name is unaffected by a third-level wildcard. That asymmetry surprises people during audits.

A subdomain is a naming relationship — any name below another in the tree. A zone is an administrative unit: a set of records served together by one set of nameservers, with one SOA.

Creating admin.example.com normally just adds a record to the example.com zone. It becomes a separate zone only when the parent publishes NS records for it — a delegation — which is a deliberate handover of authority, usually to a different team or organisation.

The one-command test, which is what makes this a practical answer rather than a definition: query any name under it and read the owner name of the SOA in the AUTHORITY section. If the SOA says example.com, the name is a record in the parent zone. If it says admin.example.com, it is its own zone. That tells you immediately whether the change is yours to make or somebody else's.

They are two different names in the tree and nothing in DNS links them. www has to be created explicitly, usually as a CNAME to the apex or as its own address record, and in this case nobody did — or it was deleted.

I would confirm with dig www.example.com +noall +comments and expect NXDOMAIN, then check the authoritative server directly to rule out a cached negative.

The reason this is worth getting right instantly: the www convention is so universal that people assume it is a protocol behaviour. It is not — it is a record someone has to maintain, and "we migrated DNS and forgot the www CNAME" is a genuinely common outage. The same reasoning applies at any depth: www.admin.example.com does not follow from admin.example.com either.

Part 1 — the zone.

$TTL 3600
$ORIGIN corp.internal.
@       IN  SOA ns1.corp.internal. hostmaster.corp.internal. (
                2026081701  ; serial
                7200        ; refresh
                900         ; retry
                1209600     ; expire
                300 )       ; requirement 6 - negative TTL 5 min
@       IN  NS  ns1.corp.internal.
@       IN  NS  ns2.corp.internal.
ns1     IN  A   192.0.2.10
ns2     IN  A   192.0.2.11

; requirement 1 - apex CANNOT be a CNAME, so a real A record,
; and www is an alias to the apex. The alias is at www, not at @.
@       IN  A   192.0.2.20
www     IN  CNAME @

; requirement 2 - one RRset, three members, one shared TTL
api     IN  A   192.0.2.30
api     IN  A   192.0.2.31
api     IN  A   192.0.2.32

; requirement 3 - targets are real hostnames with A records, not aliases
@       IN  MX  10 mail1.corp.internal.
@       IN  MX  20 mail2.corp.internal.
mail1   IN  A   192.0.2.40
mail2   IN  A   192.0.2.41

; requirement 4 - null MX, RFC 7505
static  IN  A   192.0.2.50
static  IN  MX  0 .

; requirement 5 - single issuer plus violation reporting
@       IN  CAA 0 issue "letsencrypt.org"
@       IN  CAA 0 iodef "mailto:[email protected]"

named-checkzone corp.internal db.corp.internal      # requirement 7
named-checkzone -D corp.internal db.corp.internal   # and READ it

The seven traps, and where each requirement tries to catch you:

1. Requirement 1 is the apex-CNAME trap. A CNAME at @ collides with SOA, NS, MX and CAA — CNAME and other data, zone rejected. The alias belongs at www
2. Requirement 2's phrase "fail over together" is the RRset property: one TTL, shared, not chosen per record. Writing three different TTLs gets you TTL set to prior TTL and two silently discarded values
3. Requirement 3 says "neither target an alias" — an MX pointing at a CNAME is illegal per RFC 2181 and named-checkzone warns while still returning OK, which is the trap
4. Requirement 4 is MX 0 . — a single MX whose target is the root. A missing MX is not the same thing: senders then fall back to the A record
5. Requirement 5 needs two records, not one. issue alone silently discards violation reports; iodef is what makes them reach you
6. Requirement 6 is the SOA MINIMUM field, and the subtlety is that the effective negative TTL is min(MINIMUM, SOA TTL). With $TTL 3600 and MINIMUM 300, you get 300 — correct. Had you set MINIMUM to 7200 you would have got 3600, not 7200
7. Requirement 7 means reading the output. OK alone does not satisfy it, because OK appears alongside warnings