Most companies think of DNS as infrastructure plumbing.
A domain points to a website. MX records point to email. TXT records are added when a vendor asks for verification, when email authentication is configured, when a certificate provider needs validation, or when a SaaS platform needs proof that the organisation controls the domain.
Then everyone moves on. But public DNS is not just configuration. It is public organisational metadata.
And TXT records are often where the most interesting traces live.
They can reveal which vendors a company uses, how outbound email is routed, which platforms have been connected to the domain, which cloud or SaaS services have been verified, and how much historical residue has accumulated over time.
This is rarely a direct vulnerability.
A TXT record does not usually expose a password, a private key or an internal document.
But security is not only about secrets.
It is also about context. This is not unique to DNS:
Metadata tends to accumulate at the edges of systems — not as something intentionally exposed, but as a byproduct of how those systems are used and connected. I wrote about a similar pattern in Metadata, identity and the shadows we leave behind.
DNS is simply a more structural version of the same phenomenon.
For an attacker, context reduces uncertainty. It helps answer practical questions before any phishing email is sent, before any login page is tested, and before any employee is contacted.
Which vendors does the organisation use? Which systems handle mail? Which platforms are connected to the domain? Which workflows might employees recognise? Which teams might administer those systems? Which suppliers could be impersonated convincingly?
Public DNS can help build that map.
DNS as reconnaissance
Reconnaissance is often misunderstood as something dramatic.
In practice, it is usually quiet.
It is the work of collecting small pieces of public information and turning them into a more accurate picture of an organisation.
DNS fits naturally into that process because it is meant to be public. Anyone can query it. No breach is required. No access is needed.
TXT records are especially useful because they are flexible. They are used for many different purposes: SPF, DKIM, DMARC, domain verification, certificate validation, MTA-STS, TLS reporting, vendor onboarding and platform checks.
Each record may be legitimate.
The problem is the accumulated picture.
A company may not publish anything secret, but still reveal enough to make targeted research easier.
That is the real security angle.
Not “DNS leaks credentials”.
Rather:
DNS can expose the terrain around the credentials.
Case: CNN.com — the accumulated ecosystem
A TXT lookup on cnn.com returns a large number of records.
The response contains visible traces of Microsoft, Google, Adobe, Atlassian, Canva, Cisco, Facebook, LucidLink, Mixpanel, MongoDB, OpenAI, Stripe, Zendesk, GlobalSign and other verification or policy mechanisms.
That does not mean CNN is misconfigured.
It means CNN, like many large organisations, has accumulated a public record of connected systems, vendors and operational dependencies.
From the outside, this becomes useful intelligence.
A Microsoft record may suggest enterprise identity or productivity tooling. Google verification records suggest Google-connected services. Adobe and Canva records point toward creative or content workflows. Atlassian suggests collaboration or engineering tooling. Zendesk in SPF suggests support or ticketing-related email. Stripe verification records suggest payment or platform validation. GlobalSign records show certificate-related validation.
None of this is a password.
But each trace narrows the field.
An attacker no longer has to start from a blank page. Public DNS already suggests which vendors may be worth impersonating, which SaaS platforms may be worth researching, and which internal functions may be connected to those tools.
For a company with thousands of employees, this does not make compromise easy.
Large organisations have layered controls, security teams, monitoring, training and vendor processes.
But it can still make targeting sharper.
A generic phishing email is one thing.
A message that references a real vendor, a real workflow, a real platform and the right employee group is something else.
Public DNS can help move an attacker from generic to specific.
Case: Whitehouse.gov — smaller surface, still meaningful
A lookup on whitehouse.gov shows a much smaller set of TXT records.
The visible records include Microsoft domain verification, Google site verification and an SPF record authorising mail through a government-specific mail routing domain, Microsoft’s Outlook protection infrastructure, Mandrill/Mailchimp and several specific IP addresses.
Compared with cnn.com, the surface is far more controlled.
There are fewer visible third-party verification traces and less obvious SaaS sprawl.
But even this smaller response reveals structure.
It suggests Microsoft-connected services. It shows that Google services are, or have been, connected in some capacity. The SPF record gives insight into outbound email handling and authorised sending paths.
Again, this is not secret information.
It is required configuration.
But it still tells an external observer something about how communication is structured.
The lesson is not that whitehouse.gov is exposed in the same way as a large commercial media domain.
The lesson is that even a small TXT footprint can reveal operational architecture.
Less noise does not mean no signal.
Case: Stripe.com — DNS as an organisational map
Stripe is a useful example because the records show how modern technology companies look from the outside.
A public TXT lookup of stripe.com shows traces of Anthropic, Apple, Atlassian, Canva, Cursor, Docker, DocuSign, ElevenLabs, Facebook, Fastly, Google, HackerOne, LiveRamp, Postman, Microsoft, Salesforce, Qualtrics, Greenhouse and others.
This does not reveal a breach.
It reveals an ecosystem.
From the outside, Stripe does not only appear as a payments company with a website. It appears as a large operational environment connected to developer tooling, AI services, marketing platforms, hiring systems, document workflows, analytics, customer engagement, CDN infrastructure, enterprise identity and security workflows.
The SPF record is especially useful analytically.
It shows that outbound mail is authorised through internal Stripe mail systems, Greenhouse recruitment mail and Qualtrics survey infrastructure.
That is operational context.
A recruiter-themed phishing attempt becomes more credible if Greenhouse is visibly part of the mail path. A survey-themed lure becomes more plausible if Qualtrics is authorised. A vendor-themed social engineering attempt can be sharpened if Atlassian, DocuSign, Docker, Postman, Salesforce, Microsoft or Fastly are already visible in public DNS.
This does not mean any of those attacks will succeed.
It means the attacker has better starting assumptions.
In security, that matters.
Attackers do not need perfect knowledge. They need leads.
Public DNS can provide those leads.
How this becomes attack surface
The phrase “attack surface” is often used too narrowly.
People think of exposed services, open ports, vulnerable software or leaked credentials.
Those are real attack surfaces.
But there is also an intelligence surface.
That is the public information that helps an attacker decide where to look, who to target and what story to tell.
TXT records can contribute to that surface in several ways.
They can reveal suppliers.
If a company publishes verification records for specific SaaS tools, those tools become part of the visible supplier map. That can guide vendor impersonation, credential phishing or further research into known incidents affecting those platforms.
They can reveal email flows.
SPF records often show which systems are allowed to send mail for a domain. That may include marketing platforms, recruitment tools, support systems, survey tools or internal mail relays.
That information can make phishing themes more believable.
They can reveal organisational functions.
Greenhouse points toward recruitment. Zendesk points toward support. Qualtrics points toward surveys or experience management. DocuSign points toward document workflows. Atlassian points toward collaboration or engineering processes. Salesforce points toward sales or customer operations.
These are not secrets.
But they are organisational clues.
They can reveal security posture.
DMARC policy, SPF breadth, missing reporting records, stale verification tokens and excessive includes can all suggest whether DNS is tightly governed or loosely accumulated.
They can reveal history.
Old verification records may remain long after a tool was tested, abandoned or migrated away from. From the outside, it is not always clear whether the system is still active.
That ambiguity can still be useful.
An attacker can test assumptions.
The realistic risk
It is important not to overstate this.
Public TXT records do not automatically make a company vulnerable.
Large organisations are hard targets. They often have security teams, identity controls, vendor management, phishing-resistant authentication, monitoring, logging and incident response.
But attackers do not need DNS to do everything.
They use it as one input.
A LinkedIn profile gives names and roles. Job postings reveal technologies. GitHub may reveal engineering habits. Press releases reveal suppliers and partnerships. Breach datasets reveal old credentials. Public DNS reveals infrastructure and vendor traces.
Individually, each source may be harmless.
Together, they become a map.
That map can support targeted phishing, vendor impersonation, credential stuffing, helpdesk abuse, supplier research or platform-specific vulnerability research.
The risk is not that TXT records alone compromise the organisation.
The risk is that they make the reconnaissance phase easier.
And many real compromises begin with good reconnaissance.
The governance failure
The problem is usually not one bad DNS record.
It is lifecycle.
A vendor asks for a TXT record. A marketing team adds one. An agency adds another. A developer verifies a tool. A certificate provider requires validation. A migration happens. A project ends.
The record remains.
Nobody removes it because nothing breaks.
Over time, DNS becomes an archive of operational decisions: some current, some historical, some forgotten.
That archive is public.
This is where DNS hygiene becomes a security discipline.
Good DNS hygiene: treating TXT records as a managed surface
TXT records should not be treated as one-time setup tasks. They are a managed public surface. The goal is not to remove every record — many are necessary and security-positive — but to know what exists, why it exists, who owns it and what it reveals. Every TXT record should have a clear owner, a documented purpose, an associated system and a review date. If nobody can explain who requested a record or whether the related service is still active, the record is not just technical debt. It is public technical debt.
A practical DNS hygiene routine starts with regular inventory across the root domain and important subdomains. Classify records by purpose: email authentication, domain verification, certificate validation, reporting, SaaS onboarding, security policy or unknown. Investigate unknown records, remove stale verification tokens, narrow SPF includes where possible, clean up duplicate vendor traces, and confirm that DMARC and TLS-RPT reporting addresses are still active and owned. The question is not only whether the domain works. The question is what the domain says.
The bigger point
Metadata is not only created by apps, cookies, analytics scripts or mobile networks. It is also created by infrastructure. DNS is one of the oldest and most important systems on the internet, designed to be public, distributed and queryable. That is what makes it useful — and also what makes it revealing. Public DNS does not usually expose the secret itself. It exposes the terrain around the secret. For defenders, that terrain should be known and governed. For attackers, it is a starting point. And in many organisations, nobody is responsible for the story DNS is telling.