Domain verification using DNS

By on 26 Jun 2023

Category: Tech matters

Tags: , ,


Blog home

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:  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 with Let’s Encrypt is also the person who has control over the DNS for Consequently, this person should be given a TLS certificate for

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 for its TXT records (shortened for readability).

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


;; ANSWER SECTION:		293	IN	TXT	"bj6sbt5xqs9hw9jrfvz7hplrg0l680sb"		293	IN	TXT	"canva-site-verification=lMnZ3wMh7c1uqZqa-cxZTg"		293	IN	TXT	"google-site-verification=TNhAkfLUeIbzzzSgPNxS5aEkKMf3aUcpPmCK1_kmIvU"		293	IN	TXT	"google-site-verification=h6dJIv0HXjLOkGAotLAWEzvoi9SxqP4vjpx98vrCvvQ"		293	IN	TXT	"loom-site-verification=638c6bc173b9458997f64d305bf42499"		293	IN	TXT	"miro-verification=6e1ca9ad6d0c2cd2e4186141265f23ed618cfe37"		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 (this is actually pretty common across the Internet; try looking at the TXT records for or, 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, 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:


You could have :


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.


  1. Peter Lowe

    This is an excellent document and I hope it’s adopted in as many places as possible in the future. I think it’ll be a hard slog though, given how so many people are doing things at the moment – but as has been pointed out, that’s exactly why a document like this is needed.

    Not trying to shill here, but it might be of interest that I included some stats on how often domain verifications appear in an analysis of a top 1m list of domains’ TXT records:

    Out of the 595,398 TXT records found, 402,230 of them were for domain verifications of various kinds. It’s the #1 use of TXT records for this dataset by far!

    Raw text file of all those records here:

  2. Shumon Huque

    Interesting analysis Peter. Thanks for sharing that work. You might consider presenting it at a venue like DNS-OARC.

    The latest (and improved) version of our document (published yesterday) is available at:

  3. Shumon Huque

    Interesting analysis Peter; thanks for sharing. You might consider presenting it at a venue like DNS-OARC.

    Note: the latest (and improved) version of our document, published yesterday, is available at

  4. cs.lev

    Excellent write-up, thanks for that and also for implicitly reminding me why CNAME records cannot have any other records 😀

    So, eventually, you say that subdomain-based methods, like the one Let’s Encrypt uses, are considered “good” approaches?

    Or what if we were using DNS HTTPS RR for this purpose. Although it would sound like the case of the TXT record in the beginning (when there are only 1 or 2) and can potentially be bloated as time passes (as Peter Lowe showed us), it would not require introducing a new RR type. Today, our browser already uses HTTPS resource records of DNS for finding QUIC-based access faster than several extra roundtrips and HTTP redirects.
    HTTPS RR is also used for Encrypted Client Hellos.
    I think, since we all talk about certificates and secure websites, it would make sense to utilize HTTPS records for the same purpose.

    Note, I am not sure whether this is any better than the subdomain-based approach. Initially, the precursor of ECH, eSNI, is also using a subdomain-based trick for getting the public key to encrypt the SNI field in the TLS handshake.
    What do you think about these two approaches?


Leave a Reply

Your email address will not be published. Required fields are marked *