Considerably slower in the UK/EU


#1

Hi,

I’m finding 1.1.1.1/1.0.0.1 much slower than Google’s, as in a delay by seconds rather than milliseconds. Here’s my traceroute:

1     1 ms     5 ms     4 ms  BTHUB [192.168.1.254]
2     *        *        *     Request timed out.
3     *       20 ms    13 ms  31.55.186.181
4    11 ms    13 ms     9 ms  31.55.186.188
5    19 ms    35 ms    14 ms  core3-hu0-6-0-3.faraday.ukcore.bt.net [195.99.127.194]
6    10 ms    23 ms    26 ms  peer1-xe-11-0-0.faraday.ukcore.bt.net [213.121.193.169]
7    10 ms    21 ms    14 ms  195.99.126.1
8    36 ms    45 ms    23 ms  1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]

And with 1.0.0.1:

  1     3 ms     1 ms     4 ms  192.168.1.254
  2     *        *        *     Request timed out.
  3     *       15 ms     8 ms  31.55.186.177
  4    16 ms     8 ms     8 ms  31.55.186.184
  5     9 ms     8 ms     9 ms  195.99.127.94
  6    11 ms    12 ms    12 ms  peer1-xe0-0-1.faraday.ukcore.bt.net [213.121.193.193]
  7     9 ms    15 ms     9 ms  195.99.126.1
  8    14 ms    18 ms    22 ms  1dot1dot1dot1.cloudflare-dns.com [1.0.0.1]

Anything looking weird here?

Thanks


#2

Just for kicks, how about just a dig @1.1.1.1 command and check the response time? Do the same for @8.8.8.8


#3

Hey, I’m on Windows so I set up Debian subsystem on Windows. Here’s what I got back.

For dig @1.1.1.1:

; <<>> DiG 9.10.3-P4-Debian <<>> @1.1.1.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56728
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       1759    IN      NS      a.root-servers.net.
.                       1759    IN      NS      b.root-servers.net.
.                       1759    IN      NS      c.root-servers.net.
.                       1759    IN      NS      d.root-servers.net.
.                       1759    IN      NS      e.root-servers.net.
.                       1759    IN      NS      f.root-servers.net.
.                       1759    IN      NS      g.root-servers.net.
.                       1759    IN      NS      h.root-servers.net.
.                       1759    IN      NS      i.root-servers.net.
.                       1759    IN      NS      j.root-servers.net.
.                       1759    IN      NS      k.root-servers.net.
.                       1759    IN      NS      l.root-servers.net.
.                       1759    IN      NS      m.root-servers.net.

;; Query time: 10 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Apr 01 21:51:39 DST 2018
;; MSG SIZE  rcvd: 431

and 8.8.8.8:

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59064
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       230247  IN      NS      i.root-servers.net.
.                       230247  IN      NS      c.root-servers.net.
.                       230247  IN      NS      m.root-servers.net.
.                       230247  IN      NS      k.root-servers.net.
.                       230247  IN      NS      g.root-servers.net.
.                       230247  IN      NS      f.root-servers.net.
.                       230247  IN      NS      l.root-servers.net.
.                       230247  IN      NS      j.root-servers.net.
.                       230247  IN      NS      b.root-servers.net.
.                       230247  IN      NS      h.root-servers.net.
.                       230247  IN      NS      e.root-servers.net.
.                       230247  IN      NS      a.root-servers.net.
.                       230247  IN      NS      d.root-servers.net.

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 01 21:54:38 DST 2018
;; MSG SIZE  rcvd: 239

Perhaps the required restart fixed the issue?


#4

Another weird issue I’m getting is that on my device using 1.1.1.1/1.0.0.1 I can’t reach hxxps://archive.li however on my device using 8.8.8.8/8.8.4.4 I can reach it fine. Even weirder is that running tracert on both shows timeouts. The only difference is that the former device hops through linx-224.retn.net -> x.y.z.ams.nl.retn.net -> gw-serverius.retn.net -> etc whereas the latter device connects through stream-internet.net.

