A DNS zone is a database file with a beginning and an end, and the first line of it is a promise: "I am authoritative for this name." Everything else — every A record, every SRV entry that makes Active Directory work — is a row in that file.
Understanding zones explains most "DNS is broken" reports, because the answer is usually a record in the wrong zone, a zone that exists twice, or a delegation that points at a server which no longer answers.
The two records every zone needs
| Record | Purpose | Consequence if wrong |
|---|---|---|
| SOA | Names the primary server, the admin mailbox, the serial, and default TTLs | Secondaries never refresh; negative caching misbehaves |
| NS | Lists the authoritative servers for the zone | Resolvers cannot find the zone at all |
The serial number is how secondaries know there is a change. Modern AD-integrated zones handle it automatically; hand-edited zone files do not, and a stale serial is why a secondary can serve an old answer for days.
Record types you will actually use
| Type | Answers | Notes |
|---|---|---|
| A | IPv4 address | The workhorse |
| AAAA | IPv6 address | Publish only if the path works |
| CNAME | Alias to another name | Never at the zone apex; never alongside other records |
| MX | Mail exchanger | Priority + hostname |
| TXT | Arbitrary text | SPF, DKIM, domain verification |
| SRV | Service location | _ldap._tcp.dc._msdcs is how AD is found |
| PTR | Reverse lookup | Lives in in-addr.arpa, not your forward zone |
| CAA | Which CAs may issue certificates | Cheap protection against mis-issuance |
The CNAME apex rule catches people every year. marionisd.net CNAME example.com is invalid because
the apex must also carry SOA and NS records, and a CNAME cannot coexist with anything. Use an A record
at the apex, and CNAMEs for www, help, vpn.
AD lives and dies by SRV records
_ldap._tcp.dc._msdcs.marionisd.net is how a domain-joined machine finds a domain controller. If that
record is missing, stale, or published in a zone the client cannot reach, logins take ninety seconds
and then fail with an error that says nothing about DNS. Check SRV records before you touch anything
else in AD.
Split horizon: one name, two answers
marionisd.net exists twice:
- Internal zone, on the domain controllers, containing servers, printers, SRV records, and internal addresses.
- External zone, at your DNS host, containing the website, mail, and whatever the public needs.
That is not a mistake; it is the design. Internal clients get internal answers, external clients get public ones, and neither leaks the other's address plan.
The failure mode is drift: someone adds vpn.marionisd.net externally, internal clients resolve it,
and the VPN gateway only accepts connections from the internet side. Or an internal A record for a
server is published externally and exposes an address you did not mean to publish.
Delegation and subdomains
A delegation hands a subdomain to different nameservers. In AD, _msdcs.marionisd.net is typically
delegated so domain controllers can register their SRV records independently of the parent zone's
replication scope.
For a new campus, you may want 50.marionisd.net or newcampus.marionisd.net as a delegated
subdomain. It is optional — a flat zone with descriptive names works fine at district scale — but if
you delegate, the NS records must point at servers that answer for that name, or every lookup in the
subdomain fails with SERVFAIL.
TTL strategy by record type
| Record | TTL | Why |
|---|---|---|
| Stable infrastructure (MX, NS) | 3600–86400 | Rarely changes |
| Web and service records | 300–3600 | Changes need to propagate |
| Records about to change | 60–300 | Lowered a day before, restored after |
| SRV records | 600–3600 | AD tolerates longer, but failover wants shorter |
Worked example: publishing a new service
You stand up helpdesk.marionisd.net internally, on 10.0.0.40.
- Add an A record in the internal zone:
helpdesk→10.0.0.40, TTL 600. - If it must be reachable from outside, add an A record in the external zone pointing at the public address, and a port forward or reverse proxy.
- Add a PTR in the reverse zone if anything logs by name.
- If it uses a certificate, confirm the name matches the certificate exactly.
- Test from a staff VLAN, a student VLAN, and outside the district — three different resolvers, three different answers.
That last step is the one people skip, and it is where split-horizon designs fail.
What breaks in production
- A CNAME at the apex. The zone fails to load, or the provider silently refuses the record.
- Stale records after decommissioning. The server is gone; the A record is not; monitoring alerts on a host that no longer exists and someone spends an hour proving it.
- Duplicate zones. Two servers both claim authority for
marionisd.net; clients get whichever answers first, and the answers differ. - Missing reverse zone. Everything works, but logs show only IP addresses, which turns every incident into a lookup exercise.
- Scavenging disabled, or enabled without understanding it. Either records accumulate forever, or dynamic registrations disappear and clients lose their own names.
Checklist
- Every zone has correct SOA and NS records, and a serial that increments.
- No CNAME at an apex; no CNAME sharing a name with other records.
- The internal and external zones are documented side by side, with who owns each.
- SRV records for AD are present, current, and resolvable from every VLAN.
- Reverse zones exist for every subnet that appears in logs.
- Scavenging is either on with documented intervals, or off with a manual cleanup process.
Next
Names are one half of core services. Continue with DHCP in Depth for the other half, where a full scope looks exactly like a broken network.