Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 21 September 2017 03:45 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 648D61330AE for <dnsop@ietfa.amsl.com>; Wed, 20 Sep 2017 20:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=QUsifVND; dkim=pass (1024-bit key) header.d=yitter.info header.b=Oue8Or4I
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 4UY63CqL44gj for <dnsop@ietfa.amsl.com>; Wed, 20 Sep 2017 20:45:37 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76B01201F8 for <dnsop@ietf.org>; Wed, 20 Sep 2017 20:45:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 1C657BEDA1 for <dnsop@ietf.org>; Thu, 21 Sep 2017 03:45:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1505965537; bh=38c7VkKeZTtwy/iAxaiv5LORsex9q6a4ujz5a0KRb/4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=QUsifVNDTP8Y07yNEaY3J5/x70EVxe2sS7wUKsrOJYf48lG63T92Swqol+YpAY0wS 4PYsbx1UwAS8eRmnCOABObGgtiinYA6AwETA5nLLFnQnlWH9nFkKJ+FvxlLvsC7Orp kTh+RKaX8XDxbZHzHV5pIFgIHspEdZ9pNS0gCjw4=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRjSYx8l5kAz for <dnsop@ietf.org>; Thu, 21 Sep 2017 03:45:35 +0000 (UTC)
Date: Wed, 20 Sep 2017 23:45:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1505965535; bh=38c7VkKeZTtwy/iAxaiv5LORsex9q6a4ujz5a0KRb/4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Oue8Or4Ip/6j6FkBfKInRa+xjtvDJMu+9M2VtsA50S5MrErqO/eFTKC1NVRcG6KEA 7z9Eg6TKHmIipyt+RFnheE01VuEiEg+GoBbrFVChqMLj8gZBv2krJ/1mF4hOJxMCxz vSD+YfMO4QFgFa91+GzOd/cm0WIHnWxvBTmzBkB0=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170921034533.d2isi2idl7cyepea@mx4.yitter.info>
References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170824142147.lshdlmjv62nojd32@nic.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jXl6yIy8gcHPHGTbJAlWcGpT_Ro>
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 21 Sep 2017 03:45:39 -0000

Hi,

The conversation on QNAME went quiet some time ago, so I thought it
might be a good time to send a proposal about what to say about this
term.  I haven't passed this by my co-editors, since it seems like
we're going all to need to discuss anyway.

Here's the old text:

   QNAME  The most commonly-used definition is that the QNAME is a field
      in the Question section of a query.  "A standard query specifies a
      target domain name (QNAME), query type (QTYPE), and query class
      (QCLASS) and asks for RRs which match."  (Quoted from [RFC1034],
      Section 3.7.1.)

      [RFC2308], however, has an alternate definition that puts the
      QNAME in the answer (or series of answers) instead of the query.
      It defines QNAME as: "...the name in the query section of an
      answer, or where this resolves to a CNAME, or CNAME chain, the
      data field of the last CNAME.  The last CNAME in this sense is
      that which contains a value which does not resolve to another
      CNAME."

Here's a proposal to replace it:

   QNAME  The most commonly-used rough definition is that the QNAME is a
      field in the Question section of a query.  "A standard query
      specifies a target domain name (QNAME), query type (QTYPE), and
      query class (QCLASS) and asks for RRs which match."  (Quoted from
      [RFC1034], Section 3.7.1.).  Strictly speaking, the definition
      comes from [RFC1035], Section 4.1.2, where the QNAME is defined in
      respect of the Question Section.  This definition appears to be
      applied consistently: the discussion of inverse queries in section
      6.4 refers to the "owner name of the query RR and its TTL",
      because inverse queries populate the Answer Section and leave the
      Question Section empty.  (Inverse queries are deprecated in
      [RFC3425], and so relevant definitions do not appear in this
      memo.)

      [RFC2308], however, has an alternate definition that puts the
      QNAME in the answer (or series of answers) instead of the query.
      It defines QNAME as: "...the name in the query section of an
      answer, or where this resolves to a CNAME, or CNAME chain, the
      data field of the last CNAME.  The last CNAME in this sense is
      that which contains a value which does not resolve to another
      CNAME."  This definition has a certain internal logic, because of
      the way CNAME substitution works and the definition of CNAME.  If
      a name server does not find an RRset that matches a query, but it
      finds the same name in the same class with a CNAME record, then
      the name server "includes the CNAME record in the response and
      restarts the query at the domain name specified in the data field
      of the CNAME record."  ([RFC1034] Section 3.6.2).  This is made
      explicit in the resolution algorithm outlined in Section 4.3.2,
      which says to "change QNAME to the canonical name in the CNAME RR,
      and go back to step 1" in the case of a CNAME RR.  Since a CNAME
      record explicitly declares that the owner name is canonically
      named what is in the RDATA, then there is a way to view the new
      name (i.e. the name that was in the RDATA of the CNAME RR) as also
      being the QNAME.

      This creates a kind of confusion, however, because the answer to a
      query that results in CNAME processing contains in the echoed
      Question Section one QNAME (the name in the original query), and a
      second QNAME that is in the data field of the last CNAME.  The
      confusion comes from the iterative/recursive mode of resolution,
      which finally returns an answer that need not actually have the
      same owner name as the QNAME contained in the original query.

      To address this potential confusion, it is helpful to distinguish
      between two meanings:
      
      QNAME (original)  The name actually sent in the Question
         Section in the orignal query, which is always echoed in the
         (final) reply in the Question Section when the QR bit is set to
         1.

      QNAME (effective)  The name actually resolved, which is either the
         name actually queried or else the last name in a CNAME chain as
         defined in [RFC2308].

I'm certainly not wedded to these two names.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com