Hi Kishore, a comment below... > On 30 May 2026, at 20:14, S Kishore <[email protected]> wrote: > > > • Drop the HTTPS record mode. "HTTPS" records are for improving the > bootstrapping of HTTP connections, not for identifying affiliated services > that happen to use HTTP. Using a TXT record here may be ugly but at least it > matches the common practice in email world (DKIM, SPF, etc.). We can also > define a new RR type. > > • Yes, that sounds like the right thing to do. TXT should be the > canonical DKA designation record.
We have been looking at a similar case for an organisational agent index in https://datatracker.ietf.org/doc/draft-mozleywilliams-dnsop-dnsaid/ and proposed an SvcParamKey for a well-known value such as "/.well-known/domain-key-authority” to address the point below. In draft-mozleywilliams-dnsop-dnsaid we’re proposing an SVCB record and to us it doesn’t seem to be a good idea to use TXT records when it is possible to get a more defined set of key-value pairs, including existing ones such as alpn and ipv[46]hint, as well as indirection via "Owner IN SVCB TargetName", where TargetName could be a different domain from the owner. We are allowing for a protocol suite though, such as alpn=mcp,h2,h3, so perhaps this is less relevant in your case. > > • Note that DNSSEC is mandatory. This is presumably for discovery of > public encryption keys (not signing keys, which can be accompanied by a > signature chain), so the required security level is very high. Mandatory > DNSSEC is very limiting, so you might want to support > "https://example.com/.well-known/domain-key-authority" as an alternative that > will often be easier to deploy. > • Just a point of clarification: DNSSEC is not mandatory in the > draft; it is recommended. > • A .well-known URL is an interesting suggestion, but I do not think > it is the right architectural mechanism for DKA designation. The DKA is a > domain-level infrastructure function: it identifies the service that is > authoritative for public keys associated with email-address identifiers under > that domain. That kind of designation belongs at the domain/DNS layer, not in > an application-level HTTP resource. > • A .well-known pointer would also not eliminate the underlying DNS > security dependency. A client still has to use DNS to reach the HTTPS origin > serving that .well-known resource, so absent DNSSEC, both the DNS-based > designation and the .well-known alternative remain vulnerable to DNS > redirection at discovery time. > Cheers, Jim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
