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 <bortzme...@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. Below is a live example I just configured on a BIND 9.10.4-P2 authoritative server as reported by an "unbound" recursor (RRSIGs elided): ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a truth.msmuxy.org ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39791 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;truth.msmuxy.org. IN A truth.msmuxy.org. CNAME fiction.msmuxy.org. msmuxy.org. SOA ns.imrryr.org. postmaster.dukhovni.org. 631 3600 1200 604800 1200 U3H5CG8C4NE5NMCTRQ6BGRTB6LS3ROJQ.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 VM1M59BBPA704LUI11Q0T4CA3VA6KS77 NS SOA MX RRSIG DNSKEY NSEC3PARAM RP80TVU8HQVVE7P086NTPTN2SLRLU5OC.msmuxy.org. NSEC3 1 0 10 468B49CA72DA45F2 TM87BRIHMJM6HUF608JKLNOGTJQIAH0J While at the same time we also have: ; <<>> DiG 9.10.4-P2 <<>> +dnssec +noall +comment +qu +ans +auth +nocl +nottl +cmd -t a stranger.truth.msmuxy.org ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56877 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;stranger.truth.msmuxy.org. IN A stranger.truth.msmuxy.org. A 192.0.2.1 So the NXDOMAIN for "truth" in the first query definitely does not preclude a "stranger" subtree under "truth". It only attests to the non-existence of "fiction". IIRC, reading a long-ago discussion on this topic, Paul Vixie, for one, seemed to say that the first NXDOMAIN response is not only acceptable, but is in fact the more correct choice. That compared with the alternative of returning just the CNAME (NOERROR) w/o a chained answer for the original RRTYPE and leaving the client to ask again with the target name only to discover that the target of the CNAME elicits NXDOMAIN. So it seems that "NXDOMAIN" + CNAME, attests only to the target, not the original QNAME and with DNSSEC comes along with a proof of non-existence for the target, and a proof existence for the CNAME itself. This could almost have imposed rather complex for DANE clients, had there been a possibility of useful TLSA records for a hostname that is an alias leading to a non-existent target. However, since it is not possible to connect to such a host (no A/AAAA records), any TLSA records it might have are moot. -- Viktor. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop