Frequently Asked Questions

The DNS Lookup tool performs full recursive resolution through the DNS hierarchy, from the root servers to the domain's authoritative nameservers. It bypasses caching layers to retrieve live DNS records exactly as they exist at the source. The tool returns all major record types (A, AAAA, CNAME, MX, TXT, NS, SOA) plus DNSSEC records (DS, DNSKEY, RRSIG, etc.), along with a full resolution trace showing per-hop latency and packet size. It delivers a comprehensive view of DNS for administrators, developers, and anyone who needs to troubleshoot with precision.

A DNS Lookup could be the move when you need to diagnose the root of a website problem (spoiler: it's always DNS). It is a crucial step when making DNS changes that can break things – waiting 48 hours is never a good strategy. Use it to cut through your ISP cache, the funky office VPN, and those "is it down or just me" guesses. Whether you're troubleshooting website connectivity, planning a big migration, verifying domain ownership with TXT records, or setting up email authentication with SPF/DKIM, this tool gives you the real answers – straight from the authoritative source.

Unlike command-line tools that only return one record type at a time, our 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.

WHOIS is like a dusty phonebook for the internet. When you perform a WHOIS query it pulls details about domain registration, ownership, creation/expiration dates, DNS servers, and whatever contact data hasn't been scrubbed for privacy. It's important to understand that WHOIS is a protocol like HTTP, not a central database, so the information in each response can vary wildly between different registries (TLDs) and registrars (GoDaddy, Namecheap, etc).

Use WHOIS to find out who owns a domain, check its expiration date and current status, and identify the registrar who manages it. It's a fundamental tool for developers, domain investors, security teams, IP enforcement, and anyone needing to contact a domain owner for business or legal reasons. A WHOIS lookup is the usual first step in due diligence. If the WHOIS response is broken or unhelpful, try RDAP for more structured data.

WHOIS is the legacy text protocol for querying domain registration data – inconsistent but still widely used. RDAP (Registration Data Access Protocol) is its modern successor, designed to provide data in a more standardized and predictable format. These days (in the year 2025), it's best to start with an RDAP Lookup for more reliable data; then fall back to WHOIS if the registry hasn't implemented RDAP.

Privacy laws (like GDPR) and registrar policies have cleared out most public WHOIS contact records since 2018. Most registrars hide contact info by default now, and you'll see anonymized proxy emails and 'REDACTED FOR PRIVACY' almost everywhere. Some registrars do offer a forwarding service or web forms to contact the owner. For legitimate legal requests, you'll need to contact the registrar directly with the right documentation.

The WHOIS standard dates back to 1984(!) and has never had strict formatting rules. Each registry seems to do its own thing; dates in every which way, fields in random order. Some use key-value pairs, while others write some kind of interpretive poetry. We do our best to parse and normalize this mess so you don't have to.

Expiration dates can differ between the registry and the registrar, especially for registrars that auction off their expired names. After expiry, most domains go through a 30-45 day "grace period", followed by an additional ~30 day "redemption period", where the owner can still renew (at a premium). A domain status of "pending deletion" means the domain is close to being released and should soon be available for registration.

No, WHOIS is only for registration info, not DNS data. To find the IP address for a domain, you can use our DNS Lookup tool. The WHOIS record will tell you the nameservers (NS) for the domain, which you can then query to get the A records for the IP address.

Domain status codes (aka EPP status) describe a domain's current state and any security locks. They control whether a domain can be transferred, updated, deleted, or resolved in DNS. Multiple codes can apply at once, and some are set by the registrar ("client") while others are enforced by the registry ("server").

• ok – No restrictions, domain is active, nameservers are configured. Can be updated, transferred, or deleted.
• active – Registered and nameservers configured; may have other restrictions.
• inactive – Registered but not resolving due to no nameservers or hold.
• clientTransferProhibited – Registrar lock blocking transfers. Must be removed before transfer.
• serverTransferProhibited – Registry-applied lock blocking transfers. Requires registry approval to remove.
• clientDeleteProhibited – Registrar-applied lock preventing deletion (including transfer to another registrar). Used to protect important domains.
• serverDeleteProhibited – Registry-applied lock preventing deletion; cannot be removed by the registrar alone.
• clientHold – Registrar suspension that removes the domain from DNS. Common causes: unpaid renewal, invalid/expired WHOIS data, abuse complaints.
• serverHold – Registry suspension that removes the domain from DNS. Common causes: abuse or policy violations, legal disputes.
• redemptionPeriod – (30-45 days) Domain has expired and been removed from DNS, but can be restored by the original owner (for a fee).
• pendingDelete – (5 days) Final deletion stage after redemption. Cannot be restored by owner.
• pendingTransfer – Transfer in progress; no modifications allowed.
• pendingRestore – Restoration requested after redemption; not yet complete.
• renewPeriod – Automatic renewal grace period after successful renewal.
• pendingUpdate – A change (e.g., contact info, nameservers) is in progress; not yet finalized in the registry.

RDAP (Registration Data Access Protocol) is the designated successor to WHOIS, but is it not fully adopted by all domain registries. It provides a more structured format for information about domain names, IP addresses, and ASNs, with standardized fields and proper Unicode support. It's essentially the same (mostly redacted) data from a WHOIS lookup, just now in beautiful JSON with predictable formatting.

RDAP is the new standard for domain lookups. It's designed to fix the inconsistencies that have plagued the WHOIS system for (40) years. No more parsing nightmares because every registry has decided to reinvent the contact field. Instead of plain text, RDAP returns structured JSON responses over HTTPS. It can include additional details like entity relationships, role definitions, and event timelines – making it much more reliable for automation. Think of it as WHOIS revamped as a modern API – it's mostly the same source data but with a more user-friendly format.

Try RDAP first. If it's not supported then fall back to WHOIS. RDAP is officially the future according to ICANN, but in reality you'll probably need both since coverage isn't 100% yet. WHOIS still works, but it is often inconsistent and quite brittle. For most use cases today (it's 2025), RDAP should be the first choice, and increasingly required as many registries deprecate WHOIS access.

