DNS Privacy Leak & Hostmaster Audit
Inspect DNS intelligence footprints: decode RFC 1035 SOA hostmaster email addresses, audit SPF netblock exposure, detect stale SaaS verification token sprawl, and analyze vanity nameserver topology.
Frequently Asked Questions
How does an SOA rname field expose administrator email addresses?
The Start of Authority (SOA) record contains an rname mailbox parameter defined in RFC 1035. The first unescaped period represents the @ symbol. For example, hostmaster.example.com decodes to [email protected]. If personal or departmental addresses are used instead of generic aliases, they become directly indexable by reconnaissance scanners and spam harvesters.
Why can SPF (Sender Policy Framework) TXT records leak internal infrastructure?
SPF records often include ip4 and ip6 CIDR blocks representing outbound mail servers, internal relay nodes, or third-party CRM SaaS integrations. Attackers routinely parse SPF records during reconnaissance to map private subnets, cloud host targets, and identify third-party vendors.
What is TXT token sprawl and how does it compromise privacy?
Web services (Google Workspace, Microsoft 365, Facebook Domain Verification, Atlassian, DocuSign) mandate publishing verification tokens in DNS TXT records. Domains that never prune old tokens leak their complete SaaS application stack, giving adversaries valuable intelligence on vendor software to target.
What are best practices to minimize DNS information leakage?
Use RFC-compliant generic aliases for SOA contact records (such as [email protected]), prune stale verification TXT tokens regularly, avoid vanity nameserver hostnames that expose underlying host IP topologies, and review SPF records to ensure only active sending relays are advertised.