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

Shumon Huque <> Fri, 25 August 2017 02:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28982132A08 for <>; Thu, 24 Aug 2017 19:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ic5Dg1NYurlP for <>; Thu, 24 Aug 2017 19:46:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58F311329F7 for <>; Thu, 24 Aug 2017 19:46:46 -0700 (PDT)
Received: by with SMTP id s199so3905493vke.1 for <>; Thu, 24 Aug 2017 19:46:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hvcqg8LU+WudQGrPBaeJ/42nlkfmZ8f/LjdaCEqkvEY=; b=IgoeHOgjnyoOvoAjpVxgd/HDkB2xuYj6Jj4QcSpOgtmK2njmoJl1WKdnEMGOwSVwsI 1dndn1VDFFOmaJ2FV6uw81zVZhd832DA9A6psXDFeKualqEzFvWKzfEfgZRfHgQ/5Sna s3fDEpyNkk39OCm3bwlFCfJw+qli38qoUbh8QlAjTIn9JVSvf76oXNTUCI5lyVCcMeEp sVjDP7R8gh0kJ8miwts8GMbCv/HCSQb+tqXv2ay0qhmI8biJkKaFw4bjP3BYvsAJp1TU YVtGa+TVxKufXXt3P8qO4aWWyI6Zm2lrPyqS4FZHVHX7drz+QKf6WTlEY6RamjMxs04A l5NA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hvcqg8LU+WudQGrPBaeJ/42nlkfmZ8f/LjdaCEqkvEY=; b=AfkcquCnRkdY81LsyJ1x6v2l4BRyckBQvRKsZTDV47Jc1mybbh5By4wYgwYe89GR5r 5fZyd3kXtoDvScA9ikBQYLq7Zlpxbo5oVgaDW0iwrhSFevsWfdgF4a0FXGHnbZHkby/z Wbga0MpmBw6wT+ks719DOR+KjQHFryWROyjfTCGQQPJlOYCZNRQXb7GUbViOhBWrSdMa ZAEAQO4pfHDWZcNb36Yktl8LNGzBSBGGCy7VwVWx39y383/yI0L3thsgnyZfinw+l/7M jx7+IEWDj4fBLGNVx4SwkRFdK64KcWYTfIb7Qzd4n3Zs/VFfu15hRjj0Qo+qvaTqVb9Q t0Fg==
X-Gm-Message-State: AHYfb5jp8hvbZYGLoOpXnOuFopTap5xNBkgkrrIVrL/o/S54JqLWQflZ 6gUdDK/pxJI8g0rhoQPij/omu+4QDA==
X-Received: by with SMTP id x143mr4571448vke.175.1503629205380; Thu, 24 Aug 2017 19:46:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Aug 2017 19:46:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Shumon Huque <>
Date: Thu, 24 Aug 2017 22:46:44 -0400
Message-ID: <>
To: "Darcy Kevin (FCA)" <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a11438f9aa9251c05578af428"
Archived-At: <>
Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Aug 2017 02:46:48 -0000

On Thu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) <
> wrote:

> 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_.

Yes, I agree with your characterization.

> 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"?

A while back I had suggested "Resolved qname" or "Canonicalized qname" ..