DNS Lookup

Unlike command-line tools dig and nslookup which only return one record type at a time, this tool queries for all common DNS record types in parallel and performs full recursive resolution from the root servers down to the domain's authoritative nameservers, complete with a diagnostic trace showing per-hop latency. It's like running a whole suite of dig +trace commands for every record type, but with a user-friendly web interface that doesn't require memorizing command-line syntax.

The DNS Lookup tool supports a comprehensive set of record types, including a special ALL query that fetches the most common and critical record types in a single request.

Here are all the officially supported DNS record types:

• SOA - Contains administrative information about a DNS zone
• NS - Specifies which name servers are authoritative for a domain
• A - Maps domain names to IPv4 addresses
• AAAA - Maps domain names to IPv6 addresses
• CNAME - Creates an alias that points one domain name to another
• DNAME - Redirects an entire subdomain tree to another domain
• MX - Directs email to mail servers with priority settings
• TXT - Stores text information for verification, SPF, DKIM, and other purposes
• CAA - Controls which certificate authorities can issue SSL certificates
• TLSA - Associates SSL certificates with domain names (DANE)
• DS - Delegation signer that enables DNSSEC for subdomains
• DNSKEY - Public key used for DNSSEC validation
• RRSIG - Digital signature that validates other DNS records (DNSSEC)
• NSEC - Proves that certain DNS records do not exist (DNSSEC)
• NSEC3 - Enhanced NSEC with hashed domain names for privacy (DNSSEC)
• NSEC3PARAM - Parameters for NSEC3 hashing algorithm (DNSSEC)
• CDS - Child DS record for secure domain transfers
• CDNSKEY - Child DNSKEY record for secure domain delegation
• KEY - Legacy security key record (replaced by DNSKEY)
• SIG - Legacy digital signature record (replaced by RRSIG)
• SRV - Specifies the location of services like email or chat servers
• HTTPS - HTTPS service binding for secure web services
• SVCB - General-purpose service binding record
• CERT - Stores digital certificates and cryptographic keys
• HINFO - Host information including CPU and operating system details
• TSIG - Authenticates DNS messages between servers
• OPENPGPKEY - OpenPGP public key for email encryption
• RP - Responsible person contact information for a domain
• SSHFP - SSH host key fingerprints for secure connections
• URI - Maps domain names to Uniform Resource Identifiers
• NAPTR - Maps domain names to services like phone numbers or URIs
• LOC - Geographical location information for a domain
• PTR - Maps IP addresses back to domain names for reverse DNS

DNS Propagation is a misleading term – nothing actually "propagates" across the internet. Instead, thousands of recursive resolvers worldwide independently cache your DNS records, each for as long as your TTL (Time To Live) allows. When you update a record, authoritative nameservers show the change immediately, but cached copies must expire before resolvers fetch the new data. A high TTL (e.g. 24 hours) means some resolvers will continue to serve old data for that long, creating the illusion of slow propagation. Most updates today settle within minutes to a few hours; the infamous "48-hour propagation" was a relic from the days when everyone used 48 hour TTLs by default.

TTL (Time To Live) is the number of seconds a DNS answer may be cached by resolvers before they must re‑query the authoritative server. Each DNS record carries its own TTL, and caches honor the value they previously received until it expires. The TTL value you set represents a trade-off between performance and agility:

• Higher TTLs (e.g. 24 hours) reduce the query load on your authoritative nameservers and speed up lookups for repeat visitors through local caching, but they also extend the "propagation" time for changes, delaying the visibility of DNS updates.
• Lower TTLs (e.g. 5 minutes) allow for faster updates, but increase the number of queries your nameservers must handle.

When planning DNS changes, lower TTLs ahead of time, make the change, then raise them again. If updates seem stuck, check the prior TTL, flush DNS caches, and compare authoritative answers to public resolvers. Some resolvers enforce minimums, so ultra‑low TTLs (like 30s) may be rounded up.

• Authoritative servers are the definitive source of truth for a DNS zone. They host the actual records (the master copies) and always return the current configuration. When a domain owner updates their DNS records, the changes are made on the authoritative servers and take effect there immediately.
• Recursive resolvers (run by your ISP, workplace, or a public DNS provider) fetch DNS answers by following the DNS hierarchy – starting at the root servers, then TLD servers, and finally the authoritative servers. They cache the results for the period defined by each record's TTL. This caching speeds up lookups but can cause outdated answers to linger until the TTL expires, creating the illusion of slow "propagation."

For troubleshooting, remember: recursive servers may serve stale data, but authoritative servers always return the current configuration. Our DNS Lookup tool queries authoritative servers directly by default, bypassing caching layers.

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, preventing tampering and forgery. When DNS was first created, it had no built-in security, making it vulnerable to cache poisoning and man-in-the-middle attacks. DNSSEC addresses this by creating a chain of trust from the root servers down to individual domains, digitally signing each layer of the hierarchy so DNS responses can be verified as authentic.

Our DNS Lookup tool displays all DNSSEC-related records (DS, DNSKEY, RRSIG, NSEC/NSEC3) alongside the regular answers so you can see whether signing is in place, but it doesn't perform full cryptographic validation. For complete end-to-end verification of the chain of trust, use the dedicated DNSSEC Tool.

Because DNS is a fragile house of cards, a spindly web held together by RFCs, glue records, and tribal knowledge. It's invisible when working and catastrophic when broken. When your website is down or your email bounces, start with DNS. It's probably DNS. It's always DNS.