Re: [Driu] Comments on draft-pusateri-dhc-dns-driu-00

Tom Pusateri <> Thu, 19 July 2018 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB7CD130F0F; Thu, 19 Jul 2018 11:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hCtBurbyX8qC; Thu, 19 Jul 2018 11:59:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30600130E8B; Thu, 19 Jul 2018 11:59:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3DA25E1F; Thu, 19 Jul 2018 14:57:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Thu, 19 Jul 2018 14:59:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Tomek Mrugalski <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Driu] Comments on draft-pusateri-dhc-dns-driu-00
X-Mailman-Version: 2.1.27
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, 19 Jul 2018 18:59:47 -0000

> On Jul 19, 2018, at 9:24 AM, Tomek Mrugalski <> wrote:
> Hi,
> I have read the draft-pusateri-dhc-dns-driu-00 draft and I like it.
> A lot.
> Here are some improvement suggestions. There are quite a few of them,
> but they are mostly editorial in nature and easy to fix. The basic
> proposal sounds good, at least from the DHCP perspective. Options are
> well designed and mostly follow guidelines of RFC7227.
> What should the client do if the options are no longer sent by the
> server when renewing or the server sends different values?
> Section 3: Each encapsulating option should be specified in a separate
> section for easier referencing.
> Section 4: The text suggests the options defined in 4.1-4.3 can appear
> only in DNS_TLS option, which is not true as they can also appear in
> DNS_DTLS. The text also incorrectly mentions four options (three are
> defined).
> Section 4.1: OPTION_IPV6 is not a good name. The name should be
> reasonably descriptive, so when looked upon on an all DHCP options list
> users would have some fighting chance to guess what this option is
> about. How about OPTION_DNSS_ADDR?  The same applies to other names
> (OPTION_PORT and OPTION_URI). Adding the same prefix (DNSS? SDNS?) to
> all of them would be useful. When browsing a list of options it would be
> then immediately obvious that all of them serve similar goal and are
> supposed to be used together.
> Section 4.2: This text "The use of OPTION_ADN by the server is OPTIONAL
> but strongly encouraged." should use a stronger normative language,
> i.e. be rephrased to use SHOULD. Makes a lot of a difference for server
> implementors (we can print warnings when not configured) and test
> implementors (it's tricky to write reasonable testes for OPTIONAL and
> MAY).
> Section 4.3: "It defaults to port 853 as defined in Section 3.1 of
> [RFC7858]." We don't do option defaults in DHCPv6. This needs to be
> clarified. Do you want the server, when not explicitly configured, to
> send this option with a value of 853 or the client to assume value of
> 853 when the option is not sent by the server?  These are two different
> things. The former would require extra per-option logic to be
> implemented on the server side and that's something the DHCP community
> likes to avoid. Having default client behavior is fine, though. I think
> this text should be moved to a separate client/server section. See the
> explanation below.
> Section 7: These are well written security considerations. Thanks for
> putting them out clearly. One aspect not mentioned here is time-based
> attack, such as using expired (or not yet valid) DNSSEC keys. I wish I
> could offer a solution to this problem. Mandating NTP_SERVER option
> wouldn't help much, it would just increase the attack complexity (a
> perpetrator would need to also spoof NTP server).
> Section 10.1: Why these all normative references? As a DHCP implementor,
> do I really need to read and understand the whole DoT and DoH to
> implement those options? I think most of them are informational, except
> 2119, 3315.
> There should be new client behavior and server behavior sections added.
> These sections are very useful for implementors and also help a
> lot avoiding confusion which side is supposed to do what. Also, that's
> what RFC7227 recommends (and provides some boiler plate text).
> The client behavior section should offer some guidance with relation to
> plain DNS options (RFC3646). Perhaps something like the following would
> make sense: "A client requesting DNS_TLS, DNS_DTLS and/or DNS_HTTPS
> SHOULD also request OPTION_DNS as a fallback mechanism.  In legacy
> networks that do not support any of the new mechanisms, the client will
> receive only OPTION_DNS values. In such case the client should do X".
> I'm not sure what X would be. Perhaps adding a non-normative text
> explaining that a client can either chose to use plain servers and
> losing benefits of TLS/HTTPS or discard them and be left with unusable
> connection.
> The client behavior section should clarify the client is supposed to
> request only the container options, not the options within them.  The
> RFC3315bis is around the corner (in RFC-Ed queue right now) and it will
> add two extra columns to the DHCPv6 options list. First specifies
> whether an option is a singleton (your draft already clearly says that
> multiple options are allowed). The second column is whether an option
> code can appear in ORO. My recommendation is to request only the
> container options.
> The A.1 appendix uses non-RFC3849 addresses. Thank you for using ISC
> software.
> Overall, with a bit of easy tweaking this draft will be in a great
> shape. It's been a long time since a new draft appeared in the DHC WG
> with such a well defined purpose, reasonable proposed solution and this
> level of maturity at -00.
> Finally, one comment with my DHC co-chair hat on. If the DRIU BoF turns
> out to be a WG forming one, this draft should be adopted there, not in
> DHC. However, if there is no better suited WG, we'll need to talk with
> our AD and will likely be able to do adoption call in DHC.
> Thank you for this work. Let me know if you need any help.
> Tomek Mrugalski

Thanks for the encouraging feedback. We will be glad to make the recommended changes.