3

I'm currently building and setting up my own Linux router, and one of the advantages of this is the ability to run benchmarks on my router directly.

I'm currently using 8.8.8.8 with dnsmasq for name resolution One of the things that has worked well in the past was using namebench to pick a dns server.I was running it off my desktop.

On Windows, this was a sub 10 mb download. On Ubuntu...

It requires 256 extra packages and 492mb of space. Its fine on my overstuffed rig but on a minimal router build it would be bloated, and I would rather keep this system as light as possible.

I'd like a better, more up to date alternative.

Prerequisites:

  • Needs to run on Ubuntu 18.04
  • Needs to be as light as possible - and I don't want a 10mb app that has 400mb of dependencies.
  • I'm fine with compiling, but being in repositories would be nice. I'm OK if its a PPA
  • Kept up to date - namebench was last updated 8 years ago.
  • Pure console application - I don't need or want a GUI.
  • 1
    Have you consider to run DNS cache server. This will help you with speedup DNS requests – Romeo Ninov Nov 12 '18 at 15:33
  • 1
    Technically - dnsmasq does do caching. It's a brilliant little piece of software – Journeyman Geek Nov 12 '18 at 22:42
0

Just use dig. It's installed natively as part of the base system with Ubuntu (it's in the dnsutils package on Debian derived systems like Ubuntu, the package name differs on other Linux distributions), provides easy timing info for the query itself, and it's wicked fast.

Usage for your case would be something like this:

dig @1.1.1.1 one.one.one.one. ALL

The first argument (with the @) indicates what server to query (in this case, CloudFlare's public DNS server). The second argument is the domain name to search for (in this case, one of the standard names for CloudFlare's DNS service). The final one says to return all records associated with the domain (this is important if you're using a system that has both IPv4 and IPv6).

This should produce output something like this:

; <<>> DiG 9.12.2-P2 <<>> @1.1.1.1 one.one.one.one. ALL
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4695
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;one.one.one.one.               IN      A

;; ANSWER SECTION:
one.one.one.one.        259     IN      A       1.1.1.1
one.one.one.one.        259     IN      A       1.0.0.1

;; Query time: 28 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Nov 12 15:09:27 EST 2018
;; MSG SIZE  rcvd: 76

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43564
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;ALL.                           IN      A

;; AUTHORITY SECTION:
.                       9078    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2018111201 1800 900 604800 86400

;; Query time: 25 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Mon Nov 12 15:09:27 EST 2018
;; MSG SIZE  rcvd: 107

The part here that you care about is the first line that says ;; Query time:, which tells you how long it took to get an answer from the moment your system sent the request until the response from the server arrived.

There's another big advantage to using dig for this type of thing. If you use a domain name that you know the IP address for, you can be certain you're getting back correct data for it. You can also test a known bogus domain (like www.bogus.bogus.), and verify that you get back an NXDOMAIN status like you should (some providers, especially ISP's, point these at advertising pages instead of saying that it doesn't point at anything).


As an alternative, why not just configure your DNS resolver on your router to query multiple servers The good ones either query all the configured servers in parallel (and as a result automatically end up using info from the fastest one, because they get the response from that one first), or they maintain info about how well each performs and preferentially query the fast ones (Unbound is an example of a server that does this).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.