On Wed, Jan 20, 2021, at 09:17, Ben Schwartz wrote:
> As I noted in that discussion, the client generally doesn't know in
> advance that they aren't needed.
I am asserting that the client very much knows. Indeed, it has to know. If we
define a new protocol that relies on SVCB and that protocol is able to use SVCB
exclusively (which would be a good thing in my view, all this parallel DNS
querying is unnecessary, even if the DNS protocol is pretty good at it), then a
client can very much know.
> Another thing I like about the arrangement in #288 is that it
> simplifies a protocol-independent app/library boundary. The app can
> say "SVCBQuery(hostname, prefixes)" and get back a fully resolved
> object like {svcbEntries: [{...}, ...], hostIPs: [...]}.
I'm suggesting that the interface might be a little wider. If the interface is
provided with a scheme, them the library might be able to lookup the scheme and
know whether A/AAAA is needed, but it might be better to have a very different
interface for those protocols that might need fallback as opposed to those that
don't.
A protocol might genuinely need SVCB. If additional SVCB information is
critical to the operation of the protocol (think ECH here, but there might be
other reasons for this), then the API might look like (eliding the attr-leaf
and prefixing stuff):
svcb.query(name) -> svcbEntry[] // where the API fills in an address (or
addresses) for each svcbEntry
This is far more ergonomic for something that doesn't care about A/AAAA. And
less wasteful. If a fallback is possible, then you get something very
different, which requires additional logic to handle:
svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
