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.
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 HTTPS RRs
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.
[*] = https://github.com/curl/curl/discussions/11125 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
