Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Dave Crocker <dhc@dcrocker.net> Mon, 13 March 2017 16:12 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A966129508 for <dnsop@ietfa.amsl.com>; Mon, 13 Mar 2017 09:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 Odm9GEO6-u5B for <dnsop@ietfa.amsl.com>; Mon, 13 Mar 2017 09:12:24 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953F4129522 for <dnsop@ietf.org>; Mon, 13 Mar 2017 09:12:24 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2DGEK5Q012145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Mar 2017 09:14:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1489421660; bh=EVxzfzlpd4iUyKiM8dULO7HL2kqm9fdgfQ+rMQxG1kM=; h=Subject:To:References:Cc:Reply-To:From:Date:In-Reply-To:From; b=WAidfNjaVAD06Rlph1vDSvbQ3ZjUZdry2/p9yWZ56lpw1/a6HbDJLcw9qfprc6j5e GWjxnua8kD89Us0Wwm/KowbTmewZmLgJOQ/SRpnmg98hHCahgUaQqoTTiiTabDY379 xFtxPvBUDaNst6rgjDj2kh9R8aRdnvBQ0ctOqD/0=
To: Paul Wouters <paul@nohats.ca>
References: <CADyWQ+ETSd199ok0fgh=PB=--hW7buPgSoCg22aK51Bk4xxBmw@mail.gmail.com> <CADyWQ+GUDg2iA+MQ9xjNLDVvRgnd9PD=pLBNNvp0xK3UZVSqTA@mail.gmail.com> <1AD82FB6-735A-4124-A0A3-2158EC567AD6@nohats.ca> <CAHw9_iK+SWiHZwGgHZRO2T1MLVQZS-2BaeZBzyUuZ0iWHX2ZjA@mail.gmail.com> <fa0b1bd1-f7b8-c3bc-58a3-397c1b118370@bogus.com> <alpine.LRH.2.20.999.1703121922250.11053@bofh.nohats.ca> <19668099-d361-5bd5-7efb-2aab92c190e6@bbiw.net> <alpine.LRH.2.20.999.1703130533180.18195@bofh.nohats.ca> <677ed378-554b-5129-4f46-c2478696e483@dcrocker.net> <4A94FA48-C7CD-480E-8E22-9F3115542A61@nohats.ca>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <165d0ec7-809f-d914-e8a6-31c049ab32ac@dcrocker.net>
Date: Mon, 13 Mar 2017 09:12:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <4A94FA48-C7CD-480E-8E22-9F3115542A61@nohats.ca>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nFaCRsLryfqBrZOIpJ67FUhIDVU>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 16:12:25 -0000

On 3/13/2017 7:58 AM, Paul Wouters wrote:
>> On Mar 13, 2017, at 15:44, Dave Crocker <dhc@dcrocker.net> wrote:
>>> On 3/13/2017 4:11 AM, Paul Wouters wrote:
>>> The draft breaks DNSSEC.
>> ...
>>> I have proposed a method that would not change the RPZ response for a
>>> non-DNSSEC client, but would add data for DNSSEC capable clients to be
>>
>> That sounds like an excellent bit of technical enhancement to consider... /after/ documenting /existing/ practice.
>
> I would have agreed if the feature didn't break my DNS.


Actually, that's exactly the kind of reason to have existing practice 
documented inside a working group rather than outside.

Besides seeking to make such a document accurately specify the technical 
details, there is the need to document the implications.  That is 
benefits and problems.

This lays some foundation for future work, to fix problems, as well as 
add enhancements.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net