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]

Reply via email to