Subject: Re: [Doh] operational issues with doh

From: tjw ietf <[email-masked]>
Date: Fri, 3 Nov 2017 16:16:01 -0400

Agree with Patrick, this should be more of an operational considerations
document.

On Tue, Oct 31, 2017 at 3:47 PM, Patrick McManus <[email-masked]>
wrote:

> I think I would prefer a separate document if people were interested in
> working on that.
>
> On Tue, Oct 31, 2017 at 2:57 PM, Eliot Lear <[email-masked]> wrote:
>
>> Hi everyone,
>>
>> Just to follow up on the lengthy discussion that took place during
>> chartering, there are some operational issues that use of doh can
>> create, particularly with regard to load balancers and split DNS.  Do
>> those go into the draft or do they go into a separate doc?  It's quite
>> possible they can be mitigated against, and if they can be, and if the
>> text isn't too long, can I suggest that we start out by having some text
>> in the draft, and if it starts to get lengthy we split it off?
>>
>> Eliot
>>
>>
>>
>> _______________________________________________
>> Doh mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/doh
>>
>>
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Martin Thomson <[email-masked]>
Date: Sat, 4 Nov 2017 09:33:39 +1100

Maybe someone can send an email outlining the operational concerns to
the list and we can discuss them first.  I don't know what these
concerns are.

---

From: Eliot Lear <[email-masked]>
Date: Sun, 5 Nov 2017 08:30:08 +0100

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 ;-).

Eliot

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 05 Nov 2017 07:45:55 -0800

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

--Paul Hoffman

---

From: tjw ietf <[email-masked]>
Date: Sun, 5 Nov 2017 10:48:55 -0500

in the case of detect and prevent access to known malware-infested
sites, could;n't DoH deploy an RPZ like mechanism?