Re: [Doh] operational considerations

Eliot Lear <lear@cisco.com> Mon, 20 November 2017 21:30 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 112DB12711D for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 13:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, URIBL_BLOCKED=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 VX57N7d2c70G for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 13:30:21 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF18126FDC for <doh@ietf.org>; Mon, 20 Nov 2017 13:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10576; q=dns/txt; s=iport; t=1511213421; x=1512423021; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jdpscWJWPyXQPO+Ho0m1GUAkmrdc8FH/mGQriSEIhro=; b=UUBnUSEK8JmNYzijCqhJbdSm6nVqpMT1x9OfeLDd4l2sA3V2QEzRlS89 ruIHYEl6P6svR1LouE7Gr3ug4vYyE6hgiOtW8T4vDlG95dqvlX81tf5OJ fEU1LnFylQUMWOrTdyBMpll4bNh0REnmlAVOO+8rg5yTEtMCaG5liiOho A=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAQA/SBNa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRRuJ4N/ixOQCyaRGYVZggEHA4U7AoVAFAEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAgEjVhALGCcDAgJGEQYNBgIBAYoZCKhVgicmilABAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEOD4M0hW4LgneEXyaDK4JjBZF0kEqESYIojhuMBIdIljKBOjY?= =?us-ascii?q?igXQ0IQgdFYMthGBANotSAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,429,1505779200"; d="asc'?scan'208,217";a="331636"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 21:30:19 +0000
Received: from [10.61.98.150] (dhcp-10-61-98-150.cisco.com [10.61.98.150]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vAKLUIT0017365; Mon, 20 Nov 2017 21:30:18 GMT
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: "doh@ietf.org" <doh@ietf.org>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> <CAOdDvNpuNhZF+966qUY8Sq4cfdrC-j_vFYoE9LT_jMRnWozgaQ@mail.gmail.com> <e1292551-21b7-802c-aec0-81eb7988fb80@cisco.com> <CAOdDvNqxytTf_Vf1QeKzi1D8qBi5VdxgeuZcFnEjefxNuLbfXg@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com>
Date: Mon, 20 Nov 2017 22:28:52 +0100
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
In-Reply-To: <CAOdDvNqxytTf_Vf1QeKzi1D8qBi5VdxgeuZcFnEjefxNuLbfXg@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="FTj8C5IFxsgtoo5ITTmIwUvvp7w9F1LwE"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PlwVPSJ3coUsCN-dj9aVgaWwlno>
Subject: Re: [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: Mon, 20 Nov 2017 21:30:23 -0000

Hi Patrick,

The answer is not just different, but inappropriate.  We need to capture
that point because that is why remediation would be required, and why
this is at all worth mentioning.  I propose that we take another swing
at this text over the next few days.

Eliot




On 11/20/17 9:39 PM, Patrick McManus wrote:
> I've taken the (imo) best bits from Eliot, Jim, and myself.. (I've
> tried to reject 'non-default', 'proximate', and 'policy' all as things
> that muddy the issue.) what do we think of this iteration?
>
> Operational Considerations
>
> Different DNS servers may provide different results to the same query.
> It logically follows that which server is consulted influences the end
> result. Split-horizon DNS [RFC6950] is a specific example of this
> approach where the answers are derived from the source of the query. A
> client that queries a resolver which uses this style of algorithm can
> expect to sometimes be returned different answers from the responses
> given by resolvers which do not use them
>
> The HTTPS channel used by this specification establishes secure two
> party communication between the DNS API Client and the DNS API Server.
> Filtering or inspection systems that rely on unsecured transport of
> DNS will not function in a DNS over HTTPS environment.
>
> On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear <lear@cisco.com
> <mailto:lear@cisco.com>> wrote:
>
>     Hi Patrick,
>
>     This is good text.  I think Jim has a point about "default resolver". 
>     Also, further reduction is possible.  See below:
>
>
>     On 11/19/17 2:48 AM, Patrick McManus wrote:
>     > Hi Eliot - indeed this is fairly brief.. thank you. if we can
>     keep it
>     > to this scope I'm ok - but if the section begins to grow organically
>     > we should really discuss moving to a different doc. I have a
>     proposed 
>     > minor rework of your text below which I believe to be more
>     concise and
>     > a bit more illuminating on the root issues. Let me know what you
>     think.
>     >
>     > Operational Considerations
>     >
>     > Different DNS servers may provide different results to the same
>     query.
>     > It logically follows that which server is consulted influences
>     the end
>     > result. Split-horizon DNS [RFC6950] is a specific example of this
>     > approach where the answers are derived from the (potentially natted)
>     > source of the query. A client that chooses to query a non-default
>     > resolver for a name that is using this style of algorithm may not
>     > obtain correct results.
>
>     s/chooses to query/queries/
>
>     s/non-default resolver/resolver that is not proximate/
>
>     How's that?
>     >
>     > The HTTPS channel used by this specification establishes secure two
>     > party communication between the DNS API Client and the DNS API
>     Server.
>     > Filtering or inspection systems that rely on unsecured transport of
>     > DNS will not function in a DNS over HTTPS environment.
>
>     Eliot
>
>