Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Paul Vixie <> Wed, 22 August 2018 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98CD4130E44 for <>; Wed, 22 Aug 2018 11:48:59 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tqyQukgNgwl2 for <>; Wed, 22 Aug 2018 11:48:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B30D130E2F for <>; Wed, 22 Aug 2018 11:48:58 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d] (unknown [IPv6:2001:559:8000:c9:9061:ce0d:93bf:336d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 1EF2A892C6; Wed, 22 Aug 2018 18:48:58 +0000 (UTC)
Message-ID: <>
Date: Wed, 22 Aug 2018 11:48:54 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <>
CC: Vittorio Bertola <>, dnsop WG <>, David Conrad <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Aug 2018 18:49:00 -0000

Ted Lemon wrote:
> It's never been up to the DHC working group to decide whether new DHCP
> options are architecturally good.   People have often used the DHC
> working group as a way to skate by due diligence on architectural
> considerations; this was considered to be a problem even before I was
> chair, and we burned a lot of time evaluating bad ideas before we
> decided not to be the place where new work on DHCP options is done by
> default.   If a DHCP option were to be entertained, this WG, the dprive
> WG or the DoH WG would be where it would have to happen, not because the
> DHC working group is freezing new features, but because it's not in
> their charter.

you, as an author of two implementations as a former DHC WG chair, have 
said that new features should not be added to DHCP because 
authentication. while i disagree, i recognize that your voice has more 
credibility in the DHCP space than mine does, and i'm ready to give up 
rather than actually fight and lose the battle.

> That said, you responded to a message where I talked about what I think
> we ought to do to move forward by saying that moving forward is
> impossible other than by just adding a hack somewhere.   I don't think
> that's true, and in fact I'm feeling like I need to write up a threat
> analysis because even though it's not something that I want to work on,
> it sounds like most people assume it's impossible and I'm just
> suggesting it as a roadblock, and the people who get that it's necessary
> don't seem to be any more enthusiastic about doing it than I am.   I'd
> appreciate it if, when I've written that analysis, you could contribute
> to it, but I'll understand if you don't have time or don't think it's
> worthwhile.

my own experience as a widely unread author is that i have to keep 
things short or people will refile/delete them, no matter how 
meritorious or relevant (or even pithy and clever) the writing was.

P Vixie