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 <p...@redbarn.org>
Sent: Tuesday, February 11, 2020 9:01 PM
To: dnsop@ietf.org; Paul Ebersman <ebersman-i...@dragon.net>
Cc: Linda Dunbar <linda.dun...@futurewei.com>
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.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. ...
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:
https://nam03.safelinks.protection.outlook.com/?url=http:%2F%2Ffamily.redbarn.org%2F~vixie%2Fproxynet.pdf&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Cea9257cce7324514505a08d7af67db4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637170732927513090&sdata=%2FzrBVSfi5L13cbWGdv4bcKgBPE2vSioKdrSLymRFsq4%3D&reserved=0
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
