Re: [Doh] operational considerations

Eliot Lear <lear@cisco.com> Mon, 20 November 2017 21:50 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 DCC7C126FDC for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 13:50:24 -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 omlI4bAckIiP for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 13:50:22 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21524126B6E for <doh@ietf.org>; Mon, 20 Nov 2017 13:50:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16089; q=dns/txt; s=iport; t=1511214622; x=1512424222; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=WGBY2JQz/MXdD0N/l7lTunheJwudkcP4M46UMptMiDY=; b=mRD6LfFLmZG1xe7kFGdzURTfzQ2dc/IO/GxaO1gITfm9C1COPP9R3XqW 86UqS+tOntEyatuwnadSsErZ+eGOm3Gp8knjfJt7YdR6KzzZMH+iJnLUB GoSDv1NrGaT83uzXC8THLorboN59vDly4YlgSrfZxJ6uApK3V/4lbhS6R g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQB1TRNa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOgRRuJ4N/ixOQMZEZhVmCAQcDhTsChT8VAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQECASNWEAsYJwMCAkYRBg0GAgEBihkIqE6CJyaKUAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQ4PgzSFboMChF8mgyuCYwWRdJBKhEmCKI4bjASHSJYygTo1I4F?= =?us-ascii?q?0NCEIHRWDLYRgQDaLUgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,430,1505779200"; d="asc'?scan'208,217";a="384717"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 21:50:20 +0000
Received: from [10.61.98.150] (dhcp-10-61-98-150.cisco.com [10.61.98.150]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAKLoJrI030209; Mon, 20 Nov 2017 21:50:19 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> <468958c4-36b0-9567-4207-6c4ab4c48249@cisco.com> <CAOdDvNrp2_kgmvXhBqWTX-1e2jCZ8rQMSC6GSDbd1RKR4L1gsw@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <28b3ed9f-5f0a-ca07-9a50-68111d5c7fb7@cisco.com>
Date: Mon, 20 Nov 2017 22:48:53 +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: <CAOdDvNrp2_kgmvXhBqWTX-1e2jCZ8rQMSC6GSDbd1RKR4L1gsw@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HV1TAl1cdbL9OIinUSgQcI8lgQkOEcSlh"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/e3le3l5g8vpVJw74Z9ClJblI0ak>
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:50:25 -0000

WFM.

Thanks,

Eliot


On 11/20/17 10:44 PM, Patrick McManus wrote:
> I agree a bit. I had originally gone with incorrect (or not correct or
> something like that) and Jim pushed back a tad. Its incorrect wrt the
> algorithm and I think its fine to capture that if the scope is tight..
>
> Here's another swing (with Rory's editorial changes.) that I like.
>
> "Different DNS servers may provide different results to the same
> query. It logically follows that the server which 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. If a client selects a server that is unanticipated by
> this style of algorithm the response may be not be correct."
>
>
>
>
> On Mon, Nov 20, 2017 at 4:28 PM, Eliot Lear <lear@cisco.com
> <mailto:lear@cisco.com>> wrote:
>
>     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
>>
>>
>
>