Hi. After too many attempts to follow up Daniel's (off-list) reaction to my earlier mail, here's a quick summary of how I think the questions raised can most simply be resolved.
On 11 Sep 2019, at 16:33, niall.oreilly+li...@ucd.ie wrote: > * Extend `struct dohdata` or use a different > structure for tracking DoH transactions whose > purpose is other than address resolution. Extend dohdata. > * If extending `struct dohdata`, dedicate an > additional slot per QTYPE, or introduce an > array of ‘generic’ slots. 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. > * 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. > * 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. 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. Waiting for all to complete, and postponing optimization, as currently, seems the right next step at this stage. Best regards Niall O'Reilly ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
