DNS Record Lookup

You change a record, wait a little, and ask the internet whether it took. One resolver says yes. Another still hands back the old address. It is tempting to call that a fault, and usually it is nothing of the kind.

The Domain Name System was built to be answered from memory. Almost nobody asks the server that holds a zone directly. Your question goes to a recursive resolver, which keeps every answer it fetches for as long as the answer itself allows, and serves it again to the next person who asks. Two resolvers are two memories, filled at different moments. Comparing them tells you a great deal, but only if you know which differences are about the data and which are only about time.

What comes back when you ask

Every record in a reply carries the same handful of parts: the name it belongs to, its type, its class, a time to live, and the data itself. The DNS specification defines the time to live as an unsigned 32-bit count of seconds for which the record may be cached before it should be thrown away. A value of zero means use it for this one transaction and keep nothing.

The type is a number. The registry kept by IANA lists 1 for an IPv4 address, 28 for an IPv6 address, 15 for a mail exchanger, 16 for text, and 257 for the record that says which certificate authorities may issue for a name. The same registry names the response codes.

Those codes matter more than people expect. A reply with code 0 and no records is not the same as a reply with code 3. Code 3, which the original specification calls a name error and almost everyone now calls NXDOMAIN, says the name does not exist at all, for any type. Code 0 with an empty answer says the name exists but has nothing of the type you asked for; the negative caching standard calls this NODATA and notes that it has to be inferred from the shape of the answer. Mixing the two up sends people hunting for a typo in a name that is perfectly fine.

Even a negative answer has a lifetime. An authoritative server is required to put the zone’s SOA record into the authority section of such a reply, and the time a resolver may remember the absence is the smaller of that record’s own time to live and the last number in its data, the field called MINIMUM. So “it does not exist” can linger for an hour after you create the record.

There are flags as well. The JSON forms offered by public resolvers report them by name. AD, for authenticated data, is the one worth watching: the DNSSEC protocol says a validating resolver should set it only when it considers every record set in the answer authentic. A missing AD bit therefore means the answer was not proved, not that it is false; the zone may simply not be signed.

Why two resolvers can tell you different things

Here is the part that confuses people. The specification describes the time to live of cached data as counting down, while the copy in the zone keeps its constant value. If one resolver fetched your mail exchanger record a minute ago and another fetched it eleven minutes ago, the first reports 3,540 seconds and the second 2,940, for a record published at 3,600. Same record, same data, different ages. Nothing is out of sync except the clocks.

Order is the other false alarm. Records of one name and one type form a set, and the original concepts document says the order of records in a set is not significant and need not be preserved by servers or resolvers. A tool that compares answers line by line will flag a reordered set as a change, and that is exactly the mistake worth designing out: the fair comparison treats each answer as a set and reports order and age separately, as notes.

The disagreements that do mean something are of three kinds. One side has a record the other lacks, the status codes differ, or one side did not answer. The first is what a recent change looks like while old copies expire. The second means they disagree about whether the name, or anything of that type at it, exists at all. The third is a network question rather than a DNS one.

A worked example makes the distinction concrete. The tool on this page opens on a built-in set of answers for example.org, a name reserved for documentation, and makes no request until you press the button; the same example comes back with Show the example.

In that example the first resolver returns 192.0.2.10 with a time to live of 300 seconds, and the second returns 192.0.2.20 with 1,714 seconds left. That is a real difference in data, and it is what a cache still holding an address fetched under an older, longer setting would look like. That copy may be served for up to 1,714 more seconds, about 29 minutes, unless the cache drops it sooner. The two mail exchanger answers in the same example come back in opposite orders with 3,600 and 2,950 seconds left. That pair is the same answer, and the page says so.

Spelling is a quieter trap. Measured on the two services this page asks, one returns names without the final dot and text records as quoted strings, while the other adds the dot and joins the strings. One gives a DNSSEC digest in lower case, the other in capitals. None of that is a difference in the zone. The JSON shape itself is not standardized; one of the providers states plainly that no formal RFC defines it and that it chose to follow the other’s schema.

Reading SPF and DMARC without guessing

Text records are where people read by eye and get it wrong. The mail standards are short enough to read by the rules instead.

An SPF policy is a text record at the domain that begins with exactly v=spf1 followed by a space or nothing; v=spf10 is discarded. If more than one such record exists at a name, the check stops with a permanent error, which receivers treat as a broken policy. Each term after the version is either a mechanism, such as ip4, mx or include, or a modifier such as redirect. A mechanism may carry a qualifier: plus for pass, minus for fail, tilde for softfail and question mark for neutral, with plus assumed when none is written.

The rule that bites most often is the lookup limit. Six kinds of term make the receiver query the DNS while it evaluates your record: include, a, mx, ptr, exists and redirect. The standard caps those at 10 for the whole evaluation, nested includes counted, and past that the answer is a permanent error. Addresses written out with ip4 or ip6 cost nothing. The example record on this page, with two address ranges, one mx and one include, uses 2 of the 10 on its own terms. The included record’s terms are added on top, and a tool that has not fetched that record cannot know how many there are.

Two smaller rules are worth remembering. Anything after all is never evaluated, and a redirect is ignored entirely when all appears anywhere in the record. A record with neither ends in neutral, as if it closed with ?all. And one text record may hold several strings, each at most 255 octets, which a reader must join without adding spaces.

DMARC lives one level down, at a name that starts with _dmarc. The record must begin with v=DMARC1, exactly, and the policy tag p must follow: none, quarantine or reject. Everything else has a default that applies silently when the tag is absent. Alignment for both DKIM and SPF defaults to relaxed, the percentage of failing mail the policy covers defaults to 100, and aggregate reports default to one a day. A record that says pct=50 is asking receivers to apply the policy to half of the failing mail, a cautious step that is easy to forget about.

DKIM keys sit at a selector name under _domainkey. The key record’s p tag holds the public key in base64, and an empty p means the key has been revoked. Its length is not written anywhere in the record; it has to be read from the key. Decoding the structure and counting the bits of the modulus gives the answer exactly. The example key on this page measures 2,048 bits. The DKIM standard requires signers to use at least 1,024 bits for long-lived keys, while an Ed25519 key, added later, is always 256 bits.

What DNS over HTTPS hides, and what it does not

Ordinary DNS crosses the network in the clear. DNS over HTTPS wraps each question in an encrypted, authenticated web request, which defeats passive listening and makes it harder to divert your questions to a rogue server. That is the whole of its promise.

It does not make the resolver forget you. The standard is candid that the client’s IP address is an obvious way to link requests, and that ordinary web features such as cookies or the headers a browser sends could add more. One provider’s documentation adds that its resolver normally forwards an approximate network address to the servers it asks on your behalf, and that a client wanting none of it can send edns_client_subnet=0.0.0.0/0. This page sends exactly that, omits cookies and the referrer, and asks only when you press the button.

There is a quieter detail in how a name is sent. A name typed with accented or non-Latin letters must travel in its ASCII form. Browsers do that conversion as part of parsing any web address, following the URL Standard’s domain to ASCII steps, and the page shows the converted form before it asks.

Know the limits. A public resolver shows what that resolver currently holds, not what your own network’s resolver will answer, and not necessarily what the zone’s own servers say this second. An AD flag says the resolver validated the signatures, not that the records are the ones you meant to publish. And reading SPF on the page checks the record’s grammar and its own lookups, not whether a given server would pass. The page answers a narrower question honestly: what do two well-run caches say right now, and do they agree on the data.