DNS Lookup

Between a few minutes and a couple of days, and the number that decides it is the TTL on the old record rather than anything your registrar does. Every resolver that has already asked for a name keeps that answer for the TTL it was given and serves it until it expires, whatever you have since edited — which is why a change looks live from one office and invisible from another. The lever is to lower the TTL a day before you touch the record, then raise it once the change has landed. Nothing here displays TTLs, so a lookup tells you what is being answered now, not how long the old answer has left.

Because you asked different resolvers and they need not agree. Each caches independently and started its timer at a different moment, so one may still hold the previous address. Large sites also answer differently on purpose: anycast and geographic routing hand out the nearest edge, so two people in different countries get different addresses and both are right. A VPN moves you for the same reason. A lookup run here is a third vantage point again — the query leaves from a server, using whatever resolvers that server is configured with — so a mismatch with your laptop is expected rather than a fault.

An A record maps a name straight to an IPv4 address and AAAA does the same for IPv6. A CNAME instead says this name is another name, so the answer is a hostname and the resolver goes round again. The practical rule is that a CNAME cannot sit alongside other records on the same name, which is why a bare domain cannot have one: the apex must carry NS and usually MX. Providers work around it with ALIAS records or CNAME flattening, resolving on their side and answering with addresses — which is why a flattened apex appears under A here with nothing under CNAME.

They are priorities, shown in brackets after each mail host, and lower wins. A sending server tries the lowest number first and falls back to a higher one only if that host will not take the message, so 10 is the primary and 20 the backup; equal numbers share the load. The values mean nothing on their own — 5 and 500 behave exactly like 1 and 2. Two mistakes recur: leaving an old provider's host in the list at a low priority after a migration, which quietly keeps delivering mail to the wrong place, and pointing an MX record at a name that is itself a CNAME, which the standard does not allow.

Text, and by convention machine-readable text that other systems go looking for. SPF sits at the domain itself, starting v=spf1 and listing which servers may send mail as you. Domain verification strings from Google, Microsoft and others live there too, which is why a busy domain's TXT block reads as a wall of unrelated lines. DMARC and DKIM are TXT records as well, but they live under names beginning with an underscore — _dmarc.example.com, or a selector such as s1._domainkey.example.com — and those names fail the validation here, so they never appear under the bare domain. Long keys are rejoined into one line rather than shown in chunks.

Two different things, and the wording separates them. If the nameservers answered and had nothing — the name does not exist, or exists with no record of that type — the message names the domain and says it may not exist. If the queries failed for another reason, a timeout or a refusal, the message says instead that the resolver did not respond and to try again shortly. The distinction matters because a resolver having a bad minute otherwise looks identical to a domain being unregistered. A registered domain parked with no records is also possible, so only a whois check settles registration.

Not to the domain's owner, in the ordinary case. A record lookup talks to nameservers rather than to the site, so nothing lands in that domain's web logs and no page is fetched. The authoritative nameservers do see a query, but they see it arriving from the resolver that asked — and here the request leaves from a server rather than from your machine. The one thing worth knowing is that a lookup which fails outright is written to the server's error log with the domain you typed, because a resolver outage on the box otherwise looks exactly like every domain at once ceasing to exist. The route writes nothing else and keeps nothing between requests.

Not from a domain lookup — that is a reverse lookup, and it lives in a different tree. An address is rewritten as a name under in-addr.arpa for IPv4 or ip6.arpa for IPv6, and a PTR record there carries the hostname. Only whoever controls the address block can set it, so that is your hosting provider rather than your registrar, and plenty of addresses have no PTR at all. Forward and reverse need not match, and mail is where the mismatch bites: receiving servers often check that a sending address has a PTR resolving back to itself. Only the six forward types are queried here.

A registrar panel records your instruction to the registry; the NS records a lookup returns are what the parent zone is actually delegating to, and the second is what the internet obeys. A change of nameservers goes through the registry and can lag by hours, and a domain that is locked, expired or pending transfer may not have had the change applied at all. Resolvers also cache delegations, so an old pair can survive for a while after the registry has moved on. If the NS block still shows the previous provider, that provider is still answering for you, and editing records at the new one changes nothing anybody can see.