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
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 |
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.
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 |
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)