Re: [DNSOP] Where in a CNAME chain is the QNAME?

Robert Edmonds <edmonds@mycre.ws> Fri, 23 September 2016 20:21 UTC

Return-Path: <edmonds@mycre.ws>
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 EAB6412B846 for <dnsop@ietfa.amsl.com>; Fri, 23 Sep 2016 13:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-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 2hmYx0kP9vVi for <dnsop@ietfa.amsl.com>; Fri, 23 Sep 2016 13:21:20 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463DD12B827 for <dnsop@ietf.org>; Fri, 23 Sep 2016 13:21:20 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id B510B12C0F09; Fri, 23 Sep 2016 16:21:19 -0400 (EDT)
Date: Fri, 23 Sep 2016 16:21:19 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20160923202119.f6rjtsmgxxdl35ty@mycre.ws>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <20160923195726.GE4670@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160923195726.GE4670@mournblade.imrryr.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Y8EJEDZ3GNCZHu0Gze9aUsyj4XM>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 23 Sep 2016 20:21:22 -0000

Viktor Dukhovni wrote:
> On Fri, Sep 23, 2016 at 10:22:32AM +0200, Stephane Bortzmeyer wrote:
> 
> > On Tue, Sep 20, 2016 at 06:13:50PM +0200,
> >  Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote 
> >  a message of 68 lines which said:
> > 
> > > This issue was spotted by Peter van Dijk. It is about
> > > draft-ietf-dnsop-nxdomain-cut-05, recently approved by IESG. The
> > > problem is the definition of "QNAME" when there is a CNAME chain.
> > 
> > OK, after reading the discussion, my opinion, as an author (but I'll
> > of course defer the decision to the working group, the WG chairs, the
> > RFC editor and the flying spaghetti monster):
> > 
> > The re-definition of QNAME by RFC 2308 is awkward and does not match
> > the general usage, or the previous definitions. Therefore, I prefer to
> > keep the "common sense" usage "QNAME is the owner name of the record
> > in the Question Section". Which means that, in my example, the QNAME
> > is "www.afnic.fr" and the current text of
> > draft-ietf-dnsop-nxdomain-cut-05 is correct.
> 
> This would I believe cause problems if one then concludes that the
> subtree below the QNAME is absent.

How would one conclude that, when the document is careful to distinguish
between the QNAME and the "denied name"?

    Abstract

       This document states clearly that when a DNS resolver receives a
       response with response code of NXDOMAIN, it means that the domain
       name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

       […]

       "Denied name": the domain name whose existence has been denied by a
       response of rcode NXDOMAIN.  In most cases, it is the QNAME but,
       because of [RFC6604], it is not always the case.

       […]

       Warning: if there is a chain of CNAME (or DNAME), the name which does
       not exist is the last of the chain ([RFC6604]) and not the QNAME.
       The NXDOMAIN stored in the cache is for the denied name, not always
       for the QNAME.

       […]

-- 
Robert Edmonds