Most DNS configurations stop at A, AAAA, CNAME, MX, and TXT. That covers routing and mail, sure. But you're leaving performance, security, and resilience on the table if that's where your zone file ends.
I've seen production outages that a single DNAME record would have prevented, certificate mis-issuances that CAA would have blocked in under sixty seconds, and TLS handshakes that TLSA records could have authenticated without a third-party CA. The record types below aren't exotic anymore—they're just underused. Let's fix that.
1. CAA: certificate authority authorization
CAA records declare which certificate authorities may issue certificates for your domain. Without them, any publicly trusted CA can issue a cert for your domain if an attacker convinces them they control it.
A compromised email account, a DNS hijack lasting minutes, or a malicious insider at a hosting provider can lead to fraudulent certificates. CAA won't stop a sophisticated state-level attacker, but it raises the bar considerably and gives you an audit trail.
The syntax is simple:
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "letsencrypt.org"
example.com. CAA 0 iodef "mailto:[email protected]"
The issue tag permits cert issuance for the domain. The issuewild tag permits wildcard certificates. The iodef tag tells CAs where to report violations—someone tried to get a cert from a non-authorized CA.
If you only use Let's Encrypt, list only Let's Encrypt. If you have a legacy cert from DigiCert for your main domain and Let's Encrypt for everything else, add both. Lock it down to exactly what you use.
One gotcha: CAA is checked at issuance time, not validation time. If you add a CAA record after a certificate has already been issued, that cert remains valid until expiration. The protection is forward-looking.
Another: CAA lookup is recursive up the domain tree. If you have no CAA record at sub.example.com but you do at example.com, the parent record applies. An empty CAA record at the subdomain (using a semicolon as a placeholder in some implementations) blocks issuance entirely, which can surprise you during renewals.
Check your current CAA policy:
dig CAA example.com +short
If you see nothing, you have no policy. Any CA can issue.
2. SVCB and HTTPS: service binding for HTTP/3 and ECH
SVCB (Service Binding) and HTTPS records are the newest addition to the DNS optimization toolkit. They let you advertise alternative endpoints, supported protocols (like HTTP/3), and encrypted client hello (ECH) keys—all in DNS, so the client knows before the first connection attempt.
An HTTPS record for your domain might look like this:
example.com. HTTPS 1 . alpn=h3,h2 ipv4hint=203.0.113.1 ipv6hint=2001:db8::1
The priority is 1, the target is . (the domain itself), and the parameters describe what the client can expect: HTTP/3 (h3) and HTTP/2 support, plus the IP addresses to try. The client can skip a DNS round-trip for the A/AAAA lookup if the hints are fresh.
Why does this matter? HTTP/3 over QUIC is faster than TCP in lossy or high-latency conditions, but clients traditionally discover it only after a first connection via HTTP/2. With an HTTPS record, the client knows immediately and can connect using QUIC from the start.
ECH (Encrypted Client Hello) support is advertised here too. ECH encrypts the SNI field in the TLS handshake, hiding which specific hostname the client wants from eavesdroppers. If your CDN or origin supports ECH, publishing the ech parameter in the HTTPS record enables it.
Browser support is rolling out now, and CDN support is ahead of origin server support. Cloudflare, Fastly, and some others already honor these records. If you're on a modern CDN, check their docs and enable it.
One caveat: HTTPS records are relatively new. Older recursive resolvers may drop them or return errors. Monitor your query logs after adding them.
3. DNAME: delegation at scale
DNAME is like CNAME for an entire subtree. Instead of aliasing one hostname to another, DNAME aliases everything under a given label.
Suppose you've migrated a service from service.old-domain.com to service.new-domain.com and you want all subdomains under the old label to follow automatically. A DNAME record does that:
service.old-domain.com. DNAME service.new-domain.com.
Now a query for api.service.old-domain.com will be rewritten to api.service.new-domain.com by the resolver. The client receives a CNAME-like response, but you only had to add one record instead of one CNAME per subdomain.
Where I've used this most: multi-tenant SaaS platforms where customer subdomains need to be transparently redirected after an acquisition or rebrand. You can't manually CNAME hundreds of customer labels. DNAME handles it.
Important: DNAME and other records cannot coexist at the same label, except for DNSSEC signatures. If you have an A record at service.old-domain.com, you cannot add a DNAME there. It's an apex-like restriction.
Also, DNAME doesn't rewrite the query itself in the packet the client sees—it synthesizes a CNAME on the fly. Some very old resolvers don't understand DNAME and will fail to resolve. That population is small now, but test in your environment.
4. SRV: service location beyond MX
SRV records locate services by protocol and priority, just like MX does for mail. The difference is SRV works for any TCP or UDP service.
The format:
_service._proto.name. TTL IN SRV priority weight port target.
Concrete example for SIP:
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sipserver1.example.com.
_sip._tcp.example.com. 3600 IN SRV 10 40 5060 sipserver2.example.com.
Clients query _sip._tcp.example.com, get back two records with the same priority (10), and choose between them proportionally by weight. sipserver1 gets 60% of traffic, sipserver2 gets 40%.
Where this shines: XMPP, Minecraft servers, VoIP, LDAP, Kerberos. Any situation where you need the client to discover the service endpoint and port dynamically rather than hardcoding it.
Microsoft Active Directory relies heavily on SRV for domain controller and LDAP discovery. If you've ever debugged domain join issues, you've looked at SRV records whether you realized it or not.
The weight field is your load-balancing lever. If one backend can handle twice the load, set its weight to twice the others. But remember: DNS-based load balancing is coarse. Clients cache the result for the TTL, so adjustments take time to propagate.
So what if you need authenticated DNS responses?
That's where TLSA comes in.
5. TLSA: certificate pinning in DNS
TLSA records publish certificate fingerprints or public key hashes directly in DNS, protected by DNSSEC. Clients can verify that the certificate presented by the server matches the hash in DNS, eliminating reliance on the CA trust model entirely for that connection.
The record format:
_443._tcp.example.com. IN TLSA 3 1 1 <SHA-256 hash>
The three numbers are the usage, selector, and matching type. Usage 3 means "domain-issued certificate"—you're pinning your own cert and ignoring the CA chain. Selector 1 means match the public key only (not the whole cert). Matching type 1 means SHA-256.
So that record says: "For TLS on TCP port 443 at this name, the server's public key must hash to this value."
Why use it? Defense in depth. Even if an attacker compromises a CA and issues a fraudulent cert for your domain, clients that validate TLSA will reject it because the fingerprint won't match.
The downside: you've created an operational dependency on DNSSEC and on updating the TLSA record every time you renew or rekey. Miss the update and valid clients will refuse to connect. Automation is mandatory.
TLSA is most common in SMTP with DANE (DNS-based Authentication of Named Entities). Mail servers check TLSA records before accepting TLS connections, which stops man-in-the-middle attacks on mail delivery that forged certificates would otherwise enable.
If you run your own mail server and DNSSEC-sign your zone, implement DANE. It's one of the few ways to get authenticated encryption for SMTP without S/MIME or PGP.
6. NAPTR: rewriting and regex for telephony
NAPTR (Naming Authority Pointer) records perform regex-based rewriting of queries and are used heavily in ENUM (telephone number mapping) and dynamic delegation. The use cases are niche, but when you need them, nothing else works.
A simplified example:
example.com. NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:[email protected]!" .
This says: if you're looking for a SIP URI, rewrite the query using this regex and return sip:[email protected].
In ENUM, a telephone number like +1-555-1234 is reversed into a DNS query under e164.arpa, and NAPTR records return the SIP or email address associated with that number. It's the DNS-based phone directory.
Outside telephony, I've seen NAPTR used for dynamic service discovery in large federated networks where the target service name needs to be computed rather than statically listed. The regex is powerful but error-prone—test thoroughly.
If your setup doesn't involve VoIP, ENUM, or similar, you'll likely never touch NAPTR. But if you're troubleshooting a SIP trunk or integrating telephony and web services, this record is the bridge.
7. LOC: geographic location for physical assets
LOC records publish the physical latitude, longitude, and altitude of a server or facility. The format is arcane but precise:
example.com. LOC 37 23 30.900 N 121 59 19.200 W 30.00m 10m 10m 2m
That's 37°23'30.9"N, 121°59'19.2"W, at 30 meters altitude, with horizontal and vertical precision values.
Why publish this? Compliance, asset tracking, and GeoDNS sanity checks. Some regulated industries require documenting physical server locations. LOC makes it queryable rather than buried in a spreadsheet.
GeoDNS services sometimes use LOC as a cross-check. If your authoritative server claims to be in Europe but the LOC record says California, that's a misconfiguration worth investigating.
The practical use is limited. Most operators don't populate LOC, and most software doesn't check it. But if you manage infrastructure across data centers and want a programmatic way to map hostnames to physical locations, LOC is the standards-compliant answer.
Privacy note: LOC is public. If you don't want to advertise your server's physical coordinates to anyone who can run dig, don't publish it.
8. RP: responsible person for security contacts
RP records specify a responsible person for a domain and point to a TXT record with contact details. The format:
example.com. RP admin.example.com. contact-info.example.com.
The first field is an email address in DNS format (admin.example.com means [email protected]). The second points to a TXT record that holds human-readable info.
Why bother when you could just put an email address in a TXT record? Structure. RP is machine-parseable. Automated security scanners, abuse desks, and cert validation tools can query RP and get a standardized result.
In practice, RP has been largely superseded by security.txt files in the /.well-known/ directory. But DNS is sometimes more reliable than HTTP for contact discovery, especially when the web server itself is compromised or unreachable.
I recommend both: an RP record for DNS-based lookups and a security.txt for web-based discovery. Redundancy costs you two lines of config.
Performance and caching implications
Every record type has a TTL, and every lookup costs time. Adding exotic record types increases the size of your zone and the number of queries clients may need to make.
But most of the records above reduce total query load when used correctly. HTTPS records eliminate a round-trip. DNAME consolidates dozens of CNAMEs into one. SRV and NAPTR centralize service discovery so clients don't have to guess.
The exception: TLSA and DNSSEC. DNSSEC signatures add kilobytes to responses and require extra validation. If you enable DNSSEC to support TLSA, monitor response sizes and consider enabling DNS over TCP if UDP responses are getting truncated.
Set TTLs based on volatility. CAA and RP can have long TTLs—86400 or more—since they rarely change. SVCB and HTTPS should have shorter TTLs if you're still tuning parameters. SRV weight changes need to propagate quickly, so 300-600 seconds is common.
What to check first
Start with CAA. It takes two minutes, prevents real attacks, and has zero downside. Then look at your CDN or hosting provider's documentation for HTTPS record support—if they've enabled it, you should too.
If you run mail servers and have DNSSEC, implement TLSA for DANE. The incremental security gain is significant and the operational cost is just keeping the hash in sync with your certificate.
The others—DNAME, SRV, NAPTR, LOC, RP—solve specific problems. Add them when you hit the problem they solve, not before. But know they exist, because the next production issue might be one of them waiting to be used.