A realization about using DNS sub-names in modern protocols like DMARC

February 22, 2022

I was adding DMARC DNS records to some of our domains today, and the process of doing this made me realize something about how modern protocols that use the DNS structure their interactions with it. Famously, the way you add arbitrary information to DNS is with DNS TXT records, which take basically arbitrary text. However, there are two approaches to where this information goes, the old approach and the new one.

In the old approach, your DNS TXT record or records go directly on the domain or subdomain they're for. For example, SPF records go directly on the domain that they're for:

; dig +short txt google.com | grep spf
"v=spf1 include:_spf.google.com ~all"

In the new approach, some of your DNS TXT records are deliberately put on fixed sub-names of your domain, usually sub-names that involve an underscore. For example, DMARC records go on '_dmarc.<whatever>':

; dig +short txt _dmarc.google.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

DKIM keys are similarly put on sub-names that are composed not only of a fixed portion but also of a name for the key (the DKIM selector), giving you DNS names such as 20210112._domainkey.gmail.com:

; dig +short txt 20210112._domainkey.gmail.com
"v=DKIM1; k=rsa; p=[....]

(As I write this entry, gmail is still signing messages with this DKIM selector, which I assume was created more than a year ago. I can't throw stones, since we aren't rotating our DKIM keys either.)

One thing this new approach does is keep down the number of TXT records directly attached to the domain apex, which is valuable in its own right (those things add up and it's nice if DNS responses are kept small). But another thing it enables is replacing direct records with CNAME records to a canonical version. If you have a bunch of domains or subdomains, you don't have to put a bunch of DMARC records or DKIM records into all of them; you can put the actual master record in one and then CNAME everything else to it.

Of course, sometimes a protocol that signals things through DNS doesn't want people to be able to delegate this signal off to another domain. I was going to say that Let's Encrypt is an example of this, but they actually use a sub-name in their DNS-01 challenge and document that you can use CNAMEs and other DNS delegation. But broadly, if you want to force people to demonstrate ongoing control of a domain on demand, you want to require that they put the signature TXT record in the domain itself instead of in something that can be CNAME'd to elsewhere.

(Otherwise an attacker only has to control their DNS long enough to insert a CNAME record that points to somewhere else. Such an inserted CNAME record might linger for a long time without being noticed.)

Of course I suspect that a bunch of sites require you to put TXT records directly on your domain mostly to simplify their life (or just because it never occurred to them to do otherwise). That way they don't have to come up with a sub-name of their own, for example.

(Now that I've looked, it's amusing just how many TXT records major domains like apple.com, google.com, microsoft.com, and amazon.com have. Google even has two 'google-site-verification' records on google.com.)

Written on 22 February 2022.
« Python's Global Interpreter Lock is not there for Python programmers
Some early notes on Dovecot namespaces (in Dovecot 2.2.33, currently) »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Feb 22 22:32:55 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.