On Fri, 25 Sep 2020 at 23:11, Michael Richardson <[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. > > 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 <[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
