Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt

"Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com> Fri, 25 August 2017 00:00 UTC

Return-Path: <kevin.darcy@fcagroup.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AA813265E for <dnsop@ietfa.amsl.com>; Thu, 24 Aug 2017 17:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE4TVT2fwO6u for <dnsop@ietfa.amsl.com>; Thu, 24 Aug 2017 17:00:19 -0700 (PDT)
Received: from odbmap07.extra.chrysler.com (odbmap07.out.extra.chrysler.com [129.9.107.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4B71323B9 for <dnsop@ietf.org>; Thu, 24 Aug 2017 17:00:19 -0700 (PDT)
Received: from shbmap09.shdc.chrysler.com (Unknown_Domain [151.171.73.109]) by (Symantec Messaging Gateway) with SMTP id AB.FC.09157.8886F995; Thu, 24 Aug 2017 20:00:11 -0400 (EDT)
X-AuditID: 81096b23-a9bff700000023c5-0d-599f6888f661
Received: from mxph1chrw.fgremc.it (Unknown_Domain [151.171.20.45]) by (Symantec Messaging Gateway) with SMTP id B5.FB.04970.CB66F995; Thu, 24 Aug 2017 19:52:28 -0400 (EDT)
Received: from mxph4chrw.fgremc.it (151.171.20.48) by mxph1chrw.fgremc.it (151.171.20.45) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 24 Aug 2017 20:00:14 -0400
Received: from mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701]) by mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1236.000; Thu, 24 Aug 2017 20:00:13 -0400
From: "Darcy Kevin (FCA)" <kevin.darcy@fcagroup.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
Thread-Index: AQHTHORnHuETSd4O0EiRIffADErT/qKT6iSAgAAsejiAAAX28A==
Date: Fri, 25 Aug 2017 00:00:13 +0000
Message-ID: <30735661ffd84430b8d9ab8ff2be0f06@mxph4chrw.fgremc.it>
References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <f3e75bd0-b398-1b6a-db3f-ecafd4f0c610@nic.cz> <20170824222734.C786E831AA5D@rock.dv.isc.org>
In-Reply-To: <20170824222734.C786E831AA5D@rock.dv.isc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [151.171.20.216]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyfbVnrm53xvxIg1nLJSzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIsvHzIV9AtWfLj2jaWB8TlvFyMnh4SAicSNzr2MXYxcHEIC 2xkljv1ezwKT2HziDDuILSSwnlGi+5U8RNE6Rollb76zQjg7GSXmHrgPVsUG1LHwyl1mEFtE QFXiwr/vTCC2sECKxL6fG9kh4qkSkw7NYYGwnSS6/p1hA7FZgOpPnnkCVs8LFF/7fwkzxOaz jBLzpguC2JwCVhK7JuwD62UUEJP4fmoNWD2zgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCNtA YuvSfVCfKUm82zMbqldP4tmpWSwQtrbEsoWvmSFuEJQ4OfMJC8iTEgK32CVWL1/JPIFRchaS fbOQ9M9C0j8LSf8CRpZVjNL5KUm5iQUG5nqpFSVFiXrJGUWVxTmpRXrJ+bmbGIFR2MiZrbyD ccpcy0OMAhyMSjy8hanzI4VYE8uKK3MPMUpwMCuJ8KaaAoV4UxIrq1KL8uOLSnNSiw8xSnOw KInzdpfNjRQSSE8sSc1OTS1ILYLJMnFwSjUwziwL/if9RMTs/8TwXKFf3x5ovG3sWvxDU9Fh 1SXNggkSPJvPm17MedmW2LYpq/n5uqb5YVWB53/H6v/6WOTaGvK2myMvrkNstcjimI+ZW6Rd nXdNP/Mv6tNtzv/LkjqlTeMOLeC8vFu/NN+MawlTxp5GN+kPMgHf5a4pzZ6zmWtqcK3p3qSZ SizFGYmGWsxFxYkAMPwkob4CAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUyfbWIru6etPmRBi8m21jcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRdfPmQq6Bes+HDtG0sD43PeLkZODgkBE4nNJ86wg9hCAusZ JbpfyXcxcgHZ6xgllr35zgrh7GSUmHvgPlgVG1DHwit3mUFsEQFViQv/vjOB2MICKRL7fm5k h4inSkw6NIcFwnaS6Pp3hg3EZgGqP3nmCVg9L1B87f8lzBCbzzJKzJsuCGJzClhJ7JqwD6yX UUBM4vupNWD1zALiEreezGeCuFpAYsme88wQtqjEy8f/WCFsA4mtSyF6JQSUJN7tmQ3Vqyfx 7NQsFghbW2LZwtfMEDcISpyc+YRlAqPYLCQrZiFpmYWkZRaSlgWMLKsYpYozknITCwws9Yoz UpL1kjOKKotzUov0kvNzNzGC48YzZwfj/4WWhxgFOBiVeHh/J82PFGJNLCuuzD3EKMnBpCTK uzwaKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN9UUKMebklhZlVqUD5OS5mBREudVKXAIFBJI TyxJzU5NLUgtgsnKcHAoSfCuCwRqFCxKTU+tSMvMKUFIM3FwggznARouHwcyvLggMbc4Mx0i f4pRUkqcdybIRQIgiYzSPLjeV4ziQC8I8x4BeYEHmALhul4BDWQCGjjpxByQgSWJCCmpBkaV 2CzFd7qM75O+c0goRe7ZOZH9lpfUK+W6Fd0Pj9dM23B/6tdX/a+/V1Y8zHPZtjJI7iDnG46T PHf+BeWlWit/vbZg/sf7RrcMTi96s23PieBA9vX/P3i1NvasulOvwPuoQKvW/G725s0Nu9h2 uDQ5+rx1cTgWpcQh5ZV19F3rpJ08MeqRsw4rsRRnJBpqMRcVJwIABLz+xj4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/chN4kdc5BeOVBonRoN5-k0xpTfo>
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Aug 2017 00:00:21 -0000

Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change QNAME to the canonical name in the CNAME RR, and go back to step 1" is just treating the string "QNAME" as a variable in a loop. One will note that the analogous portion of the *resolver* algorithm (5.3.3) says "change the SNAME to the canonical name in the CNAME RR and go to step 1." So "QNAME" substitutes for a variable name in one version of the algorithm, and "SNAME" substitutes in the other version. There's nothing "magical" about the reference to "QNAME", therefore, and one shouldn't assume this was an attempt to (re)define protocol terminology, _per_se_.

RFC 2308, on the other hand, defines "QNAME" as encompassing both the "pure" and the CNAME-chain sense, in its "Terminology" section, and thus broadens the scope of the term in ways that IMO can lead to ambiguity, if read as applying beyond that particular RFC.

The challenge, however, with saying, that "QNAME" can puristically *only* refer to what was originally requested in the query packet, is that we need to then come up with another term to describe the end of the CNAME-chain, if any, which has been followed. One suggestion was "effective QNAME", but I'd prefer to leave "QNAME" out of the term completely, to avoid confusion. "Terminal name" or "terminating name", perhaps? "End name"? "Resultant name"?

												- Kevin

-----Original Message-----
From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Mark Andrews
Sent: Thursday, August 24, 2017 6:28 PM
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt


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.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop