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

"Patrik Fältström " <paf@frobbit.se> Thu, 16 August 2018 06:12 UTC

Return-Path: <paf@frobbit.se>
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 75ADD130EE4; Wed, 15 Aug 2018 23:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.622
X-Spam-Level:
X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 TqRzKjVyZRzb; Wed, 15 Aug 2018 23:12:13 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A57F130E6F; Wed, 15 Aug 2018 23:12:12 -0700 (PDT)
Received: from [192.165.72.241] (unknown [192.165.72.241]) by mail.frobbit.se (Postfix) with ESMTPSA id 1DF4121F37; Thu, 16 Aug 2018 08:12:10 +0200 (CEST)
From: Patrik Fältström <paf@frobbit.se>
To: John C Klensin <john-ietf@jck.com>
Cc: Paul Hoffman <paul.hoffman@icann.org>, dnsop@ietf.org, dnsop-chairs@ietf.org, ietf@ietf.org, draft-ietf-dnsop-terminology-bis@ietf.org
Date: Thu, 16 Aug 2018 08:11:51 +0200
X-Mailer: MailMate (2.0BETAr6116)
Message-ID: <127DA514-53CC-4189-9B27-D2EA8554FEA9@frobbit.se>
In-Reply-To: <6314E3B19DA5C00A92191A38@PSB>
References: <153298445658.8167.4045103372772856058.idtracker@ietfa.amsl.com> <7C7531F385095225A8D60CE1@PSB> <0756F0C0-6BB9-4917-ACB1-52920AB1126D@icann.org> <6314E3B19DA5C00A92191A38@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_17F875B8-A39E-4979-95C0-14268DAA4292_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jsoMfcZgjXJ5Y27jvcQPeDabSsE>
Subject: Re: [DNSOP] [Ext] Last Call: <draft-ietf-dnsop-terminology-bis-11.txt> (DNS Terminology) to Best Current Practice
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 16 Aug 2018 06:12:16 -0000

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 hierarchical structure based on a different root.   That is a different case from names (even fully-qualified ones) that different user can resolve but for which they will get different results.  It may also be different from practices in CDNs to return different answers depending on the presumed network location from which the question is being asked, practices that presumably fall into your "view" category.
> I can't make a case for holding up the document to try to sort that out better, but it perhaps should be flagged as an
> opportunity for future work.

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