On Fri, 21 Aug 2026, Paul Vixie wrote:
i have not studied the proposed mechanism but i strongly support the goal. the
PSL which underlies the whole TLS universe is still run on a volunteer basis
and we
need to evolve the architecture to support what it does.
The PSL should be a DNSKEY flag, similar to how I proposed
draft-ietf-dnsop-delegation-only
a long time ago. Imagine telling people "you can get on the PSL, just enable
DNSSEC with
this one flag set".
As for draft-barrett-dnsop-domain-set, I also share concerns about what
it means to be on it to an application. And how without DNSSEC, this
signal cannot be trusted.
Section 1.5 talks about the use of defensive registrations that have no
HTTP services, but then I don't see why it should be mapped into
something that makes it equivalent to other domains. Either you want it
to not go anywhere and trust is not needed, or it redirects you, in
which case you would put some HTTP redirect service there?
or when the referenced manifest is retrieved over HTTPS with a
certificate valid for the publishing domain and hosted at the publishing
member's own registrable domain (or a subdomain of it).
This means one website compromised means one can update the domain set,
include a malicious entry, and exploit this.
But what I still don't understand is how an (agentic) consumer/client is
supposed to use any of this?
Why would Big Bank want to link bigbank.com to bigbank.ca to bigank.com
to bigbank100yearanniversary.com ? That is, what is the use case for
this protocol ? Why do agents needs to know these links? What can they
do with this, that they cannot do right now?
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
