On 4 Apr 2017, at 11:35, Mark Andrews wrote:
In message <20170328143352.ga12...@laperouse.bortzmeyer.org>, Stephane
Bortzmeyer writes:
The new definition of QNAME describes as equivalent two conflicting
definitions, the original one, in RFC 1034, and the one of RFC 2308,
which seems used only by this RFC. IMHO, we should keep only the RFC
1034 definition.
As noted in the current draft, RFC 1034 says:
A standard query specifies a target domain name (QNAME), query type
(QTYPE), and query class (QCLASS) and asks for RRs which match.
To me, the use of appositives for QNAME, QTYPE, and QCLASS gives them
definitions.
RFC 1034 also says:
The query contains a QTYPE, QCLASS,
and QNAME, which describe the types and classes of desired information
and the name of interest.
RFC 1034
If the data at the node is a CNAME, and QTYPE doesn't
match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
the CNAME RR, and go back to step 1.
Note "QNAME" refers the the name *after* CNAME substituion when you
are following the process as described in 4.3.2. Algorithm.
This is indeed the definition of the algorithm, not of the terms. But
RFC 1034 says that the algorithm is not definitive: "The actual
algorithm used by the name server will depend on the local OS and data
structures used to store RRs."
There is no confict between 1034 and 2308. Only a failure to
examine all uses of QNAME in 1034.
We disagree here. RFC 2038 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." That definition is derived from the
optional algorithm.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
