Querying a domain looks simple but actually involves three distinct protocols — WHOIS, RDAP and DNS — and dozens of tools. Finding out who owns a domain, when it expires, reading MX records or discovering hidden subdomains all require different methods. This page focuses on practical commands, the right endpoints and how to interpret what comes back.
If you need the fundamentals (TLDs, registrars, registries) start with our domain names guide. For how DNS actually resolves, see DNS basics. This article answers the how do I query question.
Related guides: What is DNS, settings · Domain names & WHOIS lookup · Hosting types guide · Nginx configuration · Plesk panel guide
Three Protocols: WHOIS, RDAP and DNS
Domain lookup actually pulls data from three independent sources. WHOIS and RDAP return registration data (creation date, registrar, registrant contacts). DNS returns operational data (server IPs, mail routing, verification records). They are complementary, not interchangeable.
WHOIS is a plain-text protocol from 1982, defined in RFC 3912. It sends a query over TCP port 43 and the server returns free-form text. There is no standard output format — every registrar uses its own, which makes writing automated parsers painful.
RDAP (Registration Data Access Protocol) is the modern successor. RFC 9082 and RFC 9083 specify JSON-structured responses, HTTPS transport and standard error codes. ICANN has required gTLD registrars to support RDAP since 2018; on January 28, 2025 WHOIS was officially retired and RDAP became the sole standard.
DNS is what actually runs the domain. Record types — A, AAAA, MX, NS, TXT, CAA, DNSKEY — determine how the name resolves, where mail goes and which CAs may sign certificates. The three most common query tools are dig, nslookup and host.
dig: The Standard DNS Query Tool
dig (Domain Information Groper) ships with BIND and is documented in the official BIND9 manual pages. Its output is parser-friendly, you can target authoritative servers directly and DNSSEC validation is built in. On Linux/macOS it ships with bind-utils or dnsutils; on Windows use the BIND installer or WSL.
# Basic A record lookup
dig keydal.net
# Short answer only (one line per record)
dig +short keydal.net
# Query a specific resolver
dig @1.1.1.1 keydal.net
# IPv6 (AAAA)
dig +short keydal.net AAAA
+short reduces the output to one line per record and is the workhorse mode for automation. @1.1.1.1 targets Cloudflare''s public resolver, @8.8.8.8 hits Google — useful for bypassing your local resolver cache. +trace walks the delegation chain from the root servers down to the authoritative name servers — invaluable for diagnosing delegation problems.
dig +trace keydal.net
# Step-by-step output: . -> net -> registry NS -> zone NS
# Each hop shows which server answered
DNS Record Types and How to Query Them
A modern domain has far more than just A and AAAA. A proper operational audit checks every record below.
MX (Mail Exchange)
Lists mail servers and their preference. With multiple MX records, the one with the lower preference number is tried first.
dig keydal.net MX +short
# Sample output:
# 10 mail.keydal.net.
# 20 backup-mail.keydal.net.
TXT — SPF, DKIM, DMARC
TXT records are free text and play a critical role in mail authentication. SPF declares which servers can send for the domain, DKIM publishes the public keys used to verify signatures, DMARC defines policy and reporting endpoints.
# SPF (apex TXT)
dig keydal.net TXT +short
# DKIM (under a selector)
dig default._domainkey.keydal.net TXT +short
# DMARC (fixed subdomain)
dig _dmarc.keydal.net TXT +short
NS (Name Server)
Authoritative name servers for the zone. Answers the question who controls this domain. NS records exist in both the parent zone (registry) and the child zone (your own name servers); when these disagree you have a lame delegation — a classic operational bug.
dig keydal.net NS +short
# Query the authoritative NS directly
dig @ns1.keydal.net keydal.net SOA
CAA — Certificate Authority Authorization
CAA (RFC 8659) restricts which CAs may issue certificates for the domain. If your domain has issue "letsencrypt.org", no other CA — Sectigo, DigiCert — may sign for it. A misconfigured CAA record silently breaks renewals.
dig keydal.net CAA +short
# Sample output:
# 0 issue "letsencrypt.org"
# 0 iodef "mailto:security@keydal.net"
DNSKEY and DS — DNSSEC
DNSSEC-signed zones publish DNSKEY (zone signing key) and DS (delegation signer, in the parent) records. dig +dnssec additionally returns RRSIG signatures.
dig keydal.net DNSKEY +short
dig keydal.net DS +short
# DNSSEC validation (AD flag in response)
dig +dnssec +cd keydal.net
PTR — Reverse DNS
To go from an IP to a name, use the PTR record. Critical for mail servers — IPs without a PTR are routinely rejected as spam sources.
# IPv4 reverse
dig -x 8.8.8.8 +short
# IPv6 reverse
dig -x 2606:4700:4700::1111 +short
# Manual ARPA notation
dig PTR 8.8.8.8.in-addr.arpa +short
nslookup and host: Quick Alternatives
nslookup ships with Windows and is still common in scripts. host on Linux gives more compact output than dig and is good for fast checks.
# nslookup MX (Windows and Linux)
nslookup -type=MX keydal.net
# Target a specific resolver
nslookup keydal.net 1.1.1.1
# host — common types in one line
host keydal.net
host -t TXT keydal.net
host -a keydal.net
Important: nslookup output is harder to parse and lacks some DNSSEC features. Production scripts should prefer dig +short.
The whois Command for Registration Data
whois sends an ASCII query to your selected registrar over TCP 43. It''s a stock package on Linux/macOS; for Windows use Sysinternals'' build. Each TLD uses either a thin or thick model — for example .com is thin (the registry returns only a registrar pointer; details require a follow-up to the registrar), while .tr is thick.
# Standard query
whois example.com
# Force a specific whois server
whois -h whois.verisign-grs.com example.com
# IP whois (RIR — ARIN/RIPE/APNIC)
whois 8.8.8.8
whois -h whois.ripe.net 188.114.96.0
Output typically contains Registrar, Creation Date, Expiration Date, Updated Date, Name Server and Status. clientTransferProhibited means the transfer lock is on; pendingDelete means the domain is being deleted. Keep the EPP status code reference handy.
GDPR and WHOIS Redaction
Since May 25, 2018, under ICANN''s GDPR-compliant policy, gTLD registrars must remove personal data — name, email, address, phone — from public WHOIS. Today most .com / .net / .org queries show those fields as REDACTED FOR PRIVACY. Creation date, registrar, name servers and EPP status remain visible.
Some country-code TLDs (ccTLDs) follow different laws. .tr only publishes a subset of registrant data through TR-NIC; DENIC restricts .de queries to authorised requests. Getting full registrant details now generally requires tiered access with a documented legal basis.
RDAP: Structured JSON for Modern Queries
RDAP exposes JSON over HTTPS. The IANA RDAP bootstrap file lists which server is authoritative for which TLD. A typical gTLD endpoint looks like https://rdap.example/domain/example.com.
# Verisign RDAP for .com / .net
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq .
# IANA bootstrap with auto routing
curl -s https://rdap.org/domain/example.com | jq '.events, .nameservers'
In the response JSON, events[] carries registration, expiration and last changed dates; entities[] the registrar; status[] the EPP states. Redactions appear as descriptive entries in remarks. ICANN Lookup is the official web frontend that uses these RDAP responses.
Why RDAP Wins
- Structured data: no regex parsers — pipe straight into
jq - HTTPS: certificate validation, no eavesdropping
- Standard error codes: 404, 429, 451 (rate limit, legal block)
- Internationalization: UTF-8 and IDN built in
- Tiered access: extended fields for authenticated users
Online WHOIS and DNS Tools
When the CLI is unavailable or you need a quick visual check, web tools are convenient. Recommended:
- KEYDAL WHOIS Lookup — RDAP-backed, sub-second response
- KEYDAL DNS Lookup — A, AAAA, MX, TXT, CAA, NS, SOA in one screen
- ICANN Lookup — the canonical RDAP frontend
- who.is — classic whois plus DNS history
- viewdns.info — reverse IP, DNS report, whois history
- DNSViz — visualize the DNSSEC chain
- intoDNS — quickly diagnose common DNS errors
Advanced Sources: CT, Historic, IANA
Subdomain Discovery via Certificate Transparency
Enumerating all subdomains of a target is critical for security audits and reconnaissance. DNS itself usually blocks zone transfers (AXFR) externally, but every certificate Let''s Encrypt and other CAs sign gets logged to a public Certificate Transparency log — and those logs are searchable historically.
crt.sh, run by Sectigo, is an open CT-log search engine. It can return JSON and is easily scripted.
# Pull all subdomains from logged certs
curl -s 'https://crt.sh/?q=%25.keydal.net&output=json' \
| jq -r '.[].name_value' \
| sort -u
# Filter to last 7 days
curl -s 'https://crt.sh/?q=%25.keydal.net&output=json' \
| jq -r '.[] | select(.entry_timestamp > "2026-04-18") | .name_value'
The output includes every Subject Alternative Name (SAN), wildcards included. Expect hundreds of lines for an active organization — your internal naming convention leaks here, so sign internal services with an internal CA rather than a public one.
Historical WHOIS and DNS Data
Sometimes you want past ownership, old IPs or deleted records — for due diligence on a domain purchase, fraud investigation or brand monitoring.
- viewdns.info/iphistory — IP history
- SecurityTrails (paid) — historical DNS and WHOIS
- DomainTools Iris — enterprise forensics, deepest archive
- archive.org Wayback Machine — old WHOIS page snapshots
- WhoisXML API — historic WHOIS database, programmatic access
Open-source alternatives are limited; serious investigations usually require a paid provider (SecurityTrails, DomainTools, Whoisology).
IANA Root Zone and TLD Lists
The IANA Root Zone Database is the canonical list of every TLD (gTLD, ccTLD, sTLD). Look up a TLD''s sponsoring organisation, authoritative WHOIS server and technical contact here. The single source of truth for any TLD whose extension you don''t recognise.
Practical Scenarios
Four common cases. (1) Identify the mail provider — MX is enough: aspmx.l.google.com is Google Workspace, *.mail.protection.outlook.com is Microsoft 365, *.zoho.com is Zoho. (2) After migration the DNS still returns the old IP — bypass the resolver cache and query the authoritative NS directly. (3) Expiry check — RDAP is the fastest path. (4) SPF/DMARC health check — three TXT lookups reveal the whole layer; start DMARC at p=quarantine.
# 1) Mail provider
dig keydal.net MX +short
# 2) Bypass cache, hit authoritative NS
dig @$(dig keydal.net NS +short | head -1) keydal.net A
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
dig @$r keydal.net A +noall +answer
done
# 3) Expiry date (RDAP)
curl -s https://rdap.org/domain/example.com \
| jq -r '.events[] | select(.eventAction=="expiration") | .eventDate'
# 4) SPF + DMARC + DKIM
dig keydal.net TXT +short | grep 'v=spf1'
dig _dmarc.keydal.net TXT +short
dig google._domainkey.keydal.net TXT +short
Common Pitfalls and Misreadings
- Forgetting TTL: caching resolvers may hold the old answer for 24 hours; lower TTL to 60s before changes
- Glue record problems: when name servers live under the domain itself (ns1.example.com), the parent zone needs a glue A record — otherwise cyclic dependency
- Privacy proxy fakery: the registrant may be a privacy service; identifying the real owner now requires an ICANN complaint or legal request
- Wildcard DNS misleading you: if
*.example.comexists, even non-existent subdomains return answers - WHOIS lag: after registration or transfer, WHOIS can take 24-48 hours to update; RDAP is usually faster
- Misreading EPP status:
clientHoldmeans the domain is suspended — not free parking; the registrar has frozen it
Automation: Bulk Domain Audits
Manual queries don''t scale to hundreds of domains. Bash, Python or Go can drive DNS audit scripts. Here is a tiny Bash loop that performs a basic health check across a domain list.
#!/usr/bin/env bash
for d in $(cat domains.txt); do
expiry=$(curl -s https://rdap.org/domain/$d \
| jq -r '.events[]? | select(.eventAction=="expiration") | .eventDate' \
| head -1)
ns=$(dig $d NS +short | wc -l)
mx=$(dig $d MX +short | wc -l)
dnssec=$(dig $d DS +short | wc -l)
printf '%-30s exp=%s ns=%s mx=%s dnssec=%s\n' "$d" "$expiry" "$ns" "$mx" "$dnssec"
done
Pipe the output to CSV and you can filter pending expirations and missing DNSSEC in seconds with Excel.
Modern Web Hosting and Server Infrastructure
A performant web hosting service rests on three infrastructure decisions: NVMe SSD disks (4-6× IOPS over SATA SSD), LiteSpeed Web Server or Nginx + LSCache (9× request capacity over Apache) and CloudLinux + Imunify360 isolation. The hosting provider's control panel (cPanel, Plesk, DirectAdmin), daily backup policy, data center location and support response time make a big difference too. Turkish locations give low latency to local visitors, while Hetzner Frankfurt or OVH Roubaix suit global traffic. As your site grows, transitioning from shared hosting to VPS to dedicated server scales CPU/RAM/disk to your needs.
Sources and Official Documentation
The following resources are the authoritative references for protocol details, reference tools and official query services.
- ICANN Lookup — official RDAP/WHOIS frontend
- RFC 3912 — WHOIS Protocol Specification
- RFC 9082 — RDAP Query Format
- RFC 9083 — RDAP JSON Response
- IANA Root Zone Database — canonical TLD list
- IANA RDAP Bootstrap — TLD-to-RDAP routing
- Verisign RDAP — official .com / .net endpoint
- crt.sh — Certificate Transparency search
- BIND9 Man Pages — dig, named, host references
- ICANN GDPR Page — WHOIS redaction policy
- ICANN EPP Status Codes
- who.is — popular whois frontend
- viewdns.info — historic DNS / reverse IP tools
Related Content on KEYDAL
- Domain Names: WHOIS Lookup and Registration Guide
- What is DNS? Changing DNS Settings
- Let''s Encrypt: Free SSL with Certbot
- HTTPS and TLS 1.3 Guide
- What is Web Hosting? Types and How to Choose
- KEYDAL WHOIS Lookup Tool
- KEYDAL DNS Lookup Tool
For bulk domain audits, DNSSEC rollouts, mail authentication (SPF/DKIM/DMARC) and migration planning, the KEYDAL team is here to help. Contact us