Subject: [Add] Fwd: New Version Notification for draft-reddy-add-enterprise-split-dns-00.txt

From: tirumal reddy <[email-masked]>
Date: Tue, 23 Feb 2021 14:29:05 +0530

Hi all,

https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-00
discusses a mechanism to inform endpoints of split-horizon DNS and their
DNS domains, and is compatible with encrypted DNS. It addresses the use
cases of DNS configuration on explicitly trusted networks presented at ADD
interim (please see slides 7 to 9 in
https://datatracker.ietf.org/meeting/interim-2021-add-01/materials/slides-interim-2021-add-01-sessa-draft-box-add-requirements-design-slides-00.pdf
).

Please review the draft and provide your valuable comments.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, 21 Feb 2021 at 12:16
Subject: New Version Notification for
draft-reddy-add-enterprise-split-dns-00.txt
To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]>

A new version of I-D, draft-reddy-add-enterprise-split-dns-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-add-enterprise-split-dns
Revision:       00
Title:          Split-Horizon DNS Configuration in Enterprise Networks
Document date:  2021-02-20
Group:          Individual Submission
Pages:          12
URL:
https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-00.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns
Htmlized:
https://tools.ietf.org/html/draft-reddy-add-enterprise-split-dns-00

Abstract:
   When split-horizon DNS is deployed by an enterprise, certain
   enterprise domains are only resolvable by querying the network-
   provided DNS server.  DNS clients which use DNS servers not provided
   by the network need to route those DNS domain queries to the network-
   provided DNS server.  This document informs DNS clients of split-
   horizon DNS, their DNS domains, and is compatible with encrypted DNS.

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.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Feb 2021 15:50:36 -0500

This draft contains a large amount of veiled policy argumentation and
outright specification of client policy.  That material is out of scope for
this working group.

Apart from that issue, the draft's quote from RFC 2826 quite expressly
forbids the technical approach taken in this draft.  RFC 2826 says
"if [private networks] wish to make use of names uniquely defined for the
global Internet, they have to fetch that information from the global DNS
naming hierarchy".  RFC 2826 later clarifies

> The
> requirement for uniqueness within a domain further implies that there
> be some mechanism to prevent name conflicts within a domain.  In DNS
> this is accomplished by assigning a single owner or maintainer to
> every domain, including the root domain, who is responsible for
> ensuring that each sub-domain of that domain has the proper records
> associated with it.  This is a technical requirement, not a policy
> choice.

In my view, any draft that defines a modified lookup procedure must
therefore ensure that it is not altering the party who controls the
contents of any defined global domain.  This could work by first checking
that a given name does not exist in the global namespace, or by providing
evidence that the local network operator is the party responsible for the
global name.

I recommend that the authors adopt one or both of those approaches to make
this draft compliant with IAB guidance and good DNS practice.

On Tue, Feb 23, 2021 at 3:59 AM tirumal reddy <[email-masked]> wrote:

> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: tirumal reddy <[email-masked]>
Date: Fri, 26 Feb 2021 15:39:24 +0530

Hi Ben,

Thanks for the review. Please see inline.

> outright specification of client policy.  That material is out of scope for

PvD can be used to provide the network configuration information, see
https://tools.ietf.org/html/rfc7556. If the WG thinks it is useful but not
in scope, we can discuss to enhance the scope; otherwise will remove the
text.

> evidence that the local network operator is the party responsible for the

If the client queries a public resolver to check if the private DNS names
exist in the global namespace, it would leak the private sensitive names to
the public resolver and adversely impact privacy. Alternatively the client
can use bloom-filter of well-known domains to check if the name does not
exist in the global namespace (similar to the way Chrome uses bloom- filter
to identify if the domain visited by the user is not malicious), it avoids
leaking the private names to external resolvers.

We can update the draft to discuss the above mechanism.

I did not get the latter part of the comment : How would the local network
operator provide evidence that it claims authority over a global name ?

