Re: [OPSAWG] I-D Action: draft-richardson-opsawg-mud-iot-dns-considerations-03.txt

[Michael Richardson <[e-mail]>]

Panwei (William) <[e-mail]> wrote:
    > This is an very useful and essential draft, I think. The DNS resolving
    > issue may be an important obstacle for deploying MUD solution
    > successfully.

Thank you.

    mcr> The simplest successful strategy for translating names is for a MUD
    mcr> controller to take is to do a DNS lookup on the name (a forward
    mcr> lookup), and then use the resulting IP addresses to populate the
    mcr> physical ACLs.

    > This strategy is simple, but I doubt it can't be called 'successful' as
    > it won't work all the time. You already listed some failure scenarios.

Okay, so maybe my words are not perfect.  Please suggest some better ones here.

The naive method of using the reverse map never works :-)
(Some people read RFC1034/35 and think that DNS inverse queries are still a thing)

This method is the simplest that can be made to work.
The rest of the document is really about making this method work.

    > 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.

    > 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.
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.

    > 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.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide