I'd like to try to get to consensus on this point, which is one of the last open issues for the draft.
To restate my previous argument, let P_svcb be the probability that a SVCB
record is present, and if so, let P_targethost be the probability that it
contains a TargetName that is the hostname. Then (ignoring Additional
Section processing) the initial AAAA/A query saves (1 - P_svcb) +
P_svcb*P_targethost resolver roundtrips, on average.
Currently, for HTTPS, P_svcb is about 15%(!), and P_targethost is ~100%*,
so this always saves one resolver roundtrip.
For a SVCB-reliant protocol, P_svcb is 100%, so the formula simplifies to
"P_targethost". If P_svcb for HTTPS were to approach 100%, the result
would be the same, even though HTTPS is not SVCB-reliant.
In other words, keeping P_targethost high, and using speculative queries,
is good for performance when SVCB is heavily used.
* Assuming Cloudflare has the only current large-scale deployment of HTTPS
records.
On Tue, Jan 19, 2021 at 10:00 PM Ben Schwartz <bem...@google.com> wrote:
>
>
> On Tue, Jan 19, 2021 at 7:40 PM Martin Thomson <m...@lowentropy.net> 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.
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