Further, it is quite common in split DNS for an authoritative server to
give different responses to queries from the Internet than queries from
devices attached to the network (see
https://tools.ietf.org/html/rfc6950#section-4).

Cheers,
-Tiru

>> To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]
>> >
>>
>>
>>

---

From: Bob Harold <[email-masked]>
Date: Fri, 26 Feb 2021 09:29:04 -0500

There are a few sections that say something like:

   If SplitDNSAllowed is set to false, the client should not trust the
   SplitDNSAllowed key in case of connecting to unknown or untrusted
   networks (e.g., coffee shops or hotel networks).  For example, if
   SplitDNSAllowed is set to false, client can choose to use a alternate
 network to resolve the global domain names.

But I see no way for a client to know whether it is in an untrusted network
or not.
-- 
Bob Harold

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 26 Feb 2021 10:24:08 -0500

On Fri, Feb 26, 2021 at 5:09 AM tirumal reddy <[email-masked]> wrote:

> https://tools.ietf.org/html/rfc7556. If the WG thinks it is useful but
> not in scope, we can discuss to enhance the scope; otherwise will remove
> the text.
>

The Introduction section largely discusses access policies and how networks
can override the client's preferences.  This is not in-scope.
Additionally, the normative text contains requirements like

   For each dnsZones entry, the client MUST use the network-provided DNS
   servers as the only resolvers for the listed domains and its
   subdomains and it MUST NOT attempt to resolve the provided DNS
   domains using public resolvers.

That's explicitly specifying client policy, which is out of scope for ADD.

> exist in the global namespace, it would leak the private sensitive names
>

Yes

> to the public resolver and adversely impact privacy.
>

I disagree.  The client has a choice of resolvers to which to send its
queries.  That choice impacts their privacy, and so the client makes that
choice on the basis of their perception of the resolvers' privacy posture.
If the client chooses to direct queries to a public resolver, it is because
they have decided that this choice is not adverse to their privacy.

> Alternatively the client can use bloom-filter of well-known domains to
> check if the name does not exist in the global namespace
>

This is a fun idea!  I think this is a research topic for now but it's a
good puzzle.  While we're talking about tricky ways to find nonexistent
domains, you could also imagine using NSEC to prove the nonexistence of a
name in a zone without revealing the name to the resolver.  (Even better
with NSEC3.)

...

> operator provide evidence that it claims authority over a global name ?

The simplest way would be to do an NS query for a zone, and see that one of
the listed nameservers is the network's local DNS server.

> https://tools.ietf.org/html/rfc6950#section-4).

Yes, that seems fine.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 28 Feb 2021 21:48:02 -0500 (EST)

On Fri, 26 Feb 2021, Bob Harold wrote:

>          SplitDNSAllowed is set to false, client can choose to use a alternate    network to resolve the global domain names.
> 
> But I see no way for a client to know whether it is in an untrusted network or not.--

In fact, the document goes even further:

 	The scope of this document is restricted to unmanaged BYOD devices
 	without a configuration profile.

This is the classic case of a device owner who claims its sovereinity
trumps the network administrator, and vise versa.

The examples then given at the end, is about a VPN client connecting to
the Enterprise without MDM enforcement.

At best, the network provides a list of domain names to resolve via the
network DNS servers (as per document via RA RFC8801) and for the VPN
case, everything is already covered in 8598, other than the transport
to the DNS server. Which I assume in the enterprise, is that the DNS
servers there will just support port53, DoT, DoQ and/or DoH and are
defined in draft-btw-add-ipsecme-ike-01.

I think I said this in earlier discussion as well, back when we were
discussing the charter of this WG, I don't see this document adding
anything. Unmanaged devices per definition cannot trust the networks they
trust (even if it is the wifi name and password they were told). What if
my boss suddently decides to add gmail.com to their list of domains? So
unmanaged clients at best can be presented with a list of domain names
to confirm/reject. And for non-split DNS, the client has no choice to
use whatever it is given via DHCP/VPN config as DNS servers.

As implementer, I don't really know what this document tells me to do.
It specifies ways to convey information, but I don't see when I would
or should use or can trust, that information.

Paul