Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 15 May 2018 16:57 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 01EB2126CC4 for <dnsop@ietfa.amsl.com>; Tue, 15 May 2018 09:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4hfcb-Egf9de for <dnsop@ietfa.amsl.com>; Tue, 15 May 2018 09:57:21 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B091201F2 for <dnsop@ietf.org>; Tue, 15 May 2018 09:57:21 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D121D7A3309 for <dnsop@ietf.org>; Tue, 15 May 2018 16:57:20 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 15 May 2018 12:57:20 -0400
References: <72D91139-BD51-43A9-8AEA-177753A29F90@dukhovni.org> <CAAiTEH_iXs33YdWrRmn6_iQYH2ba-WxqbYbp27Q2gpzBL7=q5g@mail.gmail.com> <24D5D313-4F02-4A99-9E64-44B35331608E@dukhovni.org> <CAAiTEH9J_VWkQBF=Ytv0Von+YFG1EhxHDpP5Aj=iuXTDsFU0ZA@mail.gmail.com> <8930E547-6327-45B5-89AB-37282D2C245D@dukhovni.org>
To: dnsop <dnsop@ietf.org>
In-Reply-To: <8930E547-6327-45B5-89AB-37282D2C245D@dukhovni.org>
Message-Id: <1D06889C-770F-4F92-BF06-A76338AEB320@dukhovni.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gdn6115uxQfkaUv7zadDEn4sKeQ>
Subject: Re: [DNSOP] Acceptance processing in draft-ietf-regext-dnsoperator-to-rrr-protocol-04 section 3.4
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: Tue, 15 May 2018 16:57:24 -0000


> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> So at this point I think we understand each other, and the issue comes down to whether it is appropriate for the registry to automatically turn on DS records for the first time for a domain which is substantively operationally deficient at the time its CDS records are encountered.
> 
> I think that garbage-in/garbage-out is not only a disservice to the domain's owner, but more importantly it poisons the ecosystem for everyone else.
> 
> If turning on DNSSEC validation in your resolver stops email delivery to a bunch of domains, or breaks all access to the domain's data, whom exactly is the registry helping by enabling DNSSEC for a substantially broken domain.
> 
> Think of this as anti-pollution environmental regulation.

I see a new version -05, with (so far) the Section 3.4 acceptance text
unchanged. I strongly feel broken DNSSEC adoption is much worse than no
DNSSEC adoption, it not only has operational impact on the target domain,
but also creates strong disincentives to enabling validation in resolvers.

Therefore, if at all possible, broken implementations should not have their
DS records published, and all reasonable effort should be made to detect
known forms of breakage before inflicting such breakage on the world at
large.

For example, nazwa.pl has recently signed a bunch of domains with lame
wildcard NS records under the zone apex.  This breaks denial of existence
for all child domains, including TLSA lookups, and therefore breaks email
delivery to the newly signed domains.  This is easily detected, and such
detection should be part of acceptance criteria for having DS records
published.  Yes, some domains will introduce breakage after the fact,
but we can and should avoid it at inception.

$ grep nazwa broken | ... | xargs -n1 unbound-host -D -t tlsa
validation failure <_25._tcp.andyandmag.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.fruty.pl. TLSA IN>: nodata proof failed from 85.128.128.10
validation failure <_25._tcp.funit.com.pl. TLSA IN>: nodata proof failed from 195.238.185.146
validation failure <_25._tcp.informica.org. TLSA IN>: nodata proof failed from 195.238.185.146
validation failure <_25._tcp.vitacard.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.sjedrzejewski.pl. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.centrumuslugszklarskich.com. TLSA IN>: nodata proof failed from 85.128.129.10
validation failure <_25._tcp.ts3priv.pl. TLSA IN>: nodata proof failed from 195.238.185.146

-- 
	Viktor.