Domain verification using DNS

At the Internet Engineering Task Force (IETF), Shumon Huque, Paul Wouters, and I have been working on describing best practices for domain verification using the Domain Name System (DNS). The Internet-Draft, titled ‘Domain Verification Techniques using DNS‘, has been adopted by the DNSOP Working Group as a Best Current Practice document. I began working on this when I was part of a DNS team where we had to deal with several domain verification DNS records.

The idea behind the document is to outline ‘good’ ways of verifying domains using the DNS. An example of domain verification is that every time you get a TLS certificate from Let’s Encrypt, you need to add something like the following TXT record to your DNS:

_acme-challenge.example.com.  IN  TXT "cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L"

In the above example, cE3A8qQpEzAIYq-T9DWNdLJ1_YRXamdxcjGTbzrOH5L is a random token given to you by Let’s Encrypt. This token that proves the person who made the request for a certificate for example.com with Let’s Encrypt is also the person who has control over the DNS for example.com. Consequently, this person should be given a TLS certificate for example.com.

The issue is that domain verification using the DNS, while extremely important to the web’s security, is done in many different ways by different providers (some better than others). For example, here’s a real problem that occurs if you try to query twitter.com for its TXT records (shortened for readability).

$ dig twitter.com txt
;; Truncated, retrying in TCP mode.

...

;; ANSWER SECTION:
twitter.com.		293	IN	TXT	"bj6sbt5xqs9hw9jrfvz7hplrg0l680sb"
twitter.com.		293	IN	TXT	"canva-site-verification=lMnZ3wMh7c1uqZqa-cxZTg"
twitter.com.		293	IN	TXT	"google-site-verification=TNhAkfLUeIbzzzSgPNxS5aEkKMf3aUcpPmCK1_kmIvU"
twitter.com.		293	IN	TXT	"google-site-verification=h6dJIv0HXjLOkGAotLAWEzvoi9SxqP4vjpx98vrCvvQ"
twitter.com.		293	IN	TXT	"loom-site-verification=638c6bc173b9458997f64d305bf42499"
twitter.com.		293	IN	TXT	"miro-verification=6e1ca9ad6d0c2cd2e4186141265f23ed618cfe37"
twitter.com.		293	IN	TXT	"mixpanel-domain-verify=164dda91-31f4-41e8-a816-0f59b38fea30"
...

Look at the first line: “Truncated, retrying in TCP mode.” The response was so large that dig had to fall back from UDP to TCP. This results in fragmentation, which is known to be vulnerable to various attacks. Not all networks properly transport DNS over TCP and some DNS software mistakenly believes TCP support is optional. Plus, it’s just bad for performance.

This overly large response happens because the domain verification records were put at the top-level twitter.com (this is actually pretty common across the Internet; try looking at the TXT records for bbc.com or tesla.com, for example).

A better way would have been to do domain verification the way that Let’s Encrypt does it. That is, put it under _provider-challenge.website-name.com., so that you don’t end up polluting the top-level (also called apex) domain name.

As it stands, a DNS administrator has no idea whether or not they can remove these DNS records once verification has finished. DNS administrators don’t always recognize service providers by name, so might not know if the service is still being used. Plus, the domain verification record is usually a one-time check, but in some cases, the provider wants to continually check for the verifying record.

If a record is accidentally cleaned up and a provider doesn’t see the record it expects, the customer’s privilege will be revoked (for example, revoking the TLS cert). This can be pretty disastrous, so customers just keep these records lying around way past most of them could have been cleaned up, leading to the kind of bloated responses we talked about.

It would be good if there were some recordkeeping metadata attached to these records. For example, instead of just having:

google-site-verification=TNhAkfLUeIbzzzSgPNxS5aEkKMf3aUcpPmCK1_kmIvU

You could have :

google-site-verification=TNhAkfLUeIbzzzSgPNxS5aEkKMf3aUcpPmCK1_kmIvU;expiry=2023/12/31

The draft outlines these problems and solutions. We’ve had great feedback, both on the IETF mailing list and offline. JPRS which handles the .jp domain even cites the draft in their guidance for DNS-based domain verification! If you have any feedback, let me know in the comments below.

Shivan Sahib is a privacy engineer with an interest in privacy-respectful standards and is active in the IETF and W3C, co-chairing groups responsible for Oblivious HTTP and privacy research. Shivan is currently on the Advisory Council of Open Tech Fund’s Information Controls Fellowship.

Adapted from the original post at Pistachio Musings?

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.