Re: [DNSOP] New draft for consideration:

Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 25 March 2019 08:38 UTC

Return-Path: <vittorio.bertola@open-xchange.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 792C21203B3 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 UhO0i6yiVA47 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 01:38:15 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B784B12039E for <dnsop@ietf.org>; Mon, 25 Mar 2019 01:38:12 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id CC8C56A265; Mon, 25 Mar 2019 09:38:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1553503089; bh=UCiShrhv9IeKMFYYlwoqPZLh5X67vmUZIjai9yOg4VU=; h=Date:From:To:In-Reply-To:References:Subject:From; b=6XB1a08umWzXrhw0F/IWhP4ADEa2lM1DxPw+QgQqtGUBPGLzQbL03eS1QPa6K0QW6 1nUhgWbt+qLBRV5p3Xhjpnj5gkcK6qeNWiFykBWEmwo966JqmOB1wimGgCqXY9de3L g2UEaUlsFEoDTUAbXh8wFZhOV8JERjZ910mO/W1kVBF+wRP3dq8eAdMRQVYCpZrEg6 2V4kWtPabfQ7Yr+fRtjVKz60yMUZvusKcKLwSPK6YMq3/nUubFkCUEUKwdXpCNPmxw 4wbRI90mfw5an5onQyQkbI2PWxXEhA/PWMA3IcsmZWRkg8vbNxocNOxjUGsH9gcDJ/ kMw96GYuIKorQ==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id C01C73C0412; Mon, 25 Mar 2019 09:38:09 +0100 (CET)
Date: Mon, 25 Mar 2019 09:38:09 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Message-ID: <1743613011.14034.1553503089731@appsuite.open-xchange.com>
In-Reply-To: <E2267015-0A5F-4D6E-85F0-3FA93348CA79@icann.org>
References: <E2267015-0A5F-4D6E-85F0-3FA93348CA79@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev9
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uklk03tcYJLRYBC6H7BjkmhCDCA>
Subject: Re: [DNSOP] 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:38:24 -0000

> Il 24 marzo 2019 alle 7.42 Paul Hoffman <paul.hoffman@icann.org> ha scritto:
> 
> 
> Greetings again. As y'all have seen over the past few weeks, the discussion of where DNS resolution should happen and over what transports has caused some people to use conflicting terms. As a possible solution to the terminology problems, I am proposing a few abbreviations that people can use in these discussions. The draft below, if adopted by the DNSOP WG, would update RFC 8499 with a small set of abbreviations.

I don't know if these terms are already defined somewhere else, but the distinction that I've found most useful in the DoH discussion is "local resolver" (i.e. the one provided on/by the local network the user connects to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go beyond the Internet access provider's network). Some of the issues happen, and already happen today, as soon as the user adopts a remote resolver, even with plain old DNS.

I agree that another set of problems derives instead from applications using a resolver different than the one configured in the operating system, which may or may not be the local resolver. So it's fine to define a couple of terms like "DaT" and "DaO", though I don't really like these two acronyms :-) In my draft I introduce the terms "network-level name resolution", "application-level name resolution" and "application-level resolver selection". They are not acronyms, but I think they would be more understandable in a discussion than more and more acronyms. 

(I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is just clearer.)

Ciao,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy