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

Ted Lemon <mellon@fugue.com> Mon, 25 March 2019 08:53 UTC

Return-Path: <mellon@fugue.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 4F3E8120388 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 DfUSKBK_3EMF for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:53:01 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 A606612044A for <dnsop@ietf.org>; Mon, 25 Mar 2019 01:52:55 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id z17so9270090qts.13 for <dnsop@ietf.org>; Mon, 25 Mar 2019 01:52:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3SWk8ThhbvWvlM4Yl/fkMDS9q69Nl/GBQroxsMYWlFc=; b=XeHH07du00QRPx8BDilY1sGenFI18x0hrZedvgWLCfh6FWwPSNhinQ28feyvpk4DTu u5a6kMf64+8b070H6KYocyMDYTdXpvTt2UYYiYtughqlnVst81hzLNFoS4pMVCz/irHC xOI9zJVxcGyL2bcECc3YzynU1klBvMFIuexD7l7qeg6RlYiZ/X3akMz0oEXLyDD0wPNB ZQQqrMnDquyjkg5qozU+doIIjd9T56VD8Dz7qnOX/4AeTXaE5WEacGcFoJnITb3zE9wJ quxziBbo5Lpp+t//uOroGcjIMAsMjs6qGugNXB/p29n6M+mgaGOgCoqYALtaTv0FWH/a lJRw==
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=3SWk8ThhbvWvlM4Yl/fkMDS9q69Nl/GBQroxsMYWlFc=; b=c9iysLBqld1rvloWkwGcaF2SgNIiYwdCM0NWQjHrTfQhjrh2qQZ0Lm7pZEicrCi9lO NsSZ0RhayDxn4Zh7HReDhcIqJyDDDXkRWUXp1bnMfAnsP5nQw0CxXCgJXB/7XRtyt7C4 DBCVMfnTeZCT06y8Tp9VYgZyP1f/BC6GZ2tA9yScqmDCB8CKt3jDRrGmIgqb2khc5VJk Bp4HbmVnPJFiLPlPhAfhKlwwKnTBgg23vrOt9LPsM3sMwpkGXubTsx2A6K30Barp20lO NCowEddciRMYL4Ghb42hZTCrNjM7tdmImfPaEaI6n9dI0T+7PDWfPSA3b17Jb0ncqmD9 6u+w==
X-Gm-Message-State: APjAAAXJU6P+i6413b5MEjy91BZFjN37JUweDlhZ/N3vLQdDD++X1VL3 iQGmtmCvN4bOVC4RRt9m+NfbN04bdraAApBfldkh3A==
X-Google-Smtp-Source: APXvYqwYdmXpOd7Uzz7podvcGLikZFp4wa+93rxSSD+YFYrz13BH5fQAHGhLekj4ENQtBLwalJCcL58JGenoeDyZhaY=
X-Received: by 2002:a0c:add2:: with SMTP id x18mr13007983qvc.23.1553503974665; Mon, 25 Mar 2019 01:52:54 -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> <CAAiTEH8CvuaSHRNJ0UFuUswbLLU29Bqz0WSTGVoc6q_Oj10BiQ@mail.gmail.com>
In-Reply-To: <CAAiTEH8CvuaSHRNJ0UFuUswbLLU29Bqz0WSTGVoc6q_Oj10BiQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Mon, 25 Mar 2019 09:52:43 +0100
Message-ID: <CAPt1N1=rLho+8PX-JCaypgK+eXdH=+N8-XoTDzb=9xuZWU4RSw@mail.gmail.com>
To: Matthew Pounsett <matt@conundrum.com>
Cc: Joel Jaeggli <joelja@bogus.com>, Paul Hoffman <paul.hoffman@icann.org>, bert hubert <bert.hubert@powerdns.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000915d0a0584e754a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s9mb9WAgd5Mq1pA-o296yxDvjos>
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: Mon, 25 Mar 2019 08:53:08 -0000

Bonjour uses DNS or mDNS. If it’s using DNS, it can in principle use DoT or
DoH, and indeed “Back to my Mac” was using DoT before it was specified in
an RFC. That functionality is still in the open source mDNSResponder code.

I realize that this is somewhat tangential to the point you were making but
wanted to clarify this detail.

On Sun, Mar 24, 2019 at 22:26 Matthew Pounsett <matt@conundrum.com> wrote:

>
>
> 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.
>>
>> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>