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
OpenPGP_0x4931CA5B6C9FC5CB.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
