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 protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
