DNS lookup. How to read the result, resolver by resolver

A DNS lookup asks the domain name system what a name resolves to, and the answer comes from a cache rather than from the server that owns the record. That one fact is why two lookups for the same name can differ, and why the result is worth reading rather than glancing at.

You can check a record from four resolvers in each of five regions without an account. This is how to read what comes back.

What a DNS lookup is asking

The record itself lives on the authoritative nameservers for the zone. Those servers are the truth, and they are not what answers you. A lookup goes to a recursive resolver, and the resolver answers from what it already holds. It fetched the record once, kept it for as long as the record's time to live allowed, and it will not ask again until that time is up.

So every result is a statement about one cache at one moment. Why the caches fall out of step, and how to plan around it, is the subject of what DNS propagation actually is. This page is about the result in front of you.

The three figures above the resolver table

Consensus compares the answer sets. Every resolver that answered is asked whether it returned the same set of records, and the result says either that they all agree or how many different sets came back. It is the first figure to read, because it decides whether anything under it is a problem.

Lowest TTL is the shortest remaining time to live that any resolver reported. It is not the TTL you set in your zone. It is how long the quickest-expiring cache in front of you will keep the answer, so a small number here means one resolver is nearly due to ask again.

Regions answered counts the five regions that replied. A region that failed is named underneath rather than folded into the count, because four answers and one timeout is a useful result and hiding the four would be worse than showing them.

The same record with four different TTLs

This is a real lookup for the A record of example.com, run from all five regions at once.

Every resolver in every region returned the same two addresses, so the record is settled and the consensus figure says so. The TTLs are all over the place, from 4 seconds in St Louis to 300 in Frankfurt, and that is not a fault. Each resolver is at a different point in its own countdown, and the number it reports is what is left of it rather than what you configured.

The pairs are worth noticing. Cape Town reports 165 for two resolvers and 268 for the other two, which reads as two cache states rather than four. Resolvers that share an upstream cache or that happened to ask at the same moment show the same remainder, and a resolver that asked earliest has the least left.

The order of the answers is not a disagreement. The two addresses can come back in either order, and the tool compares them as a set. A result where one resolver lists the second address first is the same answer, and reading it as a mismatch is the most common way to misread this panel.

When the resolvers disagree

A consensus other than a single set means part of the internet is still holding an older answer. Two things follow, and the second is the one people get wrong.

The first is that nothing is broken. A resolver serving the old record is behaving correctly, because that is what a cache is for. It will ask again when its copy expires, and the lowest TTL in the result is how long the quickest of them will take.

The second is that editing the record again does not hurry it. A second change resets the clock on the caches that had already picked up the first one, and it makes the result harder to read rather than easier. If the record is right on the authoritative nameservers, the remaining work is waiting.

To confirm that, check the value at your DNS provider rather than in the browser. A resolver in Sydney holding an old answer says nothing about what your zone currently publishes.

When the answer is empty

An empty answer is usually the wrong question rather than a missing record. The name and the record type both have to be right.

A nameserver has NS records and rarely an A record. A mail host answers on MX. A TXT record used for domain verification usually belongs to the exact name you were given, such as a subdomain you were told to create, rather than to the bare domain. Asking for an address at the apex of a zone that uses a CNAME is another version of the same mistake, because a CNAME cannot coexist with the records a zone needs for itself.

There is also a real difference between two kinds of empty that the result does not spell out. A name that does not exist at all and a name that exists but has no record of the type you asked for are different answers, and both are cached. RFC 2308 sets out how long a resolver may hold a negative answer. The period comes from the zone's own start of authority record rather than from the record that is missing, so a record you have just created can appear to be absent for longer than feels reasonable.

What the lookup cannot tell you

It cannot resolve a name that only exists inside your own network. A private name is answered by a resolver we cannot reach, and the public resolvers return nothing, so private and reserved addresses are refused rather than looked up.

It is not a security check. It does not validate DNSSEC signatures and it does not report whether a zone is signed, so a correct result here is not evidence that the answer was authenticated.

It also cannot know what you intended. The record it returns may be exactly the one you asked for and still be wrong, because nothing in the domain name system knows which address your website should be on.

And it says nothing about what happens afterwards. Mail being delivered, a page loading and a certificate being trusted are all separate from whether the record is published and visible.

What to do with the result

A single answer set across all five regions needs nothing. The change has reached everywhere this tool can see, and there is no cache left to wait for.

A disagreement needs patience and a look at the authoritative value, in that order. Read the lowest TTL first, because it tells you whether minutes or hours are left.

An empty answer needs the record type and the exact name checked against the instructions you were given. If both are right and it is still empty, the record is not published where the lookup is being answered from, which is a question for whoever runs your DNS.