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

["STARK, BARBARA H" <[e-mail]>]

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 <[e-mail]> On Behalf Of Ben Schwartz
Sent: Tuesday, September 21, 2021 9:25 AM
To: ADD Mailing list <[e-mail]>
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: <[e-mail]<mailto:[e-mail]>>
Date: Tue, Sep 21, 2021 at 10:10 AM
Subject: New Version Notification for draft-schwartz-add-ddr-forwarders-00.txt
To: Benjamin Schwartz <[e-mail]<mailto:[e-mail]>>



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
   ([e-mail]<mailto:[e-mail]>), 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