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 Sent: Friday, February 14, 2020 2:11 PM To: Linda Dunbar Cc: Morizot Timothy S ; Paul Vixie ; dnsop@ietf.org; Paul Ebersman ; RTGWG 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 mailto:linda.dun...@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 mailto:timothy.s.mori...@irs.gov>> Sent: Thursday, February 13, 2020 6:23 AM To: Linda Dunbar mailto:linda.dun...@futurewei.com>>; Paul Vixie mailto:p...@redbarn.org>>; dnsop@ietf.org<mailto:dnsop@ietf.org>; Paul Ebersman mailto:ebersman-i...@dragon.net>> Cc: RTGWG mailto:rt...@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 coll
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 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 > *Sent:* Thursday, February 13, 2020 6:23 AM > *To:* Linda Dunbar ; Paul Vixie < > p...@redbarn.org>; dnsop@ietf.org; Paul Ebersman > > *Cc:* RTGWG > *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 > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
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 Sent: Thursday, February 13, 2020 6:23 AM To: Linda Dunbar ; Paul Vixie ; dnsop@ietf.org; Paul Ebersman Cc: RTGWG 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
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
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Scott, 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. 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 to. When applications in one Cloud need to communication 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 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 subdomains and the ability to delegate administrative boundaries are considered. Linda -Original Message- From: Morizot Timothy S Sent: Wednesday, February 12, 2020 6:35 AM To: Paul Vixie ; dnsop@ietf.org; Paul Ebersman Cc: Linda Dunbar Subject: RE: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement Paul Vixie wrote: >if the names are global then they will be unique and DNS itself will >handle the decision of how to route questions to the right authority servers. >... >first i hope you can explain why the simpler and existing viral DNS >paradigm (all names are global and unique) is unacceptable for your purpose. I wanted to highlight the central point Paul Vixie made and note that it applies 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. (Both of those are significant concerns for my organization.) 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 would also like to understand why global and unique names are unacceptable. Thanks, Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Paul, Thank you very much for pointing out the potential collision and conflicts when globally unique names are not used for cloud resources. I am copying to rt...@ietf.org<mailto:rt...@ietf.org> so that the WG is aware of those issues. By the way, your email to rt...@ietf.org<mailto:rt...@ietf.org> will be posted after the RTGwg manually permit the post. So you don't need to remove the email in your reply. As for why not use globally unique names: Most Cloud resources are internal to the Cloud DC, therefore, they often use private addresses and private names. 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. Thank you very much. Linda Dunbar -Original Message- From: Paul Vixie Sent: Tuesday, February 11, 2020 9:01 PM To: dnsop@ietf.org; Paul Ebersman Cc: Linda Dunbar Subject: Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement On Tuesday, 11 February 2020 22:21:05 UTC Linda Dunbar wrote: > ... > > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-net2cloud-problem-statement% > 2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cea9257cce73245145 > 05a08d7af67db4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637170732 > 927513090&sdata=xvnMh3OYhHfS1G7%2BEU3ERvK6OmHAsoBvsel6YzZl81c%3D&a > mp;reserved=0 > > During IETF 106, we received comments that the document should cover > the problems associated with DNS service by different Cloud Operators > for Enterprise to utilize Cloud Resources even though DNS is not > within the scope of IETF routing area. We greatly appreciate DNS > experts to provide comments to our description. you've addressed this e-mail to two mailing lists (dnsop@ and rtgwg@) which you are a member of, and both will accept and publish your e-mail. however, some of us here are members of only one of those mailing lists (me, dnsop@), and won't be able to participate in whatever threads may occur on the other mailing list (me, rtgwg@). so, i am removing rtgwg@ from my reply here.. > 3.4DNS 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. ... you may not realize it, but that is an astonishing statement. i'll explain below. > ... 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. ... while this is an obvious approach for each and every cloud service operator, it depends on lock-in, is not multi-cloud ready, and cannot be made so within the DNS paradigm or using any of the common layers added to that paradigm. DNS is currently viral, if you can look up anything at all global, then you can look up everything global. cutouts for non-global names are quite common especially when accompanied by NAT. however, collisions cannot be managed this way. you can have some names (like .cloud or .corp or .internal) visible within your network as long as they aren't also used globally, because there is no way to discriminate which collision-name is wanted, other than by client-
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
tmorizot> I would also like to understand why global and unique names tmorizot> are unacceptable. Why do folks insist on NAT and RFC 1918? or ULA v6? There is a common feeling that it's another layer of security. I personally am not a fan of it but I think this is probably the most critical thing to have in the draft/RFC, i.e. pointing out that using globally unique names is way cleaner and outlining the issues not doing that will force you to deal with. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Paul Vixie wrote: >if the names are global then they will be unique and DNS itself will handle >the decision of how to route questions to the right authority servers. >... >first i hope you can explain why the simpler and existing viral DNS paradigm >(all names are global and unique) is unacceptable for your purpose. I wanted to highlight the central point Paul Vixie made and note that it applies 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. (Both of those are significant concerns for my organization.) 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 would also like to understand why global and unique names are unacceptable. Thanks, Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
On Tuesday, 11 February 2020 22:21:05 UTC Linda Dunbar wrote: > ... > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ > > During IETF 106, we received comments that the document should cover the > problems associated with DNS service by different Cloud Operators for > Enterprise to utilize Cloud Resources even though DNS is not within the > scope of IETF routing area. We greatly appreciate DNS experts to provide > comments to our description. you've addressed this e-mail to two mailing lists (dnsop@ and rtgwg@) which you are a member of, and both will accept and publish your e-mail. however, some of us here are members of only one of those mailing lists (me, dnsop@), and won't be able to participate in whatever threads may occur on the other mailing list (me, rtgwg@). so, i am removing rtgwg@ from my reply here. > 3.4DNS 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. ... you may not realize it, but that is an astonishing statement. i'll explain below. > ... 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. ... while this is an obvious approach for each and every cloud service operator, it depends on lock-in, is not multi-cloud ready, and cannot be made so within the DNS paradigm or using any of the common layers added to that paradigm. DNS is currently viral, if you can look up anything at all global, then you can look up everything global. cutouts for non-global names are quite common especially when accompanied by NAT. however, collisions cannot be managed this way. you can have some names (like .cloud or .corp or .internal) visible within your network as long as they aren't also used globally, because there is no way to discriminate which collision-name is wanted, other than by client-ip address and even that is nonstandard, relying on DNS vendor extensions. similarly, 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 there can be no discriminator, and so it can't work. this is why most names are global -- there can be no collisions that way. even with large NAT buildouts, it's become common to use the global domain name both internally and externally, and to simply provide different views of that global domain name internally vs. externally. this was explored 25 years ago: http://family.redbarn.org/~vixie/proxynet.pdf can you explain why the simple answer (use unique global names for each cloud resource) isn't reachable by your proposal? > ... For enterprises utilizing Cloud > services by different cloud operators, it is necessary to establish > policies and rules on how/where to forward DNS queries to. ... if the names are local, and never collide, this has been possible in one vendor's DNS implementation for about 20 years, and is variously possible in others. however, this became much more difficult in the DNSSEC era. if the names are local and may collide, no coherent set of policies or rules about how/where to forward DNS queries will be possible. if the names are global then they will be unique and DNS itself will handle the decision of how to route questions to the right authority servers. > ... When > applications in one Cloud need to communication 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 be forwarded to the DNS > service in another Cloud. Needless to say, configuration can be complex > depending on the application communication patterns. it is that complexity that prohibits scale. are you suggesting that the DNS paradigm be expanded to include automated context-dependent naming? i imagine it would look something like BGP4, but for names rather than addresses. but first i hope you can explain why the simpler and existing viral DNS paradigm (all names are global and unique) is unacceptable for your purpose. thanks for bringing your question here, and thanks to otherpaul and suz for what appears to have been vital outreach. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Many thanks to Paul Ebersman and Suzanne Woolf discussion during NANOG about the deep intricate issues around DNS and learned that DNSOP is the right group to solicit feedback about DNS issues for utilizing hybrid Clouds. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ describes the problems that enterprises face today when interconnecting their branch offices with dynamic workloads in third party data centers (a..k.a. Cloud DCs). There can be many problems associated with network connecting to or among Clouds, many of which probably are out of the IETF scope. The objective of this document is to identify some of the problems that need additional work in IETF Routing area. Other problems are out of the scope of this document. During IETF 106, we received comments that the document should cover the problems associated with DNS service by different Cloud Operators for Enterprise to utilize Cloud Resources even though DNS is not within the scope of IETF routing area. We greatly appreciate DNS experts to provide comments to our description. 3.4DNS 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 to. When applications in one Cloud need to communication 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 be forwarded to the DNS service in another Cloud. Needless to say, configuration can be complex depending on the application communication patterns. Thank you very much. Linda Dunbar ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop