Managing application data fetched from DNS (eg for ESNI)

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
Received on 2019-09-11