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

[Robert Edmonds <[e-mail]>]

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 <[e-mail]> 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