Yes, pinging public DNS servers is bad.
Googling didn’t help me find anything.
Are there any authoritative resources from said organizations saying you shouldn’t use their servers for your persistent ping destinations?
a message of 140 lines which said:
Are there any authoritative resources from said organizations saying
you shouldn't use their servers for your persistent ping
destinations?
Why not using RIPE Anchors, which are made to be pinged (reasonably)?
I’m not looking to do the pinging myself. I have my own destinations I use. I also use the RIPE system on occasion.
Hello,
Are there any authoritative resources from said organizations saying you shouldn’t use their servers for your persistent ping destinations?
I’m not sure that an ’ authoritative resource ’ is really needed. It should be generally understood at this point in the internet’s life that networks will block / restrict some or all ICMP traffic as they need to.
Some people need a clue by four and I’m looking to build my collection of them.
Someone on Outages was nice enough to send this about someone else’s thread:
https://peering.google.com/#/learn-more/faq
“Google services, including Google Public DNS, are not designed as ICMP network testing services”
Some people need a clue by four and I’m looking to build my collection of them.
Someone on Outages was nice enough to send this about someone else’s thread:
https://peering.google.com/#/learn-more/faq“Google services, including Google Public DNS, are not designed as ICMP network testing services”
you know what you COULD do though… probe it with DNS requests, and then you know, test the service being offered, and still know that ‘the internet is not on fire’.
Right, someone could do that.
I was more here to find ammunition to show someone that they were doing something wrong than to build anything myself.
Hard to disagree with "their network, their rules", but we're talking about an entrenched,
pervasive, Internet-wide behaviorial issue.
My guess is that making ping/ICMP less reliable to the extent that it becomes unusable
wont change fundamental behavior. Rather, it'll make said "pingers" reach for another tool
that does more or less the same thing with more or less as little extra effort as possible
on their part.
And what might such an alternate tool do? My guess is one which SYN/ACKs various popular
TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a few popular
DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few tweaks, shall
we?
After all, it's no big deal to the pinger if their reachability command now exchanges
10-12 packets with resource intensive destination ports instead of a couple of packets to
lightweight destinations. I'll bet most pingers will neither know nor care, especially if
their next-gen ping works more consistently than the old one.
So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy network admins
change internet behaviour for the better? Or will it have unintended consequences such as
an evolutionary adaptation by the tools resulting in yet more unwanted traffic which is
even harder to eliminate?
Mark.
What?!? Use UDP to test the Internet? How would you even know if the
Internet was fine but some router didn't like how your packet smelled and
dropped it? 
Seriously though, if ICMP is becoming the problem this thread seems to
believe, TCP rather than UDP is probably a better judge of the
"availability of the Internet" as the remote end is going to attempt to
respond.
Though I cannot argue that lack of DNS also can indicate why Chicken
Little is perturbed.
I don't have any issues with ICMP generally, though I'm usually sending
such packets to systems and servers and networks I control or have
permission/access to.
For people that don't have access to multiple servers dotted around the
Internet, is it time for them to move away from ICMP and start using HTTP
HEAD TCP requests to well-known websites to determine if a route is
available and functioning? That's a lot more data when multiplied by a few
million queries per second, just to check that the Internet is up... but
also less likely to get filtered or throttled to the point where you get
no response, even though the sky is not falling.
Beckman
Anyone swinging a clue-by-four it going to hit Meraki real hard.
I was more here to find ammunition to show someone that they were
doing something wrong than to build anything myself.
this is just soooooooo classic. mind if i quote you?
randy
Someone once challenged me to find documentation showing that the Java
garbage collector does not (and is not supposed to) terminate
abandoned running threads. I ended up leaving that job. You can't fix
willful ignorance.
Meraki finally allowed an operator to stop this a few years ago, but it’s still the default.
Orly? 64 bytes from 8.8.8.8: icmp_seq=10937 ttl=112 time=44.408 ms
64 bytes from 8.8.8.8: icmp_seq=10938 ttl=112 time=43.480 ms
64 bytes from 8.8.8.8: icmp_seq=10939 ttl=112 time=57.839 ms
64 bytes from 8.8.8.8: icmp_seq=10940 ttl=112 time=38.816 ms
-LB
Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC
CEO
ben@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the world.”
ANNOUNCING: 6x7 GLOBAL MARITIME
FCC License KJ6FJJ
What irked me today was an equipment manufacturer. I found out because Google had some issues handling ICMP to their DNS resolvers today and some of my devices started spazzing out.
There’s no reason this manufacturer doesn’t just setup a variety their own servers to handle this, other than being lazy.
It is clear that a number of Internet users find pinging "reliable" IP addresses useful, regardless of whether it actually is or isn't, or whether it's ethical or not.
Like we have done with other public services such as NTP, perhaps it's time we developed some infrastructure for this, so that folk can have something reliable to ping that was built for purpose, and also release the Google's and Yahoo's of the world from having to bear the brunt of such.
Certainly, trying to get people to stop pinging is not going to work. Time to go with the tide, than against it.
Mark.
I've long referred to finding rules / RFCs / documents / test results / etc. as loading small 22 caliber shells for the powers that be to use for $TASK.
I specifically say 22 caliber because each one in and of itself is small and quite likely insignificant. But when there are hundreds of them fired at a single target at a rapid rate, the recipient tends to take notice and try to avoid causing such actions again.
Hard to disagree with "their network, their rules", but we're talking about an entrenched, pervasive, Internet-wide behaviorial issue.
The entrenched, pervasive, Internet-wide behavior used to be to use any convenient SMTP server to relay mail too.
The entrenched, pervasive, <something?>-wide behavior used to be to smoke on planes too.
Things change with the times.
My guess is that making ping/ICMP less reliable to the extent that it becomes unusable wont change fundamental behavior. Rather, it'll make said "pingers" reach for another tool that does more or less the same thing with more or less as little extra effort as possible on their part.
I'm curious what sort of resources Google, et al., expend responding to these types of tests.
And what might such an alternate tool do? My guess is one which SYN/ACKs various popular TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a few popular DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few tweaks, shall we?
If ~> when that happens, we'll probably start to see responses for those tests too.
After all, it's no big deal to the pinger if their reachability command now exchanges 10-12 packets with resource intensive destination ports instead of a couple of packets to lightweight destinations. I'll bet most pingers will neither know nor care, especially if their next-gen ping works more consistently than the old one.
Though I wouldn't be surprised to learn that it might be easier for Google to respond to a full / fat / heavy weight HTTP GET / POST that includes an actual search than it is to respond to an ICMP ping. As if their network magic is a LOT more efficient / better scaled for HTTP than it is for ICMP. <ASCII shruggie>
So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy network admins change internet behaviour for the better? Or will it have unintended consequences such as an evolutionary adaptation by the tools resulting in yet more unwanted traffic which is even harder to eliminate?
Time will tell.
(as posted to outages)
It is clear that a number of Internet users find pinging “reliable” IP
addresses useful, regardless of whether it actually is or isn’t, or
whether it’s ethical or not.Like we have done with other public services such as NTP, perhaps it’s
time we developed some infrastructure for this, so that folk can have
something reliable to ping that was built for purpose, and also release
the Google’s and Yahoo’s of the world from having to bear the brunt of such.Certainly, trying to get people to stop pinging is not going to work.
Time to go with the tide, than against it.
Do a DNS query. You don’t even have to randomise the id number, just query for something that will have a small set of results (so, not the root) and ensure checking is disabled. For 8.8.8.8, I’m guessing “dns.google” is probably an excellent target.
If you wanted something generic, what about a PTR query for something in 10/8, directed at the AS112 project? That’s pretty much the sinkhole that expects that kind of unwanted traffic…
I bet that within a gnat’s crotchet you’ll find systemd has adopted that as a special “liveness” command or something.
M