Download
Browse source Changelog
Documentation
Project   Bug Bounty   Help us   Known bugs   TODO Protocols   CA bundle   HTTP Cookies   HTTP/2   SSL Certs Releases   Security   Version numbers   Vulnerabilities curl tool   man page   Tutorial   HTTP scripting Who and Why
libcurl
ABI API Competitors Examples Features Mailing list Related libs Using libcurl Tutorial Testimonials
Get Help
curl-library curl-users Mailing lists Book: Everything curl Video presentations Report a bug Paid support
Development
Autobuilds Code Style Contribute Deprecate Internals Release Notes Release Procedure Roadmap Run Tests Security Process Specifications Test curl
News
Changelog Release table
curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

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

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 12 Sep 2019 15:55:14 +0200 (CEST)

On Wed, 11 Sep 2019, Niall.oReilly+lists--- via curl-library wrote:

Hi Niall, thanks for the status report and it is certainly encouraging to hear
that you're progressing nicely!

> 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.

There are also the always returning discussions about supporting SRV and URI
records. Getting some fundamental infra for DNS records in place can then
later be used for several potential features.

> For now, I¢m minded to focus on how to meet this requirement using DoH, and
> leave a c-ares implementation until later.

Seems like a reasonable start!

> 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.

I think extending dohdata sounds good. One "dnsprobe" entry for each request.

> - Choose a structure for caching returned
> data, as existing (hostname, port, address)
> tuples cannot represent all the significant
> data items (QNAME prefix, QTYPE).

Right. I hadn't actually considered that we want an ESNI cache but it
certainly makes sense. Do you think it makes sense to extend the existing DNS
cache and just add more data in that, or would it somehow be better to keep it
separate?

(Possibly you skip the cache in the first step, just to get the functionality
there first, before you optimize and add the cache in a step two.)

> - Decide what DNS-derived data must be present
> before advancing the connection state machine.

Shouldn't you wait for all answers before moving on? What "early exit"
possibilities are there you say? 

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