Running your own DNS server is a great way to accelerate your network’s responsiveness, reduce your reliance on public infrastructure, and benefit from extra functionality like hostname routing. Here’s how to set up a DNS server on a Linux machine using Dnsmasq.
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
192.168.0.101. Configuring your router to use your DNS would result in any of your connected devices being able to access
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
184.108.40.206 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
192.168.0.101. If the request was for
http://web-server/example-page, it will send
192.168.0.101back to the router.
- When Dnsmasq has no matching route, it will forward the DNS request to Google’s
220.127.116.11, 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.
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:
# Assuming a Debian system apt update apt install dnsmasq
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:
# 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.comwill be eligible for resolution via Google but
web-serverwill 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.101will 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
18.104.22.168. If that server’s unavailable,
22.214.171.124 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.
/etc/hosts and add your routes to the bottom of the file. The IP address comes first, followed by the name to assign:
192.168.0.101 web-server 192.168.0.105 gateway.lan
These lines mean any request to
http://web-server will be directed to
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:
sudo service dnsmasq restart
Check the server’s running correctly:
sudo service dnsmasq status
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.
dig google.com @localhost dig gateway.lan @localhost
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
@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
126.96.36.199, 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
gateway.lan, and benefit from network-level DNS caching.
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.
- › Here’s How Mozilla Thunderbird Is Making a Comeback in 2022
- › 5 Annoying Features You Can Disable on Samsung Phones
- › Why Do I See “FBI Surveillance Van” in My Wi-Fi List?
- › Using Wi-Fi for Everything? Here’s Why You Shouldn’t
- › Why Unlimited Mobile Data Isn’t Actually Unlimited
- › MSI Clutch GM41 Lightweight Wireless Mouse Review: Versatile Featherweight