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<mailto: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 a further motivation for the resolver to implement qname minimization with a single resource record type. It might be worth reading this blog post to get a better understanding of the impact of another recent source of unintended additional queries to the root servers: https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traffic/ Scott
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
