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.
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:
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...
Who reads your email? Ok, ok, nobody does. Even you don't want to, I know. But... who _could_?
A 🧵 about centralization of MX records across gTLDs:
SMTP relies on MX records in the DNS to identify which server(s) it should hand the mail off to, and over 40 years after RFC722 was published, email is still cleartext.
Together, this means that any receiving mail server can trivially read any message passing through.
It used to be common for domain operators to run their own mail servers, but doing that is actually hard. And what do we do when things are hard? We pay somebody else to do it for us. To the cloud!
So I was wondering: how much is SMTP centralized in 2023?
A Twitter 🧵 coming live at you at a palindromic 1666666661...
As you well know, on Unix systems we measure time as the number of seconds since "the epoch": 00:00:00 UTC on January 1st, 1970.
This has made a lot of people very angry and been widely regarded as a bad move.
How did we get here?
It all began back in 1971, when the First Edition Unix Programmer's Manual defined Unix time as "the time since 00:00:00, 1 January 1971, measured in sixtieths of a second":
Hey, so y'all know SPF, the Sender Policy Framework, right?
It's straight forward, isn't it? I mean, client connects, you check envelope-from, client IP, and (what else) a DNS record, and then make your call.
Well. Turns out there's (a bit) more to it. Let's take a look...
Simple example:
We try to send mail pretending to be from Microsoft through Yahoo's mail server.
Yahoo looks up microsoft.com's TXT records, finds our sending IP is not authorized, and rejects our mail.
Neat, right? RFC7208 defines a number of qualifiers and mechanisms. You'll mostly encounter 'a', 'mx', 'include', 'ip4', and 'ip6', ending with 'all', all optionally prefixed with one of [+?~-].
But there's also 'ptr', 'exists', and the "modifiers" 'redirect' and 'exp'.
Pop quiz: what is the maximum size of a DNS response?
Everybody Knows(tm) that your DNS response MUST fit into 512 bytes, because that's the size of a UDP packet. Right?
Let's pretend that's true. How many A records can you put into a round-robin?
Here's a name that will return a bunch of A records and still fits into 512 bytes:
This returned 28 A records. So far, so good. But 28 IPv4 addresses is only 28 * 4 bytes = 112 bytes. Shouldn't we have been able to add a whole bunch of IPv4 addresses more?
Let's take a look at what the packets actually look like, using tcpdump(1):