Thread by @jschauma

Just how much stuff can we stash in the DNS?

A Twitter 🧵 of Resource Records:

Ok, we all know the common resource records:

A - IPv4 address
AAAA - IPv6 address
CNAME - kinda like a symlink
NS - name server
MX - mail server
PTR - reverse IP to name
TXT - domain validation and 500 other things

Before AAAA records, there were A6 records, which included the ability to advertise prefixes.

And you can use the DNS to announce entire address prefix lists using the APL record.

CNAMEs, for example, are great, because you can point a name to another one.

So you get entire CNAME farms and redirector services for all your name- and typo-squatting domains, as well as to put just about every vanity product name into your second-level name.

CNAMEs are not so great when you then get cert errors, accidentally leak cookie scope, or create a loop. Like... cname.dns.netmeister.org. or cname01.dns.netmeister.org.

You've probably seen CAA records, which define which Certificate Authorities are allowed to issue a cert for a given name. Neat.

Only problem here is that they do not play well with CNAMEs.

Yo, I heard you liked CNAMEs, so I put a DNAME into your CNAME so you can redirect the entire domain. Add a wildcard label and you got all your bases covered.

Do you remember HINFO? Used to tell the world what CPU and OS your system runs. (Although @Cloudflare nowadays returns HINFO when receiving a QTYPE=* query.)

You also what to tell everybody what ports you have open? No prob, use the Well Known Services (WKS) record:

IP Geolocation via the DNS is a thing by way of GPOS and LOC RRs. Take that, MaxMind!

But the DNS is a phonebook, right? So how about we stash actual phone numbers in there? Like... ISDN, or X.25.

And who needs ARP if we have a distributed database / phonebook? We can just do MAC address lookups via EUI48 / EUI64 RRs.

In the history of the internet, not a single person has ever validated an SSH hostkey.

SSHCA host certs can avoid that whole mess, but the SSHFP RRs predate those:

But for SSHFP records to be able to be trusted, we need DNSSEC. Which comes with its own list of RRs:

CDNSKEY, CDS - child copies of ↴
DNSKEY, DS - pubkey and hash of pubkey
RRSIG - signature of record set
NSEC, NSEC3 - next record and next hashed record

Oh, and if you have DNSSEC, then you really don't need a PKI relying certificate bundles containing hundreds of CA certs you somehow have to trust because... people give them money?

Use TLSA records instead:

Which gets us to the various ways we stash keys and certificates into the DNS:

CERT - for x509, S/MIME, PGP, IPSec
OPENPGPKEY
IPSECKEY
KEY - for use with => SIG(0) / TSIG / TKEY
SMIMEA

But the DNS is also more broadly used for all sorts of service discovery.

You may know the SRV record, frequently used for e.g., kerberos (_kerberos._udp.<realm>), but there's also a URI RR, and the newer SRVB and HTTPS records:

datatracker.ietf.org/doc/draft-ietf…

All sorts of different protocols outsource discovery to the DNS, ranging from slightly unusual:

AFSDB - Andrew File System database
AVC - IP Flow Information Export (IPFIX)
HIP - Host Identity Protocol
KX - Key Exchange Delegation
PX - Mime Internet X.400 Enhanced Relay (MIXER)

...to the obscure:

AMTRELAY - Automatic Multicast Tunneling
DOA - Digital Object Architecture
EID, NIMLOC - Nimrod Routing Architecture
L32, L64, LP, NID - Identifier/Locator Network Protocol
NAPTR - Dynamic Delegation Discovery System
NSAP - Connectionless-mode Network Service

You probably know about the SOA record (you know, serial, contact, refresh, expire etc.), but did you know that there's also an RP (responsible person), a NINFO (generic info about the zone) as well as a ZONEMD (digest of the entire zone) record?

The MX record is used to define the Mail Exchange delegation and replaced a number of older RRs, but some of them have not yet been fully obsoleted:

MB - mailbox
MG - a mail group; effectively a mailing list implementation in the DNS
MINFO - list admin info
MR - a mail rename

Talking about email, the Sender Policy Framework got its own record: SPF

Which... nobody uses, because we collectively decided to just stuff anything else into the kitchen sink of resource records. No, not SINK (tools.ietf.org/html/draft-eas…) -- TXT

TXT is used to, amongst other thing:

- discover PGP keys
- combat spam via SPF, DKIM, and DMARC
- add SMTP Strict Transport Security (MTA-STS)
- enable SMTP TLS reporting

Certificate authorities, Facebook, Google, Microsoft, Apple, Amazon, and every other cloud service in the world uses TXT records for domain authentication.

Nobody ever removes old TXT records, though, so the DNS also becomes a great OSINT tool...

Anyway, the DNS is wild. :-)

All of the above (and a few bits more) in a single blog post:
netmeister.org/blog/dns-rrs.h…

A zone file that serves each record is here:
github.com/jschauma/dns-r…

Peace out, and remember to enable DNSSEC and not to monkey with /etc/hosts!