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

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 24 Aug 2017 16:21:47 +0200

On Sat, Jul 01, 2017 at 02:40:43PM -0700,
 [email-masked] <[email-masked]> wrote 
 a message of 45 lines which said:

>         Title           : DNS Terminology
>         Authors         : Paul Hoffman
>                           Andrew Sullivan
>                           Kazunori Fujiwara
> 	Filename        : draft-ietf-dnsop-terminology-bis-06.txt

One of the issues I would like to discuss for terminology-bis is the
definition of QNAME. I filed this erratum against RFC 2308 :

https://www.rfc-editor.org/errata_search.php?rfc=2308&eid=4983

Five months later, it has not been accepted or rejected. So, it is
time to poke the WG: do you think we should mark the RFC 2308 as
wrong, and keep only the definition of RFC 1034?

---

From: Petr Špaček <[email-masked]>
Date: Thu, 24 Aug 2017 17:48:31 +0200

> wrong, and keep only the definition of RFC 1034?

I vote for keeping RFC 1034 definition and declaring RFC 2308 wrong.

-- 
Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Aug 2017 08:27:34 +1000

RFC 2308 is consistent with RFC 1034.

Go read *all* of RFC 1034.  QNAME is used to refer to *both* the original
*and* updated value after following a CNAME.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: P Vix <[email-masked]>
Date: Thu, 24 Aug 2017 22:40:12 +0000

We might want to invent a new term here like effective qname, but basically I agree with Mark. 2308 was written after bind itself learned the distinction.

On August 24, 2017 3:27:34 PM PDT, Mark Andrews <[email-masked]> wrote:
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Fri, 25 Aug 2017 00:00:13 +0000

Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change QNAME to the canonical name in the CNAME RR, and go back to step 1" is just treating the string "QNAME" as a variable in a loop. One will note that the analogous portion of the *resolver* algorithm (5.3.3) says "change the SNAME to the canonical name in the CNAME RR and go to step 1." So "QNAME" substitutes for a variable name in one version of the algorithm, and "SNAME" substitutes in the other version. There's nothing "magical" about the reference to "QNAME", therefore, and one shouldn't assume this was an attempt to (re)define protocol terminology, _per_se_.

RFC 2308, on the other hand, defines "QNAME" as encompassing both the "pure" and the CNAME-chain sense, in its "Terminology" section, and thus broadens the scope of the term in ways that IMO can lead to ambiguity, if read as applying beyond that particular RFC.

The challenge, however, with saying, that "QNAME" can puristically *only* refer to what was originally requested in the query packet, is that we need to then come up with another term to describe the end of the CNAME-chain, if any, which has been followed. One suggestion was "effective QNAME", but I'd prefer to leave "QNAME" out of the term completely, to avoid confusion. "Terminal name" or "terminating name", perhaps? "End name"? "Resultant name"?

												- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: Thursday, August 24, 2017 6:28 PM
To: Petr Špaček <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

Mark

---

From: Shumon Huque <[email-masked]>
Date: Thu, 24 Aug 2017 22:46:44 -0400

On Thu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) <[email-masked]
> wrote:

> Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change
> QNAME to the canonical name in the CNAME RR, and go back to step 1" is just
> treating the string "QNAME" as a variable in a loop. One will note that the
> analogous portion of the *resolver* algorithm (5.3.3) says "change the
> SNAME to the canonical name in the CNAME RR and go to step 1." So "QNAME"
> substitutes for a variable name in one version of the algorithm, and
> "SNAME" substitutes in the other version. There's nothing "magical" about
> the reference to "QNAME", therefore, and one shouldn't assume this was an
> attempt to (re)define protocol terminology, _per_se_.
>

Yes, I agree with your characterization.

> RFC 2308, on the other hand, defines "QNAME" as encompassing both the
> "pure" and the CNAME-chain sense, in its "Terminology" section, and thus
> broadens the scope of the term in ways that IMO can lead to ambiguity, if
> read as applying beyond that particular RFC.
>

