Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

[Robert Mortimer]

I may be missing something obvious but this draft seems to contradict it self 
as it says in the introduction:

"Authoritative servers MUST NOT answer queries that are defined in this 
protocol."

and then goes onto say in section 2:

"if the resolver can be configured to also be authoritative for some zones, it 
can use that configuration to actually be authoritative for the addresses on 
which it responds."

I also wonder what the correct behavior is for a server which is both recursive 
and authoritative - is it prohibited from supporting this protocol by that 
first "MUST NOT"? 

-- 
RobM
On 12/02/2020 02:25:52, internet-dra...@ietf.org  
wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title : DNS Resolver Information Self-publication
Authors : Puneet Sood
Roy Arends
Paul Hoffman
Filename : draft-ietf-dnsop-resolver-information-01.txt
Pages : 9
Date : 2020-02-11

Abstract:
This document describes methods for DNS resolvers to self-publish
information about themselves, such as whether they perform DNSSEC
validation or are available over transports other than what is
defined in RFC 1035. The information is returned as a JSON object.
The names in this object are defined in an IANA registry that allows
for light-weight registration. Applications and operating systems
can use the methods defined here to get the information from
resolvers in order to make choices about how to send future queries
to those resolvers.

There is a GitHub repo for this draft where pull requests can be
issued: https://github.com/DNSOP/draft-ietf-dnsop-resolver-
information However, starting issues on the WG mailing list is
preferred.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-information-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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

[Morizot Timothy S]

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 Ebersman]

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] [Ext] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

[Paul Hoffman]

On Feb 12, 2020, at 1:59 AM, Robert Mortimer 
 wrote:
> 
> I may be missing something obvious but this draft seems to contradict it self 
> as it says in the introduction:
> 
> "Authoritative servers MUST NOT answer queries that are defined in this 
> protocol."
> 
> and then goes onto say in section 2:
> 
> "if the resolver can be configured to also be authoritative for some zones, 
> it can use that configuration to actually be authoritative for the addresses 
> on which it responds."
> 
> I also wonder what the correct behavior is for a server which is both 
> recursive and authoritative - is it prohibited from supporting this protocol 
> by that first "MUST NOT"? 

Good call. Would it make both parts clearer if the introduction instead said:

   Because the information returned in this protocol only applies to recursive
   resolvers, servers that are acting as both authoritative servers and 
recursive
   resolvers MUST only answer queries that are intended for the recursive
   resolver portion of the server. Servers that are only authoritative servers
   MUST NOT answer queries that are defined in this protocol.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
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]

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 so that the WG is aware of those issues.  
By the way, your email to 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-ip address 
and even that is nonstandard, relying on DNS vendor extensions.

similarly, if you use an internal name like .cloud and then want y

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

[Linda Dunbar]

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 Vixie]

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