[DNSOP] Re: New I-D: draft-barrett-dnsop-domain-set-00 - T he Domain Set Discovery Protocol (seeking dispatch guidance)
Paul Wouters <[email protected]>
| Newsgroups | gmane.ietf.dnsop |
|---|---|
| Message-ID | <[email protected]> |
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]