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 <[email protected]>
Date: Friday 2019-07-05 at 14:34
To: "[email protected]" <[email protected]>
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:
https://atlas.ripe.net/results/maps/root-server-performance/
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
[1] https://atlas.ripe.net/docs/data_struct/#v4750_dns
[2] https://en.wikipedia.org/wiki/Round-trip_delay_time
