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: [email protected] <[email protected]>
Sent: Monday, March 2, 2026 5:19 PM
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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 -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
