Re: [DNSOP] SVCB without A/AAAA records at the service name

[Ben Schwartz <[e-mail]>]

On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <[e-mail]> wrote:

> 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.
>

Querying in parallel is of course just an optimization, but the client
can't obviously know that those queries won't be needed, even for a
protocol that uses SVCB exclusively.

Every SVCB mapping ultimately relies on A/AAAA records for the ServiceMode
TargetName.  The client doesn't know what that TargetName will be until it
gets the SVCB response.  However, in every protocol considered thus far,
the most likely TargetName is the original hostname (or its CNAME alias).
By querying that name in parallel, the client can short-circuit a
subsequent lookup and reduce latency.  This has nothing to do with fallback.

Section 10.2 ("Structuring zones for performance") takes this observation
and turns it into a recommended convention for the use of TargetName.  You
can place TargetName anywhere, but if you can line it up with the hostname
you'll get better performance, so that's recommended.

If I were arguing for your version, I would say either:
1. By the time we have SVCB-reliant protocols, nearly all resolvers will
have implemented Additional Section processing, so the client won't have to
issue A/AAAA queries at all.
OR 2. There will be SVCB-reliant protocols where it is normally
inconvenient to use A/AAAA records on the hostname, so the client knows
that the TargetName->hostname convention doesn't apply.

Personally, I don't believe either of those things ... and since they're
both predictions about future standards, we can always clarify in the
future.

It's worth noting that the sentence in question (Section 3 point 2) has no
normative force.  That section is just describing what clients are expected
to do.  So if you want to do it differently ... whatever works.

> 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.


Sure, that's fine too.

...

> svcb.query_with_fallback(name) -> Either<svcbEntry[], address[]>
>

Nit: Pair<svcbEntry[], address[]>.  If the svcbEntries are all unreachable,
clients SHOULD fall back to bare IPs.