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. 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; 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 collision at the present or in the future and 
they make DNSSEC trust manageable. It's not as 

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

[Scott Morizot]

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

[DNSOP] SHA-1 and DNSSEC validation

[Tony Finch]

I've posted a follow-up to my article last month about SHA-1 chosen prefix
collisions and DNSSEC. This discusses DNSSEC validation:

https://www.dns.cam.ac.uk/news/2020-02-14-sha-mbles.html

Summary:

DNSSEC validators should continue to treat SHA-1 signatures as secure
until DNSSEC signers have had enough time to perform algorithm rollovers
and eliminate SHA-1 from the vast majority of signed zones.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty: Southerly 6 to gale 8,
occasionally severe gale 9 except in South Utsire, veering southwesterly 4 to
6 for a time. Rough or very rough, occasionally moderate. Rain or showers.
Good, occasionally poor.

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

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

[DNSOP] Last Call: (Running a Root Server Local to a Resolver) to Informational RFC

[The IESG]

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Running a Root Server Local to
a Resolver'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2020-02-28. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Some DNS recursive resolvers have longer-than-desired round-trip
   times to the closest DNS root server such as during a network attack.
   Some DNS recursive resolver operators want to prevent snooping by
   third parties of requests sent to DNS root servers.  Such resolvers
   can greatly decrease the round-trip time and prevent observation of
   requests by serving a copy of the full root zone on the same server,
   such as on a loopback address or in the resolver software.  This
   document shows how to start and maintain such a copy of the root zone
   that does not cause problems for other users of the DNS, at the cost
   of adding some operational fragility for the operator.

   [ This document is being collaborated on in Github at:
   https://github.com/wkumari/draft-kh-dnsop-7706bis.  The most recent
   version of the document, open issues, and so on should all be
   available there.  The authors gratefully accept pull requests. ]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ballot/


No IPR declarations have been submitted directly on this I-D.




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop