Re: Managing application data fetched from DNS (eg for ESNI)

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+lists_at_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
Received on 2019-09-20