🌐 DNS-opzoeking

About DNS and DNS lookups

The Domain Name System is the internet's directory. Humans use names such asippigeon.co.uk; routers and switches only understand numeric addresses. DNS is the distributed database that translates between the two — and it carries a great deal more than addresses, including where your email should be delivered, which certificate authorities may issue certificates for your domain, and arbitrary text used to prove domain ownership.

A lookup is not one question but a chain of them. A recursive resolver (the one your ISP hands you, or a public one like Cloudflare's 1.1.1.1) starts at the root servers, is referred to the servers for the top-level domain such as.uk, is referred again to the authoritative name servers for the domain itself, and only then gets the real answer. It caches that answer so it does not have to repeat the walk. This tool asks a public resolver over DNS-over-HTTPS, so what you see is what that resolver currently holds or has just fetched.

What each record type is for

• A (type 1) — maps a name to a single IPv4 address. A name can have several A records; clients pick one, which is the crudest form of load balancing.
• AAAA (type 28) — the IPv6 equivalent. The name comes from an IPv6 address being four times the size of an IPv4 one, hence four As. A dual-stack host publishes both A and AAAA.
• CNAME (type 5) — a canonical-name alias. www.example.commay be a CNAME to example.com. A name with a CNAME cannot hold other record types, which is why you cannot put a CNAME at the apex of a zone (providers work round this with proprietary ALIAS or flattening records).
• MX (type 15) — mail exchange. Each record has a preference number and a hostname; lower numbers are tried first. Equal preferences are used round-robin. If a domain has no MX records, senders fall back to its A record.
• TXT (type 16) — free-form text, in practice the dumping ground for policy. SPF (v=spf1 …) lists who may send mail as you, DKIM publishes signing keys under selector._domainkey, DMARC sits at_dmarc, and countless services ask you to add a verification string.
• NS (type 2) — the authoritative name servers for the zone. This is what a registrar changes when you "point the domain" somewhere new.
• SOA (type 6) — start of authority. One per zone. It names the primary name server and the zone administrator's email address (with the first dot standing in for the @), and carries the serial number plus the refresh, retry, expire and minimum timers that govern how secondary name servers stay in step. The final value also sets how long negative answers (NXDOMAIN) may be cached.
• CAA (type 257) — certificate authority authorisation. Lists which CAs are allowed to issue certificates for the domain. Public CAs are obliged to check it, so a CAA record is a cheap defence against mis-issuance.
• PTR (type 12) — reverse DNS: address to name. It lives in thein-addr.arpa (IPv4) or ip6.arpa (IPv6) tree, so8.8.8.8 is really a query for8.8.8.8.in-addr.arpa. Mail servers weigh matching forward and reverse DNS heavily when deciding whether you are a spammer. This tool builds the reverse name for you — just type the IP address.
• SRV (type 33) — service location, used by SIP, XMPP, Minecraft, Microsoft 365 autodiscover and others. The name is structured as_service._protocol.domain, and the data is priority, weight, port and target host.

What TTL actually means

Every record carries a time-to-live in seconds. It is not an expiry date on the record itself — it is an instruction to everyone downstream saying "you may keep this answer in your cache for at most this many seconds." A record with a TTL of 3,600 may be served from a resolver's cache for up to an hour before that resolver asks the authoritative servers again.

The TTL this tool reports is the resolver's remaining TTL, counting down, not the value configured in the zone. Look up the same name twice a few seconds apart and you will usually see the number drop. When it reaches zero the resolver discards the entry and the next query fetches a fresh copy at the full configured TTL.

• Short TTLs (60–300s) — fast to change, but more queries and a little more latency. Use them ahead of a planned migration.
• Medium TTLs (1–4 hours) — the usual default; a sensible balance.
• Long TTLs (24 hours or more) — efficient and resilient for records that never move, such as NS or CAA, but painful if you need to change them in a hurry.

"DNS propagation" is a myth

Nothing propagates. When you edit a record, the change is written to your authoritative name servers and it is live there instantly — you can prove that by querying those servers directly. What takes time is the rest of the world forgetting the old answer. Every resolver that already cached the previous record keeps serving it until its copy of the TTL runs out, and each one started its countdown at a different moment.

That is why a change appears to arrive at different times in different places, and why the worst case is roughly the old TTL — the value that was in effect before you made the change, not the new one. Lowering a TTL after the fact does not help; you have to lower it in advance.

The practical recipe for a move without downtime:

• Drop the TTL on the records you intend to change to 300 seconds, and wait for the old TTL to elapse in full — if it was 24 hours, wait a day.
• Make the change. Caches now clear within five minutes.
• Keep the old server answering for a while anyway, because some resolvers ignore short TTLs and impose a floor of their own.
• Once traffic has moved, put the TTL back up.

Nameserver (NS) delegation changes are the slow exception. Those are cached at the registry with TTLs typically measured in days, and you cannot shorten them, so a registrar-level nameserver change genuinely does take up to 48 hours to settle everywhere.

Reading the response code

• NOERROR (0) — the query worked. Note that this does not mean records were found: a name can exist with no records of the type you asked for, which returns NOERROR and an empty answer section.
• FORMERR (1) — the resolver could not parse the query.
• SERVFAIL (2) — the lookup broke. Usually the authoritative servers are unreachable or DNSSEC validation failed. A SERVFAIL on a domain that works elsewhere is a strong hint of a DNSSEC misconfiguration.
• NXDOMAIN (3) — the name does not exist at all, at any type. The Authority section of an NXDOMAIN reply carries the SOA of the closest enclosing zone, which tells you who is denying it and how long the negative answer will be cached — this tool shows it for exactly that reason.
• REFUSED (5) — the server declined to answer, usually a policy decision rather than a fault.

Notes on this tool

• Queries go over DNS-over-HTTPS to Cloudflare (1.1.1.1) or Google (8.8.8.8) — pick whichever you prefer, and compare the two when you suspect a caching problem.
• You are seeing that resolver's cached view, not the authoritative zone. To read the zone itself, look up its NS records and query one of those servers directly.
• Results are ordered as the resolver returned them, except MX records, which are sorted by preference so the primary mail server appears first.