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

[Linda Dunbar <[e-mail]>]

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 <[e-mail]>
Sent: Thursday, February 13, 2020 6:23 AM
To: Linda Dunbar <[e-mail]>; Paul Vixie <[e-mail]>; [e-mail]; Paul Ebersman <[e-mail]>
Cc: RTGWG <[e-mail]>
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.