Subject: [Add] Fwd: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt

From: Ben Schwartz <[email-masked]>
Date: Tue, 21 Sep 2021 10:25:04 -0400

Hi ADD,

I've written a new draft regarding DDR and legacy DNS forwarders ("the 85%
problem").  This replaces my previous proposed changes to the DDR draft.

Note that this draft's "intended status" is currently "Informational", on
the theory that we are more likely to reach consensus (and stay within the
charter) if we aren't trying to make normative rules about client policy
details.

--Ben

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Sep 21, 2021 at 10:10 AM
Subject: New Version Notification for
draft-schwartz-add-ddr-forwarders-00.txt
To: Benjamin Schwartz <[email-masked]>

A new version of I-D, draft-schwartz-add-ddr-forwarders-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-schwartz-add-ddr-forwarders
Revision:       00
Title:          Discovery of Designated Resolvers in the Presence of Legacy
Forwarders
Document date:  2021-09-21
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.txt
Status:
https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/
Html:
https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders

Abstract:
   This draft describes how the Discovery of Designated Resolvers (DDR)
   standard interacts with legacy DNS forwarders, including potential
   incompatibilities and relevant mitigations.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the mailing list
   ([email-masked]), which is archived at
   https://mailarchive.ietf.org/arch/browse/add/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bemasc/ddr-forwarders.

The IETF Secretariat

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 24 Sep 2021 13:50:41 +0000

Hi Ben,
I really like the idea presented in this draft. I think it could be very helpful to many end users – allowing automated upgrade to DoH for people behind DNS proxies who aren’t using any filtering in those DNS proxies.

I have just a few comments.
I think there needs to be a more complete definition of “non-public IP address” (or perhaps a more refined and specific set IP addresses of where this relaxed validation might be considered). I’m thinking it might be good to restrict to an IPv4 address on the same subnet, an IPv6 address in an on-link prefix, or 127.0.0.0/8. This latter would be for clients that make use of stub resolvers. Note that an IPv4 subnet and IPv6 on-link prefix could be comprised of globally routable addresses – so not necessarily “non-public” as some people might understand that word.
But since we’re all trying to head for IPv6, I think it’s good to recognize that the IPv6 address being advertised for DNS proxies tends to be from the delegated prefix and not ULAs. And it might be good if we could support this case.

I’m not too sure about the 6.1.1 mitigation solution related to implementing DNR. It’s not that it’s necessarily wrong -- it’s just not really a part of DDR-based discovery and there’s no rules around how DDR and DNR interact.

I think the 6.1.2 and 6.1.3 mitigations should somehow be strongly recommended in conjunction with this technique. Though I understand the desire to avoid normative language, I still think it would be beneficial to use some lowercase recommending words.

BTW, I really like how short and readable the draft is. 😊
Thx,
Barbara

From: Add <[email-masked]> On Behalf Of Ben Schwartz
Sent: Tuesday, September 21, 2021 9:25 AM
To: ADD Mailing list <[email-masked]>
Subject: [Add] Fwd: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt

Hi ADD,

I've written a new draft regarding DDR and legacy DNS forwarders ("the 85% problem").  This replaces my previous proposed changes to the DDR draft.

Note that this draft's "intended status" is currently "Informational", on the theory that we are more likely to reach consensus (and stay within the charter) if we aren't trying to make normative rules about client policy details.

--Ben
---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Sep 21, 2021 at 10:10 AM
Subject: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt
To: Benjamin Schwartz <[email-masked]<mailto:[email-masked]>>

Name:           draft-schwartz-add-ddr-forwarders
Revision:       00
Title:          Discovery of Designated Resolvers in the Presence of Legacy Forwarders
Document date:  2021-09-21
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.txt
Status:         https://datatracker.ietf.org/doc/draft-schwartz-add-ddr-forwarders/
Html:           https://www.ietf.org/archive/id/draft-schwartz-add-ddr-forwarders-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-schwartz-add-ddr-forwarders

Abstract:

Discussion Venues

   Discussion of this document takes place on the mailing list
   ([email-masked]<mailto:[email-masked]>), which is archived at
   https://mailarchive.ietf.org/arch/browse/add/.

The IETF Secretariat

---

From: Chris Box <[email-masked]>
Date: Fri, 24 Sep 2021 18:00:10 +0100

Ben,

Thanks for this draft. As Barbara says it's short and readable, and it
carefully articulates the issues.

In section 3 we could clarify "removes the certificate validation policy".
What I mean is to tighten it to clearly refer to the quoted policy in 2.1,
not  to all types of certificate validation. We still want the client to
perform normal TLS validation (e.g. correct chain of trust exists).

Section 4 is concerned with the implementation of these features *on the
legacy forwarder*. Where they are implemented on the forwarder, I agree the
way to continue to support the behaviour is to add resolver.arpa to the
blocklist. HOWEVER it would be worth also commenting on the implementation
of these same features on the upstream resolver, which I suspect is pretty
common. In this latter case, the behaviour is naturally supported as soon
as the upstream publishes the SVCB for _dns.resolver.arpa.

Caveat: this is only true if the legacy forwarder has no role in the
implementation of the features. In networks where both the forwarder and
the upstream need to co-operate (e.g. forwarder assists the upstream in
communicating the type of service required for this user), then it can only
continue if we block resolver.arpa.

Chris

On Fri, 24 Sept 2021 at 14:51, STARK, BARBARA H <[email-masked]> wrote:

> Hi Ben,
>
> I really like the idea presented in this draft. I think it could be very
> helpful to many end users – allowing automated upgrade to DoH for people
> behind DNS proxies who aren’t using any filtering in those DNS proxies.
>
>
>
> I think there needs to be a more complete definition of “non-public IP
> address” (or perhaps a more refined and specific set IP addresses of where
> this relaxed validation might be considered). I’m thinking it might be good
> to restrict to an IPv4 address on the same subnet, an IPv6 address in an
> on-link prefix, or 127.0.0.0/8. This latter would be for clients that
> make use of stub resolvers. Note that an IPv4 subnet and IPv6 on-link
> prefix could be comprised of globally routable addresses – so not
> necessarily “non-public” as some people might understand that word.
>
> But since we’re all trying to head for IPv6, I think it’s good to
> recognize that the IPv6 address being advertised for DNS proxies tends to
> be from the delegated prefix and not ULAs. And it might be good if we could
> support this case.
>
>
>
> I’m not too sure about the 6.1.1 mitigation solution related to
> implementing DNR. It’s not that it’s necessarily wrong -- it’s just not
> really a part of DDR-based discovery and there’s no rules around how DDR
> and DNR interact.
>
>
>
> I think the 6.1.2 and 6.1.3 mitigations should somehow be strongly
> recommended in conjunction with this technique. Though I understand the
> desire to avoid normative language, I still think it would be beneficial to
> use some lowercase recommending words.
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of *Ben Schwartz
> *Sent:* Tuesday, September 21, 2021 9:25 AM
> *To:* ADD Mailing list <[email-masked]>
> *Subject:* [Add] Fwd: New Version Notification for
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>