-----Original Message-----
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Peter van Dijk
Sent: Tuesday, August 29, 2017 4:09 AM
To: dnsop@ietf.org
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
