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

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Sep 2017 23:45:33 -0400

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
[email-masked]

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 21 Sep 2017 14:20:15 +0200

Hello Andrew,

thank you for this, I like it a lot. One nit below.

>       explicit in the resolution algorithm outlined in Section 4.3.2,

It’s unclear that 4.3.2 is in 1034, as 1034 is in parens just before.

> I'm certainly not wedded to these two names.

They certainly are adequate, and I do not have better suggestions.

Wonderful work!

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Sep 2017 09:12:44 -0400

> I'm certainly not wedded to these two names.

These two terms sound reasonable to me.

-- 
Shumon Huque

---

From: Jim Reid <[email-masked]>
Date: Thu, 21 Sep 2017 14:17:11 +0100

> On 21 Sep 2017, at 14:12, Shumon Huque <[email-masked]> wrote:
> 
> On Wed, Sep 20, 2017 at 11:45 PM, Andrew Sullivan <[email-masked]> wrote:
> 

Maybe the definition of QNAME (effective) needs to be extended to include the result of NAPTR record processing? Says he running away quickly...

---

From: Tony Finch <[email-masked]>
Date: Thu, 21 Sep 2017 14:31:10 +0100

Jim Reid <[email-masked]> wrote:
>
> Maybe the definition of QNAME (effective) needs to be extended to
> include the result of NAPTR record processing? Says he running away
> quickly...

As I understand it, NAPTR processing happens in applications outside the
DNS so the result is a QNAME (original) from the DNS point of view.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Southeasterly 5 or 6. Moderate. Showers. Good.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 21 Sep 2017 16:01:15 +0000

> thank you for this, I like it a lot. One nit below.

Me too, with another nit...

> >       second QNAME that is in the data field of the last CNAME.  The

Why only the "last CNAME?" If a chain contains more than one CNAME, the
answer includes intermediate names as well:

;; ANSWER SECTION:
www.paypal.com.         5       IN      CNAME   geo.paypal.com.akadns.net.
geo.paypal.com.akadns.net. 5    IN      CNAME   wlb.paypal.com.akadns.net.
wlb.paypal.com.akadns.net. 5    IN      CNAME   www.paypal.com.edgekey.net.
www.paypal.com.edgekey.NET. 5   IN      CNAME   e3694.a.akamaiedge.net.
e3694.a.akamaiedge.net. 5       IN      A       104.91.181.63

> >          name actually queried or else the last name in a CNAME chain as

This does match the use of the term in RFC 2308, but in other contexts,
I think it would be better to expand it to include intermediate names:
"A name actually resolved, which is either the name originally queried,
or a name received in a CNAME chain response." 

RFC 2308 is interested in caching of answers after recursion is done,
but if one were discussing the recursion process itself, this would be a
natural term to use for itermediate names.  ("If the response is a CNAME,
update the effective QNAME to the CNAME target and go back to step 2...")

If it's necessary to have a specific term that only refers to the *last*
name, perhaps "QNAME (final)" would be a better choice for that.

Incidentally "CNAME chain as defined in [RFC2308]" is ambiguous. RFC
2308 has a definition of QNAME that includes the last CNAME in a chain,
but it does not define the term "CNAME chain".

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 21 Sep 2017 19:26:37 +0200

Hello,

> e3694.a.akamaiedge.net. 5       IN      A       104.91.181.63

That’s a very good point. If any of these CNAMEs are synthesised from 
wildcards, and DNSSEC is in play, then the use of QNAME in RFC5155 (and 
presumably also the NSEC equivalent) demands that each step of this 
chain is the QNAME at some point.

> name, perhaps "QNAME (final)" would be a better choice for that.

+1 - with the caveat that the definition needs to decide if it applies 
when the chain does not end (a loop, or a failure). Is that ‘final’? 
‘effective’?’ ‘intermediate’? Perhaps the right division is 
original+intermediate+final, dropping effective in favour of the 
intermediate+final division.

Kind regards,