Re: [Doh] operational issues with doh

"Paul Hoffman" <paul.hoffman@vpnc.org> Sun, 05 November 2017 15:46 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AB713FA91 for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 07:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4ttiS0ChVhE for <doh@ietfa.amsl.com>; Sun, 5 Nov 2017 07:46:03 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE74313F979 for <doh@ietf.org>; Sun, 5 Nov 2017 07:46:02 -0800 (PST)
Received: from [169.254.97.244] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vA5FiWrg013668 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 5 Nov 2017 08:44:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.97.244]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Eliot Lear" <lear@cisco.com>
Cc: doh@ietf.org
Date: Sun, 05 Nov 2017 07:45:55 -0800
Message-ID: <A0507661-1D71-4EF4-97F3-1C6188D3141A@vpnc.org>
In-Reply-To: <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com>
References: <abe6593a-0bc9-9ed4-4ad4-c03093bcb490@cisco.com> <CAOdDvNoSONY2NkdzPYpSq=6sUWMo3Y3HJigWBWZpx9MDRcrr4Q@mail.gmail.com> <CADyWQ+H74a0ks3LTBgdYyCW2T98jDwGccKTEe6biOhA9SFrADg@mail.gmail.com> <CABkgnnWfrjf5tdP_dQSxfMR_2y53HfE6nmHvZMJKMRPhUsFUpQ@mail.gmail.com> <8f57526e-461d-2782-ae44-1087b3a4ed43@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.7r5425)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/waSUNc0Izo0RJGyD2m6fNq3waKg>
Subject: Re: [Doh] operational issues with doh
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2017 15:46:04 -0000

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