Device 1 (Cloudflare DNS):

  1    10 ms     1 ms     2 ms  BTHUB [192.168.1.254]
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     9 ms    11 ms    13 ms  31.55.186.176
  5     9 ms    16 ms     8 ms  core3-hu0-16-0-1.faraday.ukcore.bt.net [195.99.127.196]
  6    12 ms    12 ms    11 ms  peer2-et-7-0-0.slough.ukcore.bt.net [109.159.252.112]
  7    10 ms    10 ms    13 ms  linx-224.retn.net [195.66.224.193]
  8    18 ms    17 ms    17 ms  ae2-9.rt.tc2.ams.nl.retn.net [87.245.233.97]
  9    20 ms    20 ms    25 ms  gw-serverius.retn.net [87.245.246.59]
 10    28 ms    24 ms    21 ms  185.8.179.22
 11    21 ms    24 ms    20 ms  185.8.179.27
 12   115 ms    24 ms    35 ms  185.53.163.41
 13 [timeouts until 30]

Device 2 (Google DNS):

$ traceroute archive.li
 1?: [LOCALHOST]                      pmtu 1500
 1:  bthub                                                 3.951ms
 1:  bthub                                                 5.770ms
 2:  bthub                                                 3.382ms pmtu 1492
 2:  no reply
 3:  no reply
 4:  31.55.186.176                                        24.566ms asymm  6
 5:  195.99.127.110                                       13.614ms asymm  6
 6:  peer2-et3-0-0.slough.ukcore.bt.net                   11.621ms asymm  7
 7:  mil-cr01-te6-2.lnd.stream-internet.net               13.794ms
 8:  tct-cr02-ae2.192.ams.stream-internet.net             29.997ms
 9:  anc-cr03-ae5.131.ff.stream-internet.net              64.132ms asymm 16
10:  radio-cr01-ae4.135.hel.stream-internet.net           65.008ms asymm 15
11:  mmon-cr01-be3.78.spb.stream-internet.net             66.810ms
12:  a433-cr01-be1.78.msk.stream-internet.net             64.962ms asymm 10
13:  m9-cr05-ae9.77.msk.stream-internet.net               64.031ms asymm 11
14:  212.188.11.170                                       67.405ms asymm 15
15: [timeouts until 30]

#5

if you dig @1.1.1.1 and @8.8.8.8 for archive.li do you get the same host names/ IPs in response?


#6

Is this what you mean? Sorry I’m linux noob

$ dig archive.li @1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> archive.li @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62859
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1536
;; QUESTION SECTION:
;archive.li.                    IN      A

;; ANSWER SECTION:
archive.li.             300     IN      A       146.0.75.2

;; Query time: 22 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Apr 01 23:54:35 DST 2018
;; MSG SIZE  rcvd: 55

$ dig archive.li @8.8.8.8

; <<>> DiG 9.10.3-P4-Debian <<>> archive.li @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52835
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;archive.li.                    IN      A

;; ANSWER SECTION:
archive.li.             299     IN      A       194.1.239.252

;; Query time: 28 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 01 23:54:44 DST 2018
;; MSG SIZE  rcvd: 55

#7

Hmm… and i get a completely different answer from 8.8.8.8. My guess is they are using some kind of EDNS Client-Subnet by default and at least one fo the addresses (the one we are returning for you… isn’t valid or reachable from your host.

dig archive.li @8.8.8.8

; <<>> DiG 9.11.1 <<>> archive.li @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3652
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;archive.li. IN A

;; ANSWER SECTION:
archive.li. 299 IN A 54.36.225.114

;; Query time: 125 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Apr 01 18:08:34 CDT 20


#8

You certainly know more than I do about this, haha. All I can confirm is that running that command on both the device using 1.1.1.1 and the device using 8.8.8.8 return the same for dig archive.li @8.8.8.8. They are both on the same network. The router uses the same ISP DNS (the router is ISP-supplied and as such doesn’t allow the DNS to be configured).


#9

So sorry to bump this but is there any real solution currently?


#10

Can you run dig @1.1.1.1 id.server ch txt and paste the results? I think it is something on their end… we can try to forward to domain owner, but it appears the response we’re getting is ‘correct’.