Re: [DNSOP] raising the bar: requiring implementations

Matthijs Mekking <> Fri, 30 March 2018 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DF31124BAC for <>; Fri, 30 Mar 2018 00:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W8RWhMx3TOv0 for <>; Fri, 30 Mar 2018 00:44: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 ESMTPS id DEEBF1205D3 for <>; Fri, 30 Mar 2018 00:44:43 -0700 (PDT)
Received: from [IPv6:2001:981:19be:1:395e:64ed:1228:ed55] ([IPv6:2001:981:19be:1:395e:64ed:1228:ed55]) by with ESMTPSA id 1oiFfYNv44EsM1oiGfNSMK; Fri, 30 Mar 2018 09:44:41 +0200
References: <> <> <> <20180328151939.GA19504@jurassic> <> <20180328194836.GB14536@jurassic>
From: Matthijs Mekking <>
Message-ID: <>
Date: Fri, 30 Mar 2018 09:44:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180328194836.GB14536@jurassic>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfMlU7J6xkt0qQJnVXwGxfKVRWtU8KOLzTyXu4VmpxOB8JCmtDkUFBdY9WNyZAh62fBgMD6ywpQiAwtyrCkLFfP5bhFK7kkoH4lyEKWBtQH3j8CTkr5s0 hxUwswdfNATayjo05xrKZFSuXH/oq7/MYVBkw6JktcF3MddUOqCLSoCU0XFMxCxsszlfFo1mNRrp4Yc0iB4TE8BjDCmCih9qaMvV7U1UdZSn/4YYI3+BO7CK U2jlcGFEbbf5hBaZa/NZ2/GP1F1ZrPv9VqxH/DHHHbE=
Archived-At: <>
Subject: Re: [DNSOP] raising the bar: requiring implementations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Mar 2018 07:44:46 -0000

I can agree with the argument that if implemented in a major open-source 
DNS implementation it would weigh in more to the discussion, but 
limiting to is far too restricting in my opinion.

Best regards,

On 03/28/2018 09:48 PM, Mukund Sivaraman wrote:
> On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote:
>> As mentioned in the meeting, I am in favor of requiring implementations
>> before drafts become standards.
>> However, I would be opposed to limit acceptable implementations to the few
>> major open source DNS implementations (define major). It should be
>> acceptable for other organizations or just persons to contribute a reference
>> implementation.
> It depends on the topic of the draft of course, esp. where in operations
> it applies. If it is nameserver territory, I absolutely want to see an
> implementation in *any* of the major DNS implementations. By major, I
> mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is
> because:
> * A full-fledged nameserver is somewhat different from a toy
>    implementation in performance and scalability (this point is from
>    experience with a bad implementation of a draft)
> * The rest of us want to see proof that it can be implemented (not just
>    a promise or mention of implementation) and play with it and observe
>    operational characteristics _freely_, and determine whether a draft
>    will really improve things in the way it says it will. E.g., take all
>    the multiple-answer drafts that are making the rounds.. in Singapore
>    there was a presentation of a grand matrix of them, but who knows how
>    they actually perform?
> It's 2018. We aren't living in the dark ages with a single DNS
> implementation.
> If a draft is for nameserver software to implement, and if the authors
> cannot implement it by themselves, they can persuade one of the open
> source vendors to do so. If they are unable to persuade any, that should
> be enough consensus about how significant that draft is. Speaking for
> myself, we in our DNS implementation add support for several drafts
> early in the draft stage because they look necessary or interesting, or
> because we want to know how they behave early on.
> 		Mukund
> _______________________________________________
> DNSOP mailing list