Every query you run on this page is a DNS-over-HTTPS request from your browser directly to a public resolver. Mungomash never sees the domain you typed — there is no server-side code involved on this page. Two providers are queried in parallel for each record type so we can show you when they disagree.

DNS-over-HTTPS (DoH, defined in RFC 8484) is the same DNS protocol carried inside an HTTPS request. The traditional UDP-on-port-53 channel is unencrypted — anyone on the network path can see and tamper with the questions and answers. DoH wraps each query in TLS, so the lookup is private from the network and the resolver sees only what your browser would send anyway.

The two providers used here:

• Cloudflare via cloudflare-dns.com/dns-query — the JSON DoH endpoint Cloudflare runs alongside the well-known 1.1.1.1 resolver.
• Google via dns.google/resolve — Google Public DNS's JSON DoH endpoint, the public-resolver counterpart to 8.8.8.8.

If a record set differs between the two — say the TTL has just changed and one resolver still has the old value cached — the page will say so under the lookup form. A small disagreement during a propagation window is normal; a sustained disagreement usually means the authoritative DNS configuration is genuinely inconsistent.

A DNS record is a labeled piece of data attached to a name. The label says what kind of answer it is. The eight types this page resolves:

• A — IPv4 address. The most common record type. example.com A 93.184.216.34 means "the IPv4 address for example.com is 93.184.216.34."
• AAAA — IPv6 address. Same idea, the IPv6 sibling of A. Read aloud as "quad-A."
• MX — Mail exchanger. Tells the world where to deliver email for the domain. Each MX record carries a priority (lower wins) and a target hostname.
• TXT — Free-form text. The catch-all record — often used for domain-ownership verification, SPF (which mail servers may send for the domain), and DMARC (what to do with mail that fails authentication).
• NS — Authoritative name servers. The DNS servers responsible for the domain — the canonical answer to "who do I ask about this domain?"
• CNAME — Canonical name (alias). Maps one name to another — www.example.com CNAME example.com means "look up the right side instead."
• SRV — Service location. Tells clients where (host + port) and at what priority/weight a particular service runs. Used by SIP, XMPP, Minecraft servers, and others.
• CAA — Certification Authority Authorization. Limits which TLS certificate authorities are allowed to issue certificates for the domain.

Email authentication on the modern internet rests on three DNS records that work together. When you look up a domain's TXT records on this page, this site detects SPF and DMARC and breaks them down into their pieces.

SPF (Sender Policy Framework) — a TXT record on the domain itself, starting with v=spf1. It lists which IPs and other domains are allowed to send mail "from" this domain. Receivers reject (or quarantine) mail from anyone not on the list. Defined in RFC 7208.

DKIM (DomainKeys Identified Mail) — TXT records under _domainkey sub-labels (typically selector._domainkey.example.com). Each record is a public key. Outgoing mail is signed with the matching private key, and receivers verify the signature against the published public key. Defined in RFC 6376.

DMARC (Domain-based Message Authentication, Reporting & Conformance) — a TXT record at _dmarc.example.com, starting with v=DMARC1. It tells receivers what policy to apply to mail that fails SPF or DKIM (none / quarantine / reject) and where to send aggregate reports. Defined in RFC 7489.

Together: SPF says "these IPs are authorized," DKIM says "this signature proves the message wasn't altered in transit," and DMARC says "if both fail, here's what to do, and please tell me about it." A domain that's serious about deliverability publishes all three.

• No "dig +trace" mode. Authoritative-server traversal — walking from the root down through TLD servers — adds substantial complexity and is mainly useful when debugging a delegation. People who genuinely need it will use dig.
• No global propagation map. Some lookup sites query 20 geographic resolvers and put pins on a world map. It's eye-catching but mostly a re-statement of resolver caching behavior. Two-provider disagreement is the meaningful signal during propagation.
• No reverse DNS / PTR records. Reverse lookup goes from an IP back to a name and uses a different query shape (in-addr.arpa / ip6.arpa). It belongs alongside ASN lookup, not domain lookup.
• No saved query history. The page keeps no record of what you looked up. There is no client-side storage of others' domains.