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

Viktor Dukhovni <> Fri, 23 September 2016 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 974C912B39A for <>; Fri, 23 Sep 2016 12:57:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JkIRSBebRuzw for <>; Fri, 23 Sep 2016 12:57:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 071C512B36A for <>; Fri, 23 Sep 2016 12:57:27 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 03C3C284AD7; Fri, 23 Sep 2016 19:57:27 +0000 (UTC)
Date: Fri, 23 Sep 2016 19:57:26 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Sep 2016 19:57:32 -0000

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 <> 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 "" 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
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39791
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1
    ;      IN A       CNAME             SOA 631 3600 1200 604800 1200 NSEC3 1 0 10 468B49CA72DA45F2 VM1M59BBPA704LUI11Q0T4CA3VA6KS77  NS SOA MX RRSIG DNSKEY NSEC3PARAM 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
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56877
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
    ; IN A A

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.