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 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
The situation with HTTPS+ is pretty much the same as A+: 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 latt
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 ha
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 reso
Reviewer: Klaas Wierenga
Review result: Ready
My review comments on an earlier version have been sufficiently addressed, so
as far as I am concerned this version is ready for publication.
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an
Dne 12. 09. 24 v 22:26 Petr Menšík napsal(a):
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.
I'm quite an op
