DNS Lookup

Query the global directory service that translates human-readable names into the addresses and metadata that networks actually use.

TL;DR

DNS (Domain Name System) is the lookup service that turns names like example.com into IP addresses, mail server hostnames, text records, and other metadata. A DNS query asks an authoritative server for one specific record type and returns whatever that server holds.

What it is

The Domain Name System is the internet's distributed directory. Without it, every connection would need a numeric IP address. With it, you type a name, your resolver finds the answer, and the connection proceeds.

DNS is hierarchical. The root (.) delegates to top-level domains (.com, .co.uk, .org), which delegate to registered domains (example.com), which can delegate further to subdomains. Each zone has authoritative name servers that hold the records for that zone.

A DNS query is a one-shot exchange: ask for a name and a record type, receive an answer or a referral. The protocol runs over UDP for most queries and falls back to TCP for large responses or zone transfers.

How it works

A typical resolution path:

1. Client asks its recursive resolver (often run by an ISP, Cloudflare 1.1.1.1, or Google 8.8.8.8) for www.example.com type A
2. Resolver checks its cache. If fresh, it answers immediately
3. If not cached, resolver asks a root server which TLD server handles .com
4. Resolver asks the .com TLD server which name servers handle example.com
5. Resolver asks the authoritative name server for example.com what www.example.com resolves to
6. Authoritative server returns the answer with a TTL (cache lifetime)
7. Resolver caches the answer and returns it to the client

Each record has a TTL in seconds. Low TTLs (60 to 300) allow fast changes. High TTLs (3600 to 86400) reduce query load but slow propagation.

Common record types

When to use it

• Confirm a domain resolves to the address you expect
• Verify DNS changes have propagated globally
• Inspect MX records when email is failing
• Read TXT records for SPF, DKIM, DMARC, or ownership verification
• Check NS records when delegation looks wrong
• Pull AAAA records to confirm IPv6 readiness
• Inspect CAA records when a certificate issuance is being blocked
• Reverse-lookup an IP via PTR

Running it on networktoolkit.io

Select dns, enter a hostname, pick a record type (a, aaaa, mx, txt, ns, cname, soa, ptr, srv, caa), and the query fires from each of our distributed workers. Different workers may use different upstream resolvers, so you can spot inconsistent or stale records globally. Sample output for an A record query:

;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; Query time: 18 msec
;; SERVER: 1.1.1.1#53
;; WHEN: Mon Sep 23 14:22:01 UTC 2025
;; MSG SIZE  rcvd: 56

Sample output for an MX query:

;; ANSWER SECTION:
example.com.            3600    IN      MX      10 mail1.example.com.
example.com.            3600    IN      MX      20 mail2.example.com.

Reading the results

For MX records, the leading integer (10, 20) is the priority. Lower is preferred.

Common scenarios

Limitations & gotchas

• Caching is everywhere. A change to a record will not appear globally until every resolver's cached copy expires. Lower the TTL before making changes.
• CNAMEs cannot coexist with most other records at the same name. You cannot put a CNAME at a zone apex (example.com itself); use ALIAS or ANAME at providers that offer them.
• Reverse DNS (PTR) is managed by the IP holder, not the domain holder. You usually cannot set your own PTR without your hosting provider or ISP.
• TXT records have length limits. Single strings are capped at 255 characters; longer values are split into multiple concatenated strings.
• DNSSEC validation failures appear as SERVFAIL, not a clear DNSSEC error. Check resolver logs to confirm.
• Negative caching means an NXDOMAIN is also cached, so a newly created record may not appear immediately even though the name now exists.

Security & privacy notes

DNS queries are unencrypted by default and visible to any on-path observer, including your ISP. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt queries between client and resolver. They do not encrypt queries from the resolver to authoritative servers.

DNSSEC (RFC 4033 to 4035) signs records so resolvers can verify authenticity. It protects against forged answers but does not encrypt traffic or hide query content.

TXT records often contain operational secrets in plain sight: SPF rules reveal mail infrastructure, DKIM selectors reveal signing key rotation, domain verification tokens reveal which third-party services a domain uses.

Standards & references

• RFC 1034 — Domain Names, Concepts and Facilities
• RFC 1035 — Domain Names, Implementation and Specification
• RFC 2181 — Clarifications to the DNS Specification
• RFC 4033–4035 — DNS Security Extensions (DNSSEC)
• RFC 7858 — DNS over TLS
• RFC 8484 — DNS over HTTPS
• RFC 8659 — DNS Certification Authority Authorization (CAA)

FAQ

Why does the same DNS lookup return different answers from different locations?

Either propagation is still in progress after a recent change, the domain uses geo-aware DNS that returns location-specific answers, or some resolvers still hold a cached older value.

What is TTL and why does it matter?

Time To Live is the number of seconds a record can be cached. Low TTLs let you change records quickly; high TTLs reduce query load and improve resilience. Lower TTLs ahead of any planned change.

Can a domain have both A and AAAA records?

Yes. Dual-stack hosts publish both, and the client picks whichever protocol it has connectivity for, usually preferring IPv6 when available (per Happy Eyeballs, RFC 8305).

What does NXDOMAIN mean?

The authoritative server confirmed the name does not exist. SERVFAIL, by contrast, means the resolver could not determine whether it exists.

Is DNS encrypted?

Not by default. DNS over HTTPS and DNS over TLS encrypt the link between client and recursive resolver. Authoritative DNS traffic remains largely unencrypted.

What is the difference between a recursive resolver and an authoritative server?

A recursive resolver does the legwork of chasing referrals to find an answer. An authoritative server holds the actual records for a zone and answers questions about it directly.