What Is DNS?
DNS is the system that translates a domain name like example.com to the numerical IP address of its server. This could look like 127.0.0.1. Whenever you make a network request using a domain name, your system will perform a DNS lookup to determine the server address it should contact.
This adds an overhead to every request you make. Although your device will cache DNS responses, visits to new domains will incur a DNS round-trip before the actual request begins. This occurs at the level of the OS networking stack, invisible to you as the user.
ISPs usually run DNS servers. You’re probably relying on your ISP’s server if you’re using default settings on your router and devices. Other public DNS servers are available from providers such as Cloudflare and Google.
Why Run Your Own DNS?
Running your own DNS server gives you more control over your network. One common motivation is being able to configure network-level domain mappings, such as web-server to 192.168.0.101. Configuring your router to use your DNS would result in any of your connected devices being able to access 192.168.0.101 via http://web-server.
Having your own DNS server lets you centralize settings into one location instead of applying them individually in /etc/hosts on each device. They’ll apply to everything you connect to your network, including embedded hardware which provides no other way to customize its routing stack.
An in-house DNS server can also improve performance and provide an extra layer of resilience. Wide-scale DNS outages are not unheard of; using a custom server with a long-lived cache for critical services you interact with could help you ride out downtime at your selected upstream provider.
DNS With Dnsmasq
Dnsmasq is a lightweight DNS server that’s included with most Linux distributions. It’s also refreshingly simple to configure.
Before starting out, it’s worth thinking about what functionality you need your DNS server to provide. In this guide, we’ll look at setting up Dnsmasq with local caching, some custom domain routes, and Google’s 8.8.8.8 as our upstream DNS provider.
The routing flow will look like this:
Network router receives a request from one of your connected devices. The router will be configured to use the Dnsmasq host as its DNS server. Dnsmasq will check whether it has a defined route for the domain name, such as web-server to 192. 168. 0. 101. If the request was for http://web-server/example-page, it will send 192. 168. 0. 101 back to the router. When Dnsmasq has no matching route, it will forward the DNS request to Google’s 8. 8. 8. 8, enabling resolution on the public internet. This ensures you can still reach the wider web when using your own DNS.
You won’t need to make any config changes on your client devices. Everything behind your router will end up making DNS queries via Dnsmasq. However, it is worth noting that all popular desktop and mobile operating systems support setting a DNS server, so you could configure individual devices to use Dnsmasq without enabling it at the router level.
Getting Started
We’ll assume you’ve already got a functioning Linux machine ready to host Dnsmasq. Dnsmasq is not particularly resource-intensive – if you’ve got few client devices, it will easily run on a Raspberry Pi.
Your host should have a static IP assigned. From hereon, the IP 192.168.0.1 refers to the Dnsmasq server.
Make sure Dnsmasq is installed:
Dnsmasq’s config file is usually located at /etc/dnsmasq.conf. This is pre-populated with initial settings. Some changes need to be made for Dnsmasq to work effectively in a local network scenario. Run sudo nano /etc/dnsmasq.conf to open the file, then use the Ctrl+W keyboard shortcut to find and uncomment the following lines:
Remove the # character from the start of each line. Here’s what these settings are enabling:
domain-needed – This stops Dnsmasq from forwarding local names without a domain part to the upstream DNS server. In our installation, it means example. com will be eligible for resolution via Google but example or web-server will not. It reserves dot-less names for your local network. bogus-priv – Prevents forwarding DNS reverse-lookup queries to the upstream DNS server. It means internal IPs like 192. 168. 0. 101 will never be exposed to Google. Not enabling this could unintentionally leak the architecture of your internal network to your upstream provider.
To set your upstream DNS server, add a new line to your config file:
This instructs Dnsmasq to forward unresolved queries to 8.8.8.8. If that server’s unavailable, 4.4.4.4 will be used instead. These addresses are the primary and secondary resolvers for Google’s DNS service.
Next adjust the cache size. This defaults to a relatively low value of 150 cached requests. Increasing this will let Dnsmasq serve more lookups from the cache, reducing network latency. Find the cache-size line, uncomment it, and change its value:
Save and close the file now.
Mapping Hostnames to IPs
There are a few different ways to map hostnames to their IP addresses. The simplest is to add entries to your server’s existing /etc/hosts file. Dnsmasq automatically loads the rules from this file as part of its default configuration.
Open /etc/hosts and add your routes to the bottom of the file. The IP address comes first, followed by the name to assign:
These lines mean any request to http://web-server will be directed to 192.168.0.101 while http://gateway.lan will end up at 192.168.0.5. Save and close the file when you’ve finished mapping your devices.
Testing Your Server
Restart Dnsmasq to apply all your changes:
Check the server’s running correctly:
You should see active (running) displayed in green. If you don’t, check the log lines at the bottom of the status information to work out what’s wrong.
Now you’re ready to test your server. You can make manual DNS lookup attempts with the dig tool. You might need to install the dnsutils package first.
Both of these commands should show an IP address in the ANSWER SECTION. In the case of gateway.lan, the result should be 192.168.0.5 according to the routing rule set up in /etc/hosts. The @localhost part of the commands instructs dig to query your local DNS server.
Configuring Your Network
The final step is to configure your network router to make DNS lookups via your Dnsmasq server. The steps for this will vary depending on the routing equipment you’re using.
Once you find the correct settings page, set your server’s IP (192.168.0.1 in this guide) as the router’s primary DNS server. It’s a good idea to configure a public DNS provider, such as Google’s 8.8.8.8, as the secondary server. This ensures you’ll still have internet access if your DNS server crashes and goes offline.
Now all the devices connected to your router will make DNS queries via your Dnsmasq instance. They’ll be able to reach your devices by their assigned names, such as web-server and gateway.lan, and benefit from network-level DNS caching.
Conclusion
DNS is an intricate topic but Dnsmasq makes it easy to get a basic server operational. There are many more settings which you can explore once you’ve got the core functionality working. These let you filter queries, manage relays and proxies, run scripts when events occur, and set up other kinds of DNS record such as MX results for mail servers.
Dnsmasq doesn’t usually need much manual intervention once it’s live. You can monitor logs using service dnsmasq status or systemctl status dnsmasq. Now you’re ready to benefit from your self-hosted DNS server, maximizing performance and letting you use internal domain names to reach local network devices.
