MyRecon OSINTDNS Records Explained: A, MX, TXT, NS and the Rest
A domain's DNS zone is a public list of every decision its owner has made about where things live. It names their host, their mail provider, and, through a set of records almost nobody thinks of as revealing, a good part of the software they run the company on.
What DNS actually is
DNS turns names into the answers a machine needs. Almost everyone describes it as "turning names into IP addresses", which is the most common job but not the only one, and the other jobs are where the interesting information is.
A zone is the set of records for a domain. Each record has a name, a type, a value and a time-to-live. Anyone can ask for them, because they have to be readable for the internet to work at all, which is what makes DNS the single most productive public source in an infrastructure investigation.
The record types, and what each one tells you
A and AAAA: where the name points
An A record maps a name to an IPv4 address; AAAA does the same for IPv6. This is the record people mean when they say a domain "points at" a server.
What it tells an investigator is less than you would hope, and this is worth internalising early: most sites now sit behind a CDN or a proxy, so the A record returns the CDN's address, not the origin's. Cloudflare, Fastly and their equivalents answer for millions of domains. Seeing one of their ranges tells you which CDN the site uses and nothing whatsoever about who runs the server behind it.
CNAME: an alias to another name
A CNAME says "for this name, go and look up that name instead". It is how www usually points at the bare domain, and how services hand customers a subdomain on their own infrastructure.
CNAMEs are the most informative record type for working out a company's vendor stack, because they point directly at the vendor. A support subdomain aliased to a helpdesk provider, a status page aliased to a status-page service, a shop aliased to a commerce platform, each one names a supplier, and suppliers are a route in. That is not a hypothetical concern: a large share of the case files on this site begin at a third party rather than at the company in the headline.
Two rules people trip on: a CNAME cannot coexist with other records on the same name, and it cannot legally sit at the zone apex, the bare domain, which is why providers invented non-standard ALIAS and ANAME records to work around it.
The dangling CNAME, and why it is a security finding rather than a curiosity. When a company stops using a service but leaves the CNAME in place, that subdomain still points at the provider, at a name nobody owns any more. Anyone who registers that name on the provider gets a working, HTTPS-valid page on the company's own subdomain. That is a subdomain takeover, it is one of the most reliably found issues in bug bounty work, and it exists because deleting a DNS record is a step that is very easy to skip.
MX: where mail goes
MX records name the mail servers that accept mail for the domain, each with a priority number where lower wins. They are the fastest way to identify a company's mail provider: hostnames ending in Google's or Microsoft's mail infrastructure account for an enormous share of business domains, and a self-hosted mail server on the company's own range is now unusual enough to be worth noting.
A domain with no MX records cannot receive mail. On something claiming to be a business, that is a meaningful finding, it usually means the domain exists to be clicked, not corresponded with.
TXT: the accidental inventory
TXT records hold arbitrary text, and because they were the only flexible field available, the industry piled everything into them. Two things live there.
First, email authentication: SPF, DKIM and DMARC are all TXT records, and they are worth a guide of their own, this one.
Second, and much less appreciated, domain verification tokens. Every SaaS product that needs to prove you control a domain asks you to add a TXT record, and almost nobody removes them afterwards. The result is a public list of the vendors a company has signed up with, sometimes years of them. You will recognise them by their prefixes:
- google-site-verification=, Google Search Console or Workspace.
- MS=, Microsoft 365 tenant verification.
- atlassian-domain-verification=, Jira or Confluence.
- facebook-domain-verification=, an advertising or commerce account.
- docusign=, stripe-verification=, adobe-idp-site-verification= and dozens more in the same shape.
Read together, these describe an organisation: its identity provider, its payment processor, its ticketing system, its marketing platform. None of it is secret and all of it was published deliberately, which is exactly what makes it open-source intelligence rather than anything else.
NS and SOA: who is in charge of the zone
NS records name the authoritative nameservers for the domain. They tell you which DNS provider the owner uses, and they are the strongest single link between separate domains: two unrelated-looking sites on the same unusual nameserver pair are very often the same operator.
SOA: start of authority, carries the zone's administrative parameters, including a serial number that increments when the zone changes and an administrative email address in an old notation where the first dot stands in for the @. That address is frequently the last surviving human contact detail in a post-redaction world.
PTR: the reverse direction
PTR maps an address back to a name, and it lives in a separate zone controlled by whoever holds the IP range rather than by the domain owner. That distinction is the whole reason it is useful, and it is covered properly in the IP and reverse DNS guide.
CAA: which authorities may issue certificates
CAA records list the certificate authorities permitted to issue for a domain. A CA is required to check them before issuing. Few domains publish them, which makes their presence a decent proxy for a security team that has done the unglamorous work.
SRV, DS and DNSKEY
SRV records advertise a service, a protocol, a port and a host, historically the fingerprint of on-premise directory and communications servers, and still visible on plenty of corporate domains. DS and DNSKEY are the DNSSEC chain: the signing keys and the fingerprint the parent zone holds for them. A domain with a DS record at the registry is signed; almost none are.
TTL, and the propagation myth
Every record carries a time-to-live: how many seconds a resolver may keep the answer before asking again. Nothing about DNS "propagates". Changes are published instantly at the authoritative server, and the delay everyone experiences is simply resolvers elsewhere serving cached answers until their TTL runs out.
TTLs are also a small operational tell. A zone where every record has a five-minute TTL belongs to someone who expects to move things, or who did move things recently and lowered the TTL beforehand. Day-long TTLs belong to a zone nobody has touched in a long time.
What DNS will not tell you
- The origin server behind a CDN. The A record is the proxy. Finding the origin is a separate problem and often an unsolvable one.
- Every subdomain. There is no command that lists a zone, zone transfers were locked down decades ago, and a server that still allows one is a misconfiguration rather than a source. Subdomains are found through certificate transparency logs, passive DNS collections and wordlists, all of which are incomplete by nature.
- Who owns it. That is the registration record's job, and it mostly will not tell you either. See WHOIS and RDAP.
- What the internal network looks like. Many organisations run split-horizon DNS, where the answers inside the building differ entirely from the public ones.
Where the answer comes from matters. Public resolvers return different results in different countries, and some ISPs rewrite failed lookups to point at their own advertising pages. MyRecon queries DNS over HTTPS against a public resolver so the answer is not shaped by whatever your network decided to do with it, and shows you the records as returned.
A reading order for an unfamiliar zone
- NS first. Who runs the zone, and have you seen those nameservers before?
- MX. Which mail provider, or none at all, which is its own answer.
- TXT. Read the verification tokens as a vendor list, then read SPF and DMARC as a security posture.
- A, AAAA and CNAME. Hosting, CDN and every aliased subdomain you can find.
- CAA and DS. Present or absent, they tell you how much deliberate work went into this zone.
- Then compare against the registration record. A zone built out with care on a domain registered last week is a contradiction worth explaining.
Run a live DNS lookup on any domain with the MyRecon domain tool, or read how to investigate a suspicious domain for the full workflow these records fit into.