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…

Now what I wanted was to be able to set a wildcard DNS entry, but there was no guarantee I would be on a network that could support that. I would be setting up these VMs on my work laptop – and my laptop would be used on a variety of different networks.

Most of the VMs would be using Virtualbox‘s bridged adapter to connect to the Internet, so I couldn’t rely necessarily on the IPs being fixed on an internal network; The network addresses for my VMs would be at the mercy of whatever DHCP server that was handing out IPs at the time.

The majority of interaction that I would have with these servers would be through a web browser directly on my Windows 7 laptop.

My original goal would have been to just define a hosts file using wildcards, and modify that when the IPs of my VMs changed. But since you can’t use wildcards in a hosts file, that wasn’t an option. An alternative approach would have been to just define every single host that I might need in the hosts file (i.e. no wildcards for you, mister!), but that seemed untidy, especially when I might require several different domains for the same VM (for doing tests with sessions) and have several subdomains (one for each service on the machine) all pointing to the same box.

So I tried an approach which appealed to me a lot more – a local VM for serving DNS.

Now why on earth does such a thing merit a blog post? Well, a few reasons.

• If I ever have to do this again, at least I will have a guide.
• If anyone thinks of doing something similar, at least they will have a guide.
• Because this approach muddles between working on real networks and internal virtual ones, and has a sort of quirky elegance about it which makes me feel more like a hacker than simpler solutions would. So I want to share.

So, here’s the general idea of how my approach would work:

• I would create a small VM (small in disk space, small in RAM consumption) to host a DNS server.
• The DNS server would only be authoritative for local domains.
• The vast majority of configuration would be done with wildcards.
• It would only be necessary to change DNS entries for VMs which were using bridged network connections. Any VM’s that use host only network addresses would probably have fixed IPs, regardless of what network the host machine was on.

A typical interaction which would involve the DNS server would be something like this:

• In browser on laptop, go to http://service1.vm1.devbox/
• Primary DNS will not resolve this address, but the DNS server running on my internal network will.
• The DNS entry will be of the form *.vm1.devbox and will point to an IP address which is on the normal (real) network; a virtual machine using a bridged connection.
• The browser connects to this IP address, which will probably hit my reverse proxy of choice, Nginx.
• Nginx is configured to direct all traffic which goes to service1.* to a particular running service.
• Interaction between browser and service takes place.

The point about Nginx handling service1.* is important – if it is configured like that, then I can interact with service1.env1.vm1.devbox and service1.env2.vm1.devbox without needing to add any additional DNS settings or modify Nginx’s settings – env1 and env2 are just used for the sake of the browser to use different cookies to test different sessions.

So, first step was to get a VM running. I went with installing a minimal version of Ubuntu; 10.04 suited me fine. Within Virtualbox, I allocated it a small amount of memory (128 MB) and tried to allocate a small amount of hard disk space – but allocating less than a GB appears to prevent the installer from automatically creating partitions for you. So I went back and defined 2 GB of storage, but used dynamic allocation, so that it would only grow when required.

One important thing to remember to do is to initially give the VM a bridged network connection while you’re setting it up – it relies entirely on grabbing packages from the internet. The installation was quite smooth; I liked the fact that it asked me how I was going to use the OS – I selected “DNS server”, and it automatically installed BIND 9 for me. In retrospect, I should have also told to install SSH as well, but it wasn’t difficult to install it afterwards.

Once complete, I powered down the VM, switched the adapter from “bridged” to “host only”, and fired it back up. Now all the important work we had to do was to modify configuration files. It was slightly disconcerting not to have vim for use, and plain old vi wasn’t for me, so I made do with simple, but friendly Nano.

We have to give the box a static IP – I’m not sure whether Virtualbox allows you to fix the IP address using its own DHCP server, but I couldn’t see a way. So:

• sudo nano /etc/network/interfaces

And insert the following (replacing the existing definition):

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.56.10
netmask 255.255.255.0
network 192.168.56.0
broadcast 192.168.56.255

A restart is probably required at this point. Now my VM was ready to be configured for a DNS server, but I’ll leave that for a second post.

Before doing that, I decided that I would actually post about it in a blog, because I had been mulling over these thoughts for a while, and fancied posting them somewhere public.

Before doing that – I decided I had to actually acquire a blog. Makes sense, I guess.

So why did I choose WordPress? Mainly because I wasn’t too sure what I wanted to go for – LiveJournal was old school and Blogger wanted to use my Google account, and I don’t subscribe to the whole “everything under one account” notion yet. So WordPress it is. Unless someone wants to point me to something better…

Turns out that I’ve got something that I fancy actually ranting about, and since so many of my co-workers appear to have blogs for such things, I guess I’d better catch up…