Please send your comments to the revised draft-ietf-rtgwg-net2cloud-problem-statement based on comments from DNSop experts

[Linda Dunbar <[e-mail]>]

Alia

This revised version covers the problems associated with Identity Management, API abstraction, DNS/NAT  service by different Cloud Operators for Enterprise to utilize Cloud Resources which you had suggested in IETF106.
At NANOG 78, we had extensive discussion with DNS experts on the DNS related problems for Hybrid Cloud and have got very good constructive comments on the mailing list from DNSOP experts.
Here is the revised draft that incorporate the discussion.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/


Can you please review this revision?
Can you suggest other experts or IETF groups to review the Identity Management, API abstraction and NAT which are added to the document?
We would like to move this document forward and draw closure. The document has been in RTGwg for over a year.

Thank you very much.

Linda

From: Linda Dunbar
Sent: Friday, February 14, 2020 3:04 PM
To: Scott Morizot <[e-mail]>
Cc: Morizot Timothy S <[e-mail]>; Paul Vixie <[e-mail]>; [e-mail]; Paul Ebersman <[e-mail]>; 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

Scott,

Thank you. It makes sense now.
i.e.  some zones resolve differently based on the origins of the query, and some zones resolve the same globally for all queries from any source.

Linda

From: Scott Morizot <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 14, 2020 2:11 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Morizot Timothy S <[e-mail]<mailto:[e-mail]>>; Paul Vixie <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Paul Ebersman <[e-mail]<mailto:[e-mail]>>; RTGWG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement

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

_______________________________________________
DNSOP mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dnsop<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C2f789148051e4b79942d08d7b18a0b58%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637173078791030675&sdata=E3CpblukdDt43XnDlq34RgUlYyAPc1GW4uxqT8o1KSo%3D&reserved=0>