DNS Lookup Tool Online

The eight record types you actually reach for

DNS is a key-value store keyed on a (name, type) pair, which is why a lookup makes you pick one type at a time. The types you meet in practice:

• A maps a name to a 32-bit IPv4 address. A browser resolves this before it can open a connection.
• AAAA is the IPv6 equivalent, a 128-bit address. A host can publish both; clients choose per the Happy Eyeballs algorithm.
• CNAME is an alias meaning “for every type, go look up this other name instead.” It is a redirect at the DNS layer, not an address.
• MX lists mail servers, each with a priority number — lower wins, equal numbers share load. An MX must point to a hostname with an A/AAAA record, never to an IP and never to a CNAME.
• TXT holds free-form text, now the workhorse for SPF, DKIM, DMARC, and domain-ownership verification tokens.
• NS names the authoritative name servers for the zone — the servers a resolver follows down from the root.
• SOA (Start of Authority) is a single record per zone holding the primary name server, the zone serial, and the timers that govern secondaries and negative caching.
• CAA declares which certificate authorities may issue certificates for the name. A CA is required to check it before issuing; with no CAA record, any public CA may issue.

“DNS propagation” is a myth — you are waiting for caches to expire

Nothing propagates. When you change a record, your authoritative server serves the new value immediately. The delay comes from resolvers all over the internet that cached the old answer, each holding it until its TTL (time to live, in seconds) counts down to zero. There is no push, no broadcast, no update flooding outward — only independent caches expiring on their own schedules.

The practical consequence: lower the TTL before a migration, not during it. If a record sits at a one-hour TTL and you drop it to 300 seconds an hour ahead of the cutover, resolvers will be re-fetching every five minutes by the time you flip the value, so the change is picked up in minutes instead of an hour. Lowering the TTL after you have already changed the record does nothing for caches still holding the old high-TTL answer. This is also why “it works for me but not for my colleague” is normal mid-change — you are hitting different resolvers whose caches expired at different times.

Why you cannot CNAME your root domain

A CNAME is special: the standard says a name that owns a CNAME may own no other records. That rule collides with reality at the zone apex (the bare example.com), because the apex is required to carry an SOA record and NS records. Those cannot coexist with a CNAME, so a CNAME at the apex is invalid — many DNS providers will simply refuse to save it.

This is why you cannot point example.com straight at a load balancer or CDN hostname the way you can with www.example.com. The workarounds are provider features called ALIAS, ANAME, or CNAME flattening: the provider resolves the target hostname itself and answers apex queries with the resulting A/AAAA records, giving you CNAME-like behaviour while still returning a plain address record. The flattening happens on the server, so a lookup of the apex shows A records, not a CNAME.

A missing record is cached too

Caching is not just for answers. When a resolver receives an NXDOMAIN (the name does not exist) or an empty answer for a type, it caches that negative result as well. The lifetime is governed by the minimum field of the zone's SOA record, not by the TTL of the record you were hoping to see.

That is the usual explanation for “I just created the record but the lookup still says it doesn't exist.” A resolver asked a moment before you published, got nothing, and is now honouring the negative cache. It is worth checking the SOA minimum before a launch for the same reason you lower a record's TTL: it bounds how long an absence sticks around.

What this tool actually queries

This page uses DNS over HTTPS against Google's public resolver (dns.google) and shows you the raw JSON it returns. Two things follow. First, the domain and record type you enter are sent to Google's resolver — the lookup does not run purely in your browser, because browsers have no way to speak the DNS protocol directly. Second, you are seeing a resolver's answer, which may be served from its cache, complete with a TTL field counting down the remaining cache lifetime. It is not necessarily a fresh answer straight from the domain's authoritative name servers. For most troubleshooting that is exactly what you want — it is the same view a real client gets — but if you are chasing a change you just made, a cached resolver answer is precisely the thing that can mislead you.