Re: [OPSAWG] [Mud] changes to draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[tirumal reddy <[e-mail]>]

On Fri, 25 Sep 2020 at 23:11, Michael Richardson <[e-mail]>
wrote:

>
> tirumal reddy <[e-mail]> wrote:
>     > +1.  The problem is not just with public resolvers but also with
>     > designated resolvers. The IoT device supporting MUD must use the
>     > encrypted DNS server discovered in the attached network.
>
> Yes-ish.
>
> I don't think that we have to mandate use of encrypted DNS servers,
> as long as it's the ones on the attached network.
>

In the home network use case, if the CPE does not support an encrypted DNS
forwarder, endpoint will discover and use the ISP encrypted DNS recursive
server. The CPE will no longer be able to enforce MUD rules. For instance,
Firefox can discover and use Comcast Encrypted DNS recursive server, see
https://tools.ietf.org/id/draft-rescorla-doh-cdisco-00.html.


>
> My take is that it is better to use Do53 across the local LAN than public
> DoH
> server.   If the IoT device can be convinced to use the local DoT server,
> great.
> But, your documents in ADD are clearly trying to get there, but we aren't
> there yet.
>

In the interim ADD session 2, the consensus is to use DHCP/RA to discover
the local encrypted DNS server.
https://tools.ietf.org/html/draft-btw-add-home-09 extends DHCP/RA and it
also discusses hosting a DoH/DoT forwarder on the home router.

-Tiru


>
> I've been looking for a YANG module that would allow for explicit
> management
> of "/etc/resolv.conf" on a device.  If there is one, I don't know where it
> would be.
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>