Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement

Paul Vixie <paul@redbarn.org> Wed, 12 February 2020 22:55 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A56A120020; Wed, 12 Feb 2020 14:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Ad2uUc6DYH_4; Wed, 12 Feb 2020 14:55:30 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3D8120013; Wed, 12 Feb 2020 14:55:30 -0800 (PST)
Received: from linux-9daj.localnet (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 01E7EB0750; Wed, 12 Feb 2020 22:55:27 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>, Paul Ebersman <ebersman-ietf@dragon.net>, Linda Dunbar <linda.dunbar@futurewei.com>
Cc: RTGWG <rtgwg@ietf.org>
Subject: Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Date: Wed, 12 Feb 2020 22:55:26 +0000
Message-ID: <3037475.AyK38qQ3aQ@linux-9daj>
Organization: none
In-Reply-To: <MWHPR1301MB2096353670EF6BE8F2629F2D851B0@MWHPR1301MB2096.namprd13.prod.outlook.com>
References: <BN6PR1301MB2083B6F88FDE9A0A4EA2384985180@BN6PR1301MB2083.namprd13.prod.outlook.com> <1698737.Wqn7rEUb4T@linux-9daj> <MWHPR1301MB2096353670EF6BE8F2629F2D851B0@MWHPR1301MB2096.namprd13.prod.outlook.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/gOoe1zKZEbzFUil_ILKEXLQ0e1g>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2020 22:55:32 -0000

On Wednesday, 12 February 2020 22:43:07 UTC Linda Dunbar wrote:
> Paul,
> 
> ...
> 
> This document is meant to describe potential problems of utilizing Cloud
> Resources. It is a good idea to document the potential collisions and
> conflicts and recommend Globally unique names. How about adding the
> following sentences to the section?
> 
> ------
>       However, even with carefully managed policies and configurations,
> collisions can still occur. If you use an internal name like .cloud and
> then want your services to be available via or within some other cloud
> provider which also uses .cloud, then it can't work. Therefore, it is
> better to use the global domain name even when an organization does not
> make all its namespace globally resolvable. An organization's globally
> unique DNS can include subdomains that cannot be resolved at all outside
> certain restricted paths, zones that resolve differently based on the
> origin of the query and zones that resolve the same globally for all
> queries from any source. Globally unique names do not equate to globally
> resolvable names or even global names that resolve the same way from every
> perspective. Globally unique names do prevent any possibility of collision
> at the present or in the future and they make DNSSEC trust manageable. It's
> not as if there is or even could be some sort of shortage in available
> names that can be used, especially subdomains and the ability to delegate
> administrative boundaries are considered.

i think that language is both accurate and adequate. good luck with your 
document.

-- 
Paul