On Sun, 27 Sep 2020 at 04:32, Michael Richardson <[email protected]> wrote:
> > tirumal reddy <[email protected]> wrote: > >> tirumal reddy <[email protected]> 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. > > It's reasonable that Firefox might do that, but I don't see why IoT devices > should follow suit, and that's the point of this document. > Except in some very niche digital signage and kiosk use, I don't think a > MUD > file would be appropriate for a general-purpose browser. > I quoted Firefox as an example, the proposed mechanism of using SUDN to discover the ISP encrypted DNS resolver is generic and not specific to browsers. If the endpoint cannot discover the local encrypted DNS server (hosted on the CPE) using DHCP/RA, the endpoint will fallback to using SUDN to discover the one hosted by the ISP. -Tiru > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
