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

Bob Harold <> Thu, 05 July 2018 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41D15130F06 for <>; Thu, 5 Jul 2018 11:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVu9bytNL0Cm for <>; Thu, 5 Jul 2018 11:49:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5607130F44 for <>; Thu, 5 Jul 2018 11:49:45 -0700 (PDT)
Received: by with SMTP id y127-v6so7776203lfc.8 for <>; Thu, 05 Jul 2018 11:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NirSPtRhQ8basMKaRhSokExN3pkt4KaND9PuLNTZi0Y=; b=egR596ACE3lfPEYY4kX1lR5K8gEGTR5VU5rpHqAQOZvG5ha+m0L2g52b3iN6YTjJA4 F/PHdBY1qO2cvMSFjlCzXDYUjlyTpwdQNUrKmpz/KpI91uM7SSf4VtkCqbSuX1O2lKTr u1bzNBvnmMe+4GKXn6Aedx/UAgaYelGQViep/XWtPFNbTT+z0M9wdCVBiOUuV0oeuXD6 F1WvSs9cBhQp7kL4cVQOgPGI+pe9TqS1BmAm2TLKHVjbFWCXNfSEwJwH8LmxVHvr28aq 0t5gQHAIqPsD+AaC97BvZSwKBWxVxuyebaWYWV+N6ctLNnaz/y2+QNNQAz+8NfrK0ey5 NLIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NirSPtRhQ8basMKaRhSokExN3pkt4KaND9PuLNTZi0Y=; b=d3vJ5CjoQCuaaqr+pWoGDRNLSTk/tXg2YARYR0UV3e2T9hvHJtF09bArROdBKvG58Y ox9MOwJAqUYX7cXvNm4jnhUwyIeTRc5s8GIQ0LbZB9Ac/0RGiodzWu6u6E+p91Eq9QdV tBrypNmIeaaB+kM61tOw/ExCyS4lEv/5+Wsj+cy9TxqdQN8x0Xx6wq6NFtdzeAiHNWTW gcq95QuG5laP9kcN6S2KeEWEvN7amWTPzMP8VAxNIr9zBxWZONX07n9zh3K1KI/yd/2o +k4zISrGWDo0FKMLoMk/88a8kaOhlD54ZllBdney82zLH/4Id48VOPtS1PrHXP7lF+pX vT0g==
X-Gm-Message-State: APt69E0j1h6ZQCpr8vnoyc1dEHyWgCQjmKtrZ0S6AGC4JpI2FYIO2SK7 4C4p2yGGnjXKINyJTLZGfYVjb4GhVyMjK91gGFvZKw==
X-Google-Smtp-Source: AAOMgpfURi5DLduf/cDs8D3hYK+89Zwrio480h4LDRxIitFeyFUg0/19It0biSkB8UDXBNHWZ94o0YTzWguMliK6GUw=
X-Received: by 2002:a19:b2c7:: with SMTP id t68-v6mr5015988lfk.132.1530816583676; Thu, 05 Jul 2018 11:49:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Bob Harold <>
Date: Thu, 5 Jul 2018 14:49:31 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000afc9b00570450240"
Archived-At: <>
Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jul 2018 18:49:50 -0000

On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <> wrote:

> On Jul 5, 2018, at 1:39 PM, Bob Harold <> 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.)

Bob Harold

> -------
> And a question:
> Appendix A. ISC DHCPv6 Configuration Example
> "option tls.adn code 228 = domain-list;
> option tls.adn "";"
> Why is this defined as a list, but only a single domain is configured. And
> the text (in 1. Introduction) indicates only one domain is allowed per
> option. Is there a single domain format that should be used?
> Yeah, this is a bug in the ISC config file. I will fix the example.
> Thanks,
> Tom