Yes.

> The challenge, however, with saying, that "QNAME" can puristically *only*
> refer to what was originally requested in the query packet, is that we need
> to then come up with another term to describe the end of the CNAME-chain,
> if any, which has been followed. One suggestion was "effective QNAME", but
> I'd prefer to leave "QNAME" out of the term completely, to avoid confusion.
> "Terminal name" or "terminating name", perhaps? "End name"? "Resultant
> name"?
>

A while back I had suggested "Resolved qname" or "Canonicalized qname" ..

Shumon.

---

From: "Peter van Dijk" <[email-masked]>
Date: Mon, 28 Aug 2017 15:51:52 +0200

> *and* updated value after following a CNAME.

+1

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Mon, 28 Aug 2017 22:20:14 +0000

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]".

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.

We can talk about "references" all we want, but the erratum, despite an off-by-one error in RFC citation, is about *definitions*, and the one in RFC 2308 differs from the earlier one from the RFC 1034/1035 matched set.

											- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Peter van Dijk
Sent: Monday, August 28, 2017 9:52 AM
To: [email-masked]
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

+1

Kind regards,

---

From: "Peter van Dijk" <[email-masked]>
Date: Tue, 29 Aug 2017 10:08:51 +0200

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.

> 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.

> We can talk about "references" all we want, but the erratum, despite 
> an off-by-one error in RFC citation, is about *definitions*, and the 
> one in RFC 2308 differs from the earlier one from the RFC 1034/1035 
> matched set.

Then what we need is an erratum for 1034 and/or 1035 to make explicit 
what is implicit in 1034 4.3.2: that the QNAME follows the CNAME chain. 
Once that erratum is submitted and accepted, all is consistent again 
between 1034, 1035, 2308. Then, RFCs like 5155 which rely on the 2308 
definition remain correct in their usage of QNAME.

Kind regards,

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Tue, 29 Aug 2017 22:17:40 +0000

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

> 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.

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Aug 2017 23:08:18 -0400

Hi,

> 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…
[…] 
> 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 R…

Speaking as one of the presumed editors of post-7719 -- one who is,
so-presumed, supposed to sort this problem out -- I hope it's ok to
state _very strongly_ that I appreciate the extensive discussion of
this issue.  I think this is very much one of the kinds of knotty
terminological problems that has created enormous difficulty for
people approaching the DNS for the first time.  Not only are terms
hard to understand; but when you come across them, they seem to be
slippery.

At the same time, and taking off my editor hat for the moment, I am
quite uncomfortable having a terminology document (which is what this
thread is about) make the term not-slippery.  It _is_ slippery in the
reference documents.  I don't think it helps us to try to settle those
disputes.  I think 7719-bis can do two things:

    1.  Document, as clearly as possible, the nature of the ambiguity.
    This thread has helped, but I bet (I haven't checked with my
    co-editors) that a ¶ well-worked-out on the list (not necessarily
    the WG please note) would be welcome.

    2.  Define, as clearly as possible and using new terms, the
    distinctions in question and provide names for them.  These could
    be, of course, names not previously known.

I emphasise again that clarity of definitions is, at least for me, quite important, so ambiguous examples are super valuable.  Thanks!

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Aug 2017 06:32:53 -0700

On 29 Aug 2017, at 20:08, Andrew Sullivan wrote:

> I emphasise again that clarity of definitions is, at least for me, 
> quite important, so ambiguous examples are super valuable.  Thanks!

As another co-editor of 7719-bis, I strongly concur with Andrew. I have 
been flagging all the messages in this thread and waiting for it to 
peter out before suggesting wording. If someone who is invested in this 
thread can propose text for 1 and 2, that would help because then others 
who are invested in the thread can comment and we can get good wording 
before the editors try.

--Paul Hoffman