Paul Hoffman wrote:
> On 26 Sep 2016, at 0:33, Peter van Dijk wrote:
>
> > 2308 does not “redefine” QNAME. It clarifies that the usage in 1034
> > 4.3.2 is the definition we use in RFCs. 1035 4.1(.2) does not conflict
> > with this; the QNAME there is just the initial QNAME.
>
> This seems like a very limited view of RFC 1034. RFC 1034 actually defines
> QNAME in Section 3.7.1:
>
> 3.7.1. Standard queries
>
> A standard query specifies a target domain name (QNAME), query type
> (QTYPE), and query class (QCLASS) and asks for RRs which match.
>
> Further, the usage in Section 4.3.2 does not say that the QNAME is the last
> name in the chain, just that the algorithm itself repeats with a new value
> for QNAME:
>
> 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.
If STD 13 were to be typeset like a technical book, "QNAME" in 1034
§4.3.2 would be styled using the book's typographical convention for a
variable name.
The exact same formulation in §4.3 ("change … to the canonical name in
the CNAME RR") is used again in the resolver algorithm in §5.3:
The following resolver algorithm assumes that all functions have been
converted to a general lookup function, and uses the following data
structures to represent the state of a request in progress in the
resolver:
SNAME the domain name we are searching for.
STYPE the QTYPE of the search request.
SCLASS the QCLASS of the search request.
[…]
5.3.3. Algorithm
The top level algorithm has four steps:
[…]
4. Analyze the response, either:
[…]
c. if the response shows a CNAME and that is not the
answer itself, cache the CNAME, change the SNAME to the
canonical name in the CNAME RR and go to step 1.
[…]
Since "SNAME" doesn't conflict with a term from another part of the
document set, it's clear that SNAME is being used as a variable name. So
the parallel use in §4.3.2 ("change QNAME to the canonical name") must
also be as a variable name, not a terminological (re)definition.
--
Robert Edmonds
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
