anchor.diff:  ....
   
   
  -But if I try for a sub-domain of netflix.com I get a valid response:
  +And if I try for a sub-domain of netflix.com I get a valid response:
   
   ....
   topranks@dnsvm:~$ dig A www.netflix.com @localhost
  
positive.code: 
  I recently got a Samsung 'smart' TV which is very nice to look at.
  
  Unfortunately there have been numerous security and privacy issues with smart TVs of all kinds, and Samsung in http://www.bbc.com/news/technology-31296188[particular].  Being predictably paranoid I immediately blocked the TV's IP address on my router, to stop it getting out to the internet at all.
  
  As it turns out however, the built-in Netflix app on the TV is my only option for 4k Netflix (my HTPC won't work due to not having a Kaby Lake chip, despite the Nvidia Pascal card....).
  
  Anyway, I found myself in a situation where I allowed the TV get out to the internet, despite my misgivings.
  
  But this got me thinking - could I somehow limit it's access to just Netflix?  I initally tried an IP-based ACL on the router, but there were some issues with that so I began to wonder was there a DNS-based approach I could take?
  
  
  === Enter DNS RPZ
  
  I am relatively familiar with https://www.isc.org/downloads/bind/[ISC Bind] having used it down through the years, and one feature in particular suggested it might help - Response Policy Zones.
  
  Basically RPZ can be used to create a DNS "firewall," limiting what domains can be resolved.  There is plenty of information online about how this can be set up, however I didn't find anything specifically explaining how to do what I needed (a total blacklist with only a very small whitelist of domains).
  
  
negative.code: 
  The first step is to get a basic Bind resolver up and running.  I did this with a Ubuntu 16.04 system.
  
  I then configured a 'response-policy' block in the 'options' section of my named.conf (on my particular system I did it in /etc/bind/named.conf.options).  This lists two RPZ zones which are used to define what queries to filter.  The key thing here is that RPZ checks zones in the order they are listed - this is key to creating a whitelist as opposed to a blacklist.  A single line is required:
  
   response-policy { zone "rpz.whitelist"; zone "rpz"; };
   
  All queries will then be filtered based on the response policy zones listed.  If a match is found in the first (rpz.whitelist) then that will be used, otherwise the second one (rpz) will be checked.
  
  The Bind server needs to be configured as authorititive master for these zones, similar to a standard zone, although with "allow-query" set to none.  Again this is in named.conf (in my case /etc/bind/named.conf.default-zones):
  
   zone "rpz.whitelist" {
      type master;
      file "/etc/bind/db.rpz.whitelist";
      allow-query { none; };
   };
   
   zone "rpz" {
      type master;
      file "/etc/bind/db.rpz";
      allow-query { none; };
   };
  
  As can be seen the zone definitions reference the location of the zone files for each.  The files are created as follows, using the RPZ syntax.  The first zone, rpz.whitelist, is where to define the domains we want to allow.  In my case it looks like this:
  
  _/etc/bind/db.rpz.whitelist_:
  ....
  