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,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
