[DNSOP] Re: I-D Action: draft-ietf-dnsop-domain-verification-techniques-12.txt

[Ben Schwartz <[e-mail]>]

Review:

Section 1:

> In practice, DNS-based methods take the form of the Application Service Provider generating a Unique Token and asking the requester to create a DNS record containing this Unique Token and placing it at a location within the domain that the Application Service Provider can query for.

This sentence now seems to be in tension with the existence of draft-ietf-acme-dns-persist.  Perhaps it could be fixed by adding the word "often" or replacing the word "token".

(Also, run-on sentence.)

I continue to see major issues with this draft, somewhat related to that sentence:

1. While this is certainly a current practice, I don't believe that it is a very good one.
- A point-in-time validation that someone controls the content of a TXT record is not a logical basis on which to take any persistent action, and most actions of interest are persistent.
- Opaque tokens make the function of each record difficult to determine.  In practice, this contributes to zone cruft, in which unneeded records are not removed because their purpose is unknown.

2. The draft makes numerous, sometimes conflicting assumptions without clearly stating them.
- It seems to assume that each domain-associated permission has some kind of revalidation timescale that is known to all participants.  (Otherwise, how would I know how long I have to wait after acquiring a new domain name before I can be sure that it is safe to use?)
- It seems to assume that anyone with the ability to populate a TXT record on _$SPECIAL.$FOO can also modify any records on $FOO.  Sometimes, it also assumes that this power extends to all other names below $FOO (for wildcards), perhaps because of the assumed ability to populate NS records?
- It assumes that this party is the "owner", and is authorized to make use of this domain name outside of the DNS in unspecified other ways.  (But it also assumes that there is a distinction between this "owner" and the "owner" of the zone.  In general, individual DNS names are not described as having "owners", and the draft does not define "owner".)
- It assumes that anyone who allows a third party to choose names within their zone either (a) has registered in the PSL or (b) prohibits the third party from choosing underscore-prefixed names.  (Zone owners are not currently subject to any normative obligation to comply with either assumption, and the draft does not add one.)
- It assumes that the zone administrator intrinsically knows why the record is in place, but doesn't intrinsically know how long it is needed.

These assumptions may be reasonable, but that doesn't mean they go without saying.

3. It imagines that the acquirer of a domain might leave records from the previous owner in place, even when the purpose of those records is not known to the new owner ("accidental persistence").  This would be wildly insecure for most DNS record types, including ACME dns-persist-01.  In my view, including unauthorized records from someone else amounts to giving them control of the domain.  This problem is exacerbated by the use of opaque tokens.

I see real value from this draft for "harm reduction".  Right now, many domains are building up absurdly huge TXT RRSets at the zone apex, full of records that probably could be deleted but no one knows for sure.  Moving these to unique underscore domains and adding "expiry" tags is a clear improvement.  Including plenty of entropy is probably good too.  But in my view, this whole practice is built on very fuzzy security aims and unstated assumptions about conventional zone management practices and service account situations.

The actual "best practice", in my view, looks like dns-persist-01, CAA, SPF, or TLSA: a persistent record that clearly authorizes designated parties to take particular actions in the name of this domain.  DCV is only the "best practice" when the confidentiality loss of exposing these authorization details outweighs the benefits of clarity and auditability.  "Ephemeral" DCV is perhaps justifiable as a form of "proof of work", but it is hard to imagine a use case where the "point in time" validation semantic is desired.

This draft's version of DCV is certainly a "better practice" than many current deployments of DCV, and I support publication on that basis.  For this draft, I would like to see:
1. A disclaimer limiting the scope of applicability, distinguishing "anti-abuse" measures from formal "security" elements.  (In ACME, it is the CAA record, not the DNS challenge, that establishes formal security!)
2. A collection of all the draft's assumptions about zone management and ownership in one section.  (Note that the draft expects that all zones comply with these assumptions, even zones that are not making use of this specification!)
3. Exclusion of "accidental persistence" from the threat model, since any such zone is hopelessly compromised anyway.

--Ben Schwartz
________________________________
From: [e-mail] <[e-mail]>
Sent: Monday, March 2, 2026 5:19 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-domain-verification-techniques-12.txt

Internet-Draft draft-ietf-dnsop-domain-verification-techniques-12.txt is now
available. It is a work item of the Domain Name System Operations (DNSOP) WG
of the IETF.

   Title:   Domain Control Validation using DNS
   Authors: Shivan Sahib
            Shumon Huque
            Paul Wouters
            Erik Nygren
            Tim Wicinski
   Name:    draft-ietf-dnsop-domain-verification-techniques-12.txt
   Pages:   23
   Dates:   2026-03-02

Abstract:

   Many application services on the Internet need to verify ownership or
   control of a domain in the Domain Name System (DNS).  The general
   term for this process is "Domain Control Validation", and can be done
   using a variety of methods such as email, HTTP/HTTPS, or the DNS
   itself.  This document focuses only on DNS-based methods, which
   typically involve the Application Service Provider requesting a DNS
   record with a specific format and content to be visible in the domain
   to be verified.  There is wide variation in the details of these
   methods today.  This document provides some best practices to avoid
   known problems.

The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjyQA6i3LA$

There is also an HTML version available at:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-verification-techniques-12.html__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjy5LqDrIg$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-domain-verification-techniques-12__;!!Bt8RZUm9aw!8p43GN4-R7EjNLCrk-sXFashKhTQYA23eK6kJB_hoCMHg3Y87hWXYf5CAxlkJ9arYBDdCdrixXyVmjyQD0wTUQ$

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
DNSOP mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]