Authoritative Resources for Public DNS Pinging

Mike Hammett nanog at ics-il.net
Fri Feb 11 12:27:26 UTC 2022


The device that caused this whole conversation has failover functionality. Both interfaces ping an FQDN (that resolves to 8.8.8.8 and 1.1.1.1, with the device only latching on to one of those). If any of those meet the failure threshold, that interface is taken out of the traffic flow. 




So because someone else built a device (without a meaningful configuration to set otherwise), 8.8.8.8 went down for ICMP, and thus Internet ports began flapping, despite the Internet as a whole working just fine. 




----- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

----- Original Message -----

From: "Tom Beecher" <beecher at beecher.cc> 
To: "Lady Benjamin Cannon of Glencoe" <lb at 6by7.net> 
Cc: "NANOG Operators' Group" <nanog at nanog.org> 
Sent: Thursday, February 10, 2022 12:27:03 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 




Seems way easier than literally everything else being proposed to me, am I missing something? 





I guess it depends on what the actual problem trying to be solved is. 


If I understand it correctly, the OG issue was someone (who was not Google) building some monitoring around the assumption of the idea that ICMP echo-request/reply to 8.8.8.8 would always be available. Google decided to make a change so that assumption was now false. 

The actual problem here has nothing to do with how Google handles (or doesn't handle) ICMP towards their servers. The issue is that people have made poor assumptions about how they structured monitoring, and learned some lessons about that. Suggesting that Party B should do something because Party A made poor decisions is questionable, even if it is 75% of what we do in this world. 







On Thu, Feb 10, 2022 at 12:52 PM Lady Benjamin Cannon of Glencoe < lb at 6by7.net > wrote: 

<blockquote>


Seems way easier than literally everything else being proposed to me, am I missing something? 


-LB 

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 
6x7 Networks & 6x7 Telecom, LLC 
CEO 
ben at 6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the world.” 
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ 




<blockquote>

On Feb 9, 2022, at 12:15 PM, Tom Beecher < beecher at beecher.cc > wrote: 



<blockquote>
Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it? 

</blockquote>



Seems like a lot of overhead for zero benefit. 


On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe < lb at 6by7.net > wrote: 

<blockquote>


ok that’s amazing. 


RFC1149 amazing. 




Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it? 


Who owns 69.69.69.69 - collab? 


How naff is this? 



-LB 

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 
6x7 Networks & 6x7 Telecom, LLC 
CEO 
ben at 6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the world.” 
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ 





<blockquote>

On Feb 9, 2022, at 9:38 AM, Jay Hennigan < jay at west.net > wrote: 


On 2/8/22 23:42, Stephane Bortzmeyer wrote: 


<blockquote>
The only problem is the less friendly IP address (although this will 
be less and less a problem with IPv6, since 2001:4860:4860::8888 is 
not really friendly). 

</blockquote>

Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-) 

Please don't use it for an IPv6 ping target, thanks. 

-- 
Jay Hennigan - jay at west.net 
Network Engineering - CCIE #7880 
503 897-8550 - WB6RDV 

</blockquote>


</blockquote>

</blockquote>


</blockquote>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220211/72ada856/attachment.html>


More information about the NANOG mailing list