> On 12 Jan 2023, at 00:26, Philip Homburg wrote:
>
> In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote:
>>> However, such a setup leaves the application with no control over
>>> which transport the proxy uses.
>>
>> Why should the application have control over this?
On Wed, 11 Jan 2023, Philip Homburg wrote:
Obviously, this is not an issue if the application specifies an encrypted
transport to a public DNS resolver.
At that point you are fighting ADD proposals. You are fighting the LAN
preferences, the wireless carrier preferences, the OS and maybe the
In your letter dated Tue, 10 Jan 2023 11:33:57 -0500 (EST) you wrote:
>>However, such a setup leaves the application with no control over
>>which transport the proxy uses.
>
>Why should the application have control over this?
The following is just a thought, I didn't implement it.
With
In your letter dated Tue, 10 Jan 2023 17:27:12 -0500 (EST) you wrote:
>if applications think it is THAT important, they shouldn't be trusting
>the EDNS options of a stub proxy, which also might go through an OS
>proxy on top. It also cannot trust or know whether the proxy's upstream
>forwardering
In your letter dated 10 Jan 2023 16:25:14 -0500 you wrote:
>I'm with Paul here. If you don't like the way my resolver works, use
>another one.
>
>Experience also tells us that if you give users knobs like this, they
>will use them even when (especially when) they have no idea what they
>are doing.
