Re: [Driu] How to describe various flavors of DNS resolvers

Tom Pusateri <pusateri@bangj.com> Tue, 15 May 2018 16:32 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: driu@ietfa.amsl.com
Delivered-To: driu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B225F12D77D for <driu@ietfa.amsl.com>; Tue, 15 May 2018 09:32:12 -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, SPF_PASS=-0.001] autolearn=ham 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 z7WrNGE9unHd for <driu@ietfa.amsl.com>; Tue, 15 May 2018 09:32:11 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C40126BF7 for <driu@ietf.org>; Tue, 15 May 2018 09:32:11 -0700 (PDT)
Received: from [172.16.10.126] (unknown [107.13.237.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 83501C6E; Tue, 15 May 2018 12:31:09 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <CAAedzxqkvPan_bGLQAPnViS6_59eNB2Hu4Ex+ZEYL89Qh7Mc_A@mail.gmail.com>
Date: Tue, 15 May 2018 12:32:07 -0400
Cc: Paul Hoffman <paul.hoffman@icann.org>, driu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C69A573-5EAF-4D46-BBCF-D825B729E475@bangj.com>
References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> <CAAedzxqkvPan_bGLQAPnViS6_59eNB2Hu4Ex+ZEYL89Qh7Mc_A@mail.gmail.com>
To: Erik Kline <ek@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/i5JZJ18r9McyNkt9BLcs7cmAXQc>
Subject: Re: [Driu] How to describe various flavors of DNS resolvers
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <driu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/driu>, <mailto:driu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/driu/>
List-Post: <mailto:driu@ietf.org>
List-Help: <mailto:driu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/driu>, <mailto:driu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 16:32:13 -0000

> On May 15, 2018, at 12:46 AM, Erik Kline <ek@google.com> wrote:
> 
> I'm not sure I understand the benefit of trying to provide this extra
> information.  I think clients will need to probe nameservers for their
> capabilities.

If by ‘probe’ you mean try something and if it works, use it, then I agree this is going to happen and will change dynamically as trust relationships develop.

But as the delays of probing accumulate, it makes sense to provide a mechanism to advertise a more advanced service offering directly. DHCP is one way to do this. SRV/TLSA records are another. Manual configuration is a third way. This won’t apply in all environments.

> 
> Do we think TLS-only nameservers are a likely operational model?

Under some environments, yes.

There will be circumstances where if a client can’t connect to a well known and pre-trusted DNS server, it will drop its lease and disconnect from the network because it sees this as a form of attack.

There will be other environments where the only DNS available is provided by the enterprise network and the clients are happy about this (clients and servers have the same owners).

Tom