DNS for servers: records, zones and name resolution

Why this matters

Almost nothing on a network reaches a server by its IP address. Users, mail systems, applications and other servers all use names, and DNS, the Domain Name System, turns those names into addresses. When DNS is wrong, a perfectly healthy server becomes unreachable, and the symptom looks like the server is down.

A surprising share of server troubleshooting ends at a DNS record. This lesson covers the records a server administrator works with, how names are resolved, why a change does not appear everywhere at once, and how to test what DNS is actually answering.

The lesson

A, AAAA, CNAME, PTR, MX, SRV and TXT records, and what depends on each

DNS stores information as resource records. The ones Server+ expects you to know:

• A maps a name to an IPv4 address. It is the most common record, and what most lookups ultimately want.
• AAAA maps a name to an IPv6 address.
• CNAME (canonical name) makes one name an alias of another: a request for www.example.com is answered by following it to the real name. A CNAME cannot share its name with any other record, which is why it cannot be used at the top of a domain.
• PTR (pointer) maps an address back to a name, for reverse lookups.
• MX (mail exchanger) names the servers that accept email for a domain, each with a preference number; the lowest is tried first.
• SRV (service) records locate a service by name, giving its host, port, priority and weight. Active Directory depends on them heavily: clients find domain controllers by looking up SRV records, so missing or wrong SRV records break domain logons even when every server is running.
• TXT holds free-form text, widely used to publish email security policies (SPF, DKIM and DMARC) and to prove domain ownership to outside services.

Two more records define the zone itself: NS records name the zone's authoritative name servers, and the SOA (start of authority) record holds the zone's administrative settings, including its serial number.

Forward and reverse lookup zones

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

A forward lookup zone answers "what is the address of this name?" and holds A, AAAA, CNAME, MX, SRV and TXT records.

A reverse lookup zone answers "what is the name for this address?" and holds PTR records. For IPv4, reverse zones live under in-addr.arpa, with the address written backwards, so the network 192.168.1.0/24 has the zone 1.168.192.in-addr.arpa. IPv6 uses ip6.arpa.

Reverse lookups are easy to neglect because nothing obvious breaks without them, but several things quietly depend on them. Logs and monitoring tools show names instead of bare addresses, some security checks verify that a host's forward and reverse records agree, and receiving mail servers commonly reject or distrust mail from a sending server whose address has no matching PTR record.

Zones are often held on more than one server. A primary holds the writable copy and secondaries hold read-only copies kept current by zone transfers. In Active Directory, zones are usually AD-integrated, replicated with the directory itself, and clients can register their own records through dynamic updates.

How a client resolves a name, and where caching hides a change

When an application asks for a name, resolution follows a sequence:

1. The client checks its own cache of recent answers, and its hosts file, a local list of names and addresses that overrides DNS.
2. If the answer is not there, it asks its configured DNS server, the recursive resolver.
3. The resolver checks its own cache. If it has no answer, it resolves the name by querying the DNS hierarchy: the root servers, then the top-level domain's servers, then the domain's authoritative servers.
4. The answer is returned to the client, and the resolver and the client both cache it.

Caching makes DNS fast, and it is also why a change does not appear everywhere at once. After a record is changed on the authoritative server, the old answer can live on in the resolver's cache, in the client's cache and even in an application's own cache. On Windows, ipconfig /displaydns shows the client cache and ipconfig /flushdns clears it; on Linux systems using systemd-resolved, resolvectl flush-caches does the same. The hosts file is worth checking too: an old entry left there by someone testing will override DNS on that machine indefinitely.

Resolvers also cache negative answers, so a record that did not exist a moment ago can keep appearing to be missing for a while after it is created.

TTL, and planning a DNS change ahead of the cutover

Every record has a TTL, a time to live in seconds, which tells caches how long they may keep the answer. A TTL of 86,400 means a cache may keep the old answer for a full day.

That makes TTL the key to a planned change, such as moving a service to a new server. If you change the record while its TTL is a day, some clients will keep using the old address for up to a day. The standard procedure is:

1. Well ahead of the cutover, lower the TTL, for example to 300 seconds.
2. Wait at least as long as the old TTL, so every cache has picked up the short one.
3. At the cutover, change the record. Caches now expire the old answer within minutes.
4. Verify that clients are reaching the new server.
5. Once the change is settled, raise the TTL again to reduce query load.

Keep the old server running until the old answers have expired, so clients that still hold them are not stranded.

Testing resolution with nslookup and dig

Two tools query DNS directly and show exactly what it returns.

nslookup is available on Windows and Linux. nslookup server01.example.com returns the address, and naming a DNS server after it asks that server specifically. The query type can be set, for example to MX, to look up particular records. On Windows, the PowerShell command Resolve-DnsName does the same job.

dig, standard on Linux, gives more detail. dig example.com MX shows the records and their remaining TTL in the answer section; dig @10.0.0.53 server01.example.com sends the query to a specific server; dig -x with an address performs a reverse lookup; and +short trims the output to the answer.

The most useful technique is comparison. Ask the authoritative server and the client's usual resolver the same question. If the authoritative server has the new answer and the resolver still has the old one, the record is right and caching is the problem, which only time or a cache flush will fix. If both give the old answer, the change was never made where it matters. Check reverse lookups as well as forward ones, since the two are maintained separately and drift apart.