Authoritative Resources for Public DNS Pinging
Grant Taylor
gtaylor at tnetconsulting.net
Wed Feb 9 05:24:44 UTC 2022
On 2/8/22 4:13 PM, Mark Delany wrote:
> 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.
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220208/42579d57/attachment.bin>
More information about the NANOG
mailing list