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: Fri, 27 Sep 2019 17:31:09 +0200 (CEST)

On Fri, 20 Sep 2019, Niall O'Reilly via curl-library wrote:

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

Yes, I like that too. This stuff tends to get easier when you have actual code
to try out the different takes with.

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

Agreed. Start out with a simple and basic approach anda we can expand later if
deemed suitable.

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

This is also matching the regular getaddrinfo() behavior. I think that's a
topic for the category "optimizations we can consider later".

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

And the TXT one is just in the draft that will soon go away, right?

> Waiting for all to complete, and postponing optimization, as currently,
> seems the right next step at this stage.

Ack! 

-- 
  / 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-27