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

Robert Edmonds <> Mon, 26 September 2016 16:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EC9212B246 for <>; Mon, 26 Sep 2016 09:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rN103PB4h8hx for <>; Mon, 26 Sep 2016 09:48:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F3B012B1F3 for <>; Mon, 26 Sep 2016 09:48:20 -0700 (PDT)
Received: by (Postfix, from userid 1000) id A6A3C12C1087; Mon, 26 Sep 2016 12:48:19 -0400 (EDT)
Date: Mon, 26 Sep 2016 12:48:19 -0400
From: Robert Edmonds <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
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: Mon, 26 Sep 2016 16:48:21 -0000

Paul Hoffman wrote:
> On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
> > 2308 does not “redefine” QNAME. It clarifies that the usage in 1034
> > 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict
> > with this; the QNAME there is just the initial QNAME.
> This seems like a very limited view of RFC 1034. RFC 1034 actually defines
> QNAME in Section 3.7.1:
> 3.7.1. Standard queries
> A standard query specifies a target domain name (QNAME), query type
> (QTYPE), and query class (QCLASS) and asks for RRs which match.
> Further, the usage in Section 4.3.2 does not say that the QNAME is the last
> name in the chain, just that the algorithm itself repeats with a new value
> for QNAME:
>             If the data at the node is a CNAME, and QTYPE doesn't
>             match CNAME, copy the CNAME RR into the answer section
>             of the response, change QNAME to the canonical name in
>             the CNAME RR, and go back to step 1.

If STD 13 were to be typeset like a technical book, "QNAME" in 1034
§4.3.2 would be styled using the book's typographical convention for a
variable name.

The exact same formulation in §4.3 ("change … to the canonical name in
the CNAME RR") is used again in the resolver algorithm in §5.3:

    The following resolver algorithm assumes that all functions have been
    converted to a general lookup function, and uses the following data
    structures to represent the state of a request in progress in the

    SNAME           the domain name we are searching for.

    STYPE           the QTYPE of the search request.

    SCLASS          the QCLASS of the search request.


    5.3.3. Algorithm

    The top level algorithm has four steps:


       4. Analyze the response, either:


             c. if the response shows a CNAME and that is not the
                answer itself, cache the CNAME, change the SNAME to the
                canonical name in the CNAME RR and go to step 1.


Since "SNAME" doesn't conflict with a term from another part of the
document set, it's clear that SNAME is being used as a variable name. So
the parallel use in §4.3.2 ("change QNAME to the canonical name") must
also be as a variable name, not a terminological (re)definition.

Robert Edmonds