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

[Viktor Dukhovni <[e-mail]>]

> On Apr 28, 2018, at 1:28 AM, Viktor Dukhovni <[e-mail]> 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.