DEV Community

Murtaza ๐Ÿณ
Murtaza ๐Ÿณ

Posted on • Originally published at kazimurtaza.Medium on

Private DNS Server on RPI3+ and pushing it to the limit with Performance testing using Jmeter

I plan on configuring DNS server on my rpi3+, why you ask, well my reason for the time being are simple, just because I can, in reality, I have too many services running at home, and remembering IPโ€™s for all them has become somewhat hectic, and does not seem very nice.

This idea led me to an interesting discussion already going on the internet, why is everyone opting for the same, some for security, or privacy or caching. so I wanted to discover what was all the fuss about and actually prove to myself that RPI3, packs a punch.

Key concepts to ensure best practice(link)

  • DNS only answers to IP(s) on the internal domain,
  • Configure this DNS server to only use root hints and not forwarders (this can largely mitigate MITM attacks).
  • Have a local caching nameserver for faster query time and to prevent NXDOMAIN hijacking,
  • Recursion is allowed on a private DNS server as long as you make sure you have taken the first point into account.

Some advantages which are the reason why I am opting to have DNS Server,

  • DNS server can resolve domains, within the network. You could, for instance, resolve โ€œhello.world.comโ€ to your torrent server.
  • DNS can be used as a poor manโ€™s blacklist. you can block all unwanted domains, redirecting the request to a more suitable website.
  • Users in my network, are using a trusted DNS server and not some hijacked one.
  • we can block most of the ads, by blocking their IP(s).

why should we just keep our amateurly-configured DNS server private?

DNS protocol attacks are pretty common amongst hackers, some basic forms of attacks are; a detailed description of them can be found here.

  • DNS spoofing
  • DNS ID hacking
  • DNS cache poisoning

Why choose raspberry pi?

With evermoving innovation in arm based platforms, I have always been impressed by what these tiny machines with tiny footprint can do. let us prove if they provide value for money.

Prerequisite for implementing DNS Server on Raspberry PI

  • Raspberry PI,
  • Raspian Lite Image installed,
  • Internet connection, Internal static IP,
  • SSH enabled.

Comparison of DNS Server can be found here, I choose Bind, because of how widely accepted it is, and also it is open sourced, which mean it has good community support.

Following the tutorial here, I was able to successfully install Bind9 on the server but to be able to achieve my goal listed above, I had to modify the conf files present in the link.

**cat /etc/bind/db.subdomain.example.com**

$TTL 14400
@ IN SOA ns1.subdomain.example.com. hostmaster.subdomain.example.com. (

201006601 ; Serial
7200 ; Refresh
120 ; Retry
2419200 ; Expire
604800) ; Default TTL;

subdomain.example.com. IN NS ns1.subdomain.example.com.
subdomain.example.com. IN NS ns2.subdomain.example.com.
subdomain.example.com. IN MX 10 mail.subdomain.example.com.

ns1 IN A 192.168.100.100
ns2 IN A 192.168.100.102

www IN CNAME subdomain.example.com.

mail IN A 192.168.100.103

subdomain.example.com. IN A 192.168.100.1
raspberrypi3 IN A 192.168.100.100
raspberrypi2 IN A 192.168.100.101
router IN A 192.168.100.200
Enter fullscreen mode Exit fullscreen mode

Test your DNS server works perfectly before you go update every pc, for that I found this article to be much help.

sudo named-checkconf
Enter fullscreen mode Exit fullscreen mode

this command when executing on the DNS server would return an error if conf files are not properly configured.

next as the article suggests keep an eye on the logs, and yes use the dig command to ensure domain, is resolving correctly.

Now you can go ahead and update the internal network, or servers/pcs to your new DNS server.

Now comes the part we have all been waiting for Performance Testing DNS Server on RPI3+ , pushing it to the limit with concurrent load, for that, I follow this article here, though I made some changes not sure if they are correct, let us see.

