Re: [DNSOP] [Ext] Last Call: <draft-ietf-dnsop-terminology-bis-11.txt> (DNS Terminology) to Best Current Practice

John C Klensin <> Thu, 16 August 2018 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D65C130E7B; Thu, 16 Aug 2018 05:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cqziorWwBZxA; Thu, 16 Aug 2018 05:05:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3845C130DC5; Thu, 16 Aug 2018 05:05:30 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1fqH1q-0008Ny-1x; Thu, 16 Aug 2018 08:05:26 -0400
Date: Thu, 16 Aug 2018 08:05:19 -0400
From: John C Klensin <>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <>
cc: Paul Hoffman <>,,,,
Message-ID: <A6A4D754B512BCB668583D75@PSB>
In-Reply-To: <>
References: <> <7C7531F385095225A8D60CE1@PSB> <> <6314E3B19DA5C00A92191A38@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [DNSOP] [Ext] Last Call: <draft-ietf-dnsop-terminology-bis-11.txt> (DNS Terminology) to Best Current Practice
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Aug 2018 12:05:32 -0000


My personal view is that, if the same (or an extremely similar)
term is in use for the cases you enumerate, especially if most
of those who use it think they are saying something precise, we
are better off listing those cases and making the possible
confusion clear.  In particular, saying something that appears
to point to one particular case and ignoring the others is
likely to cause more problems than it solves.   For this case,
the current definition falls somewhere in between.  Partially, I
think, because it is a little vague it is not nearly as bad as
saying "this is the definitive definition and the term always
applies to this case" but not nearly as good as the sort of
enumeration you suggest.


--On Thursday, August 16, 2018 08:11 +0200 Patrik Fältström
<> wrote:

> On 15 Aug 2018, at 22:01, John C Klensin wrote:
>> In that regard, I find the document's definition of "split
>> DNS" a little bit frustrating, as I have seen (multiple
>> times) a distinction made between names (or a zone) that
>> would clearly be part of the public DNS except that they are
>> hidden from view and names that are part of a different

> Is it the case that various alternatives should be enumerated?
> a. When a domain name is used for access to a service we might
> have:
> a.1. The same DNS response regardless of who sends the query
> (this is the default for DNS)
> a.2. Different responses depending on context (where query is
> sent from etc), but still same service (this is CDN)
> b. When different services are accessed depending on context
> (enterprise setup)
> b.1. A service is available or not depending on context,
> implemented via DNS response or not (version of a.1)
> b.2. Different services are available depending on context,
> implemented via different DNS responses
> c. The special case of (b) based on use of different root zone
> :
> :
> :
>    Patrik