[Doh] operational considerations

Eliot Lear <lear@cisco.com> Thu, 16 November 2017 08:32 UTC

Return-Path: <lear@cisco.com>
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 43FD1126BFD for <doh@ietfa.amsl.com>; Thu, 16 Nov 2017 00:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 fKXcPNuB-0Yg for <doh@ietfa.amsl.com>; Thu, 16 Nov 2017 00:32:33 -0800 (PST)
Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5847124217 for <doh@ietf.org>; Thu, 16 Nov 2017 00:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5119; q=dns/txt; s=iport; t=1510821153; x=1512030753; h=to:from:subject:message-id:date:mime-version; bh=MMxuiaeRlmQH1YwV3Yl5PZxSCKVmJ6CmaPgY96frrV4=; b=C+ONpSgfWDBC7OgtcFqCY20aHlWGd4QUTl5+Ju69XYI+8SHD96gldC4V X4dY1VhOo0SceU6lNBSwagUd6HSNQA0GPAWVeyjtPUM2kRZN6La94Vicz oFYrKKvgyvOx3f/JabP3dZ2JEKJP3hFaR28KCNDZcQLiOBHfSLRpczMrI g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B/AQBCTA1a/xjFo0heGQEBAQEBAQEBAQEBAQcBAQEBAYUIhCaLE6E+hUmCEQcDixIWAQEBAQEBAQEBax0LhUh1PgJTDA0IAQGKIKlVgicmim4BCgEBAQEUD4M0gWaDXymIA4MrgmMFijmIS48zhEeCJY4ai3+HRZYugTkmCieBdDQhCB0VSYJlhGs0i2IBAQE
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="asc'?scan'208,217";a="44511795"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 08:32:29 +0000
Received: from [10.70.234.2] ([10.70.234.2]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vAG8WSkZ013799 for <doh@ietf.org>; Thu, 16 Nov 2017 08:32:29 GMT
To: "doh@ietf.org" <doh@ietf.org>
From: Eliot Lear <lear@cisco.com>
Message-ID: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com>
Date: Thu, 16 Nov 2017 16:31:43 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="5ccs5LPPrxCcaAirO4tO7OT558rcWEvAO"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/lNV4-DNO2Ltv4K2alrB0T2iTpx4>
Subject: [Doh] operational considerations
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: Thu, 16 Nov 2017 08:32:35 -0000

Hi everyone,

Before I get into the operational considerations part of this message, I
agree with the idea that it might be useful to have a wiki to build out
text, particularly if people find other operational considerations to
address.

What we discussed was a paragraph to talk about operational
considerations.  Here is what I propose as a starting point.  It's not
that long.  I propose not to add text around GSLB/the EDNS option.

Operational Considerations

Because DOH uses an encrypted channel that may extend beyond an
administrative boundary, several operational issues may arise.  We
discuss these below, and provide at least one possible mitigation for
each issue (there may be others).

  * When used, split-horizon DNS provides different answers based on the
    source of a query [RFC6950].  The common case of this is an
    enterprise that does not expose the existence of internal services
    to the outside world.  If a DOH server residing on the Internet may,
    therefore, provide an inconsistent answer than an internal resolver
    would.  To address the common case, a DOH client MAY contain some
    configuration, such as a list of local domains that should use UDP-
    or DPRIVE-based queries.
  * Many deployments review DNS queries and responses on the wire to
    detect for malware or other policy concerns.  Where such exposure is
    required by policy, DOH the user may wish to not configure DOH.

Eliot