Panwei (William) <[email protected]> wrote: >> 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.
That's why an extra layer of proxy is not helpful: it's already present.
No additional middle boxes are needed.
A recursive DNS server caches answers and, in a sense proxies, the question.
It pays attention to the provided TTL, and expires the data when it happens.
The MUD controller needs to know the TTL of all things it looks up, so that
it can look them up again before the TTL expires.
The operator of the service can't update their servers faster than the TTL
anyway (because clients can cache the result), so there won't be any
inconsistency.
A DNS TTL of 0 is permitted however, and either this document needs to recommend
against doing that, or provide some guidance. I'm not sure what the right
answer yet.
> 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.
I see.
This depends upon the IoT query always travelling via the same path to the
same recursive DNS server. That's why you've put this proxy in place.
I think that this just introduces an additional single point of failure, when
DNS has already provided redundancy. That is, it makes DNS less reliable.
Doing the queries when installing the ACLs leverages the resilience rather
than reduces it.
Perhaps, however, the MUD controller should perform the query to all
recursive DNS servers and should merge the results if they are not
identical.
>> 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.
It could do that.
>> > 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.
I agree that this would reduce the DNS lookup frequency.
In the end, either strategy can work, as long as the IoT device can be
convinced to always do DNS queries to a place that the MUD controller knows
about.
Updating the ACLs based upon DNS queries means that there has to be some new
active entity in the DNS lookup path, and this may be much harder to deploy.
For home gateways, it's all degenerate, so both methods are probably
equivalent. For enteprises, it is not.
DNS recursive services are something which enterprise operators tend to be
reluctant to mess with, as it often have profound effects on the desktop user
experience.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