Not really. It's usually the same source data, just in a better format. Some registrars may provide slightly different sets of data through each protocol, but the core registration data should be identical. Privacy protection still redacts the same fields. As RDAP adoption grows, it will become the primary source for this information across all registries.

Nope. RDAP follows the same privacy rules as WHOIS. If the domain is using privacy protection, RDAP will return the same redacted or proxy information that you'd see in a WHOIS record.

In an official sense, yes. ICANN considers WHOIS deprecated since Jan. 2025, and RDAP is mandatory for new gTLDs. In reality both systems are still in use but the level of support varies. Some registries have already shutdown their WHOIS servers, while others are sending deprecation notices with each response. Who knows, WHOIS may just outlive us all.

Coverage is growing steadily and most major TLD registries now support RDAP, including .com, .net, .org, and many country-code TLDs. ICANN required new gTLD registries to support RDAP starting in 2019, but ccTLDs live by their own rules. These registries are often run by small government departments or academic institutions, which can mean slower progress. You can track the progress of RDAP support amongst registries on RDAP.ORG.

RDAP outputs all contact info using jCard, which is an overly complex JSON version of vCard. Each contact field is a typed array element, so it's an array of arrays, because a simple object would be too easy. It's like they asked "how can we make contact data as unreadable as possible" and jCard was born. Here's a great resource on jCard and everything else you might want to know about RDAP.

Yes, RDAP is not just for domains. You can also look up IP addresses or ASNs (Autonomous System Numbers). Each major RIR (Regional Internet Registry), e.g. ARIN, RIPE, or APNIC, runs its own RDAP service. An Autonomous System Number may sound like dystopian jargon, but it's just a unique identifier for large ISPs and other network operators on the global internet routing table.

RDAP servers sometimes use HTTP redirects (3xx) to send clients to a different authority, especially after a domain has been transferred.

Referrals are a way to link to other servers or resources, usually pointing from the registry (who owns the domain) to the registrar (who manages it). Starting from one of the bootstrap servers, you will get referral links that lead to the correct authoritative endpoint. Follow the yellow brick road (referral chain) and you'll eventually find the Wizard (authoritative data). It's like how nameserver delegation works in DNS, but for registration/ownership info.

Domain status codes (aka EPP status) describe a domain's current state and any security locks. They control whether a domain can be transferred, updated, deleted, or resolved in DNS. Multiple codes can apply at once, and some are set by the registrar ("client") while others are enforced by the registry ("server").

• ok – No restrictions, domain is active, nameservers are configured. Can be updated, transferred, or deleted.
• active – Registered and nameservers configured; may have other restrictions.
• inactive – Registered but not resolving due to no nameservers or hold.
• clientTransferProhibited – Registrar lock blocking transfers. Must be removed before transfer.
• serverTransferProhibited – Registry-applied lock blocking transfers. Requires registry approval to remove.
• clientDeleteProhibited – Registrar-applied lock preventing deletion (including transfer to another registrar). Used to protect important domains.
• serverDeleteProhibited – Registry-applied lock preventing deletion; cannot be removed by the registrar alone.
• clientHold – Registrar suspension that removes the domain from DNS. Common causes: unpaid renewal, invalid/expired WHOIS data, abuse complaints.
• serverHold – Registry suspension that removes the domain from DNS. Common causes: abuse or policy violations, legal disputes.
• redemptionPeriod – (30-45 days) Domain has expired and been removed from DNS, but can be restored by the original owner (for a fee).
• pendingDelete – (5 days) Final deletion stage after redemption. Cannot be restored by owner.
• pendingTransfer – Transfer in progress; no modifications allowed.
• pendingRestore – Restoration requested after redemption; not yet complete.
• renewPeriod – Automatic renewal grace period after successful renewal.
• pendingUpdate – A change (e.g., contact info, nameservers) is in progress; not yet finalized in the registry.