High-performance HTTP clients usually don't worry about the number of DNS queries. Instead, they mainly worry about latency. That makes multi-qtypes a tradeoff in the wrong direction for them.
It's possible that the latency of HTTPS record usage could be improved in some cases if the DNS resolver knows that the client is single-stack. However, this only applies in somewhat unusual cases (e.g. the A record is in cache but the AAAA is not). I've heard a few implementors suggest that they would do the Additional Section processing only using records that happen to be in cache already, in which case there is no additional latency at this stage. --Ben ________________________________ From: Petr Menšík <pemen...@redhat.com> Sent: Thursday, September 12, 2024 4:26 PM To: Ben Schwartz <bem...@meta.com>; dnsop@ietf.org <dnsop@ietf.org> Subject: Re: [DNSOP] HTTPS and SVCB queries with draft-bellis-dnsext-multi-qtypes-08 extension Ah, okay. Thank you for the pointers. I wondered, why such detail is not worked into the draft. It however applies to "a non-conforming recursive resolver" only. It might be used when conforming recursive resolver is used, which fills also additional Ah, okay. Thank you for the pointers. I wondered, why such detail is not worked into the draft. It however applies to "a non-conforming recursive resolver" only. It might be used when conforming recursive resolver is used, which fills also additional answer section. I guess dns cache would have to mark current server supported after first answer is received. Also similarly, recursive resolver when talking to authoritative server might use multi-qtypes single query instead of 3 separate queries. It needs to cache that multi queries is supported. Similar to EDNS0 support indication. Still, there is no other way in the draft to indicate only one of A or AAAA additional record is desired. Spawning 3 queries for a client connected via only single address family network is wasting of CPU cycles. Spawning 3 queries on recursive resolver might be considered prefetch to help other future clients. But if it is acting as caching server exclusively for ipv6 only network, it would be wasting own and remote server resources as well. The same situation applies also to ipv4 only network, which is sadly much more common. I did not mean change meaning of AAAA record. I meant change of qname used for additional query types. But failed to spot this was adopted by dnssd wg [1], not dnsop. And there is more recent version. I think it should be possible to request (TargetName, QCLASS, QTx) of resolved HTTPS/SVCB record, instead of (QNAME, QCLASS, QTx). Because in this case, those replies would be more useful in my opinion. Or maybe both, but it would need modified encoding of negative replies. But because it might result in multiple target names, I guess a new query for that would be always necessary. Regards, Petr 1. https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dnssd-multi-qtypes/__;!!Bt8RZUm9aw!9Tqp1AcKgv7ArXuj1memk31RE667CNlNcSEzTU4kT--tk1g7QLj9hor2FzAJH8Zevj5YqzIkWmCDuQ$> On 12/09/2024 18:09, Ben Schwartz wrote: The situation with HTTPS+AAAA is pretty much the same as A+AAAA: a sufficiently patient client (favoring simplicity over speed) could wait for all the answers to come back, but an impatient (i.e. optimized) client would want each answer as soon as it is ready. Web browsers today are in the latter category. While HTTPS records do support redirection, this is not the common case. RFC 9460 Sections 5 and 10.2 discuss some of these behaviors in more detail. In summary, an optimized client can potentially make use of AAAA responses before the HTTPS record is returned, and SHOULD request all three QTYPEs in parallel. There is no need to change the specified meaning of any returned AAAA records. The HTTPS record type specifies optional Additional Section processing, which permits the server to return the relevant AAAA records (RFC 9460 Section 4.2). --Ben ________________________________ From: Petr Menšík <pemen...@redhat.com><mailto:pemen...@redhat.com> Sent: Thursday, September 12, 2024 5:24 AM To: dnsop@ietf.org<mailto:dnsop@ietf.org> <dnsop@ietf.org><mailto:dnsop@ietf.org> Subject: [DNSOP] HTTPS and SVCB queries with draft-bellis-dnsext-multi-qtypes-08 extension Hello, on discussion at DNS-OARC chat, we have briefly hit that draft-bellis-dnsext-multi-qtypes-08 is a bit problematic to use for A and AAAA addresses, because to be useful, it needs to first wait until first reply arrives. Which at least Linux stub does not do in any case. But I think it might be useful to accompany HTTPS queries made first with additional A and AAAA requests. Why? The resolver, even if serving only local network, might not know which clients are on ipv4 only network, which are on ipv6 only network and which on dual stack. On the other hand, client itself does know that. But I think it does not have clear way defined to indicate to resolver (or caching forwarder) it is using, what kind of addresses it is interested in. When user opens web page, it originally did A and AAAA queries in parallel. It does so unconditionally on Linux, unless AAAA is configured to be supressed. Problem with getaddrinfo() calls is, both responses need to arrive, before it continues to connect() call to initiate connection. There it is not useful. But since HTTPS RR is able to provide redirects similar to CNAME and also hints for addresses, I think modern clients should try HTTPS first and wait for its response, before trying legacy A+AAAA. It would be useful to indicate to it, what address is the client interested in. If the resolver can provide final addresses, after following redirections, inside the same reply, together with HTTPS response, client would not have to make additional query afterwards. It could proceed with connect() and would not make more unnecessary queries, regardless on what type network it is. It could reduce size of responses for clients with only one address family available. I think for HTTPS and SVCB record types, it could be very useful. With a bit modified meaning. In that case, addresses returned should not be for the name in question section, but for final TargetName name(s) of HTTPS/SVCB. What would you think of such modification? Does it make sense to you? Regards, Petr -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer, RHEL Red Hat, https://www.redhat.com/ PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
