Tell HN: 1.1.1.1 appears to be down Cloudflare's DNS server doesn't appear to be working. |
Tell HN: 1.1.1.1 appears to be down Cloudflare's DNS server doesn't appear to be working. |
This is a reasonable test of the DNS service on 1.1.1.1:
$ dig @1.1.1.1 www.cloudflare.com A
; <<>> DiG 9.20.4-3ubuntu1.1-Ubuntu <<>> @1.1.1.1 www.cloudflare.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34112
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.cloudflare.com. IN A
;; ANSWER SECTION:
www.cloudflare.com. 36 IN A 104.16.123.96
www.cloudflare.com. 36 IN A 104.16.124.96
;; Query time: 39 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Jul 14 23:32:57 BST 2025
;; MSG SIZE rcvd: 79
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
From 141.101.70.116 icmp_seq=1 Time to live exceeded
64 bytes from 1.1.1.1: icmp_seq=2 ttl=50 time=126 ms
The service required is DNS not ping. Test the service.
Signed, someone who was using 1.1.1.1 as their DNS server and hadn't configured a fallback
Many home routers can resolve starting from root or if you must then: 1.1.1.1, 8.8.8.8, 8.8.4.4 will get you started. You might consider 9.9.9.9 and there are quite a few others.
I never, ever, ever, recommend using ISP provided DNS unless you know how they are configured. The anycast jobbies at least publish a policy of some sort.
The article here is about a loss of DNS service and proves it with ping. That is wrong and you know it. Diagnosing the fault should involve ping but that is not how you conclusively prove DNS is not working.
To be honest you cannot conclusively prove anything in this game but you can at least explore the problem space effectively from your perspective with whatever you have access to. I happen to have a RIPE ATLAS probe at work with a gigantic amount of credit, so I could probably get that system to test Cluodflare DNS from a lot of locations.
If you present to a doctor with some mild but alarming chest pains, I'd hope they wouldn't just look at you and prescribe a course of leeches. A stethoscope is a good start (ICMP) but an ECG (dig) is better. That analogy might need some work 8)
It does seem to be responding to ping again and since my edit above, the first packet is being responded to so I suspect a NOC is having a fun old time somewhere.
You do need to test the service properly. I do this malarky for a living 8) I'm ever so popular with kiddies and their gaming related fixation with ping times ...
ping 1.1
$ ping 127.0.0.1
I run a lot of pfSense boxes and they (and OPNSense) have a pinger daemon to test connectivity which is really useful for multi-link routing. Bad idea for single links because you add an extra thing to fail. On a router with multiple internet links they are handy. You mostly ping known "reasonably stable" anycast addresses - they are the best option and usually end up being DNS servers - 1.1.1.1, 8.8.8.8, 8.8.4.4 etc are all good candidates.
their bgp monitoring found it :)
It lets you send encrypted DNS queries out onto the Internet to any service that supports it (there are many, and you can configure it to use multiple for redundancy), while serving "normal" DNS in your internal network.
It's also trivial to import a blocklist of domains with cron, from hagezi/dns-blocklists for example.
If you have no interest in setting something like this up, at least ensure that you have manually configured or are pushing _multiple_ DNS servers via DHCP. It sucks that 1.1.1.1 went down but it shouldn't matter, there's a reason every operating system supports configuring multiple DNS servers.
For anyone in the EU I can recommend https://www.dns0.eu/ or Mullvad, but at the very least if you're using Cloudflare and don't care about privacy, set 8.8.8.8 as your secondary DNS.
I agree with you, though.
PING 1.1.1.1 (1.1.1.1): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 ^C --- 1.1.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss
Does anyone have a good backup for CF? I certainly don't want to rely on my ISP, has they've done MITM before.
Maybe there is noticeable difference?
1.0.0.1 is also down.
>
> Use UDP datagrams instead of ICMP ECHO.
Rules out router control plane protection mechanisms specifically for ICMP echo rate limiting.
Your ISP publishes T&Cs and a privacy policy too.
Furthermore, your ISP’s resolver is probably in your ISP’s network, so your queries don’t have to go out through peering/transit.
Drayteks have a lot of options built in, including a funky DNS implementation. I've personally largely dumped them for rather more complicated jobbies but they are still very capable.
I'm just a consultant who's been mucking about with networks for 30+ years. I'm sure your highly paid technicians will teach granddad a thing or two.
I note you switch between the OSI seven layer model and the ARPA four layer one with gay abandon. What are you doing at layers five and six?
We are all engineers here (whether chartered or not). The big question is - "Is the service up"? The service is DNS.
We go to the toolbox as any engineer does and use a tool for the job. I can hammer a screw into a wall or use a screwdriver - both will work but one will work effectively. I'll use dig but I imagine that a Windows jockey will use nslookup - both will work.
dig/nslookup fail? OK, now we look at connectivity issues - that's when ping comes in. However we do not own the DNS service and we cannot know that it is now dropping pings for some reason. Then we might play games with packet generators and Wireshark to try and determine what is going on. However, we do not run that failing service and all we can conclusively ... conclude is that for us, it is not working.
That's a far cry from Cloudflare DNS is down for everyone. We can only conclude that Cloudflare DNS is not working for me.
In regard to an endpoint out of our control, once we demonstrate we cannot connect to it or serious connectivity problems in general, "is the service (that the endpoint provides) up?" is not a question that we need or should be trying to answer at that point.
That's cool though, if you want, you can just keep doing digs to an endpoint that is degraded from a network perspective, while I keep trying to troubleshoot why we have packet loss to the endpoint..
Connectivity over ICMP / UDP / TCP, DNS resolution, Autonomous System path, MPLS circuit, IPv4 / IPv6 routing, circuit to endpoint latency, per hop firewall configuration, device packet security configuration, jitter, MTU, and probably some other things I'm forgetting.
A carpenter knows their tools.
Quite, and they also know when to use them effectively.
I have no idea what "Autonomous System path" is but it looks like someone searching terms. An Autonomous System is a BGP thing.
You say "I'm forgetting" and I say - you don't have much skin in this game.
I've spent roughly 30 years getting to grips with this stuff.
My point stands, which is: There are a lot of capabilities in these tools that should not be overlooked or dismissed.
In addition, reachability of the service is one of the things you would note with said tools as you work your way through the stack. You can even use MTR to see if the DNS server is holding port 53 open.
Is there any documentation or contract that says this shall always respond to ICMP traffic?
Isn't it possible ICMP is being filtered but not DNS?
Imagine if they had misconfigured their DNS, did a ping to 1.1.1.1, and decided 1.1.1.1 DNS is obviously down despite it only potentially being ICMP traffic.
Imagine someone having issues with a web server so they show their proof of the web server being down by showing it won't connect with SMTP traffic. This is the same concept with showing a ping.