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. Image
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. Image
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. Image
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: Image
IP Geolocation via the DNS is a thing by way of GPOS and LOC RRs. Take that, MaxMind! Image
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. Image
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: Image
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 ImageImage
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: Image
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 Image
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… Image
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? Image
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 Image
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!

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Jan Schaumann (@jschauma@mstdn.social)

Jan Schaumann (@jschauma@mstdn.social) Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @jschauma

May 14, 2023
Remember the X.509 PKI? You know, the one that gave us

- "Oh wait, certificate revocation is basically all broken"
- The One Where That Dutch CA Issued A Fraudulent *.google.com Cert

and my all-time favorite:

- Honest Ahmed's Used Cars & Certificates
bugzilla.mozilla.org/show_bug.cgi?i…
It's great, because it secures virtually all web traffic, and all you have to do is get a certificate from a certificate authority -- any one at all!

Don't be picky: there are literally hundreds in your trust bundle: ImageImage
But you probably would want to allow only a very small number of CAs to do that.

What can you do?

For a while, we tried dynamic HTTP Public Key Pinning (HPKP, via the Public-Key-Pins header).

But, TOFU issues aside, that was a big footgun, so we deprecated that swiftly.
Read 33 tweets
Mar 10, 2023
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?
Read 25 tweets
Nov 16, 2022
Who controls the internet?

A Twitter 🧵 (if those still work) about diversity of authoritative NS records in gTLDs:
Why yes, the internet is resting on a foundation of duct tape and WD40, aka the DNS.

(Yes, yes, obligatory XKCD.)
Let's start by gathering zone files.

First, there's the root zone itself: iana.org/domains/root/f…

Next, you can request all gTLD zone files here: czds.icann.org

.gov is here: github.com/cisagov/dotgov…

And .arpa can be AXFR'd from most of the root servers.
Read 29 tweets
Oct 25, 2022
Time is an illusion, Unix time doubly so.

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":

bell-labs.com/usr/dmr/www/pd…
Read 32 tweets
Aug 31, 2022
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'.
Read 39 tweets
Jul 18, 2022
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):
Read 36 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(