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

Tom Pusateri <pusateri@bangj.com> Tue, 15 May 2018 16:20 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 A90B012421A for <driu@ietfa.amsl.com>; Tue, 15 May 2018 09:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 ip422-kQ5o8F for <driu@ietfa.amsl.com>; Tue, 15 May 2018 09:20:16 -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 00F7912D77D for <driu@ietf.org>; Tue, 15 May 2018 09:20:15 -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 74CA8C68; Tue, 15 May 2018 12:19:14 -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: <m1fIAGn-0000FaC@stereo.hq.phicoh.net>
Date: Tue, 15 May 2018 12:20:11 -0400
Cc: driu@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C63E491-2CA9-46BE-B54F-261B5A21AE07@bangj.com>
References: <50A2740C-98AE-4EA9-A290-B3231FFCBD0D@icann.org> <FB84F384-0637-4A8D-8DBD-740FB95EB021@bangj.com> <m1fIAGn-0000FaC@stereo.hq.phicoh.net>
To: Philip Homburg <pch-ietf-driu@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/m7EuAb84WaALGkQ50IselUe9YSw>
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:20:21 -0000

> On May 14, 2018, at 5:59 AM, Philip Homburg <pch-ietf-driu@u-1.phicoh.com> wrote:
> 
>>   This is something Willem and I have been working on:
>> 
>>   [2]https://github.com/pusateri/draft-tpwt-dhc-dns-discovery/blob/maste
>>   r/draft-tpwt-dhc-dns-discovery.txt
> 
> For IPv6 it is unfortunately also necessary to consider router advertisements.
> It might be worth trying to align the DHCPv6 options and any RA options 
> such that they use as much as possible the same conceptual model.

Yes, this makes sense. We will also consider IPv4 if/when there is general agreement about IPv6.

>>   But Ted Lemon is concerned that learning about private DNS over
>>   DHCP is not much benefit because you cant trust the DNS server
>>   you learn about.
> 
>>   3. Any DNS server providing DNS over TLS or DNS over HTTPS should
>>   have DNSSEC records to show they are authentic servers and TLSA
>>   records to ensure the client is talking to the actual server.
> 
> I wonder if, even just as strawman, we should document how to signal DNS over
> TLS and DNS over HTTPS just using DNS, i.e.
> - DANE in the reverse zone can signal TLS or HTTPS
> - the PTR can be used as ADN
> - SRV records can be used to specify ports as well as ADNs and also signal
>  DNS over TLS or HTTPS.
> 
> The advantage is that no new wire representations have to be introduced. 
> The disavantage it that it only works if the operator of the resolver has
> control over reverse DNS.

I think this is always a possibility (even now) but it causes delays so it would be better to explicitly advertise the service offering.

It’s also possible to have an SRV record advertising the service that can be verified and the server authenticated.

> Note that for IPv6, it may take a long time before router vendors support
> the required changes to router advertisements and some client device vendors
> seem to have strong objections against the use of DHCPv6.

Yes, definitely.

This is an attempt at determining what the community wants and hashing out the details. The difference between using RA or DHCPv6 mechanisms is mostly the same from the trust / threat on DNS perspective since the network operator controls both.

Thanks for the comments,
Tom