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

Andrew Sullivan <> Wed, 30 August 2017 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D58E13208E for <>; Tue, 29 Aug 2017 20:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=fSoWVsdf; dkim=pass (1024-bit key) header.b=HjWsQ7ug
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dIlrNagIwZtn for <>; Tue, 29 Aug 2017 20:08:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3034612422F for <>; Tue, 29 Aug 2017 20:08:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D03EBEA1E for <>; Wed, 30 Aug 2017 03:08:21 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1504062501; bh=/z045W5EjpDO7oxAOMBTd3jNraAzm3I0Cv1yenihvGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fSoWVsdfrN3qZq1u5BAKrvWwwfJdvEMhTUoHA4jmsNBMtLeUcJLc47VbdUgkUvh5j yvqSB0Wk8Psu1zI8JxLaIKGcd/Ho6Es9O1IBHKHydNhcge+WCJJi8IBgh1ItJ+KHEM wcXlyvTjN6mVka70N4Zw+TetrDvPZXbZNded0sks=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iSr55G3TdWxy for <>; Wed, 30 Aug 2017 03:08:19 +0000 (UTC)
Date: Tue, 29 Aug 2017 23:08:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1504062499; bh=/z045W5EjpDO7oxAOMBTd3jNraAzm3I0Cv1yenihvGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HjWsQ7ugeSEHZajWw1eHCAosQi34+4LCRgVBEiUPakbWH8FMn0AWu+eKQVt8WosVP yVArIMS7G8rljnbALiF8RSqrYqfZvsSvmWuv6aet3y+5fuIilXus8hqbhemGiW+4It BzdbvXVJYtEMVSOGWSg5nQJ3EOit4RmL11Ei2r5M=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
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: Wed, 30 Aug 2017 03:08:53 -0000


On Tue, Aug 29, 2017 at 10:17:40PM +0000, Darcy Kevin (FCA) wrote:
> So, as the sole definition in the foundational RFCs, perhaps that's the *only* context in which the term "QNAME" should have meaning. Which is why I suggested coming up with a different term to be used in other contexts, e.g. the resolver algorithm, the auth-server algorithm, negative caching and so forth. That other term could encompass more than just the name which was originally presented by the client as the QNAME; it could include end-of-CNAME-chain.
> It's *used* that way, but there is no *definition* in RFC 1034. That's my main point. We have only 2 competing definitions of "QNAME" -- RFC 1035 (with a limited context, as you point out) versus RFC 2308. Thus, we have a choice: to either reconcile the competing definitions via errata (where one "wins" and the other "loses"), or we can bifurcate into different terms. Personally, I prefer the 2-state solution, but it's not a strong preference.

Speaking as one of the presumed editors of post-7719 -- one who is,
so-presumed, supposed to sort this problem out -- I hope it's ok to
state _very strongly_ that I appreciate the extensive discussion of
this issue.  I think this is very much one of the kinds of knotty
terminological problems that has created enormous difficulty for
people approaching the DNS for the first time.  Not only are terms
hard to understand; but when you come across them, they seem to be

At the same time, and taking off my editor hat for the moment, I am
quite uncomfortable having a terminology document (which is what this
thread is about) make the term not-slippery.  It _is_ slippery in the
reference documents.  I don't think it helps us to try to settle those
disputes.  I think 7719-bis can do two things:

    1.  Document, as clearly as possible, the nature of the ambiguity.
    This thread has helped, but I bet (I haven't checked with my
    co-editors) that a ¶ well-worked-out on the list (not necessarily
    the WG please note) would be welcome.

    2.  Define, as clearly as possible and using new terms, the
    distinctions in question and provide names for them.  These could
    be, of course, names not previously known.

I emphasise again that clarity of definitions is, at least for me, quite important, so ambiguous examples are super valuable.  Thanks!


Andrew Sullivan