On Fri, Jan 22, 2021 at 12:43 PM Hollenbeck, Scott <shollenbeck= 40verisign....@dmarc.ietf.org> wrote:
> *From:* DNSOP <dnsop-boun...@ietf.org> *On Behalf Of * Ben Schwartz > *Sent:* Tuesday, January 19, 2021 10:01 PM > *To:* Martin Thomson <m...@lowentropy.net> > *Cc:* dnsop <dnsop@ietf.org> > *Subject:* [EXTERNAL] Re: [DNSOP] SVCB without A/AAAA records at the > service name > > > > > > > > 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. > > > > > *[SAH] We need to think about the impact on the servers that have to > respond to those queries, too. Sending unnecessary queries to the root and > TLD servers puts a load on those servers that can have an impact on every > client/resolver that needs to be able to reach them.* > This is important, but I don't think it's applicable here. The various options under consideration all impose the same amount of load on root and TLD servers.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
