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/
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>
*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
--
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
