Hi Michael, > > Beyond the considerations in the draft, another method I imagine is > > to deploy a DNS proxy (but I don't know whether it's practical). > > I am not sure what you call a DNS proxy. > A recursive DNS server accessed by Do53 effectively proxies and caches all > requests.
The DNS proxy I call more likes a middle-box, I think. I mean when the IoT device onboarding, the CPE/Access Point can provision the IoT device with the IP address of the DNS proxy rather than the real DNS server. > > In the residential scenario, the CPE device is usually the MUD > > controller and the policy enforcement point, and it can also act as a > > DNS proxy. > > > When the IoT device sends a DNS query it will send to the > > CPE. And CPE can first filter the unexpected DNS query by comparing > > the DNS names with the ones defined in the MUD file, then CPE will > > query the actual DNS server. > > Yes, the CPE could look at the DNS queries the device is using, and then > cache them. Or, when it loads the MUD file, it could do a DNS lookup on > all the names, and cache them. Then, when the device asks, it is already > cached, and one can be sure that a known IP/name combination is > returned. I think the 'cache' here means a pre-query. But the cached IP/name may be incorrect if the real DNS server changes the answer. What I suggest is no pre-queries. The IoT device sends a DNS query to the DNS proxy, and the DNS proxy queries the real DNS server. So the DNS proxy can 1) filter the illegal DNS queries which are not defined in the MUD file, and 2) know the DNS answer exactly with the IoT device. > If it does this DNS lookup on a regular basis (updating the MUD ACLs > implemented in the forwarding plane), then the cache stays warm, and the > rules are accurate. > > This is how our implementation worked. > > > When the CPE gets the answers from the actual > > DNS server, it can respond to the IoT devices with the answers and > > generate the corresponding ACLs as it knows the IP addresses now. > > If you can generate the ACL on demand fast enough, it can work. > Many IoT devices, if DNS seems slow, will switch to 8.8.8.8. > Google Chromecast for instance, always sends to both local and 8.8.8.8 from > what I've read, and uses which ever is faster. The CPE can block the DNS query to 8.8.8.8 and force the IoT device to wait. > > In the enterprise scenario, the MUD controller, the policy enforcement > > point, and the DNS proxy may be three different devices. The MUD > > controller gets the MUD file of the IoT device and dispatch the file to > > the DNS proxy. When the IoT device sends the DNS query to the DNS > > proxy, the DNS proxy can filter the DNS query as well and then get > > the answers by querying the real DNS server. After that, the DNS proxy > > will tell the IP addresses of the DNS names to the MUD controller, and > > the MUD controller can generate the ACLs and configure the policy > > enforcement point. > > Sure, that's essentially correct. > The DNS proxy is just the local recursive resolver. > What counts is that the MUD controller and the IoT device use the same > recursive resolver, and see the same cache. Yes. Also, I assume the IoT device won't do DNS lookup frequently, so updating the cache each time when the IoT device sends the DNS query can be acceptable. Regards & Thanks! Wei Pan _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
