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

["Darcy Kevin (FCA)" <[e-mail]>]

-----Original Message-----
From: DNSOP [mailto:[e-mail]] On Behalf Of Peter van Dijk
Sent: Tuesday, August 29, 2017 4:09 AM
To: [e-mail]
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 www.rfc-editor.org, 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