Re: [Doh] operational considerations

Patrick McManus <pmcmanus@mozilla.com> Mon, 20 November 2017 20:39 UTC

Return-Path: <pmcmanus@mozilla.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 1E24A12EAA8 for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 12:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.733
X-Spam-Level:
X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 02cs3q86kwWM for <doh@ietfa.amsl.com>; Mon, 20 Nov 2017 12:39:25 -0800 (PST)
Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7EB120713 for <doh@ietf.org>; Mon, 20 Nov 2017 12:39:25 -0800 (PST)
Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 92C523A0BC for <doh@ietf.org>; Mon, 20 Nov 2017 15:39:23 -0500 (EST)
Received: by mail-lf0-f46.google.com with SMTP id y2so10662117lfj.4 for <doh@ietf.org>; Mon, 20 Nov 2017 12:39:23 -0800 (PST)
X-Gm-Message-State: AJaThX62mMz7DxnViggtjlIotUjEVMohfoStqOZj+0trW+pxItxKgDJ2 Nbnl6Q65e5A9y1UyjsJ8APREEkgKM3JdkbTJdcA=
X-Google-Smtp-Source: AGs4zMb1OAeRMhTr1+yJJI10nmTeOPePHATKjPWqHeeA0QsB3XWdE/fg/aaOXAi91a6va1Kba8MJqg0EYWqipXqP8kA=
X-Received: by 10.25.159.196 with SMTP id i187mr3193309lfe.150.1511210362229; Mon, 20 Nov 2017 12:39:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.151.9 with HTTP; Mon, 20 Nov 2017 12:39:21 -0800 (PST)
In-Reply-To: <e1292551-21b7-802c-aec0-81eb7988fb80@cisco.com>
References: <60b879b8-d107-ec79-b2f1-357e354702e4@cisco.com> <CAOdDvNpuNhZF+966qUY8Sq4cfdrC-j_vFYoE9LT_jMRnWozgaQ@mail.gmail.com> <e1292551-21b7-802c-aec0-81eb7988fb80@cisco.com>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Mon, 20 Nov 2017 15:39:21 -0500
X-Gmail-Original-Message-ID: <CAOdDvNqxytTf_Vf1QeKzi1D8qBi5VdxgeuZcFnEjefxNuLbfXg@mail.gmail.com>
Message-ID: <CAOdDvNqxytTf_Vf1QeKzi1D8qBi5VdxgeuZcFnEjefxNuLbfXg@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, "doh@ietf.org" <doh@ietf.org>
Content-Type: multipart/alternative; boundary="001a11411bbed26070055e701437"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/YjqY7lvLhwniDH5M-O1T_Dsj96Y>
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 20:39:27 -0000

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> 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
>
>