How to block Windows 10 telemetry with your local resolver

There’s been a lot of talk about the data sent by a Windows 10 machine back to Microsoft. Some researchers have even found evidence of data being sent even when all available privacy settings are enabled. There is an emerging market for tools that will nobble Windows 10’s data collection, but who knows whether they work, or even if they’re malicious. Thankfully there is another way: if you run a local resolver, you can configure it such that DNS queries for domains linked to telemetry will always fail. Here’s how it’s done.

This technique takes advantage of the relatively new Response Policy Zones (RPZ) feature, so you’ll need suitably recent software. BIND 9.8 or later will do just fine, and that’s what I’ve used to prepare this post.

First, you’ll need to prepare a zone file which will contain your RPZ. This follows the same format as a normal zone file, except that it will contain a list of domains you want to block. Here’s an RPZ I just knocked up:

$TTL    3600
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

@       IN      NS      localhost.

*.telemetry.microsoft.com               CNAME .
*.telemetry.microsoft.com.nsatc.net     CNAME .
*.data.microsoft.com                    CNAME .
*.data.microsoft.com.nsatc.net          CNAME .
telemetry.appex.bing.net                CNAME .
ssw.live.com                            CNAME .

Note that every domain you want to block should end CNAME .. This tells the RPZ code to return NXDOMAIN for that domain. Remember that DNS wildcards (unlike SSL certificate wildcards) cover any number of subdomains, so in this example a query for all.your.keystrokes.are.belong.to.us.telemetry.microsoft.com will return NXDOMAIN.

Don’t just copy this example!—you’ll certainly need to change the SOA and NS records to match your local setup. The list of domains here is almost certainly wrong too: I just grabbed it from the first list I could find, but you’ll want to watch your logs carefully in case there’s something missing.

Next, you’ll need to tell BIND to load your new zone file (just like any other zone):

zone "rpz.your.domain" {
        type master;
        file "/etc/bind/db.rpz.your.domain";
        ... replication options etc ...
};

Finally, add the magic directive that tells BIND to treat your new zone as an RPZ:

options {
        ...
        response-policy {
                zone "rpz.your.domain";
                ...add other RPZs here (commercial ones are available)...
        };
        ...
};

Reload BIND, check the logs for errors, and then test your new config by trying to resolve a domain blocked by the RPZ:

$ sudo service bind9 reload
Reloading domain name service...: bind9.
$ dig +noall +comments +answer watson.telemetry.microsoft.com @8.8.8.8
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48788
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
watson.telemetry.microsoft.com. 1732 IN CNAME   watson.telemetry.microsoft.com.nsatc.net.
watson.telemetry.microsoft.com.nsatc.net. 52 IN A 65.52.108.29

$ dig +noall +comments +answer watson.telemetry.microsoft.com @localhost
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30579
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Hurrah! Google’s resolver shows us that watson.telemetry.microsoft.com should resolve, but our local resolver returns NXDOMAIN which is what we want. In BIND’s logs we can see what happened:

31-Aug-2015 11:24:36.820 rpz: client 127.0.0.1#47233: rpz QNAME NXDOMAIN rewrite watson.telemetry.microsoft.com via watson.telemetry.microsoft.com.rpz.your.domain

rpz indicates that the response-policy directive is doing its job, and we can see that the domain has been rewritten and NXDOMAIN was returned as we’d hoped.

If you want to try using your DNS resolver to subdue Windows 10’s chatty nature, give this a try. Do add a comment if you find a mistake (more than likely!) or have a suggestion for improvement.