Hello. So that libcurl can support ESNI, it needs to be able to fetch and manage data from the DNS beyond the address (A, AAAA) and alias (CNAME) data which it already handles. Current WIP at IETF (eg HTTPSSVC) may lead to a similar requirement.
For now, I’m minded to focus on how to meet this requirement using DoH, and leave a c-ares implementation until later. - Current *libcurl* behaviour IIUC, what libcurl does currently when using DoH is to queue a DoH transaction for either or each address type (A, AAAA), and then wait for the transaction(s) to terminate asynchronously. As each transaction is queued, a transaction-pending counter is incremented. Per-request (struct SingleRequest, struct dohdata) provides two transaction slots, each dedicated to a specific address resolution query type (A or AAAA). On completion of each transaction, the returned address and alias data are extracted from the DoH response and stored (struct dohentry, struct dohaddr, struct cnamestore), and the transaction-pending counter is decremented. Up to 12 addresses (aggregated over both types) and 4 aliases can be saved; beyond these limits, excess data are silently ignored. Addresses are subsequently placed in an address cache as (hostname, port, address) tuples. Simplifying assumptions currently used in libcurl are that the DoH QNAME corresponds exactly to the hostname of interest, and that a single TTL value adequately describes all data obtained. - Accommodating ESNI ESNI data is published in the DNS either as TXT records under a prefixed owner-name (draft 2), or as private-use TYPE65439 records under the hostname itself (drafts 3, 4). Both cases are significant, as Cloudflare servers follow draft 2, and future developments will use either TYPE65439 (in the near term) or a successor standard type (later on). Constructing a DoH query is straightforward, provided that care is taken construct the prefixed QNAME for the TXT QTYPE. Managing the corresponding transaction and storing the data returned will need some decisions, including the following. - Extend `struct dohdata` or use a different structure for tracking DoH transactions whose purpose is other than address resolution. - If extending `struct dohdata`, dedicate an additional slot per QTYPE, or introduce an array of ‘generic’ slots. - Choose a structure for caching returned data, as existing (hostname, port, address) tuples cannot represent all the significant data items (QNAME prefix, QTYPE). - Decide what DNS-derived data must be present before advancing the connection state machine. That should be enough to get the ball rolling! 8-) Niall O’Reilly
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html