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

From: tirumal reddy <[email-masked]>
Date: Sat, 11 Sep 2021 15:08:48 +0530

Hi All,

This revision
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns
addresses comments from the WG during the presentation at IETF-111.
The text related to network policy expression to perform DNS filtering and
Enterprise specific text is removed from the draft.

Further comments and suggestions are welcome.

Cheers,
-Tiru

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, 11 Sept 2021 at 14:57
Subject: New Version Notification for
draft-reddy-add-enterprise-split-dns-05.txt
To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]>,
Kevin Smith <[email-masked]>

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

Name:           draft-reddy-add-enterprise-split-dns
Revision:       05
Title:          Split-Horizon DNS Configuration
Document date:  2021-09-11
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/archive/id/draft-reddy-add-enterprise-split-dns-05.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
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-add-enterprise-split-dns-05

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

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 13 Sep 2021 10:15:40 -0400

I support this draft.  Thanks for the edits!

>    2.  The client checks that the NS RRset matches, or is a subdomain
>       of, any one of the ADN of the discovered network-designated
>       encrypted DNS resolvers.

I think we should adjust this text a bit.  We need to emphasize that any
DNR servers that are also in the NS RRSet are usable for this domain, and
the others are not.

I don't think the "is a subdomain of" rule is a good idea.  For example, if
the nameserver for "example.com" is "ns1.example.com", this rule would
allow the DNR sender to block access to "www.example.com" by adding "
example.com" to the DNR list.  The client would confirm that "example.com"
has the right certificates for itself, but all queries would fail because
it is not actually a DNS server.

There may also be situations where the DNR sender can acquire a certificate
for "example.com" but not for "ns1.example.com", e.g. due to a partial
compromise or division of responsibilities.  We should preserve that
distinction.

>   4.  If the client uses a public resolver, authenticated denial of
>       existence using NSEC3 or NSEC records can be used by a client to
>       identify that the domain name does not exist in the global DNS.
>       [RFC7149] recommends validation of responses using NSEC3.

Two notes.
1.  I don't think this is connected to the use of a public resolver.  The
client can equally well authenticate nonexistence through the network
resolver.
2.  RFC 7149 doesn't appear to mention NSEC3.  In general, DNSOP seems to
be leaning toward more use of NSEC, and less use of NSEC3.  It's probably
best to remove this sentence.

On Sat, Sep 11, 2021 at 5:39 AM tirumal reddy <[email-masked]> wrote:

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

---

From: tirumal reddy <[email-masked]>
Date: Tue, 14 Sep 2021 19:09:00 +0530

Hi Ben,

Thanks for the review and support of the draft. Please see inline

On Mon, 13 Sept 2021 at 19:45, Ben Schwartz <[email-masked]> wrote:

> I don't think the "is a subdomain of" rule is a good idea.  For example,
> if the nameserver for "example.com" is "ns1.example.com", this rule would

Good point, I will remove the sub-domain rule.

>
> There may also be situations where the DNR sender can acquire a
> certificate for "example.com" but not for "ns1.example.com", e.g. due to
> a partial compromise or division of responsibilities.  We should preserve
> that distinction.
>

The network-provided resolver would provide an existence response for
private domains. However, a public resolver would not be able to resolve
those domains and will respond with NSEC.

> best to remove this sentence.

Sure, I will remove the line.

Cheers,
-Tiru

On Sat, Sep 11, 2021 at 5:39 AM tirumal reddy <[email-masked]> wrote:
>> The text related to network policy expression to perform DNS filtering
>> and Enterprise specific text is removed from the draft.
>>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Sep 2021 10:01:44 -0400

> those domains and will respond with NSEC.

OK, thanks for the explanation.