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: ***SPAM**** Re: ECH support (when curl is not using DoH)

From: Stephen Farrell <>
Date: Wed, 13 Sep 2023 20:25:51 +0100

On 13/09/2023 13:24, Daniel Stenberg wrote:
> On Wed, 13 Sep 2023, Stephen Farrell via curl-library wrote:
>> There should be a use-case for ECH when DoH is not used by curl - if a
>> system stub resolver supports DoT or DoH, then, considering only ECH
>> and the network threat model, it would make sense for curl to support
>> ECH without curl itself using DoH.
> Yes, I am sure there will be users craving for this. I am of course fine
> with doing that in a "second wave" or something though. No need to do
> everything at once.

Fair enough, we'll concentrate on the using-DoH scenario for
now, and hope someone else does work to add HTTPS RR support
to c-ares in the meantime:-)

One other note below:

> This is similar in spirit to the people who are asking (I'm being polite
> so I do not write "demanding" here) for an option to disable the .onion
> filtering [*] because they run a setup where they are in full control of
> the resolver and they know it is fine.
>> One option would seem to be to extend the c-ares library to support
> This is the route I have been pondering myself. I am a co-maintainer of
> c-ares and I think it would fit in the library so I don't think such an
> extention would face any problems there.
> Adding another separate DNS library seems a little unfortunate since we
> already use c-ares for other things and replacing c-ares completely
> feels like quite a lot of work...
> A little extra "quirk" is of course that currently when curl is built to
> use c-ares, it *replaces* the normal resolver lookups and only c-ares is
> used, but it might be that we to allow the stock resolver for regular
> A/AAAA lookups and only use c-ares for HTTPS. This, because it turns out
> that replacing the stock resolver for these name resolves is darn next
> impossible for all of the never-ending edge cases out there in the world.

Taking that approach might in some cases increase the risk of
a mismatch between A/AAAA and an HTTPS RR value, if those do
have multiple values, with mismatching ones cached on the two
"resolution paths." That's been a concern with the ECH design
from almost the start, even though nobody seems to quite know
how much of a risk it represents. (Or even how to try measure
that risk;-)

That's another credible reason to prefer sending both A/AAAA
and HTTPS queries over the same DoH session - the theory is
it may reduce such risks.


> [*] =

Received on 2023-09-13