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]".
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.
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.
- Kevin
-----Original Message-----
From: DNSOP [mailto:[email protected]] On Behalf Of Peter van Dijk
Sent: Monday, August 28, 2017 9:52 AM
To: [email protected]
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action:
draft-ietf-dnsop-terminology-bis-06.txt
On 25 Aug 2017, at 0:27, Mark Andrews wrote:
> RFC 2308 is consistent with RFC 1034.
>
> Go read *all* of RFC 1034. QNAME is used to refer to *both* the original
> *and* updated value after following a CNAME.
+1
Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
