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

Robert Edmonds <edmonds@mycre.ws> Mon, 26 September 2016 16:48 UTC

Return-Path: <edmonds@mycre.ws>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC9212B246 for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 09:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN103PB4h8hx for <dnsop@ietfa.amsl.com>; Mon, 26 Sep 2016 09:48:20 -0700 (PDT)
Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3B012B1F3 for <dnsop@ietf.org>; Mon, 26 Sep 2016 09:48:20 -0700 (PDT)
Received: by chase.mycre.ws (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 <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20160926164819.k3k2gqwrgspuyyz7@mycre.ws>
References: <20160920161350.GA3288@laperouse.bortzmeyer.org> <20160923082232.6j2jlr4wqp2fxs56@nic.fr> <7F671C9C-BEEC-479B-99FB-8618C3C75526@powerdns.com> <8A664A35-806C-4F8C-B836-B2A1438FAEA6@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8A664A35-806C-4F8C-B836-B2A1438FAEA6@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kOHRP6igJ_Tf-rXiyuW42dCthFA>
Subject: Re: [DNSOP] Where in a CNAME chain is the QNAME?
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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
    resolver:

    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