Network Access Server with a RaspberryPi : Part 1 – DNS

The RaspberryPi did not land in the market unnoticed. For about $35 you get a ready to work computer.
Many people have done amazing things with it – from IoT to distributed computation – other uses it as a full stack home media player. Other surely have a spare RaspberryPi and don’t know what they can do with it, the answer is a SMB grade Network Access Server (NAS)

This 3 part series intend to show how to use a RaspberryPi as a Network Access Server with enterprise services.

This specific blog post will be about providing a LAN  with a local DNS resolver using dnsmasq, that will improve overall internet speed of the clients in the LAN and allow a network administrator to configure its host names in an easy fashion.

Note: The RaspberryPi is running Raspbian as its Operationg System

DNS Primer

It is taken for granted that the reader knows what is the basic function of a DNS server, translate a name to an IP address.

A DNS server in order to be effective has to match two criterias :

  • Proximity
  • Cacheability


In the wild, they are two kids of DNS servers network types.

The first one, anycast network type. With anycast network type, several geographically separated DNS servers listen on the same IP address, the DNS server closest to you in terms of hops will answer your query, providing you with the lowest latency.

The second one, unicast networy type, With unicast network type, a single server listens to a single IP address. Meaning if you live in California and your DNS provider has its servers in California you will have low latency, but if a country-side european resident uses the same DNS server he will have a much higher latency.

Bottom line on proximity, the closer the better. The closest you can get to your computer – beyond  is your LAN. Having a DNS resolver on your LAN provides one with the second lowest possible latency.


One of the biggest challenge of Public DNS resolvers is Cacheability, more precisely shared cacheability. Due to the scale of the deployed infrastructure by those PublicDNS resolvers maintaining a common cache is somewhat a big  technical challenge in itself.

When you clicked on a DNS server answered the IP corresponding to the hostname and then cached the association IP <> Hostname for TTL time. So a user can think next time s/he will be hitting the DNS server for the exact same host name (within the TTL) the DNS query may be faster, well the answer is not necessarily.

Be it an unicast or an anycast network type,  nothing can ensure one will end up on the exact same server two times in a row. (ie. Load balancer, etc…)

Bottom line on cacheability, by caching locally on a single server (the Pi) you won’t need to worry about shared cache. It will always be synced to itself

A note on dnsmasq name server feature

By deploying a DNS resolver within one local network, both proximity and cacheability issues are tackled. Also, but nonetheless, deploying dnsmasq on one local network will act as an authoritative source  for local devices names defined in /etc/hosts. No more need to deal with BIND and DNS records such as ‘router A XXX.XXX.XXX.XXX’. Simply by inserting the line ‘XXX.XXX.XXX.XXX router’ in your host file your DNS server will provide you the correct IP address.

Installation & Configuration


sudo apt-get install dnsmasq dnsmasq-base
update-rc dnsmasq default


As with most programs, dnsmasq configuration can be edited in the /etc/dnsmasq.conf file or by dropping configuration rules in /etc/dsnmasq.d directory.

In order to keep a clean configuration, only the listen-address parameter will be edited in /etc/dnsmasq.conf


Then, the extra configuration will be written in specific files under /etc/dnsmasq.d/


server=                       # Primary DNS Server
server=                       # Secondary DNS Server

server=/   # Specific DNS server for a given domain name

bogus-nxdomain=                # Return NXDOMAIN as it should (IP applies to OpenDNS)

all-servers                                 # All listed DNS servers will be queried the faster will be picked

Make your computer default DNS your raspberrypi

Once everything is set up, you need to let your computer know which DNS server to use. For this several options :

  • Configure it directly in your DHCP server if you have access to (recommended)
  • In Linux, either configure NetworkManager or your /etc/resolv.conf file to have the right DNS server
  • In Windows configure your connection accordingly to use the right DNS

Also the /etc/hosts file will be edited to highlight the name server feature of dnsmasq    printer    printer.localdomain     router     router.localdomain    storage    storage.localdomain


For tesing the performance of using the RaspberryPi as a DNS server the following script was ran 10 times from a laptop connected to a router via WiFi.
Using the RaspberryPi as DNS server


sleep 2 && dig | grep 'Query time:'
yguenane@laptop:~$ repeat 10 ./
;; Query time: 102 msec
;; Query time: 31 msec
;; Query time: 28 msec
;; Query time: 29 msec
;; Query time: 32 msec
;; Query time: 29 msec
;; Query time: 29 msec
;; Query time: 30 msec
;; Query time: 28 msec
;; Query time: 29 msec

Using OpenDNS as DNS server


sleep 2 && dig @ | grep 'Query time:'
yguenane@laptop:~$ repeat 10 ./
;; Query time: 103 msec
;; Query time: 131 msec
;; Query time: 133 msec
;; Query time: 132 msec
;; Query time: 134 msec
;; Query time: 131 msec
;; Query time: 131 msec
;; Query time: 133 msec
;; Query time: 134 msec
;; Query time: 133 msec

Using Google PublicDNS as DNS server


sleep 2 && dig @ | grep 'Query time:'
yguenane@laptop:~$ repeat 10 ./
;; Query time: 136 msec
;; Query time: 135 msec
;; Query time: 131 msec
;; Query time: 131 msec
;; Query time: 131 msec
;; Query time: 132 msec
;; Query time: 132 msec
;; Query time: 136 msec
;; Query time: 131 msec
;; Query time: 131 msec

One can see the – big – response time difference from the RaspberryPi compared to the PublicDNS servers once the entry is cached.

For the name feature, one can simply ping printer and see that will be pinged.

Cache can be tuned thanks via cache-size, no-negcache, local-ttl and neg-ttl options. Refer to the man pages for more details.


BIND is a great product, it does well what is has been conceived for, but the entrance barrier might be high for a non networking-related profile. Dnsmasq is a lightweight yet mature alternative for SMBs. It allows one, totally unfamiliar with DNS records to set up a name server easily for an entire network.
In this first part we only focused on the DNS feature of dnsmasq, but it has much more it can provide. Next part will focus on the DHCP and PXE Server feature.


One Comment on “Network Access Server with a RaspberryPi : Part 1 – DNS”

  1. anthonyvenable110 says:

    Reblogged this on anthonyvenable110.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s