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

"Darcy Kevin (FCA)" <> Tue, 29 August 2017 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 107DE13295E for <>; Tue, 29 Aug 2017 15:17:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KcunGN47tCXR for <>; Tue, 29 Aug 2017 15:17:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 691C2132697 for <>; Tue, 29 Aug 2017 15:17:46 -0700 (PDT)
Received: from (Unknown_Domain []) by (Symantec Messaging Gateway) with SMTP id B4.CF.15564.808E5A95; Tue, 29 Aug 2017 18:17:44 -0400 (EDT)
X-AuditID: 81094b67-b882b98000003ccc-08-59a5e808ffcc
Received: from (Unknown_Domain []) by (Symantec Messaging Gateway) with SMTP id 0D.26.17921.408E5A95; Tue, 29 Aug 2017 18:17:42 -0400 (EDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 29 Aug 2017 18:17:41 -0400
Received: from ([fe80::cc0c:cb4f:1b3f:2701]) by ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1236.000; Tue, 29 Aug 2017 18:17:41 -0400
From: "Darcy Kevin (FCA)" <>
To: "" <>
Thread-Topic: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
Thread-Index: AQHTHORnHuETSd4O0EiRIffADErT/qKT6iSAgAAsejiABfxBAP//5pnQgAFL5oCAAElCoA==
Date: Tue, 29 Aug 2017 22:17:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyfXWnki7Hi6WRBtumsVncfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGTea57EUnJKqeNQxi7mBcZ9oFyMnh4SAicSdpc+Yuhi5OIQE tjNKdP1uYodJnP27CcwWEljPKPGmuRCiaB2jxL4T/SwQzk5GiZ9bp7GCVLEBdSy8cpcZxBYR UJW48O87E4gtLJAise/nRnaIeKrEpENzWCDsMIkVOy6C2SxA9UvWrAGbwyvgJDGv9xwbxIJP TBLffrQzgiQ4BRwket68ZAOxGQXEJL6fWgO2gFlAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuE bSCxdek+FghbSeLbqzVsEL06Egt2f4KytSWWLXzNDHGEoMTJmU/AvpQQuMYusfDHe+YJjJKz kOybhaR/FpL+WUj6FzCyrGKULs5Iyk0sMDDXS60oKUrUS84oqizOSS3SS87P3cQIjMNGTu/0 HYxXFloeYhTgYFTi4T1/dWmkEGtiWXFl7iFGCQ5mJRHe5mdAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rwfi4FSAumJJanZqakFqUUwWSYOTqkGxuMFV1z/60tlC0t/afoj67r6mcTqiLda5jw/ 7AoD4sTmOJd8y/jOGdpxP+2h9XIWngIbcTP3GXPrrwvrmpVWW258XLNk6epZ9ftCjh4KuOc+ 98ZPjZ7Cew3qWxys3XR+fy7mOhk1TTywP3Llqe8HbHnW/M5/8/Z2NIv9nxliE1IPTsxdU/Ri lxJLcUaioRZzUXEiAKzVkT2/AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUyfbWIgS7bi6WRBp1XmSzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBvN81gKTklVPOqYxdzAuE+0i5GTQ0LAROLs303sILaQwHpG iTfNhV2MXED2OkaJfSf6WSCcnYwSP7dOYwWpYgPqWHjlLjOILSKgKnHh33cmEFtYIEVi38+N 7BDxVIlJh+awQNhhEit2XASzWYDql6xZAzaHV8BJYl7vOTaIBZ+YJL79aGcESXAKOEj0vHnJ BmIzCohJfD+1BmwBs4C4xK0n85kgzhaQWLLnPDOELSrx8vE/VgjbQGLr0n0sELaSxLdXa9gg enUkFuz+BGVrSyxb+JoZ4ghBiZMzn7BMYBSbhWTFLCQts5C0zELSsoCRZRWjVH5KUm5igYGl Xn5KSrJeckZRZXFOapFecn7uJkZw5HQq7mBsXGR5iFGAg1GJh9fi2tJIIdbEsuLK3EOMkhxM SqK8ss+AQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4m0FyvCmJlVWpRfkwKWkOFiVxXpUCh0Ah gfTEktTs1NSC1CKYrAwHh5IEbzhIo2BRanpqRVpmTglCmomDE2Q4D9BwR7DhxQWJucWZ6RD5 U4ySUuK8hU+BEgIgiYzSPLjeV4ziQC8I8+4AaeMBJkG4rldAA5mABsZ6gQ0sSURISTUwTtv/ ZM1m92X3tp9znWGatnr5bdkeqb+q9zQP6u/jbq1s1tThXbl2cR3nq2uta957ThHiy71pk7Vt y5N3hUc/dzbw/3pyiUfmuHRYGiNfgkp5YPXuh13JLp+6FN3Eou6nc/fYGJTX7bB4q51hFRas wH/25LUZ81WnxPyQWv6o4+/2L7t3Lzo1VYmlOCPRUIu5qDgRAAU8lAE/AwAA
Archived-At: <>
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Aug 2017 22:17:48 -0000

-----Original Message-----
From: DNSOP [] On Behalf Of Peter van Dijk
Sent: Tuesday, August 29, 2017 4:09 AM
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

On 29 Aug 2017, at 0:20, Darcy Kevin (FCA) wrote:

>> Please understand that I don't have a strong opinion on the DNS 
>> terminology discussion, _per_se_, but I do have them with regard to 
>> semantics, logic and proper citation, which was kind of my prior life, 
>> before I even got into DNS, or even Information Technology (at various 
>> times an English major, Philosophy major, a professional proofreader,
>> etc.)
>> The erratum-to-the-erratum is that RFC 1034 didn't *define* QNAME. But 
>> RFC 1035 did: Section 4.1.2, QNAME is one of the fields of the Query 
>> Section, which, it is stated, constitute " the parameters that define 
>> what is being asked". Thus, deductively, QNAME is defined in that 
>> document as "the name that was asked [by the client, assumed]".
> But it only defines it as such in the context of the query.

So, as the sole definition in the foundational RFCs, perhaps that's the *only* context in which the term "QNAME" should have meaning. Which is why I suggested coming up with a different term to be used in other contexts, e.g. the resolver algorithm, the auth-server algorithm, negative caching and so forth. That other term could encompass more than just the name which was originally presented by the client as the QNAME; it could include end-of-CNAME-chain.

>> RFC 2308 includes in its definition of "QNAME", end-of-CNAME-chain 
>> (where applicable). This was not covered by the RFC 1035 definition, 
>> since the client didn't ask for it.
> Right, but end-of-CNAME-chain is implied in 1034 4.3.2.

It's *used* that way, but there is no *definition* in RFC 1034. That's my main point. We have only 2 competing definitions of "QNAME" -- RFC 1035 (with a limited context, as you point out) versus RFC 2308. Thus, we have a choice: to either reconcile the competing definitions via errata (where one "wins" and the other "loses"), or we can bifurcate into different terms. Personally, I prefer the 2-state solution, but it's not a strong preference.

BTW, I looked through a big long list of DNS RFCs -- anything that came up on a search of "DNS" on, that was on standards track, and non-obsoleted. Offhand, I couldn't find any other RFCs where "QNAME" was defined. Of those that reference "QNAME" at all, most use it to refer to the name in the original query, although things get murky in the DNSSEC-related RFCs, especially when it comes to authenticated denial of existence (NSEC for end-of-CNAME-chain? I'm not familiar enough with DNSSEC arcana to discern, with any confidence). RFC 6672 borrows the algorithm from RFC 2672, which in turn borrows it from RFC 1034, wherein the value of "QNAME" is supposedly "changed" to whatever is considered the end of the CNAME chain. But this is, to repeat myself, not a (re)definition of "QNAME"; it started out as merely a convenient way of pressing a string into service as a variable within an algorithmic loop, and the text has just been copied&pasted from RFC to RFC.

													- Kevin