DNS over HTTPS

[ѽ҉ᶬḳ℠]

>> One of the benefits of DoH over DoT seems that port 443 is utilized as
>> opposed to port 853 and thus less likely to to be blocked by firewalls.
> since may DoT servers also run on 443 this should not be a reason for using
> DoH instead of DoT

Sure, if they were. Do you know of any public resolvers with DoT on port
443, other than Google and CF that is?
Those I am using (with privacy in mind) -   UncensoredDNS,  SecureDNS, 
Quad9 and getdnsapi - are all on port 853 thus far and thus risking
being blocked by firewalls in environments beyond the unbound user's
control, e.g. unbound on a travel router.

>
>> Some are voicing their concern that it would cede control over DNS
>> matters to browser vendors if they were to implement their choice of TRR
>> as Mozilla currently does with CF.
>> And certainly it would require other public DNS resolvers to implement
>> DoH if not to stay limited to the aforementioned.
>>
>> What are the thoughts of the unbound team on the subject, any plans to
>> implement DoH?
> there is a ticket for DoH already, but I believe at this point 
> implementing the connection-reuse functionality for DoT
> is more important than implementing DoH.

Yes, indeed.

> also note that from a user privacy perspective DoT is
> preferred over DoH since it does not introduce all the
> privacy problems of HTTP to DNS (like user-agent and other
> headers that can be used to fingerprint the DoH client)
>

Concur.

I was wondering with Google and Mozilla going to implementing, thus far
Mozilla at lest permits turning off DoH or if turned on to prefer DoT
over DoH, what happens to resolvers if they get brazen and force DoH
without an option to turn off, worse even setting their public resolvers
like Mozilla currently is intent on with CF. Going further if any other
application is following suit.
Any DoH traffic would bypass resolvers other than specified in the
application. The next Android release is rumoured to implement DoH too,
wondering when MS and Apple hopping on that train.

But that perhaps a discussion outside of the scope of this mailing list.