Preventing NAPTR Spam

You're the sort of cool nerd who knows all the weird esoterica which makes up DNS, right? In amongst your A, AAAA, SOA, and MX records, there's a little used NAPTR. Yes, you can use DNS to store Name Authority Pointers!

What?!

It is yet another of those baroque standards which spits out things like:

cid.uri.arpa.
;;       order pref flags service        regexp           replacement
IN NAPTR 100   10   ""    ""  "!^cid:.+@([^\.]+\.)(.*)$!\2!i"    .

Essentially, it is a way to store contact details within a DNS record (rather than in a WHOIS record).

Back in the early 2000s, the dotTel company opened the .tel TLD with a promise that it could be used to store your contact details in DNS⁰. The idea was simple, rather than storing my phone number in your address book, you'd store my domain name - https://edent.tel/

If I updated my phone number, changed my avatar, or deleted an old email address - your address book would automatically update via DNS. Nifty!

If you didn't know a company's phone number, you'd dial example.com on your phone and it would grab the phone numbers from DNS. Wowsers trousers!

You can see an example by running:

dig justin.tel NAPTR

You'll get back something like:

NAPTR   100 101 "u" "E2U+web:http" "!^.*$!http://justinkhayward.com!" 

A phone number stored in a NAPTR would look something like:

NAPTR   100 100 "u" "E2U+voice:tel" "!^.*$!tel:+442074676450!" .

Brilliant! But there's a problem - aside from the somewhat obtuse syntax! - and that problem is spam.

Those of you old enough to remember putting your unexpurgated contact details into WHOIS know that the minute it went live you were bombarded with sales calls and scammy emails. So putting your details directly into DNS is a bad idea, right?

.tel thought they'd come up with a clever hack to prevent that. As they explain in the .tel privacy paper, records can be individually encrypted.

• Alice has her contact details on alice.tel
• Bob has his contact details on bob.tel
• Alice agrees to share her phone number with Bob.
• Alice looks up Bob's public key from bob.tel.
• Alice encrypts her phone number.
• Alice generates a new DNS record specifically for Bob - bob123456.alice.tel
• Alice shares the name of the new record with Bob.
• Bob downloads the NAPTR from bob123456.alice.tel and decrypts it with his private key.
• Bob periodically checks for updates.
• Alice can decide to revoke Bob's access by removing the data or subdomain.

Clever! If convoluted. You can read more about the way friendships and public keys were managed and some more technical details.

Are there better ways?

Multi Recipient Encryption

When people say "you can't give Government a secret key to your private messages" they are technically incorrect¹. Multi Recipient Encryption is a thing.

Here's a very simplified and subtly wrong explanation:

• Alice creates a temporary public/private keypair.
• Alice encrypts some text with her temporary public key - resulting in e.
• Alice encrypts the temporary private key with Bob's public key - resulting in k1.
• Alice encrypts the temporary private key with Charlie's public key - resulting in k2.
• Alice publishes the concatenation of e+k1+k2
• Bob downloads the file, decrypts his version of the key, and uses that to decrypt the message.
• Charlie does the same.

In this way, both recipients are able to decipher the text but no one else can. So can we just shove an encrypted record in the NAPTR? Not quite.

There are two main problems with this for DNS purposes.

1. The encrypted size grows with every recipient.
2. Every time a new recipient is added, everyone needs to download the data again even if it is unchanged.

Generally speaking, DNS records are a maximum of 255 characters - although they can be concatenated.

An extra record could be used to say when the plaintext was last updated - which would let existing recipients know not to download it again.

Monitoring for changes would allow a user to know roughly how many recipients had been added or removed.

What other ways could there be?

What else could be done?

Here's the user story.

• I want a friend to subscribe to my [phone|email|street|social media] address(es).
• I must be able to pre-approve access.
• When I change my address, my friend should get my new details.
• I need to be able to revoke people's access.
• This should be done via DNS ² .

Using an API this would be playing on easy mode. A friend (or rather, their app) would request an API key from my service. I would approve it, and then ✨magic✨.

DNS isn't technically an API although, with enough effort, you could make it behave like one³.

So - how would you do it?