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

Scott Morizot <tmorizot@gmail.com> Fri, 14 February 2020 20:11 UTC

Return-Path: <tmorizot@gmail.com>
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 3C28612081D; Fri, 14 Feb 2020 12:11:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ATViY-J0K_Dx; Fri, 14 Feb 2020 12:11:15 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA69412022C; Fri, 14 Feb 2020 12:11:14 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id m25so11862818ioo.8; Fri, 14 Feb 2020 12:11:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lZMM74gGPSj6in5U6OT8N9eLmLbmB6w6nl7RQw6wqMg=; b=iX/vRyV3I/1ALp5hvrAPcpx4JptvzBJyMf0jgFLL0uu8Y0Eu7s0ksnYqwZSfiHHZn/ yZq9/zBzoyN/JtCKmWBuDlfYTmHEz6hdSvVV+nKZ/EbRySD4OQ06643d0/vdX4l+n1bD a7NFIMlO8X9jx82/+iWbvC9uh5qIsdUHhasnzqNgRHHQdrMoSvf27iF7396BaQxOlZPX MXYgxjhpnF+0Zu3IVXvV9khHD6xF71Wxy7D7JFU/84T89OA1g+aJRsfUD9MAtwD9tAzU o12YDir/IjD8UQSOSylqbnV2MO3Xn9gakgFaeZZcXmR9eKSfHGg4asIW7iOaRMh7MuGl sNcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lZMM74gGPSj6in5U6OT8N9eLmLbmB6w6nl7RQw6wqMg=; b=ICmh/TPWYrx7RAZ5nf8djoXY3LPEMD5g6WcP/8awybPkaodWsE1xvbVWccio7Jbchl f/uzlflrFyw8FvpRJMOnnmCmRYct5bHjxXQL7Gm4Rzw3ABSwTE6VEE/1uHkx0oqh9c6J SOTtC2GfVO80o1jocF+h2R+x56OM0H25XOGwrejjKF/6YWu4luTteYQSFUkO9s1r09zp Gu8UJE2caaof3ilLyujhit6af7c4hm2ZL1NaOF+CWS/qZYcV4bRBjLl7S7k2+XvrnCPi V7E6ztOBkctsHSJeSZ/t7kAGiul1gzCdONknVmXXkHabq5v6R7adkPunZFFYhdJBYYVp t5Tg==
X-Gm-Message-State: APjAAAUFbrfXl4nBRVCB36kkNtaUTbEdp4Lk/O/onM140Syg0zZOvC1l VNYfa3rRldZsW8+iy64UB/i/cnNaWMSACvN/8g==
X-Google-Smtp-Source: APXvYqyDaDIUadTJfCwiDx8SHkAPhoPihVlBKdIcB2iNPJO0CDxkEpI7TmIF6mFzE9GJAo6tH3eFf9MYX0yxQhxUGzU=
X-Received: by 2002:a05:6602:21c2:: with SMTP id c2mr3448647ioc.278.1581711074088; Fri, 14 Feb 2020 12:11:14 -0800 (PST)
MIME-Version: 1.0
References: <BN6PR1301MB2083B6F88FDE9A0A4EA2384985180@BN6PR1301MB2083.namprd13.prod.outlook.com> <BN6PR1301MB20839C511BDF230D79658BF485180@BN6PR1301MB2083.namprd13.prod.outlook.com> <1698737.Wqn7rEUb4T@linux-9daj> <31b15893bd0b4b2a871f4779331c99d6@irs.gov> <MWHPR1301MB20963F4BA7C3B157373174FD851B0@MWHPR1301MB2096.namprd13.prod.outlook.com> <8d6030c122c94e98a63fbec8a7f32e3b@irs.gov> <MWHPR1301MB2096DE38BFE29115F63A186F85150@MWHPR1301MB2096.namprd13.prod.outlook.com>
In-Reply-To: <MWHPR1301MB2096DE38BFE29115F63A186F85150@MWHPR1301MB2096.namprd13.prod.outlook.com>
From: Scott Morizot <tmorizot@gmail.com>
Date: Fri, 14 Feb 2020 14:11:02 -0600
Message-ID: <CAFy81rkK+p-Lz8yf_UWxQTKrmdoriGPA3VH1t75eaMXN8LvoJQ@mail.gmail.com>
Subject: Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
To: Linda Dunbar <linda.dunbar@futurewei.com>
Cc: Morizot Timothy S <timothy.s.morizot@irs.gov>, Paul Vixie <paul@redbarn.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Paul Ebersman <ebersman-ietf@dragon.net>, RTGWG <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b55b9c059e8ece42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/lPfF4Q38Sa67ImbLiZtRVuglZ-Y>
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: Fri, 14 Feb 2020 20:11:19 -0000

