DNS Record Types

Multiple A records for the same name are returned in varying order. The client typically uses the first one. This provides basic load distribution but is not a load balancer — it has no health checking, session persistence, or weighted distribution.

api.example.com.  300  IN  A  10.0.1.10
api.example.com.  300  IN  A  10.0.1.11
api.example.com.  300  IN  A  10.0.1.12

Happy Eyeballs (RFC 8305): Modern clients (browsers, curl) resolve both A and AAAA simultaneously and race the connections. If IPv6 connects faster, it wins. This is why you should publish both record types when IPv6 is available.

• Exclusive: A CNAME record cannot coexist with any other record type at the same name. If www.example.com is a CNAME, you cannot also have an A, MX, or TXT record there.
• No CNAME at zone apex: example.com (the bare domain) must have NS and SOA records. Since CNAME is exclusive, you cannot put a CNAME at the apex. This is a hard constraint in the DNS spec.
• CNAME targets should be FQDNs: Always use the fully qualified domain name (ending with .) to avoid ambiguity.
• CNAME chains: A CNAME can point to another CNAME, but avoid long chains — each hop adds latency. Most resolvers limit chain depth (typically 8-16).

• Priority 10 — primary mail server. All mail tries here first.
• Priority 20 — secondary. Used if priority 10 is unreachable.
• Priority 30 — tertiary. Could be an external backup MX service.
• Equal priorities = mail is distributed (load sharing). The sending MTA picks randomly among equal-priority servers.
• MX targets must be hostnames, not IPs. The target must itself have an A/AAAA record. MX targets must not be CNAMEs (per RFC 2181).

Google Workspace / O365 MX: When using hosted email, you set MX records to the provider's mail servers (e.g., 1 aspmx.l.google.com for Google Workspace). The provider then handles routing, spam filtering, etc.

Published at _dmarc.example.com. Tells receiving mail servers what to do when SPF and DKIM checks fail.

_dmarc.example.com. TXT "v=DMARC1;
  p=reject;           // reject emails that fail both SPF and DKIM
  rua=mailto:dmarc-reports@example.com;  // aggregate reports
  ruf=mailto:dmarc-forensics@example.com; // forensic reports
  pct=100"

_service._proto.name.  TTL  IN  SRV  priority  weight  port  target

# Example: SIP service over TCP
_sip._tcp.example.com.  3600  IN  SRV  10  60  5060  sip1.example.com.
_sip._tcp.example.com.  3600  IN  SRV  10  40  5060  sip2.example.com.
_sip._tcp.example.com.  3600  IN  SRV  20  0   5060  sip-backup.example.com.

• Priority: Lower = preferred (like MX). Priority 10 servers are tried before priority 20.
• Weight: Among records with the same priority, higher weight gets more traffic. 60/40 split means ~60% to sip1, ~40% to sip2.
• Port: The TCP/UDP port the service runs on. This is what makes SRV powerful — you don't need well-known ports.
• Target: The hostname providing the service (must have A/AAAA records).

When you create a headless Service (clusterIP: None), CoreDNS creates SRV records for pod discovery:

# SRV record for a headless service
_http._tcp.my-service.default.svc.cluster.local. SRV 0 33 8080 pod-abc.my-service.default.svc.cluster.local.
_http._tcp.my-service.default.svc.cluster.local. SRV 0 33 8080 pod-def.my-service.default.svc.cluster.local.
_http._tcp.my-service.default.svc.cluster.local. SRV 0 33 8080 pod-ghi.my-service.default.svc.cluster.local.

Clients (like gRPC) can use SRV records for client-side load balancing across all pod endpoints, bypassing the kube-proxy iptables/IPVS layer.

Also used by: Consul (service discovery), LDAP/Active Directory (_ldap._tcp.dc._msdcs.example.com), XMPP, Minecraft (game server discovery), and CalDAV/CardDAV (_caldavs._tcp.example.com).

• Minimum 2 NS records: For redundancy. Most registrars require at least 2 nameservers on different networks.
• Delegation: NS records at the parent zone (e.g., .com) tell resolvers where to find the authoritative servers. NS records at the child zone (e.g., example.com) are the "authoritative" copy.
• Subdomain delegation: You can delegate subdomains to different nameservers: internal.example.com. NS ns1.internal-dns.example.com. — useful for splitting DNS management between teams.
• High TTL: NS records typically have very long TTLs (172800 = 2 days) since nameserver changes are rare and critical.

• Email delivery: Many mail servers reject email from IPs without valid PTR records (or where PTR doesn't match the sending domain). Critical for email reputation.
• Logging: Tools like tcpdump, web server logs, and SIEM systems use reverse DNS to annotate IPs with hostnames.
• SSH: UseDNS yes in sshd_config triggers PTR lookups, causing slow logins if reverse DNS isn't configured.
• Cloud providers: AWS, GCP, Azure all provide mechanisms to set PTR records for your public IPs. For EC2 Elastic IPs, use the ec2:CreateTags API or request via support.

Inheritance: CAA records are inherited by subdomains. If example.com has CAA records but api.example.com doesn't, the parent's CAA policy applies. To override for a subdomain, add CAA records directly on it.