Just to confirm I verified what exactly dig measures. For example, this dig takes 8ms (which is always rounded):
[gponikie@krk-mptoy atlas_day68_step1]$ dig +tcp example.com @1.1.1.1
; <<>> DiG 9.14.3 <<>> +tcp example.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14416
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 5212 IN A 93.184.216.34
;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jul 09 13:17:55 CEST 2019
;; MSG SIZE rcvd: 56
If you check it with wireshark it looks like this:
No. Time Source Destination Protocol Length Window size value Shift count Info
1 13:17:55.014898 192.168.1.83 1.1.1.1 TCP 78 65535 6 53593 → 53 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64
TSval=676915370 TSecr=0 SACK_PERM=1
2 13:17:55.029784 1.1.1.1 192.168.1.83 TCP 74 29200 10 53 → 53593 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1412
SACK_PERM=1 WS=1024
3 13:17:55.029883 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=1 Ack=1 Win=262144 Len=0
4 13:17:55.030041 192.168.1.83 1.1.1.1 DNS 108 4096 Standard query 0x3850 A example.com OPT
5 13:17:55.038351 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [ACK] Seq=1 Ack=55 Win=29696 Len=0
6 13:17:55.038572 1.1.1.1 192.168.1.83 DNS 120 29 Standard query response 0x3850 A example.com A 93.184.216.34 OPT
7 13:17:55.038624 192.168.1.83 1.1.1.1 TCP 54 4095 53593 → 53 [ACK] Seq=55 Ack=59 Win=262080 Len=0
8 13:17:55.039580 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [FIN, ACK] Seq=55 Ack=59 Win=262144 Len=0
9 13:17:55.047201 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [FIN, ACK] Seq=59 Ack=56 Win=29696 Len=0
10 13:17:55.047273 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=56 Ack=60 Win=262144 Len=0
From this traffic looks like dig measures time between packets 4 (DNS query) and 6 (DNS response) which is precisely 8.5ms and matches what dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is expected
.
RTT can be measured on different layers for the same communication stream. In case of DNS over UDP we just ignores UDP overhead because it doesn't add any packets. With TCP additional packets are added which significantly
increase time that end-user have to wait from first packet to get information that he/she needs. IMO RTT should always be measured from 1st packet to packet which has information that you have actual data. If we want to measure raw DNS performance
without overhead then it must be explicitly market it measurement description.
Regards,
Grzegorz
From: Giovane Moura <giovane.moura@sidn.nl>
Date: Friday 2019-07-05 at 14:34
To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net>
Subject: [atlas] DNS RTT over TCP: twice as long than UDP?
Folks,
This page at Atlas provides a great visualization on the RTT of DNS
queries over TCP/UDP to the Root DNS servers:
We can see that the RTT of TCP queries is at least twice as long than
UDP ones (which, according to the page " TCP is expected to be 2-3 times
" longer.
I cannot replicate these results in my setup, even in large scale from
various vantage points: I always get very similar results for either TCP
or UDP. Example:
UDP:
* $ dig example.nl @ns1.dns.nl
Query time: 8 msec
TCP:
* $dig +tcp example.nl @ns1.dns.nl
Query time: 9 msec
I think there might be something with the definition of RTT.
My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for
TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and
the RTT of query/response itself.
By definition, however, RTT is "the length of time it takes for a
signal to be sent plus the length of time it takes for an
acknowledgement of that signal to be received."[2]. So if DNS TCP
measurements starts measuring from the SYN packet, that', in fact, be
two RTTs. Is this the case with Atlas?
I know it may sound a bit like nitpicking, but I just want to be sure of
what's exactly being measured.
thanks a lot,
/giovane