> On Sep 23, 2016, at 4:22 AM, Stephane Bortzmeyer <[email protected]> wrote: > > On Tue, Sep 20, 2016 at 06:13:50PM +0200, > Stephane Bortzmeyer <[email protected]> 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.
+1 to this interpretation. I think a good case can be made that QNAME is the last target in a chain of aliases based on the "variable substitution" use of QNAME in §4.3.2 of RFC 1035 and the definition of QNAME in RFC 2308. However, I think this definition violates the principal of least astonishment, as this thread shows: I'd venture that more people familiar with the subject matter would define QNAME as the name in the question section of a DNS message. (That's my sense of the definition, FWIW.) I like the current text in draft-ietf-dnsop-nxdomain-cut-05, which avoids confusion by explicitly calling out "denied name". Even if the consensus of this thread had been that the definition of QNAME was the "last alias target", I'd argue that we'd still want the "denied name" language to avoid any confusion because I don't think the "last alias target" of QNAME is the majority interpretation. Matt _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
