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

[Viktor Dukhovni <[e-mail]>]

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.  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.