DNS Records & Passive Infrastructure Lookup
Full DNS record enumeration, email security scoring, and propagation checks.
DNS Intelligence queries all major record types for a domain and builds a structured security report. It covers SPF, DMARC, DKIM, DNSSEC, MTA-STS, BIMI, and CAA records alongside standard A, AAAA, MX, NS, TXT, and CNAME records.
Advanced DNS Lookup
How to Use
Work through these steps in order. Use this tool for educational and ethical purposes only.
| 1 | Select DNS Intelligence from the tool navigation. |
| 2 | Enter the target domain name (e.g., example.com). |
| 3 | Click Analyze DNS. The tool queries all record types in sequence. |
| 4 | Review the record tables grouped by type: A/AAAA, MX, NS, TXT, CNAME, and security records. |
| 5 | Check the Email Security Score panel, which rates SPF policy strictness, DMARC enforcement level, and DKIM key presence. |
| 6 | Review the DMARC breakdown: p= tag value, rua/ruf reporting addresses, and subdomain policy. |
| 7 | Check the SPF record for mechanism count, redirect chains, and whether the final qualifier is \~all or \-all. |
| 8 | Review the DNS Propagation panel, which shows resolution results across multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9) to spot inconsistencies. |
What DNS Does and Why It Matters for Security
The Domain Name System is the internet’s phonebook. When a browser, mail server, or API client needs to reach recosint.com, it queries a recursive resolver, which contacts the authoritative nameservers for that domain. Those nameservers return the answer: an A record with the IP, an MX record for mail routing, or a TXT record containing policy strings like SPF.
The resolution chain has four stops:
- Recursive Resolver: usually your ISP or a public resolver like 8.8.8.8. It does the legwork.
- Root Nameservers: 13 root server clusters that know which nameservers handle each TLD (.com, .net, etc.).
- TLD Nameservers: delegate the query to the domain’s authoritative nameservers.
- Authoritative Nameservers: hold the actual records. For recosint.com, these are mike.quicns.org and kevin.quicns.net.
Every record carries a TTL (Time to Live) that controls how long resolvers cache a response before re-querying. A TTL of 280 seconds means caches refresh frequently, useful for dynamic infrastructure but potentially increasing query load.
DNS sits upstream of almost every network connection. If an attacker alters DNS responses, through a compromised registrar account, a misconfigured zone file, or a subdomain pointing to abandoned infrastructure, they can intercept traffic, forge email, or issue fraudulent SSL certificates. Records like SPF, DMARC, and CAA exist precisely to embed security policy into DNS itself, enforcing trust decisions before a single packet reaches your server.
DNS Misconfigurations You Should Fix
DNS zones accumulate technical debt. Records get added, services change, and old entries linger. Here are the three most dangerous categories.
Missing or Weak SPF Records
SPF (Sender Policy Framework) specifies which mail servers can send email on behalf of your domain. Without it, anyone can forge your From: address and deliver phishing email that appears to come from you.
A policy like v=spf1 include:_spf.mail.hostinger.com ~all tells receiving servers to check Hostinger’s approved senders. The ~all qualifier is a soft fail: unauthorized senders are marked as spam but not rejected. A stronger setup uses -all (hard fail), which instructs receiving servers to reject unauthorized email entirely. Missing SPF leaves your domain open to spoofing; an incomplete SPF record causes your own legitimate email to land in spam.
Dangling CNAME Records
A CNAME points a subdomain to an external hostname. If that hostname no longer exists because you cancelled a cloud service or let a subdomain expire, the CNAME becomes “dangling.” An attacker can register the orphaned hostname and claim the subdomain, a technique called subdomain takeover.
This is not theoretical. Bug bounty programs regularly pay out for dangling CNAMEs on production domains. Auditing your DNS zone regularly against active services is the only reliable defense.
Weak TTL Values
Very low TTLs (under 60 seconds) can mask infrastructure issues and create excessive resolver load. Very high TTLs (over 86,400 seconds) mean changes propagate slowly, a real problem during incident response when you need to redirect traffic away from a compromised IP quickly.
For stable production records, 3600-14400 seconds is standard. For frequently updated records, 300 seconds is reasonable. Always lower your TTL 24 hours before a planned change to ensure fast propagation.
How Attackers Abuse DNS
Email Spoofing via SPF and DMARC Gaps
Attackers forge the From: header to impersonate a trusted domain. SMTP has no built-in sender authentication, so SPF and DMARC are the only technical barriers.
A DMARC policy of p=none means: monitor but don’t enforce. Reports about failing messages are collected, but those messages still get delivered. An attacker can spoof your domain and the email reaches the inbox. Moving to p=quarantine or p=reject closes this gap. The sp= tag extends your DMARC policy to subdomains, important because attackers often spoof mail.yourdomain.com rather than the root domain directly.
Subdomain Takeover
When an A record or CNAME points to infrastructure that no longer belongs to you, a decommissioned S3 bucket, a cancelled Heroku app, a removed GitHub Pages site, the subdomain becomes claimable. An attacker notices staging.yourdomain.com resolves to a hostname returning a “404 Not Found” from a hosting provider, signs up for an account, and registers the same hostname. Now staging.yourdomain.com serves attacker-controlled content under your domain, with a valid SSL certificate. This technique is used to steal session cookies, serve phishing pages under a trusted domain, and bypass CSP rules.
DNS Hijacking and Cache Poisoning
DNS hijacking redirects queries for a legitimate domain to an attacker-controlled IP. It can happen at the registrar (compromised account, changed nameservers), zone file level (breached DNS management interface), or network level (BGP hijacking). The nameserver configuration is therefore a high-value target.
Cache poisoning injects forged DNS responses into a resolver’s cache, causing it to return the wrong IP to all clients using it. DNSSEC prevents this by digitally signing zone data, but adoption remains low across the industry.
Technical Details & Use Cases
DNS Intelligence goes beyond basic record lookups. It evaluates three email authentication controls in parallel: SPF (sender authorization), DMARC (policy enforcement), and DKIM (cryptographic signing). Each gets a pass, warn, or fail rating.
The DMARC parser pulls the p= policy tag, aggregate report address (rua), failure report address (ruf), and the pct= field. Missing rua addresses and pct values below 100 are flagged as misconfigurations.
SPF analysis counts DNS lookup mechanisms against the RFC 7208 limit of 10. It also checks the final qualifier: ~all is a soft fail that most mail servers accept anyway, while -all is a hard reject that actually enforces the policy.
DNSSEC validation checks for RRSIG records confirming zone signing. MTA-STS and BIMI checks extend coverage beyond what DMARC alone addresses.
Typical use cases: email deliverability audits, phishing infrastructure research, domain security hardening, and DNS verification before migrations.
Pros & Cons
| Pros | Cons |
| ✓ Evaluates SPF, DMARC, and DKIM together with one unified security score | ✗ DKIM checks need the selector name upfront since it is not published in a standard |
| ✓ DMARC parser catches common mistakes like missing rua addresses and low pct values | ✗ Results show DNS cache state at query time and may not reflect very recent changes |
| ✓ Multi-resolver propagation check surfaces split-brain DNS and caching delays | ✗ Zone transfer testing is read-only; misconfigured servers require manual follow-up |
Related Network Intelligence Tools
Frequently Asked Questions
What does a DNS lookup return?
It queries the authoritative nameservers for a domain and returns its DNS records: A records (IPv4 addresses), MX records (mail servers), NS records (nameservers), TXT records (SPF, DMARC, verification strings), and CAA records (certificate authority authorization). Together these describe how a domain routes traffic, handles email, and delegates authority.
What is the difference between SPF ~all and -all?
~all is a soft fail: mail from unauthorized senders is accepted but flagged as suspicious. -all is a hard fail: unauthorized mail is rejected outright. The ~all setting is common during initial SPF deployment but leaves the domain vulnerable because unauthorized email still reaches inboxes.
Is a DMARC policy of p=none safe?
No. It only monitors authentication failures without blocking anything. An attacker can still spoof your domain and the email will be delivered. Use p=none temporarily to collect DMARC reports and identify all legitimate sending sources, then move to p=quarantine or p=reject to enforce protection.
How many nameservers do I need?
ICANN requires a minimum of two NS records. Most production domains use two to four nameservers across different networks and geographic regions. Having only 2 NS records meets the minimum but provides limited resilience against DDoS attacks or provider outages.
Why do MX records have priority numbers?
Priority numbers control mail delivery order. Lower number means higher preference: the sending server tries the lowest-priority MX first. For recosint.com, mx1.hostinger.com at Priority 5 is the primary mail server; mx2.hostinger.com at Priority 10 is the fallback. If the primary is unavailable, sending servers retry via the fallback.
Recosint Intelligence Suite
For Business Inquiries, Sponsorship's & Partnerships
(Response Within 24 hours)