Ah. Should have used the Oxford comma for clarity. I'm normally one of the
people who always uses it so that was probably an accidental omission.
There should be a comma before that last 'and'. I was describing the three
possible states for any query and response. We have all three scenarios in
production so it's critical to understand which one covers a given name
when troubleshooting issues. In each scenario, though, the name itself is
unique and in a domain tree over which we have global administrative
control.

On Fri, Feb 14, 2020, 10:22 Linda Dunbar <linda.dunbar@futurewei.com> wrote:

> Scott,
>
>
>
> Thank you very much for the suggested changes.
>
> For the following sentence, do you you that different paths/zones can
> resolve differently based on the origin of the query and zones?
>
> Then what do you mean by adding the subphrase that “that resolve the same
> globally for all queries from any source”?
>
>
>
> 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.*
>
>
>
> Thank you,
>
>
>
> Linda
>
> *From:* Morizot Timothy S <Timothy.S.Morizot@irs.gov>
> *Sent:* Thursday, February 13, 2020 6:23 AM
> *To:* Linda Dunbar <linda.dunbar@futurewei.com>; Paul Vixie <
> paul@redbarn.org>; dnsop@ietf.org; Paul Ebersman <ebersman-ietf@dragon.net
> >
> *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
>
>
>
> Linda Dunbar wrote:
>
> >Thank you very much for suggesting using the Globally unique domain name
> and having subdomains not resolvable outside the organization.
>
> >I took some of your wording into the section. Please let us know if the
> description can be improved.
>
>
>
> Thanks. I think that covers a reasonable approach to avoid collisions and
> ensure resolution and validation occur as desired by the organization with
> administrative control over the domains used.
>
>
>
> I realized I accidentally omitted a ‘when’ that makes the last sentence
> scan properly. In the process, I noticed what looked like a couple of other
> minor edits that could improve readability.. I did not see any substantive
> issues with the revised text but did include those minor proposed edits
> below.
>
>
>
> Scott
>
>
>
>
>
> 3.4. DNS for Cloud Resources
>
> DNS name resolution is essential for on-premises and cloud-based
> resources. For customers with hybrid workloads, which include on-premises
> and cloud-based resources, extra steps are necessary to configure DNS to
> work seamlessly across both environments.
>
> Cloud operators have their own DNS to resolve resources within their Cloud
> DCs and to well-known public domains. Cloud’s DNS can be configured to
> forward queries to customer managed authoritative DNS servers hosted
> on-premises, and to respond to DNS queries forwarded by on-premises DNS
> servers.
>
> For enterprises utilizing Cloud services by different cloud operators, it
> is necessary to establish policies and rules on how/where to forward DNS
> queries. When applications in one Cloud need to communicate with
> applications hosted in another Cloud, there could be DNS queries from one
> Cloud DC being forwarded to the enterprise’s on premise DNS, which in turn
> can be forwarded to the DNS service in another Cloud. Needless to say,
> configuration can be complex depending on the application communication
> patterns.
>
> 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 when subdomains and the ability to delegate administrative
> boundaries are considered.
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>