I want to compare the speed at which 1.1.1.1 and 1.0.0.1 resolve names compared to my ISPs DNS servers. Is there a software package i can install to do this?
Running tcpdump on the interface will show you timestamps of the respective traffic.
1 Like
I’m slightly hesitant to recommend it (people love or hate this guy), but this will benchmark multiple dns servers.
4 Likes
Thanks for this idea. Ill give it a go tonight.
Is this really an issue though?
I'm in EU, and have my own pihole DNSes in an Oracle data center outside of Washington DC. Can't say I see any performance issue with them being so far away from me.
I'm on 1/1 gbit.
1 Like
dig @NS_IP host.example.net
root@magiatiko:[~]#dig @1.1.1.1 openwrt.org
; <<>> DiG 9.18.1 <<>> @1.1.1.1 openwrt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55145
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;openwrt.org. IN A
;; ANSWER SECTION:
openwrt.org. 2082 IN A 139.59.209.225
;; Query time: 11 msec <---------------------------------------------------------
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Thu Jul 14 07:59:48 CEST 2022
;; MSG SIZE rcvd: 56
4 Likes
This is even better than monitoring tcpdump, though I might try both.
1 Like
Many years ago I remember reading on a forum that even though OpenDNS (which was new at the time) could return faster results for some, but for others using their local ISPs servers yielded better results. So I’m interested to test which situation I am in, if either. What I like about both solutions presented so far is that I could script them to run for a period of time and look at the average. Will be interested to see if there is much of a difference between the two. Shouldn’t be, right?
tcpdump is not meant to be used to measure the RTT of a DNS query. Nor it is convenient to look for the query and reply, then subtract the time.
Regarding having the nameserver located on the other side of the Atlantic, it might not feel much getting a response in 100 or 200msec, but compared to a normal response time of 10-20msec and multiplying by 30.000 queries per day in a typical household, you can see that the delay is accumulating.
1 Like
Or if you're running host from unbound
host -v <host> <server>
diizzy@hanekawa:~ % host -v openwrt.org 1.1.1.1
Trying "openwrt.org"
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28108
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;openwrt.org. IN A
;; ANSWER SECTION:
openwrt.org. 626 IN A 139.59.209.225
Received 45 bytes from 1.1.1.1#53 in 5 ms
Trying "openwrt.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7701
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;openwrt.org. IN AAAA
;; ANSWER SECTION:
openwrt.org. 3186 IN AAAA 2a03:b0c0:3:d0::1af1:1
Received 57 bytes from 1.1.1.1#53 in 6 ms
Trying "openwrt.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51231
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;openwrt.org. IN MX
;; ANSWER SECTION:
openwrt.org. 3600 IN MX 10 util-01.infra.openwrt.org.
Received 59 bytes from 1.1.1.1#53 in 198 ms
1 Like
On my router it returned
-----------------------------------------------------
OpenWrt 21.02.3, r16554-1d4dea6d4f
-----------------------------------------------------
root@OpenWrt:~# dig @1.1.1.1 openwrt.org
-ash: dig: not found
root@OpenWrt:~# dig @1.1.1.1 openwrt.org
-ash: dig: not found
root@OpenWrt:~#
1 Like
You need to install either dig or unbound-host using opkg or include it in your image
3 Likes
Looks like it has more depends than unbound-host however meaning that it'll use more space
1.3MB to be exact.
while unbound-hosts
521KB!!! 
Bind on PC and run dig from command prompt.
E:\Utility\BIND>dig @1.1.1.1 openwrt.org
; <<>> DiG 9.16.26 <<>> @1.1.1.1 openwrt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21698
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;openwrt.org. IN A
;; ANSWER SECTION:
openwrt.org. 1066 IN A 139.59.209.225
;; Query time: 31 msec <----------------------------ifdown wg0 raw ISP query ------------------------------
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Jul 14 10:33:41 Eastern Daylight Time 2022
;; MSG SIZE rcvd: 56
E:\Utility\BIND>dig @1.1.1.1 openwrt.org
; <<>> DiG 9.16.26 <<>> @1.1.1.1 openwrt.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48125
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;openwrt.org. IN A
;; ANSWER SECTION:
openwrt.org. 1869 IN A 139.59.209.225
;; AUTHORITY SECTION:
. 2803 IN NS f.root-servers.net.
. 2803 IN NS g.root-servers.net.
. 2803 IN NS m.root-servers.net.
. 2803 IN NS k.root-servers.net.
. 2803 IN NS h.root-servers.net.
. 2803 IN NS c.root-servers.net.
. 2803 IN NS b.root-servers.net.
. 2803 IN NS d.root-servers.net.
. 2803 IN NS i.root-servers.net.
. 2803 IN NS e.root-servers.net.
. 2803 IN NS a.root-servers.net.
. 2803 IN NS j.root-servers.net.
. 2803 IN NS l.root-servers.net.
;; Query time: 177 msec <----------------------------ifup wg0 -------------------------------------------
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Jul 14 10:35:43 Eastern Daylight Time 2022
;; MSG SIZE rcvd: 267
Looks good, however it seems to be for windows only? I want to run the test on the router.
I’m sure you know what you’re talking about, but can you explain a little more about what the implications of not being built to measure the round trip time of DNS packets are? Even if it wasn’t built with that use in mind specifically, is there something about tcpdump that makes the data it generates unsuitable for analysing the responsiveness of DNS servers? I have wireshark set up on a computer on the Lan and was thinking of doing a remote packet capture, then using filters to easily identify the relevant data.
You have to calculate the delta from the timestamps.
Timestamps are for the packet being captured on the wire, not actual sent/receive time, so it doesn't take into consideration internal delays.
In a busy environment it can be even more difficult to setup the filters to avoid the junk.
1 Like
I accept that no measuring instruments are exact.
It may not necessary for me to eliminate all systematic errors to achieve my goal of comparing DNS server response times if the method is accurate enough. The question is, given that DNS response times I've been getting range from 0 to 300ms depending on the DNS server and other factors, I'm not sure what 'accurate enough' is in this case.
I've decided to go with dig. It's not clear to me why it's faster after the first query, but I've been flushing the DNS cache with /etc/init.d/dnsmasq restart after noticing that the response time usually drops to 3ms after the first dig.