This DNS over HTTP thing

[ahebert at pubnix.net (Alain Hebert)]

 Â Â Â  Well,

1 think for sure.

 Â Â Â  An application bypassing the OS and auto deciding where to resolve 
an address will break our DNS views for private versus public resolution 
of the same hostname.  I see fun times to be had in the Security world...

 Â Â Â  At least make it optional, not enabled by default.

 Â Â Â  PS: I know it is not Friday, but gratz to Alphabet for systemd'ing DNS.

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443

On 2019-10-02 13:14, John Levine wrote:
> In article <146431.1569964368 at turing-police> you write:
>> -=-=-=-=-=-
>>
>> On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:
>>
>>> "More concretely, the experiment in Chrome 78 will **check if the
>>> userâ??s current DNS provider** is among a list of DoH-compatible
>>> providers, and upgrade to the equivalent DoH service **from the same
>>> provider**. If the DNS provider isnâ??t in the list, Chrome will
>>> **continue to operate as it does today.**"
>> I suppose this is the point somebody has to put the words "nostrils", "tent",
>> and "camel" in the same sentence?
> This looks to me more like the tail end of the caravan.  Users have always been
> at the mercy of their browsers, which have always done unexpected things.
>
> Assuming we agree that automatically upgrading http requests to https
> is OK, how is this any different?  Same endpoints, encrypted channel.
>
> The Google people I've talked to are quite aware of the implications
> of using a different DNS resolver and I would be surprised if they
> ever did it without a very explicit request from the user.  In this
> regard they are quite different from Mozilla who are impervious to the
> reasons that sending random users' traffic to Cloudflare is not a good
> idea.
>
> R's,
> John
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191002/a8a42590/attachment.html>