Why install a Domain Name System (DNS) server on your local/home network? The goal is to configure your development server to mimic the live server as closely as possible. This means being able to access each development website by its local domain name from both mobile and non-mobile devices on the local network—what a mouthful.

On a small local network, DNS duties are easily handled by adding entries to the hosts file of each computer running a desktop operating system. And if it weren’t for those pesky smartphones and tablets, that would be that. Mobile operating systems have their hosts file locked away from our grubby little mittens. If you’re not into jailbreaking/rooting mobile devices to gain access to their hosts file, well then, a DNS server it is. As a bonus, you can manage all your local domain names from one spot.

But wait, there’s more! Smartphones, tablets, desktops, etc. require no configuration. None. Hosts files be gone. And as a bonus, my wife and I actually work on the same development WordPress site at the same time—but from different computers, we’re not crazy.

I decided to use Berkley Internet Name Domain (BIND) from Internet Systems Consortium, Inc. (ISC). BIND is free to use, open source, and the most widely used DNS software on the Internet. After some initial confusion and mild panic attacks, my BIND installation has been completely stable and easy to maintain. I can now add domain names to my local network at will and access them from multiple devices without breaking a sweat. I hope this article will help you to do the same.

What you’ll need to start:

If you’d like to toss a DNS server into your development server salad bowl, you’ll need a development web server up and running on your local network—I use Apache in the examples. You’ll also need an assortment of mobile and non-mobile devices for testing your creations. If you have already coerced your web server into serving name-based virtual hosts to non-mobile devices, you’re already ahead of the game.

Oh, and this short article is actually a great place to start, I wish I’d read it first: developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/How_the_Web_works

A bit o’ info:

This article is Windows-centric, but don’t let that put you off. Concepts, and much of the configuration, are the same no matter which operating system you use. I’m using ZoneAlarm firewall on the development server and will cover the configuration details. If you are using a different firewall, you may have to do a little research before poking the necessary holes through it to allow Apache and BIND to do their thing.

I have provided sample files—test web pages and configuration files—that you may use at your discretion. File paths and IP address are given as examples only; you’ll need to substitute your own. You’ll have to do the same for MAC addresses which I’m representing as 00-00-00-00-00-00, so when you see this MAC address, substitute your own.

About the setup:

The following will stand you in good stead when faced with the barrage of configuration ahead.  Hey, it rhymes!

• The development server is configured with a static IP address (so we can always find it).
• Development websites use name-based virtual hosts meaning many local domain names sharing a single IP address—the address of the development web server.
• Apache listens to two IP addresses: 127.0.0.1 and 192.168.0.200 (the web server’s IP) both on port 80.
• With the exception of the development server (which has a static IP), the router assigns each networked device a unique, unchanging IP address through the magic of Dynamic Host Configuration Protocol (DHCP) reservation. This makes configuration and testing much easier. More on DHCP reservation
• The BIND DNS server is configured as an authoritative name server responding to DNS queries for local domain names only, and only from the local network.

• Here’s the alchemy that transforms this project from “Argh!” to “Aha!”:

  • The development server’s primary DNS server IP address is set to 127.0.0.1 (itself).
  • The router’s primary DNS server IP address is set to the development server’s (static) IP address: 192.168.0.200
  • For web surfing duties, the secondary IP address, for both the development server and the router, is set to either a DNS server IP address provided by your Internet Service Provider (ISP), or the IP address of a public DNS server of your choice.

A tale of two paths:

Paths are written in two different ways—it’s Windows, folks.

Paths that use backslashes “\” refer to the Windows file system, example:

c:\webserver\apache\htdocs

Paths that use forward slashes “/” refer to Apache and BIND configuration files, example:

c:/webserver/apache/htdocs

Terms used in this article:

• BIND:

  Berkley Internet Name Domain (server)

• Development server:

  the computer that runs both the web server and DNS server software

• DNS server:

  Domain Name System server

• Local network:

  Local Area Network (LAN) consisting of a router, development server, and other connected devices

• Device:

  desktop, laptop, smartphone, or tablet, etc.

• Mobile device:

  a device running a mobile operating system

• Non-mobile device:

  a device running a desktop computer operating system such as macOS, Windows, Linux, etc.

What I’m using

A note on routers:
I recently purchased a new router and was dismayed by its watered down firmware. It would require three or four shots of espresso just to pass as a firmware. I haven’t been able to get it to work with BIND (yet) and probably won’t bother to try until I can update it with more robust, third-party firmware. For now I’m using an older, more feature-rich router. Why am I saying this? Your router may not include features mentioned in this article and may or may not be suitable for use on a local network running a DNS server—just so you know.

No comments yet…