> On 16 Sep 2026, at 18:42, Ben Schwartz <[email protected]> wrote: > > On Wed, Sep 16, 2026 at 12:42 PM Jim Mozley <[email protected]> wrote: > ... >>> On the content: It seems like the main potential benefit of this >>> proposal is to fail faster in certain cases, by skipping HTTP requests >>> that would return a 404 response. For this to work, the SvcParam >>> needs to be specified as an exhaustive list of all .well-known/ >>> endpoints on the host. (Otherwise, absence from the list does not >>> allow the client to skip the HTTP request.) However, many HTTP >>> origins have a large number* of resources available in .well-known, >>> which would result in bloated HTTPS records. >> >> Having a fixed list seems impractical as DNS server implementors would need >> to keep up with changes to registered well-known suffixes. > > I don't understand what you mean by "a fixed list".
I thought you were suggesting that a fixed list of URI suffixes would used, which would mean every time a new suffix is added it would need to be added to the list of possible well-known values. Our intention is to advertise selected resources, such as an agent card, rather than provide an exhaustive list. If the resource a client needs is not advertised, it can try the well-known URI. We can say in the draft that if a client does not find what it wants, the process behaves exactly as it does today. > >> One of the benefits we wanted to highlight is effectively saying these >> well-known suffixes are present, rather than a client trying one or more >> speculatively. > > OK, but in the current draft, if the suffix is absent from the > SvcParamValue, the desired resource might still be present at the > origin, so the client cannot safely skip the "speculative" request. The well-known SvcParamValue(s) are optional in the sense that a client can use them or not. So a client can use the supplied well-known values or try something else if it wanted, but it would signal to the client the resources to use. > The client makes the same request either way, so the SvcParam doesn't > change the client's behavior at all. The client is always in control, it is being supplied with information via the parameters. Where a client has more capability to decide what it wants to do (such as an AI agent) signalling resources available is intended to support the decisions it may make via advertising the available resources. > > ... >>> There are also operational friction concerns: adding and removing >>> .well-known resources now requires updating two different systems, and >>> errors may occur when they disagree. >> >> That could also be said of ipv4hints, services might change IPs due to >> availability. > > Yes. ipv4hint is an optional optimization with two key properties: > (1) it improves performance under a specific set of assumptions, and > (2) it never impairs availability if the SvcParamValue is incorrect or > outdated. This specification does not appear to meet both of these > criteria (at least not simultaneously). Hopefully this address that: (1) Hope the above helps address some of this. In addition, if a query results in an RRset with different values for well-known (and other parameters) the client can make a more informed decision based on the parameters. The client can take the positive approach of using the well-known resource(s) first, and then falling back to trying other resources speculatively if it wants to. The client can be presented with a two choices via two records in an RRset and select protocol A with well-known resources A.1,A.2 or protocol B with well-known resource B.1. (2) The client is always free to ignore well-known if it wants, just like with ipv4hints, and try something else. If the client has a different expectation of well-known or the operator of the service wants to use well-known as a means of signalling a change of the resources available then this helps the client with discovery of resources. I see this as a potential operational benefit as in addition to efficiency. > > ... >>> Given these issues, and the obvious security concerns, >> >> Can you be specific with these concerns? We have some thoughts in the >> Security Considerations section of the draft, were you referring to these or >> something else? > > From the current Security Considerations, I'm still not able to > discern what clients are allowed to do with this SvcParam. For > example, if clients use this SvcParam to skip fetches of desired > .well-known resources because it infers that they are absent, then > this allows a DNS attacker to cause the client to misunderstand the > status of those origins. The assumption here is that the operator of the service pointed to by the DNS record is managing the zone, and so controls what is in all parameters such as well-known, ipvhint, port, etc. An on-path attacker could be tampered with records in transit, but I don’t see how this is different to altering any other RDATA. Just as with any other DNS response the client then makes any decisions such as deciding to connect to the end point, if it needs to establish trust, etc. Thanks again for the feedback, Jim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
