Following on from the first part of the post – the exciting and enthralling conclusion….
Modify /etc/bind/named.conf and insert the following:
zone "dev.local" {
type master;
file "/etc/bind/db.dev.local";
};
That will tell bind to use the file db.dev.local for the domain dev.local. Tweak these names as appropriate for your situation.
The contents of /etc/bind/db.dev.local itself:
;
; BIND data file for dev.local zone
;
$TTL 604800
@ IN SOA ns.dev.local. root.dev.local. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.dev.local.
@ IN A 192.168.56.10
dev.local. IN A 192.168.56.10
ns.dev.local. IN A 192.168.56.10
vm1.dev.local. IN A 192.168.43.102
*.vm1.dev.local. IN CNAME vm1.dev.local.
*.dev.local. IN CNAME dev.local.
A basic explanation of this setup. We define the nameserver for dev.local to be this box (192.168.56.10), as well as dev.local itself. The CNAME entry for *.dev.local forces any subdomains under dev.local also to resolve to the same IP as dev.local. So everything under dev.local will resolve to this virtual machine.
The vm1.dev.local entry represents a subdomain which needs to point to a different IP. In this instance, one that sits on the bridged network. We also want all *.vm1.dev.local addresses to resolve to this different IP, so again, that’s the reason for the CNAME entry. Any time I want to add a new subdomain which points to a different IP, I just define two lines like that (one containing the IP for the subdomain, and one containing a CNAME entry for the subsubdomains).
A few things to note:
- It is important to put the trailing full stop in the places as it shown above after the domain names – failure to do so will result in some of the queries not working as expected.
- The CNAME entry for dev.local is at the end so that it doesn’t override the more specific subdomain entries. I think order is important, but I haven’t done any testing to prove this assertion.
- I’ve only done enough to get the basics working, so this doesn’t even count as a beginners guide to managing Bind.
- I have the feeling that I have used inaccurate terminology in the above paragraph!
Now, restart Bind and then we’ll test it.
sudo /etc/init.d/bind9 restart
You can test whether entries resolve correctly using dig. We want to lookup a particular domain, and we want to use the name server running on this box – we’ll search for a random subdomain of dev.local:
dnsule@dnsule:~$ dig @127.0.0.1 something.dev.local ; <<>> DiG 9.7.0-P1 <<>> @127.0.0.1 something.dev.local ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26349 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;something.dev.local. IN A ;; ANSWER SECTION: something.dev.local. 604800 IN CNAME dev.local. dev.local. 604800 IN A 192.168.56.10 ;; AUTHORITY SECTION: dev.local. 604800 IN NS ns.dev.local. ;; ADDITIONAL SECTION: ns.dev.local. 604800 IN A 192.168.56.10 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Aug 14 01:27:20 2010 ;; MSG SIZE rcvd: 103
The important parts are the answer section and the returned status in the header section. If we get returned something other than NOERROR, then something has gone wrong with the query. If this happens, I strongly suggest examining /var/log/daemon.log for clues. The answer section shows how the DNS entry is resolved – we match the CNAME record, and then look up dev.local to get the correct IP.
Running dig on specific subdomains should also succeed in returning the different IP address requested:
dnsule@dnsule:~$ dig @127.0.0.1 something.vm1.dev.local ;; ANSWER SECTION: something.vm1.dev.local. 604800 IN CNAME vm1.dev.local. vm1.dev.local. 604800 IN A 192.168.43.102
You should also modify /etc/nsswitch.conf, so that the VM will use its own nameserver to resolve DNS entries.
And that’s it! Almost. We’ve created our VM, it’s ready to serve – but nothing other than the VM itself is actually using it. In my case, I want the Windows laptop that is running Virtualbox to use it. To achieve this, you explicitly define the DNS server for the “Virtualbox Host-Only Network” network adapter to be 192.168.56.10. Now you should be able to lookup dev.local addresses correctly.
If you want to ensure that the DNS server is not exposed to public networks, you’ll probably want to add a line like this to /etc/bind/named.conf.options:
listen-on { 127.0.0.1; 192.168.56.10; };
That will stop it serving requests on normal networks.
One thing I find slightly quirky is that the machine which helps the client connect to the right server by providing the correct IP, is actually unable to see the network or the target machine. It’s probably this sort of quirkiness which made me think that this idea was cleverer than it actually is.
Having this setup does provide greater flexibility – I could change things so that my development VMs also use it for DNS in future, which is certainly much nicer than having to modify several instances of the hosts file.
In retrospect, it would have been easier to just define entries into the hosts file and use find and replace to ease the burden somewhat when it comes to changing the IP address. But I dislike modifying the hosts file, because it seems a very poor substitute for having properly defined DNS entries – it’s also fairly common to forget that they are defined and wonder why things aren’t working as they should be.
Besides, I’ve learnt a fair bit by doing this, and sometimes it’s more about the journey you take, rather than the destination you arrive at…