Used two different UDP Request all pointing to the DNS Server, used DNS JAVA Decoder Class, broke the load test in 3 scenarios 10 , 20 and 50. This means we would have to update the number of threads in a thread group and keeping the ramp-up period to 10 sec.

Apache JMeter

to follow up on perfMon Metrics collector, you can find the details here and here, download the latest release, and start the client on your DNS Server.

Note: to be able to run Perfmon Metrics collector on the Raspberry PI, we would need compatible arm based .so lib, which can be found at the link below, Thanks to RHQ for all their hard work. https://sourceforge.net/projects/rhq/files/rhq/misc/

wget [https://master.dl.sourceforge.net/project/rhq/rhq/misc/libsigar-arm-linux.so](https://master.dl.sourceforge.net/project/rhq/rhq/misc/libsigar-arm-linux.so)
Enter fullscreen mode Exit fullscreen mode

50 thread over 5 mins load test (over-Wifi);

majority of the responses were under 200ms, with occasional spikes reaching around 1000ms

response time distribution also concludes the same.

Initially, wanted to see how well would RPI do at 50 and see If we could go higher, and up our test cases, sadly my router kept on restarting then I realized my Wifi ๐Ÿ˜ต was the bottleneck, in real life I doubt my setup would create that much load, I have switched to ethernet now, but the results over Wifi, were interesting as well.

RPI DNS server is serving at two points one is at ethernet and other wifi, only my test machine is using Ethernet, which was using Wifi before.

10 thread over 5 mins 3000 requests/sec;

request per second

response time (ms)

Memory(blue) is constant, CPU(red)

3000 requests per second. The error rate is 0.00% ๐Ÿ˜…, of total 1677107 samples. It did not impact memory much, query times are quick, a wired connection has made a difference and it seems RPI, still has a lot of room left. letโ€™s double up the thread count and increase the requests slightly.

20 thread over 5 mins 4500 requests/sec;

requests per second

response time (ms)

no more spike in request per second further down the line and the error rate is still 0.00% of total 2308031 sample size.

CPU(red) has increased

failures per request

50 thread over 5 mins 6500โ€“7000 requests/sec;

requests per second

response time (ms)

CPU(red) has increased

RPI consuming 7000 requests per second and not even burping, and the error rate is rock steady 0.00% of total 2939579 samples, I feel the more load we put on this arm based mean machine, more stable and faster it is, does putting more load on RPI3 sent it in overdrive mode? ๐Ÿคฉ๐Ÿ’ฅ

On side, it is interesting how all 4 cores of RPI are being used to maximize the utilization, hats of to ARM Community.

Note: memory usage is still the same around 18mb, recorded by PerfMon, in the above image taken from HTOP system process usage is included.

Would you blame me If I tried putting more load to see if it can break? We are far beyond normal usage, now we are just trying to break it.

OK, so we have some interesting results, threads were increased to 100, and requests were increased to 10000 per second, total samples 3343290, error rate still 0.00% compared to the volume of the request, it must be further down the decimal spaces. The CPU usage was about to hit 70%, the memory still did not move from 18mb.

CPU(red) increasing

in HTOP, all cores are perfectly utilized, perfmon showing average CPU usage

negligible failed requests per second

request per second

active threads

response time (ms)

Although at the end of the test, it can clearly be seen, that RPI was struggling but it just goes to show how stable and powerful RPI platform is. ~10000 requests, that is freaking fantastic. ARM Platforms, 5v power consumption can return this much value for money, is staggering ๐Ÿ˜ฑ. Can you wonder what we can achieve if we had a cluster of them?

I use Raspberry PIโ€™s for all kind of servers at home I have RPI2 and 1 as well, running different kinds of server ranging from python, java, and mono, And only if you knew how much punishment my RPI2 has to endure you would deeply feel sorry for it. One more thing if you are already following the latest news, docker is also supported๐Ÿ‘. Future for ARM-based platform looks quite bright to me.

Top comments (0)