Re: [DNSOP] [Ext] Re: New draft for consideration:

Matthew Pounsett <matt@conundrum.com> Sun, 24 March 2019 21:26 UTC

Return-Path: <matt@conundrum.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4522412012F for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 14:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.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 grzPTrFq3PKJ for <dnsop@ietfa.amsl.com>; Sun, 24 Mar 2019 14:26:30 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030C312012B for <dnsop@ietf.org>; Sun, 24 Mar 2019 14:26:29 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id d201so6026350iof.7 for <dnsop@ietf.org>; Sun, 24 Mar 2019 14:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U1yXszbqTNMRqOiVTU1VRuCPN6DgE/fyp/gyfOOHWPw=; b=iaZ8ULG0RWBoVOuqps69Bbw9Vgo9ZD2Uq7FxHoQMr1v5AayRsWtRBlffIZMZZlDOTL DEuZtOYK2IyWWoe4UKoJO2JvhzuZP8FxBz/SvCtiWN2hr5Tq/x54NGjilQYlzmSt8/uy 2MvRl9Jaa4fvo9xNqzaySLsMhqgeNhhWp6kHL+go3i5K+guchUn+RFI+BChkHug33Cst qdRcAUQNXirxOWC2FWYT2p0/eIHqcNd3iGPBw1NzCfX7YkX1KMMoqEhBHKrvtHDPz+1c xghmiJC+XYCDVFDYLQlfxohwEgd0BlzAa70ibK0MaYqWyRLeZiJkJOWzilcalrbLVx1p GPGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U1yXszbqTNMRqOiVTU1VRuCPN6DgE/fyp/gyfOOHWPw=; b=DNwheX6/0y1ld0toQbsSrkkhuniKnzhEsPFov15YvU+UjXBUCbCpf3XDKeB5s/wiZk 7Dz2n87B0tExWjaoeNHv3rL4SyQCON4rVv8Ta+AzyQ8efkd4PgXigX1WSF8jgnaODVla treQHTgrCi6zM2Uk5E9sZB56CWHevTIIs3qp2kw6sk2G1z6MNiwiKwbjPVTD5kRPJ26H Zq3A5yJC4E9vyvDrz1btajsE9QhBimw79koxKxLa2Lt76ouY/xRwKUSg23h2oaML61wC XBXiXiC6lKUAgnGxRsGfC6ytWQ67KaHkbEHz5BFwmh6AOPwP9jVNPi73hvT/8fpP+eHU DobQ==
X-Gm-Message-State: APjAAAVsA5cLfgXAbldNCVucWOYJYCYQ7eY/jLcZwFAvfzBizwcnfK9w 4PWXlieHqmRnuBeivnSVQK1UL+tvIMmTJXi2/RFXiSHyZGnsPA==
X-Google-Smtp-Source: APXvYqwODGSTADIBSJXDRlEhm+nOA/6rickdV/ya89Xo1xllWL6Yy3OSTv15c2whlIIa6JrRSWeeGrSPoSmfLHjkYH8=
X-Received: by 2002:a6b:3b43:: with SMTP id i64mr2770094ioa.121.1553462789197; Sun, 24 Mar 2019 14:26:29 -0700 (PDT)
MIME-Version: 1.0
References: <E2267015-0A5F-4D6E-85F0-3FA93348CA79@icann.org> <20190324101805.GA22597@server.ds9a.nl> <6893EFA4-F413-4C11-828A-13E942AA345C@icann.org> <CAAiTEH9Vi108vt_NwaPxSOnekp5T4++9VE+5akmGFnosEbQQeA@mail.gmail.com> <A2E0B0E9-0D44-45D9-9E83-1BFE5664FB5F@bogus.com>
In-Reply-To: <A2E0B0E9-0D44-45D9-9E83-1BFE5664FB5F@bogus.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Sun, 24 Mar 2019 22:26:18 +0100
Message-ID: <CAAiTEH8CvuaSHRNJ0UFuUswbLLU29Bqz0WSTGVoc6q_Oj10BiQ@mail.gmail.com>
To: Joel Jaeggli <joelja@bogus.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>, bert hubert <bert.hubert@powerdns.com>
Content-Type: multipart/alternative; boundary="000000000000b8e7440584ddbde0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1TZtuXEUqLXQODLXeW7US99sPQ4>
Subject: Re: [DNSOP] [Ext] Re: New draft for consideration:
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Mar 2019 21:26:32 -0000

On Sun, 24 Mar 2019 at 17:17, Joel Jaeggli <joelja@bogus.com>; wrote:

>
>
> On Mar 24, 2019, at 08:59, Matthew Pounsett <matt@conundrum.com>; wrote:
>
>
>
> On Sun, 24 Mar 2019 at 11:46, Paul Hoffman <paul.hoffman@icann.org>; wrote:
>
>>
>> > I'm also not too hot for conflating "user consciously changes
>> > /etc/resolv.conf or equivalent" with "application makes the choice for
>> the
>> > user".
>>
>> The split here is more "someone changes from traditional without the user
>> knowing, when the user cares". If you have a better way to express that,
>> that would be great.
>>
>> > Perhaps we should talk about 'Per-application stubs'? Because this is
>> the
>> > nub.
>>
>> Maybe, but I'm hesitant to make the break that way because some
>> applications' stubs use the traditional resolver, others don't. I would be
>> hesitant to conflate those two.
>>
>
> I don't think the current wording for DaO expresses the same point that
> you've made here.  In particular, mentioning that DaO might refer to a user
> modifying /etc/resolv.conf is inconsistent with the intent that DaO is
> sending queries somewhere other than where the traditional configuration
> says.  /etc/resolv.conf (and its equivalents in non-unix OSes) *are* the
> traditional place to configure that.  Whatever that file says, I think any
> resolver that is consulting that file to find its upstreams is doing DaT.
>
>
> I think we’re at the point where using acronyms is is obscuring the detail
> of what is being described. If and acronym describes a protocol or an
> architectural feature that is unambiguous, great.
>
>
> How about:
>    DaO: DNS resolution between a stub resolver and a recursive resolver
> that
>    differs from the recursive resolver configured in the traditional
>    location(s) for a system.
>
>
> This describes a multitude of systems of varying implementation. It would
> seem for example to include bonjour, a tor client, some vpns and many
> operating system container environments.
>

I may be wrong, but I don't believe bonjour uses RDoT or DoH.

The VPNs you reference are, I think, intended to be covered by the term, so
I think the definition works there.

 I don't think I have an opinion on whether Tor should or shouldn't be
covered by the definition (although others might), so if you wanted to
suggest text that excluded it I think people would consider that.

I don't think container environments are included in the definition either,
because in a container environment the container's resolution path is the
traditional point of configuration for that type of system.  Perhaps the
word "traditional" is too ambiguous, and leads people to think more
"historical" than "typical"?


>
> DaO can be configured by a user changing where a
>    stub resolver gets its list of recursive servers, or an application
> running
>    RDoT or DoH to a resolver that is not the same as the resolver
> configured
>    in the traditional location for the operating system.
>
>