Ceci est une ancienne révision du document !
After the Christmas holidays, it’s usually time for me to take stock of my work equipment (computers and servers), and see what I can do while I’m still on holidays to make life simpler. This time around, I wanted to configure an internal Bind9 DNS server, so I can use internal domains for accessing servers, virtual machines, NAS, other computers, and so forth. Since my test area is Ubuntu 15.10 on Vagrant, I’ll cover all the steps (including the steps for Vagrant). Step 0: Configure Vagrant box If you’re setting up Bind DNS on a standalone device, or on a virtual machine that is already configured, you can skip this step. Personally, I think Vagrant is a wonderful way to test configurations, but I will be migrating the Bind9 DNS server to an Intel NUC, once the new skylake models are available. vagrant box add ubuntu/wily64 This command adds the official Wily Werewolf 64-bit Vagrant Box to your system. You can skip this and go straight to the init, but I prefer to have local copies of certain base boxes, as I spin up a lot of vagrant boxes. vagrant init ubuntu/wily64 This will initiate a Vagrantfile that uses the ubuntu/wily64 box from above. If you haven’t added the box using the box add command, it should work anyway (as this is an official image). If not, you may need to supply the URL (see the Further Reading section for a link to the webpage).
You’ll also want to set up a private network IP (if you plan to actually use the DNS). To do so, edit the Vagrantfile, and edit the line that reads ‘config.vm.network “private_network”’. The IP can be pretty much anything you’d like (provided it isn’t already in use). If you’re going to use the DNS outside the host computer, you’ll need to instead set up a public_network. Since this is a VM, I stuck with a host-only network, as, if my computer isn’t running, neither is the VM (nor do I need to have access to the test DNS from anywhere else). Lastly, you’ll want to start the Vagrant box with: vagrant up Step 1: Installing I recommend installing 3 packages - bind9, bind9-docs, and dnsutils. Bind9 and the -docs package are important, as they will be the actual DNS server. Dnsutils contains a bunch of useful tools for debugging DNS. Step 2: Basic Configuration Open/edit the correct file using the following command: sudo vim /etc/bind/named.conf.options If you’d prefer to use something like emacs or nano, substitute vim for that. If you’re doing this in a graphical environment, you’re welcome to use anything you prefer. If working in Vagrant, you’ll be limited to CLI. I’ll also be referring to line numbers. If your vim isn’t displaying the numbers, you can toggle them with the command “:set number”.
Step 2a: Forwarders Since we’re focusing on internal connections, any outside IPs (which will be requested from this server as well) can be safely called from existing DNS. This is what Bind9 calls “forwarders” - they are essentially the IP addresses of the DNS that should be checked, if the domain isn’t contained in the local copy. I’d recommend using the Google DNS, but if you want to use your ISP’s, you simply need to know the IPs of them. Find lines 13-15 (that starts with {NOWIKI}{NOWIKI} forwarders {), and make it look like this: forwarders { 8.8.8.8; 8.8.4.4; }; The big change here is replacing line 0.0.0.0; with 8.8.8.8; and 8.8.4.4; (the IPs for Google’s DNS). Also, make sure you uncomment the entire block. If you’re using vim, use a quick ‘Esc’ (to leave edit mode), and then save and quit with: :wq Step 2b: Setting up zones You’ll need to open a new configuration file: sudo vim /etc/bind/named.conf.local This file should be largely empty (on a fresh install, at least). Before we can make any edits, we need to know what our IP address is. Typically, it’s something like 192.168.0.X, or 192.168.1.X (for internal networks). To find out what your IP address is, you can run the command ‘ip addr‘. If you’re running Vagrant, you’ll have a few different interfaces - find the one that uses the private or public network IP you added to the Vagrantfile. If you’re at a physical computer with multiple internet connections, I’ll have to assume you know which IP to use. It’s important to note only the first 3 sections of the IP (so ignore the last number). Also, select a local domain you’d like to configure. I selected lswest.local, simply because it won’t interfere with existing domains (if you use google.com, for example, you will not be able to reach the google homepage). Now, in the named.conf.local file, you’ll need to add the lines shown top right. The section that reads “in-addr.arpa” is required for a DNS IPv4 reverse lookup. For more information, see the wikipedia link in Further Reading. Type indicates whether the DNS is a master (primary), or a slave (secondary). While this is a complicated distinction to fully understand, for the time being it’s safe to assume any local Bind9 DNS zone will be a master. The ‘notify no;’ on the internal IP indicates whether or not zone notifications are to be sent to slaves when changes occur. As this is a master without slaves, it’s not technically necessary. However, since this is for all IP addresses in the network, it’s useful to include (to avoid issues down the line). Now we need to create the db files we refer to in the file. To start with, I’ll focus on the local domain. sudo cp /etc/bind/db.local /etc/bind/db.lswest.local Now we’ll need to open and edit the file: sudo vim /etc/bind/db.lswest.local The file should look like the following: The changes we’ll need to make: • In line 5, we’ll need to change localhost. to domain. (a fully qualified domain name - fqdn) So, since the domain is lswest.local, the line will read “lswest.local.”. Make absolutely sure there is a trailing period. • Also in line 5, we’ll need to edit “root.localhost.” This is actually an email address (but without an @). It isn’t terribly important what you put here, but I’d recommend at least using your username. So root.localhost. becomes “vagrant.localhost.”. • You’ll need to also edit line 12 to be the domain name you chose in 1. So we would edit this to read “lswest.local.” Subdomains Now is the time to actually create subdomains. I’m going to focus only on A records, and possible CNAME (canonical name) entries. MX Records are also common, but I don’t know how often you’ll want to really configure MX records in a local network. If you do, the process is the same. I’m going to create 2 subdomains - nas (fqdn: nas.lswest.local), and web (fqdn: web.lswest.local). One will point to the physical NAS I have in the network, and the other will point to the vagrant box I use for web development. I’ll also set up a CNAME entry - vagrant, which I’ll point at the web subdomain. The file will then look like the text shown top right (from line 16 onwards). The lines that start with a semi-colon are comments, and serve to just make the file more readable. As you can see, you point the CNAME to the fqdn of another server. As you can probably figure, this is because CNAMEs are simply aliases. Step 3: Reverse Lookup This step is optional. If you’re not planning to do reverse DNS checks on IPs (to find domains), you can skip this. However, it’s good practice, and may come in useful. First, we must copy the default db.127 file: sudo cp /etc/bind/db.127 /etc/bind/db.192 Once done, open the file. It will look similar to the db.lswest.local file from above. We need to make the following changes: Line 5: change “localhost.” to the fqdn from earlier. Line 5: Change root.localhost to the email you used earlier. Line 12: change “localhost.” to the fqdn from earlier. Delete line 13 (the pointer). We’ll be replacing this entirely later. We now need to add the entries. After line 12 (the NS line), add the following line: 4 IN PTR nas.lswest.local. The 4 is the last number of the IP address from db.lswest.local. Since this is a reverse lookup for 192.168.0, we need only the last digit. It is also why I left out the web value, as the IP is 192.168.33.10 - if I wanted to reverse lookup this, I’d need to set up a zone for 192.168.33. However, as my Vagrant installs don’t generally survive long, I don’t find the effort necessary. The CNAME doesn’t get a pointer, as it’s not assigned to an IP. Save and close the file (:wq in vim). Step 4: Run server, and connect It’s now time to start the Bind9 server. To do so, run the following: sudo service bind9 start Now you need to enter the DNS on the machine you want to use it from, this could be done in the network manager in Ubuntu, or wherever you may configure a DNS on the OS of choice. Use the IP for the server we configured earlier. Step 5: Testing Once your DNS is configured, you should be able to connect to one of your servers using the domain name. If your browser initiates a search instead of pulling up the webpage, make sure you manually add http: before the domain. If the domain doesn’t resolve properly, you can check it using dig. The command for that looks something like this: dig nas.lswest.local @192.168.15.3 The @ indicates the DNS to check. If you’ve already changed your DNS IP, it shouldn’t be necessary. If, however, you’re not getting the results you expect, it may be useful.
Step 6: Logging If you run into issues, you’ll want to enable logging. AppArmor technically has a rule for bind9 already, but the folder in /var/log doesn’t exist. You’ll want to do the following: sudo mkdir /var/log/named/ sudo chown bind:root /var/log/named/ sudo chmod -R 775 /var/log/named/ That should result in a log file (once the service was restarted). If not, you’ll want to check the third link in the Further Reading section. I hope this article is interesting for anyone who may, like me, be a web developer (or just simply run a lot of devices on their internal network). If you enjoyed the article, and have any questions, issues, or suggestions, feel free to reach out to me at lswest34+fcm@gmail.com. Further Reading https://atlas.hashicorp.com/ubuntu/boxes/wily64 - URL to the Wily64 box. https://en.wikipedia.org/wiki/Reverse_DNS_lookup - Reverse Lookup wikipedia article. http://askubuntu.com/a/469867 - Permission errors with Bind9