4 ms·

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 reasonabl

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.

landofyoshi 1y ago
Well, typically 1.1.1.1 responds to pings. So it not responding is an indication that it's no longer working.
- captainkrtek 1y ago
  Or that it started filtering ICMP. If DNS works then it’s doing its job
  - Macha 1y ago
    Though the reason everyone started pinging is because DNS wasn't working
- gerdesj 1y ago
  ... or a change of policy, funky firewall or whatever. 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 ...
forbiddenlake 1y ago
This is all true, but DNS was also down. Signed, someone who was using 1.1.1.1 as their DNS server and hadn't configured a fallback
- gerdesj 1y ago
  As a punishment: Compile and install ISC BIND from source and configure it 8) 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.
  - Tijdreiziger 1y ago
    Which home routers can resolve recursively instead of needing upstream DNS? I’ve never seen this across many brands of home routers. 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.
    - gerdesj 1y ago
      "Which home routers ..." 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.
- graton 1y ago
  You weren't alone. I was actually using 1.1.1.2 and then quickly added 8.8.8.8 once I figured out the issue.
indigodaddy 1y ago
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.
- gerdesj 1y ago
  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)
  - indigodaddy 1y ago
    If you have a demonstrated network/connectivity problem to an endpoint that provides DNS, then DNS is down (or at the very least degraded) for you. If a functionality of layer 3 is not working, should we expect layer 4 to work, and keep looking into aspects of layer 4 and/or layer 7, or would it make more sense to keep troubleshooting the layer 3 issue?? Any entry level NOC Technician would know at this point that doing digs/queries to the endpoint would not necessarily be meaningful when we have an underlying connectivity/network problem that is the likeliest main contributor to the issue.
Calzifer 1y ago
> The service required is DNS not ping. ping 1.1 is short and easy to remember. Since I'm not using Cloudflare DNS, ping is actually the service I require :D
- gerdesj 1y ago
  In which case: $ ping 127.0.0.1 Provided you have a working IP stack, your ping service requirement is met admirably 8) 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.
alexktz 1y ago
Praise smokeping https://imgur.com/a/YGYl0Oy https://imgur.com/a/YGYl0Oy

landofyoshi 1y ago

Well, typically 1.1.1.1 responds to pings. So it not responding is an indication that it's no longer working.

captainkrtek 1y ago
Or that it started filtering ICMP. If DNS works then it’s doing its job
- Macha 1y ago
  Though the reason everyone started pinging is because DNS wasn't working
gerdesj 1y ago
... or a change of policy, funky firewall or whatever. 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 ...

forbiddenlake 1y ago

This is all true, but DNS was also down. Signed, someone who was using 1.1.1.1 as their DNS server and hadn't configured a fallback

gerdesj 1y ago
As a punishment: Compile and install ISC BIND from source and configure it 8) 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.
- Tijdreiziger 1y ago
  Which home routers can resolve recursively instead of needing upstream DNS? I’ve never seen this across many brands of home routers. 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.
  - gerdesj 1y ago
    "Which home routers ..." 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.
graton 1y ago
You weren't alone. I was actually using 1.1.1.2 and then quickly added 8.8.8.8 once I figured out the issue.

indigodaddy 1y ago

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.

gerdesj 1y ago
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)
- indigodaddy 1y ago
  If you have a demonstrated network/connectivity problem to an endpoint that provides DNS, then DNS is down (or at the very least degraded) for you. If a functionality of layer 3 is not working, should we expect layer 4 to work, and keep looking into aspects of layer 4 and/or layer 7, or would it make more sense to keep troubleshooting the layer 3 issue?? Any entry level NOC Technician would know at this point that doing digs/queries to the endpoint would not necessarily be meaningful when we have an underlying connectivity/network problem that is the likeliest main contributor to the issue.

Calzifer 1y ago

> The service required is DNS not ping. ping 1.1 is short and easy to remember. Since I'm not using Cloudflare DNS, ping is actually the service I require :D

gerdesj 1y ago
In which case: $ ping 127.0.0.1 Provided you have a working IP stack, your ping service requirement is met admirably 8) 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.

alexktz 1y ago

Praise smokeping https://imgur.com/a/YGYl0Oy https://imgur.com/a/YGYl0Oy