Record types we work with daily

DNS has dozens of record types. Eight of them carry almost all the work we do at Isidore. Here they are in the order they tend to come up on an engagement.

A and AAAA

Map a hostname to an IP address. A is IPv4 (acme.com → 203.0.113.45). AAAA is IPv6 (acme.com → 2001:db8::1). When a browser, a mail server, or any client connects to a host by name, these are the records that get it to the right address.

You’ll see A records for the bare domain, for www, for application servers, for internal app hostnames. AAAA records appear less consistently — most clients don’t deploy IPv6 in the DNS until they need it, even if their cloud provider supports it.

CNAME

An alias from one hostname to another. mail.acme.com CNAME ghs.googlehosted.com tells the resolver “to find mail.acme.com, go look up ghs.googlehosted.com instead.”

The rule that trips techs up: a CNAME cannot coexist with any other record at the same name. You can’t have acme.com CNAME and acme.com MX — the spec forbids it. This is why you can’t CNAME the bare domain (the apex) to a target if you also have MX records there. Most DNS hosts work around this with proprietary “ALIAS” or “ANAME” record types, but those translate to A records under the hood.

CNAMEs are how M365 publishes DKIM selectors — you publish selector1._domainkey.acme.com CNAME selector1-tenant._domainkey.tenant.onmicrosoft.com, and Microsoft handles the actual key rotation on the other end.

MX

Tells the world where to deliver mail for a domain. An MX record has two parts: a priority (lower number = preferred) and a target hostname. For an M365 tenant, you typically see:

acme.com.  3600  IN  MX  0  acme-com.mail.protection.outlook.com.

Priority is for failover, not load balancing. A sender attempts the lowest-priority MX first; if delivery fails, it tries the next.

When no MX record exists, the sender falls back to the A record of the bare domain — almost always wrong, since the A record usually points to a web server. If a client has email “just not working” on a fresh domain, check the MX record first.

TXT

Holds arbitrary text data. TXT is the swiss army knife of DNS — most security records live here:

• SPF at the apex (v=spf1 ...)
• DMARC at _dmarc.{domain} (v=DMARC1; p=...)
• DKIM keys at {selector}._domainkey.{domain} (v=DKIM1; k=rsa; p=...)
• MTA-STS at _mta-sts.{domain} (v=STSv1; id=...)
• TLS-RPT at _smtp._tls.{domain} (v=TLSRPTv1; rua=...)
• Domain verification tokens from M365, Google Workspace, AWS, etc.

When Cathedra inspects email security, it’s reading TXT records at specific hostnames. We’ll spend most of this course in TXT records.

NS

Names the authoritative nameservers for a zone. Cathedra checks these in DnsHygieneCheck — at least one NS record must exist for the domain to resolve at all. The check also flags when NS records point to multiple providers, because that’s unusual and is sometimes a misconfiguration left over from a half-completed migration.

A typical clean NS set:

acme.com.  3600  IN  NS  ns11.domaincontrol.com.
acme.com.  3600  IN  NS  ns12.domaincontrol.com.

Both nameservers at the same provider (GoDaddy’s domaincontrol.com). If one were at domaincontrol.com and the other at awsdns-19.com, Cathedra warns.

SOA

Start of Authority. There’s exactly one SOA record per zone, and it carries metadata about the zone itself — the primary nameserver (mname), the email of the zone administrator (with @ written as .), the serial number, and timing fields for secondary servers.

The field techs care about most: serial. Authoritative servers compare serials to know if they have the current version of the zone. When you make a DNS change, the serial increments. If two authoritative servers have different serials for the same zone, you’re looking at a propagation lag or a broken slave.

CAA

Certification Authority Authorization. Tells the world which Certificate Authorities are allowed to issue certificates for the domain. Cathedra reports CAA as info-only when missing — not a security failure, just a hardening opportunity.

A typical CAA record set for a domain that uses Let’s Encrypt:

acme.com.  3600  IN  CAA  0 issue "letsencrypt.org"

This says: only Let’s Encrypt can issue certs for acme.com. If an attacker tricks a different CA into issuing a cert (a real attack pattern), the issuance fails because the CA is required to check the CAA record first.

SRV

Service location records. We see these in two main contexts:

1. Autodiscover in some configurations (more commonly a CNAME today, but legacy SRV-based Autodiscover still exists in the wild).
2. VoIP and federation — SIP, XMPP, Microsoft Teams federation. Rare in our day-to-day mail security work but you’ll occasionally need to read one.

PTR (the one running backwards)

PTR records do reverse DNS — given an IP, return the hostname. They live in a different zone ({reversed-ip}.in-addr.arpa) and you generally don’t manage them in DNS Management; you manage them at the hosting provider or registrar that holds the IP allocation.

PTR matters for outbound mail. If a client runs their own mail server (rare for us, but it happens), the receiving server checks that the sending IP has a matching PTR. A mismatch is a strong spam signal. For cloud mail (M365, Google Workspace), the provider handles PTR — you don’t manage it.

Cheat sheet

Type	Used for	Where
A, AAAA	name → IP	Apex, subdomains
CNAME	name → name (alias)	Subdomains only (not the apex)
MX	mail routing	Apex
TXT	SPF, DKIM, DMARC, MTA-STS, verification	Apex and specific underscored hostnames
NS	authoritative nameservers	Apex
SOA	zone metadata, serial	Apex
CAA	which CAs can issue certs	Apex
SRV	service locator	Specific underscored hostnames
PTR	reverse DNS	Separate in-addr.arpa zone

Next lesson: how to read dig output well enough to debug everything in this list.

---

Cathedra alignment: every Examen check operates on these record types