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
- [DNSOP] I-D Action: draft-ietf-dnsop-terminology-… internet-drafts
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminol… Peter van Dijk
- Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminol… Paul Hoffman
- [DNSOP] Definition of QNAME (Was: I-D Action: dra… Stephane Bortzmeyer
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Petr Špaček
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Mark Andrews
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… P Vix
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Darcy Kevin (FCA)
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Shumon Huque
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Peter van Dijk
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Darcy Kevin (FCA)
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Peter van Dijk
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Darcy Kevin (FCA)
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Andrew Sullivan
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Paul Hoffman
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Andrew Sullivan
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Peter van Dijk
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Shumon Huque
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Jim Reid
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Tony Finch
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Evan Hunt
- Re: [DNSOP] Definition of QNAME (Was: I-D Action:… Peter van Dijk