Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt

Tom Pusateri <pusateri@bangj.com> Thu, 05 July 2018 19:31 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 DC4CE130E01 for <driu@ietfa.amsl.com>; Thu, 5 Jul 2018 12:31:51 -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, HTML_MESSAGE=0.001, 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 ZWmaNupHdoUV for <driu@ietfa.amsl.com>; Thu, 5 Jul 2018 12:31:50 -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 CA0201294D0 for <driu@ietf.org>; Thu, 5 Jul 2018 12:31:49 -0700 (PDT)
Received: from butte-480.attlocal.net (104-176-180-232.lightspeed.chrlnc.sbcglobal.net [104.176.180.232]) (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 35D5765E; Thu, 5 Jul 2018 15:30:48 -0400 (EDT)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <A1C27C1A-E1B9-4AB5-A72B-E80A4AB26438@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F20E4ABC-B58A-4C29-A699-A3C951F7886E"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 5 Jul 2018 15:31:45 -0400
In-Reply-To: <CA+nkc8CpKuzD6oXMr7RDpnM8LrYVnLN8oSh2K+eoetc9UD+kEg@mail.gmail.com>
Cc: driu@ietf.org
To: Bob Harold <rharolde@umich.edu>
References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> <CA+nkc8BKC3SmfhjCcymE=euNbaw7TymBZbyHLsrDGZ5BqcTJiA@mail.gmail.com> <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> <CA+nkc8CpKuzD6oXMr7RDpnM8LrYVnLN8oSh2K+eoetc9UD+kEg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/driu/kwPCFLUWrU7xXAYbz_uBW1OmkXg>
Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt
X-BeenThere: driu@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 19:31:52 -0000


> On Jul 5, 2018, at 2:49 PM, Bob Harold <rharolde@umich.edu> wrote:
> 
> 
> On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <pusateri@bangj.com <mailto:pusateri@bangj.com>> wrote:
> 
> 
>> On Jul 5, 2018, at 1:39 PM, Bob Harold <rharolde@umich.edu <mailto:rharolde@umich.edu>> wrote:
>> 
>> I have concern:
>> 
>> 3. DHCPv6 Encapsulating Options
>> 
>> "There is no order
>> implied by the order of options sent or received. It is up to the
>> receiving client to determine which order to use the DNS server
>> configurations."
>> 
>> Let's not wait for some non-standard way to decide the order. Please add 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like in MX and SRV records.
>> 
> 
> Willem has said that from experience with Stubby, that the client should determine the order it uses the discovered DNS servers. The network operator advertising the list doesn’t necessarily have real time data to determine response times, delays, etc. I’m happy to discuss this more. Why should the network operator dictate this?
> 
> I would think that the network operator, who can set the option per subnet, would have a better idea where the subnet is, than a client machine that roams from place to place and usually does not know where it is located.  If the operator lists more than one server, there is likely to be a need to designate primary vs backup in some cases.  If the client knows better, it can certainly have its own list, and ignore or append what the network recommends.  But the network knows better what will be faster or even reachable from a given subnet, in my opinion.  (I run the DHCP servers at my location, so I am probably biased.)

Since the option is probably only refreshed once per day on average, the list is fairly static. Assuming that an on subnet server will respond faster than a server several hops away is a bad assumption. It depends on many factors and these will change constantly depending on the number of clients, the number of TLS connections the server can manage, number of switches and congestion at the network level including APs, etc. Since these conditions change at the sub-second level, having the client figure out which server responds best seems more flexible.

If all the servers in the list should respond, does the network operator care which one is used? Once you get past the access point, is there typically congestion in the wired network you’re trying to avoid?

I’ll put this on my slides to discuss in Montréal.

Thanks,
Tom