DNS zones, resolution and time services

Why this matters

The previous lesson covered what DNS records say. This one covers how the system is organised to serve them — zones, authority, and how a resolver actually finds an answer — plus the two time protocols beyond NTP.

The zone vocabulary is where DNS questions get precise. "Authoritative" and "recursive" describe different things, and a question will offer both as options for the same scenario to see whether you know which.

The lesson

Forward and reverse zones

A zone is a portion of the DNS namespace that a server holds records for.

A forward zone maps names to addresses — the ordinary direction, and what nearly all DNS traffic uses. example.com resolves to 203.0.113.10.

A reverse zone maps addresses to names, answering "what is called 203.0.113.10?" Reverse zones live under the special domain in-addr.arpa for IPv4 (ip6.arpa for IPv6), and the address is written backwards — 10.113.0.203.in-addr.arpa — because DNS reads hierarchies right to left, from most general to most specific, and IP addresses are written the other way round.

PTR — Pointer. The record type that lives in a reverse zone and supplies the name for an address. It is the mirror of an A record.

Reverse DNS matters more than people expect:

• Mail servers check it. Many receiving servers reject or penalise mail from an address with no matching PTR record, because legitimate mail servers have one and bulk senders often do not. This is the most common exam context.
• Logs are readable when addresses resolve to names.
• Troubleshooting benefits — traceroute output is intelligible because of reverse DNS.

Note that forward and reverse are separate zones and are not automatically consistent. Creating an A record does not create a PTR record, and the reverse zone for a public address is usually delegated by whoever owns the address block — normally your ISP — which is why setting a PTR record can require a request to them.

Authoritative versus non-authoritative

An authoritative server holds the actual zone data for a domain. Its answer is definitive: it is not repeating something it learned, it is the source.

A non-authoritative answer comes from a resolver's cache. It is a copy of something the resolver learned earlier from an authoritative server, and it is valid only until the record's TTL expires.

You see this distinction directly in nslookup and dig output, which label answers as non-authoritative when they come from cache.

Why it matters operationally: after a DNS change, the authoritative server is correct immediately, while resolvers around the world keep serving the old cached answer until the TTL expires. That is why you lower a record's TTL before a planned migration — so the cached copies expire quickly when the change lands. A question describing "some users see the new site and some see the old one" is describing cached non-authoritative answers.

Primary and secondary

Within the authoritative servers for a zone:

The primary holds the master, writable copy. Changes are made here.

A secondary holds a read-only copy, obtained from the primary by a zone transfer. It answers queries with equal authority — a client cannot tell the difference and does not need to.

Secondaries exist for redundancy and load distribution, and having at least two authoritative servers is effectively mandatory for any domain that matters.

Zone transfers themselves are a security consideration. A full transfer (AXFR) hands over every record in the zone, which is a complete map of an organisation's infrastructure. Transfers should be restricted to known secondary servers, and an open transfer is a genuine finding on a penetration test.

Recursive and iterative resolution

Two different behaviours, and the exam separates them.

A recursive query says "give me the final answer, do whatever work is needed". The client asks its resolver and expects a usable address back, not a referral. Client-to-resolver queries are recursive.

The resolver then performs iterative queries on the client's behalf: it asks a root server, which refers it to the .com servers; it asks those, which refer it to example.com's nameservers; it asks those, which answer authoritatively. Each step returns a referral rather than the answer, and the resolver walks the chain.

So: the client makes one recursive request; the resolver makes several iterative ones.

The security note that follows: a resolver offering recursion to the whole internet is an open resolver, and open resolvers are abused for DNS amplification attacks — a small spoofed query produces a large response aimed at a victim. Recursion should be offered only to your own clients.

The hosts file

A plain text file mapping names to addresses, checked before DNS. It lives at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on Linux and macOS.

It predates DNS entirely — the whole early internet was a single shared hosts file, and DNS exists because that stopped scaling.

Legitimate uses today are testing and temporary overrides: point a name at a staging server to check a migration before changing public DNS. The exam interest is twofold:

• It overrides DNS, so a wrong entry produces a host that resolves a name differently from every other machine — and nothing in DNS explains it. This is a genuinely hard fault to find if you do not think of it.
• Malware modifies it, redirecting banking or security-update domains to attacker-controlled addresses. An unexplained hosts entry is a finding.

Precision Time Protocol

PTP (IEEE 1588) synchronises clocks far more accurately than NTP — to the sub-microsecond level, against NTP's milliseconds.

It achieves this with hardware timestamping: network interfaces and switches mark packets at the physical layer, so the variable delay of operating system queues and software stacks is measured out rather than guessed. Devices in the path can be PTP-aware and correct for their own transit delay.

You need that accuracy in a narrow set of places, and these are the exam contexts: financial trading, where transaction ordering is regulated; industrial control and power distribution; broadcast and audio/video production, where streams must stay in sync; and telecommunications.

For everything else NTP is correct, because PTP needs supporting hardware throughout the path and is considerably more work to run.

Network Time Security

Plain NTP has a real weakness: it is unauthenticated. A client accepts time from whatever answers, so an attacker who can intercept or spoof NTP can move a client's clock — and moving a clock is a powerful attack. It can make an expired certificate appear valid, make a revoked credential appear current, break Kerberos authentication, or cause log timestamps to lie about when an intrusion occurred.

NTS (Network Time Security) adds cryptographic authentication to NTP. It uses TLS to establish keys, then authenticates the time exchanges themselves, so a client can verify that the time it is being told genuinely came from the server it chose and was not altered.

Note what it does and does not do: it authenticates, it does not encrypt the time data — which is not secret. The one-line version for the exam: NTS is to NTP what DNSSEC is to DNS — proof of authenticity, not confidentiality.