Re: [Doh] operational issues with doh

["Paul Hoffman" <[e-mail]>]

In order to make the conversations easier to follow, I'm going to split 
these out into separate threads.

--Paul Hoffman

On 5 Nov 2017, at 0:30, Eliot Lear wrote:

> There are several:
>
>   * Use of this mechanism can cause problems with split DNS, where the
>     internal DNS is not the same as what is made available 
> externally. 
>     Many corporate networkers hide their internal topology from the
>     external DNS.  If an end host queries an external DNS for an
>     internal resource, the result would be NXDOMAIN.  To avoid this, 
> at
>     a minimum, the browser should have some configuration as to what 
> is
>     internal.  I conjecture that this would reflect what is commonly
>     found in a proxy.pac file.
>   * When an HTTP server offers this service for domains it is not
>     responsible for, it has the potential to impact DNS-based load
>     balancing by masking the IP address of the sender and substituting
>     its own.  The remedy here is that any service offering DoH should
>     sufficiently distributed as to minimize such an impact.
>   * Use of DoH will bypass protection mechanisms commonly used to
>     efficiently detect and prevent access to known malware-infested
>     sites.  There are two mitigation mechanisms available, but one is
>     incomplete:  deployments make use of in-path blocking methods 
> such
>     as IP access lists.  This is partial because there is a
>     performance/memory impact in doing so, and the query itself can
>     indicate that the device itself is infected.  The other 
> mitigation
>     here is to have a configuration mechanism to turn on/off DoH in
>     order to use the existing infrastructure.  This has the least 
> impact
>     on surrounding infrastructure (and takes the least text ;-).