How to read a DNS lookup result

The record types you will actually see

A and AAAA records point a hostname at an IPv4 or IPv6 address respectively; these are what a browser or any client ultimately needs to connect to a server. CNAME aliases one hostname to another, useful when a subdomain should simply follow wherever a different hostname points, though a CNAME cannot coexist with other record types at the same name.

MX records list the mail servers responsible for receiving email for the domain, each with a priority. TXT records hold arbitrary text, used for SPF, domain verification and various other machine-readable purposes, and a domain commonly has several TXT records at once, each serving a different protocol.

NS records name the domain's authoritative name servers, and SOA (Start of Authority) carries the zone's serial number and timing parameters used by secondary servers. CAA restricts which certificate authorities may issue TLS certificates for the domain.

What the TTL number means

Every record carries a TTL, time to live, measured in seconds: the length of time a resolver is allowed to cache the answer before it must query again. A TTL of 3600 means a resolver that fetched the record an hour ago should now ask again rather than keep serving its cached copy.

TTL is the entire explanation for why a DNS change is not visible everywhere at once. A resolver that cached the old value five minutes before you changed it will keep serving that old value for up to the record's TTL, not because anything is broken, but because that is exactly what a TTL instructs it to do.

Authoritative versus resolver answers

An authoritative answer comes directly from one of the domain's own name servers, the ones listed in its NS records, and reflects the current state of the zone with no caching involved. A resolver answer comes from a public or ISP-operated resolver, such as a widely used public DNS service, which may be serving a cached copy rather than querying the authoritative servers fresh for every request.

When troubleshooting a recent change, checking the authoritative answer first tells you whether the change actually took effect at the source. If the authoritative servers show the new value but a resolver still shows the old one, the record itself is correct and you are simply waiting on that resolver's cached TTL to expire, not looking at a real misconfiguration.

Reading a multi-record result

A domain commonly has more than one record of the same type at once, and the way to read that depends on the type. Multiple A records are typically all valid simultaneously, used for basic load distribution or redundancy across several servers. Multiple MX records are ordered by priority, lowest first, describing a preference order rather than a simultaneous set to pick from at random.

Multiple TXT records, by contrast, each usually serve an entirely separate purpose, such as one holding an SPF policy and another holding a domain verification code for an unrelated third-party service, and reading them means treating each one independently rather than assuming they combine into a single value.

Wildcard records and negative answers

A wildcard record, written as *.example.test in a zone file, matches any subdomain that has no more specific record of its own, so a lookup for anything.example.test returns the wildcard's value unless a specific record for anything.example.test exists and overrides it. Wildcards are useful for catch-all setups but can also produce a confusing result when a lookup for a hostname you never expected to exist still returns an answer.

A lookup for a name that genuinely does not exist returns an NXDOMAIN response rather than an empty list, which is a meaningfully different outcome from a name that exists but simply has no record of the requested type; the latter returns a successful, empty answer (sometimes described as NODATA) instead. Distinguishing the two matters when debugging, since NXDOMAIN indicates a typo or a domain that was never registered, while NODATA indicates the domain and name are correct but the specific record type queried was never published there.

Reading DNSKEY, DS and RRSIG in a DNSSEC-signed zone

A DNSSEC-signed zone adds three record types to an ordinary lookup: DNSKEY, the zone's public signing keys; RRSIG, a signature over a specific set of records, proving they have not been altered; and DS, published in the parent zone, linking the child zone's DNSKEY back to the wider chain of trust. These do not usually need to be read individually by hand; a DNSSEC validation tool checks the chain and reports whether it is intact, but recognizing the record types when they appear in a raw lookup avoids mistaking them for an unrelated misconfiguration.

SRV, HTTPS and SVCB: records for specific services

SRV records name a specific host and port for a specific service, in the form _service._protocol.example.test, commonly used by things like VoIP or chat protocols that need to advertise where a particular service runs rather than assuming a default port on the domain's main address.

HTTPS and SVCB are newer record types that let a domain advertise connection parameters for a service directly in DNS, such as which port to use or that a connection should attempt HTTP/3, before a client even makes its first request. They are less common in an ordinary lookup today but are increasingly used by content delivery networks and are worth recognizing rather than mistaking for an error when they appear.