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.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 <timothy.s.mori...@irs.gov> > *Sent:* Thursday, February 13, 2020 6:23 AM > *To:* Linda Dunbar <linda.dun...@futurewei.com>; Paul Vixie < > p...@redbarn.org>; dnsop@ietf.org; Paul Ebersman <ebersman-i...@dragon.net > > > *Cc:* RTGWG <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 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
