Subject: Re: [Add] Fwd: New Version Notification for draft-reddy-add-server-policy-selection-06.txt

From: "Deen, Glenn" <[email-masked]>
Date: Thu, 4 Mar 2021 16:52:17 +0000

On 3/4/21, 8:30 AM, "Add on behalf of Ben Schwartz" <[email-masked]<mailto:[email-masked]> on behalf of bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

Regarding this draft: Quad9 conveys this information on their website, and this draft provides users with a link to it.  I think that's sufficient, and a much better fit to the problem space, given the endless variety of reasons someone might want to filter a DNS response.

That’s a browser centric view of network devices – meaning it assumes the device has a UI and a user looking at it.   How could this draft be extended to accommodate IoT devices for instance that the device owner wants to direct to choose to use DNS that filters out malware that is known to attack IoT devices?    Would more detailed filtering information be useful to convey?

This may be getting into out of scope territory for ADD – as in specifying the details of what is being sent versus the how do we send it – but wherever that actual task of laying out what ends up, it would seem important to always be considering the no-UI/no screen scenario of devices that connect to the network and need to choose services that fit into what the device admin wants.

-glenn

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 4 Mar 2021 14:11:17 -0500

On Thu, Mar 4, 2021 at 11:52 AM Deen, Glenn <Glenn_Deen=
[email-masked]> wrote:

>
>
>
>
> On 3/4/21, 8:30 AM, "Add on behalf of Ben Schwartz" <[email-masked]
> on behalf of bemasc=[email-masked]> wrote:
>
>
>
> Regarding this draft: Quad9 conveys this information on their website, and
> this draft provides users with a link to it.  I think that's sufficient,
> and a much better fit to the problem space, given the endless variety of
> reasons someone might want to filter a DNS response.
>
>
>
> That’s a browser centric view of network devices – meaning it assumes the
> device has a UI and a user looking at it.   How could this draft be
> extended to accommodate IoT devices for instance that the device owner
> wants to direct to choose to use DNS that filters out malware that is known
> to attack IoT devices?
>

I find it very difficult to think of a use case where this question would
come up.

>     Would more detailed filtering information be useful to convey?
>
>
>
> This may be getting into out of scope territory for ADD – as in specifying
> the details of what is being sent versus the how do we send it – but
> wherever that actual task of laying out what ends up, it would seem
> important to always be considering the no-UI/no screen scenario of devices
> that connect to the network and need to choose services that fit into what
> the device admin wants.
>

I'm not sure I understand what you're envisioning, but I don't see any
scenario in which it makes sense for the network to present multiple
non-equivalent resolvers to a non-interactive client device that chooses
among the resolvers based on their claimed behaviors.  There is no ability
for networks to do this today, and I have not heard of any IoT
manufacturers wishing that the network would make them choose the DNS
server from a list with descriptions.

In general, I think the MUD approach to IoT security is a much better
choice than anything we are likely to design here.