[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
- [Doh] operational considerations Eliot Lear
- Re: [Doh] operational considerations Martin J. Dürst
- Re: [Doh] operational considerations Jim Reid
- Re: [Doh] operational considerations Eliot Lear
- Re: [Doh] operational considerations Patrick McManus
- Re: [Doh] operational considerations Jim Reid
- Re: [Doh] operational considerations Eliot Lear
- Re: [Doh] operational considerations Patrick McManus
- Re: [Doh] operational considerations Hewitt, Rory
- Re: [Doh] operational considerations Eliot Lear
- Re: [Doh] operational considerations Patrick McManus
- Re: [Doh] operational considerations Eliot Lear
- Re: [Doh] operational considerations Jim Reid
- Re: [Doh] operational considerations Jim Reid