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> Sent: Thursday, September 12, 2024 5:24 AM To: dnsop@ietf.org <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
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
