Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

Paul Vixie <paul@redbarn.org> Thu, 30 March 2017 18:21 UTC

Return-Path: <paul@redbarn.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 EB17C127B60; Thu, 30 Mar 2017 11:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 G-z9r4oLaeg8; Thu, 30 Mar 2017 11:21:35 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705561279EB; Thu, 30 Mar 2017 11:21:35 -0700 (PDT)
Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4079261F9C; Thu, 30 Mar 2017 18:21:35 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Steve Crocker <steve@shinkuro.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Brian Dickson <brian.peter.dickson@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Mark Townsley <mark@townsley.net>, HOMENET <homenet@ietf.org>, Terry Manderson <terry.manderson@icann.org>
Date: Thu, 30 Mar 2017 18:21:34 +0000
Message-ID: <6266533.Fy4lafrYmC@linux-hs2j>
Organization: Vixie Freehold
In-Reply-To: <D3F59F43-D1D2-4F2B-A29C-B8B3E90CB304@shinkuro.com>
References: <DAC83E33-A206-4EAA-BC96-E26ACCC013A6@icann.org> <4075745.jMg8SJvaMW@linux-hs2j> <D3F59F43-D1D2-4F2B-A29C-B8B3E90CB304@shinkuro.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/56C1aEE2JH1khyb_Q0Oc2f_JBnY>
Subject: Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.
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: Thu, 30 Mar 2017 18:21:37 -0000

On Thursday, March 30, 2017 6:11:00 PM GMT Steve Crocker wrote:
> On the other hand, might there be value in seeing how much errant traffic
> goes to the root so it can be reported and used to inform vendors, network
> architects, network administrators, et al?

it seems unlikely to me that any of them would care. they didn't for RFC 1918, 
and i did try, for years, before DNS-OARC existed, using f-root trace data.

> Given the amount of bogus traffic already goes to the root, I’m not
> immediately worried this will increase the traffic level to a point of
> concern.

that's what we've said about every other incremental increase. some day we 
will reach a tipping point and be wrong. i think if we know that dreck is 
coming, we should prepare for it, perhaps with an NS RR pointing to the AS112 
project, whose operators are ready to share data with researchers on request.

perversely, the ~90+% garbage we receive helps motivate overprovisioning, and 
helps ensure that when some server is down, its impact (less than 10% of load 
that should be answered) is statistically spread out across a large amount of 
dreck. if only good queries made it to the roots, then the statisticaly 
likelihood of not being able to answer one that mattered, would be higher. 
it's a congestion-based form of forward error correction, i suppose.

> And I remain puzzled as to why a simple NXDOMAIN response from the root
> isn’t exactly the right thing and why it matters whether it’s signed or
> not.

nxdomain isn't cached by everyone who should, and of those who cache it, 
nxdomain doesn't stop downward cache traversal everywhere (which it should), 
and in any case nxdomain covers the full qname and so would only stop 
traversals through a full (foo.bar.<homenetlabel>) qname, which is why we need 
query-minimization (which would permit queries for just <homenetlabel> or 
perhaps <onelabel>.<homenetlabel>) whose cached nxdomains would have a broader 
impact (if they stopped traversal and if they are cached at all.)

executive summary: the dns works at all, and we love that, but it's not happy 
and it's not healthy and it's never going to be.

vixie