As of today, all of my network is running off of FreeBSD name servers. In my previous post I discussed the different types of DNS, and then covered the authoritative DNS server, in my case NSD. This post will cover the few remaining items, namely a recursive and caching server, as well as blocking DNS that you don't want to resolve.
So first we will start with unbound our recursive and caching server. As of FreeBSD 10.1 it comes in the base system and it will setup in a chroot by default. Again you can still set this up in a jail if you like. And as always there is a lot I can't cover specific to your machines and network. So you need to figure of those settings and address any network or security concerns you may have. I recommend starting by running the following command:
local-unbound-setup
This puts all the basic configuration in place, and then you can tweak it from there. For almost all of this you can either edit the main unbound configuration or create an additional configuration file to be located in. By default it has:
include: /var/unbound/conf.d/*.conf
So basically if you put a file ending in .conf in that directory, it will be loaded. You may have issues with ordering, etc. For the simple purpose of avoiding confusion, just pretend everything is being added to the main /var/unbound/unbound.conf
You may need to edit, remove or comment out the include for lan-zones.conf if you use private addresses on your LAN. This will depend on your network of course. Also there is a forward file that will be generated from your resolv.conf, it will generally try to use your ISP's DNS to forward DNS queries. This could be good or bad depending again on your network. Some ISP's have used wildcard matches for mistyped addresses and you may not like that. I'll leave those settings up to you.
In the server section of the configuration I disabled tcp and hid some information. There are many other settings again, use your judgement based on your network and needs. Here are the adjusted settings for my example configuration:
do-udp: yes
do-tcp: no
# security
hide-identity: yes
hide-version: yes
We also need to put in some ACLs to decide who can use our DNS server. I will show you some examples:
access-control: 127.0.0.0/8 allow access-control: 192.168.99.0/24 allow
As always you will need to adjust this to fit your network.
Now just like on NSD we want remote control, even if we only use it locally. So run the following to generate keys:
unbound-control-setup
Once the keys are generated edit your configuration, and add the following:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
control-port: 8953
server-key-file: "/var/unbound/unbound_server.key"
server-cert-file: "/var/unbound/unbound_server.pem"
control-key-file: "/var/unbound/unbound_control.key"
control-cert-file: "/var/unbound/unbound_control.pem"
If you setup NSD as the authoritative DNS server now is the time to forward some zones over to it. In unbound these are called stub-zones. In the examples under NSD I called the forward domain domain.lan So here the example of setting up a stub for that domain is as follows:
local-zone: "nmo.local" transparent
stub-zone:
name: "domain.lan"
stub-addr: *primary nsd ip address*
stub-addr: *secondary nsd ip address*
Notice you have to declare the local zone as transparent. If you don't do this CNAME (basically DNS alias records) will not work.
The reverse DNS is very similar:
local-zone: "136.168.192.in-addr.arpa" transparent
stub-zone:
name: "99.168.192.in-addr.arpa"
stub-addr: *primary nsd ip address*
stub-addr: *secondary nsd ip address*
Again note the transparent local zone. In this case if you don't set that, you will notice right away because reverse DNS will fail altogether for this range. Unlike the forward DNS that partially works.
As always I recommend you check your configuration. For unbound the command is:
unbound-checkconf
Correct any errors as needed, and you are complete. To run the service on startup add the following to /etc/rc.conf:
local_unbound_enable="YES"
Now you can test with various DNS queries both local and remote. Depending on your configuration, you may need to disable some of the validating features. For example if you are using forwarding DNS. To do this comment out or remove the following line:
auto-trust-anchor-file: /var/unbound/root.key
Now your DNS queries should work (if you had issues at all).
You will also notice there was no talk about Master and Slave servers. Since the recursive and caching server doesn't have any zone information to share, there is no need for that configuration. If you need multiple recursive and caching servers you simply setup another one with the same configuration. They all need to talk to the authoritative servers, root servers and/or forwarding servers, but not each other.
If you want to block DNS for any reason, it is very simple with unbound. This can be for any reason, for example advertisement blocking, pornography blocking, blocking malware/virus sites, or just because you don't want anyone to go to a rival website. It really doesn't matter. In this example we will pretend that we found a site that has and tries to spread a really bad virus, and we want to protect the people on our lan and wifi from getting it. This fake website is "reallybad4u.fake". Simply adding two lines to your configuration will block that site from resolving:
local-zone: “reallybad4u.fake” redirect local-data: "reallybad4u.fake A 127.0.0.1"
This makes reallybad4u.fake and any subdomains like really.reallybad4u.fake not load. I have tested with a lot of these and the server seems to have no noticeable slowness. Of course your mileage may vary.
A couple of things to keep in mind when blocking domains. Again it covers all subdomains, you could specifically allow a certain subdomain through, but that would require additional configuration I will not cover here. Also you may not want to block everything, particularly with advertising you may wish to support some sites via their advertisements. Blocking information can also be bad. I have seen over kill filtering where a company wants to block all forums, but they end up blocking useful forums related to software. Or blocking downloadable software because they don't want employees to install anything, but then they end up blocking important helpful information about products already installed. Of course this again falls under the category of you knowing your network, your needs and your policies.
And the most important warning about DNS blocking. It can usually be gotten around very easily. If all you do is use DNS filtering whether it be a personally setup DNS server or free or pay DNS server available online, the problem is the computer, phone or other device can change which DNS server it uses. So in the case of a parent or company trying to block people from getting to pornographic web pages, a savvy teenager or employee could easily put in a public DNS server and get past the filtering. One way to try and prevent this or make it harder for the person to get around would be to put a firewall rule in place (on your main router not individual machines) to not allow any DNS connections except to the servers you would like them to use. Nothing is fool proof, and the best solutions for everyone's environment will be different.