Why use DNS tools?
DNS is the first step of every Internet connection. A DNS problem = inaccessible website, undelivered emails, impossible SSL certificate validation. Without visibility into your DNS configuration, you're working blind.
Three situations where these tools are essential:
- Server migration → Verify the new A/AAAA record has propagated before shutting down the old server
- Email issues → Confirm MX, SPF, DKIM, DMARC are correctly published
- Inaccessible site → Diagnose whether the problem is DNS, server or network
- Broken DNSSEC → Validate the chain of trust, detect orphan DS records or expired signatures
How to diagnose a DNS problem in 3 steps
Step 1: Run a DNS lookup
Go to DNS Lookup, enter your domain and select the record type:
- A: IPv4 server address
- AAAA: IPv6 address
- MX: Mail servers
- TXT: SPF, DKIM, DMARC, verifications
- NS: Authoritative nameservers
Compare responses from Google DNS, Cloudflare, Quad9 and the authoritative server.
Step 2: Audit DNS health
Use DNS Audit for a complete analysis:
- Parent/zone consistency
- Delegation and glue records
- IPv4 and IPv6 accessibility
- TCP support (required for large responses)
- SOA synchronization between servers
Step 3: Track propagation
After a change, the Propagation Test compares responses from dozens of public resolvers. You instantly see who has the new value and who still serves the old one.
What is DNS?
DNS (Domain Name System) translates domain names into IP addresses. When you type captaindns.com, your browser queries a DNS resolver that follows the chain:
- Root servers → Indicate where to find the TLD (.com)
- TLD servers → Indicate the domain's NS
- Authoritative servers → Provide the final answer
Resolution example:
Query: captaindns.com A
→ Root: ".com is managed by a.gtld-servers.net"
→ TLD: "captaindns.com is delegated to ns1.provider.com"
→ Authoritative: "A = 203.0.113.50, TTL 3600"
DNS record types analyzed
| Type | Role | Example |
|---|---|---|
| A | IPv4 address | 203.0.113.50 |
| AAAA | IPv6 address | 2001:db8::1 |
| CNAME | Alias to another name | www → captaindns.com |
| MX | Mail servers | 10 mail.captaindns.com |
| TXT | Free text (SPF, DKIM, etc.) | v=spf1 include:_spf.google.com -all |
| NS | Nameservers | ns1.captaindns.com |
| SOA | Zone authority | Serial, refresh, retry, expire, minimum |
| CAA | Certificate authorities | issue "letsencrypt.org" |
| PTR | Reverse lookup | IP → name |
DNSSEC: securing the DNS resolution chain
DNSSEC (Domain Name System Security Extensions) adds a layer of cryptographic signatures to DNS. Without DNSSEC, an attacker can intercept and modify DNS responses (DNS spoofing, cache poisoning) to redirect traffic to a malicious server.
How DNSSEC works:
- Each DNS zone signs its records with a private key
- The public key is published in DNS (DNSKEY record)
- The parent publishes a DS (Delegation Signer) record linking the child zone key
- The resolver verifies each signature up to the root
What the DNSSEC Checker verifies:
| Check | Detects |
|---|---|
| Chain of trust | Orphan DS records, invalid signatures, expired keys |
| Algorithms | Weak (RSA-1024) or obsolete algorithms |
| Parent/zone consistency | DS at parent not matching the zone DNSKEY |
| NSEC/NSEC3 | Correctly signed proof of non-existence |
DNSSEC is essential for DANE/TLSA (SMTP security) and is becoming a prerequisite for more and more services. Microsoft 365 will require DNSSEC for email domains in 2026.
RDAP: domain registration data
RDAP (Registration Data Access Protocol) replaces WHOIS for querying domain registration data. Since January 28, 2025, ICANN no longer mandates WHOIS for gTLDs. 374 TLDs have already shut down their WHOIS service.
What an RDAP Lookup reveals:
- Registrar: who manages the domain (name, IANA ID, abuse contact)
- Dates: creation, expiration, last modification, domain age
- EPP codes: active locks (transferProhibited, deleteProhibited), suspensions, transitional statuses
- DNSSEC: is the domain DNSSEC-signed at the registrar level?
- Contacts: registrant, administrative, technical (if not masked by GDPR)
Why it matters:
- A domain without
clientTransferProhibitedis vulnerable to theft (domain hijacking) - A domain in
pendingDeletewill be deleted within 30 days - A domain created less than 30 days ago is potentially suspicious (phishing)
- No DNSSEC exposes the domain to DNS spoofing
The tool automatically detects the protocol (RDAP or WHOIS) and normalizes results into the same format, regardless of the TLD.
Real-world use cases
Incident 1: Site inaccessible after migration
Symptom: The site works for some users, not for others.
Diagnosis:
- Run a DNS Lookup on the A record
- Compare responses: Google has the new IP, some ISPs still have the old one
Action: Wait for TTL expiration or lower TTL before the next migration.
Incident 2: Emails rejected after provider change
Symptom: Outgoing emails are rejected with "SPF fail".
Diagnosis:
- Check TXT with DNS Lookup
- Old include is still present, new one is missing
Action: Fix the SPF record, wait for propagation, re-test.
Incident 3: SSL certificate generation fails
Symptom: Let's Encrypt fails with "DNS problem".
Diagnosis:
- Run DNS Audit on the domain
- One NS is lame (not responding authoritatively)
Action: Fix delegation at registrar, wait for propagation.
FAQ - Frequently asked questions
Q: How does DNS lookup work?
A: The tool queries the selected resolver (Google, Cloudflare, or the authoritative server) and displays the raw response with TTL, answer/authority/additional sections and latency. You can enable iterative trace to see each step of the resolution.
Q: What is DNS propagation?
A: "Propagation" refers to the time needed for resolver caches to expire and fetch the new value. It depends on TTL: a TTL of 3600 means some resolvers may keep the old value for up to 1 hour after your change.
Q: Why do results differ between resolvers?
A: Each resolver has its own cache. If a resolver queried your zone before your change, it keeps the response cached until the TTL expires. This is why changes are not instant everywhere.
Q: What does DNS audit check?
A: The audit checks consistency between parent (registry) and zone, verifies each NS responds authoritatively, tests IPv4/IPv6, validates TCP, compares SOA serials and detects lame delegations or stale glue records.
Q: How to reduce propagation time?
A: Lower the TTL of the record you plan to modify 24-48h before the change (e.g., to 300 seconds). Make the change. Once stable, raise the TTL back to normal to optimize performance.
Q: What is DNSSEC and why enable it?
A: DNSSEC adds cryptographic signatures to DNS responses to prevent spoofing and cache poisoning. Without DNSSEC, an attacker can redirect your traffic to a malicious server. DNSSEC is essential for DANE/TLSA and will be required by Microsoft 365 in 2026. Verify your chain of trust with the DNSSEC Checker.
Q: How to check domain registration data?
A: Use the RDAP Lookup to query the registrar, dates (creation, expiration), EPP codes and DNSSEC status of a domain. RDAP replaces WHOIS since January 2025. The tool automatically falls back to WHOIS for uncovered TLDs (.de, .cn, .eu, .ru).
Complementary tools
| Tool | Purpose |
|---|---|
| SPF Inspector | Verify and fix your SPF record |
| DKIM Inspector | Validate your DKIM signature and key |
| DMARC Inspector | Configure and test your DMARC policy |
| Email Tester | Test SPF/DKIM/DMARC from your server |
| DNSSEC Checker | Validate the DNSSEC chain of trust, detect orphan DS and weak algorithms |
| RDAP Lookup | Query domain registration data (registrar, dates, EPP, DNSSEC) |
| Domain Redirect | Redirect your domains with automatic HTTPS and 301/302 forwarding |
Useful resources
- RFC 1035 - Domain Names (original DNS specification)
- RFC 8499 - DNS Terminology (official DNS glossary)
- Google Public DNS Documentation (usage guide)
- Cloudflare DNS Learning Center (DNS tutorials)