[DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> Wed, 14 September 2016 17:53 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE412B3E4; Wed, 14 Sep 2016 10:53:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147387558442.19766.339355303388852115.idtracker@ietfa.amsl.com>
Date: Wed, 14 Sep 2016 10:53:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eq5bAuNl0TSoVLix0kOHEVauveE>
Cc: tjw.ietf@gmail.com, dnsop@ietf.org, draft-ietf-dnsop-nxdomain-cut@ietf.org, dnsop-chairs@ietf.org
Subject: [DNSOP] Spencer Dawkins' Yes on draft-ietf-dnsop-nxdomain-cut-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 14 Sep 2016 17:53:04 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-dnsop-nxdomain-cut-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I honestly look forward to reading DNSOPS drafts because they are
uniquely chatty, and this one is no exception (awesome document title,
dude). That said, 

   This documents clarifies RFC 1034 and modifies RFC 2308 a bit so it
   updates both of them.
   
being "a bit modified" is like being a bit dead (either you're dead or
you're not), so maybe that's TOO chatty? 

This draft was very clear to me, as a non-DNS reader. Thanks for that.

Just for my own education, 

   But if a resolver has cached data under the NXDOMAIN cut, it MAY
   continue to send it as a reply.  (Until the TTL of this cached data
   expires.)
   
I found myself wondering why this behavior is allowed. Is this a
performance thing, that you continue to respond normally until normal TTL
expiration happens with no special processing required, or is this about
the non-tree cache implementations described in Section 6, or is there
more to it than that? Perhaps that's worth a word or two explaining.

In this text in Appendix A, 

   Even if the accompanying SOA record is
   for example only, one cannot infer that foobar.example is
   nonexistent.  The accompanying SOA indicates the apex of the zone,
   not the closest existing domain name.
   
it's not clear that this practice is OK, and (especially from the example
that will be deleted), it seems dodgy to the uninitiated. Perhaps it's
worth saying so clearly (if it is, in fact, OK).