1.1.1.1 intermittently working

Zero Trust 1.1.1.1
1

Hi, since friday we are experiencing loads of packet loss directed both to 1.1.1.1 and 1.0.0.1.
it happens just a few minutes ago that pinging 1.1.1.1 returned this:

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=4.73 ms
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 1 received, 85% packet loss, time 6112ms
rtt min/avg/max/mdev = 4.736/4.736/4.736/0.000 ms

while now it seems working as usual.
we are based in italy and both our local networks and servers(geographically located in a different area) are experiencing issues reaching your dns sporadically since friday.
considering no issue is stated in cloudflare status regarding 1.1.1.1 i think that maybe you didn’t noticed it as we did.
thank you in advance for any notice regarding this issue

2

I can see Rome is currently being re-reouted.

Can you run

dig chaos txt id.server +short @1.1.1.1

A traceroute or MTR would also be more helpful to identify possible issues on the route.

3 
~$ dig chaos txt id.server +short @1.1.1.1                         
"ZRH"

same response both from my pc and server farm.

attaching mtr screenshot: atm it is actually almost working, but since last message we have experienced at least a couple of moments where it was almost unreachable for around a minute
Schermata da 2020-09-21 21-12-03

4

Please note that Zurich, which is the node replying, is a bit nearer than rome from here, in Milan. I cannot exclude we are used to be served by Zrh and not from Rome, if geographical distance matters

5

What is your ISP? I am from Italy as well, it’s been a few days that requests have been re-routed. It was Milan and now Rome. My Enterprise domains still go to AMS despite MXP working (apparently).

6

My workplace is experiencing the same issues with 1.1.1.1 and 1.0.0.1. Our ISP is Cox. DNS requests timing out or taking longer than expected. This started happening Sunday morning around 1am CDT.

traceroute to 1.0.0.1 (1.0.0.1) from 167.224.82.3, 30 hops max, 40 byte packets
1 * * *
2 100.121.188.2 (100.121.188.2) 2.949 ms 2.881 ms 3.078 ms
3 68.1.5.140 (68.1.5.140) 7.253 ms 9.974 ms 15.683 ms
4 141.101.74.82 (141.101.74.82) 10.762 ms 10.968 ms 7.390 ms
5 1.0.0.1 (1.0.0.1) 6.859 ms 6.482 ms 6.490 ms

traceroute to 1.1.1.1 (1.1.1.1) from 167.224.82.3, 30 hops max, 40 byte packets
1 * * *
2 100.121.188.2 (100.121.188.2) 2.882 ms 3.734 ms 2.837 ms
3 68.1.5.140 (68.1.5.140) 8.687 ms 7.489 ms 7.276 ms
4 141.101.74.82 (141.101.74.82) 7.262 ms 7.031 ms 7.407 ms
5 * * *
6 * * *
7 * * *
8 * *^C

microsoft.com
Server: one.one.one.one
Address: 1.1.1.1

DNS request timed out.
timeout was 2 seconds.
*** Request to one.one.one.one timed-out

xbox.com
Server: one.one.one.one
Address: 1.1.1.1

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: had to edit this as new users can only post two links x b o x . c o m
Addresses: 40.76.4.15
40.112.72.205
104.215.148.63
40.113.200.201
13.77.161.179

7

This seems more something that the ISP messed up, capturing the 1.1.1.1 traffic. Normally 1.0.0.1 and 1.1.1.1 are served together. Either open a ticket with Cloudflare or contact Cox.

To contact Cloudflare Customer Support, login & go to https://dash.cloudflare.com/?account=support and select get more help. If you receive an automatic response that does not help you, please reply and indicate you need more help.

8

Thank you for your reply. I currently have a ticket open with both.

9

we are experiencing the same issue with 4 different isp, i think i need to open a ticket with flare

10

The issue appears to have been with our primary ISP. 1.1.1.0/24 was preferring our secondary ISP but I am wondering if there was an issue on the return path. Everything is working as expected now.

11

yes, confirmed, since yesterday we didn’t experience any loss