Tell HN: 1.1.1.1 appears to be down

DNS shouldn't be tested with ICMP. Try dig or nslookup instead. ICMP echo request/reply may help to decide reachability and nothing more.

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

[EDIT]:

  $ 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

So ping fails a bit (and then works - firewall) but DNS works.

The service required is DNS not ping. Test the service.

By using ping or MTR, they are testing general connectivity to an endpoint, doesn't matter what service is in play. For example, if you are getting significant packet loss on the endpoint itself in the output of an MTR, then that IS indicative of a network/route/connectivity problem, somewhere along the route (could still be an endpoint issue but definitely not always). The service in question doesn't matter much at that point. Whether the service itself is healthy or not, you are still troubleshooting the overarching issue presented by the bad ping/MTR.

ping and mtr only test one thing. I have saws, drills, routers (lol), planes, screwdrivers, hammers and more in my workshop. To be fair a drill driver and a hammer get a lot of jobs done! However, I will get the impact driver out or a fret saw with a very fine blade as the job requires.

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)

Ping and MTR are actually several different tools spread across them.

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.

"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.