On Fri, 20 Sep 2019, Niall O'Reilly via curl-library wrote:
Dedicate additional slots, perhaps per (data-type, origin) rather than per
QTYPE, as some QTYPEs are re-used for different purposes using distinct
QNAME prefixes.
More thought seems needed here. I'm minded to prototype a solution and have
feedback on its appropriateness.
Yes, I like that too. This stuff tends to get easier when you have actual code
to try out the different takes with.
* Choose a structure for caching returned data, as existing (hostname,
port, address) tuples cannot represent all the significant data items
(QNAME prefix, QTYPE).
Rather than a shared cache as used at present for address (A/AAAA) data, a
per-request or per-easy data structure seems good for a first attempt.
Agreed. Start out with a simple and basic approach anda we can expand later if
deemed suitable.
* Decide what DNS-derived data must be present before advancing the
connection state machine.
Existing behaviour is to wait for all launched dohprobe transactions to
complete, even though (modulo protocol-specific reachability) either an IPv4
or an IPv6 address should be sufficient.
This is also matching the regular getaddrinfo() behavior. I think that's a
topic for the category "optimizations we can consider later".
Looking ahead to ESNI, relevant key data might be published either as TXT
with prefix or as TYPE65439 (pending standardization) without prefix, so two
transactions have to be launched.
And the TXT one is just in the draft that will soon go away, right?
Waiting for all to complete, and postponing optimization, as currently,
seems the right next step at this stage.
Ack!
--
/ daniel.haxx.se | Get the best commercial curl support there is - from me
| Private help, bug fixes, support, ports, new features
| https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
