Re: Authoritative Resources for Public DNS Pinging

[Tom Ivar Helbekkmo via NANOG]

Lady Benjamin Cannon of Glencoe  writes:

> What else is like that and easy to remember and isn’t 1.1.1.1 ?

1.1  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

What's the most resource efficient way to deploy a ping destination? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mike Hammett"  
To: nanog@nanog.org 
Sent: Tuesday, February 8, 2022 11:56:44 AM 
Subject: Authoritative Resources for Public DNS Pinging 


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? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/12/22 16:43, Mike Lewinski via NANOG wrote:


Yes, I'm sure it was.


Then probably rhymes with the days of "admin/admin".

If they have been pushing out security and OS updates since then, and 
still keep 1.1.1.1 coded, that is purely their fault.


Mark.

RE: Authoritative Resources for Public DNS Pinging

[Mike Lewinski via NANOG]

> Do you know if this was codified prior to 1.1.1.1 being taken over by 
> Cloudflare?

Yes, I'm sure it was.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/11/22 14:27, Mike Hammett wrote:

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.


Pretty amazing, isn't it?

Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/11/22 22:43, Mike Lewinski via NANOG wrote:


On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband 
interface by default, and it is apparently not user modifiable. So, not only can these 
devices never use 1.1.1.1 for name resolution, but attempts to determine "is the 
circuit up" by pinging it will always return bad information. To really pour salt on 
the wound, this device has no physical outbound interface (likely why the UI doesn't 
allow changing it).

Bug report filed. I don't really want to use it for either purpose, but 
hopefully a fix saves someone else the headache. And it really chaps my  
when public addresses get used this way.


Do you know if this was codified prior to 1.1.1.1 being taken over by 
Cloudflare?


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/11/22 16:58, Jon Lewis wrote:



I have to admit, I haven't read most of this thread, but I am well 
aware of the issues with both end users and "routers" / firewalls 
pinging 8.8.8.8 as a means of verifying "that path to the Internet is 
working".  I know GOOG doesn't appreciate the amount of ICMP echo 
requests their 8.8.8.8 instances receive, and that at various 
times/places, that ICMP traffic is/has been policed by GOOG.


So...here's a pair of "what if"s:

What if instead of pinging 8.8.8.8, all these things using it to "test 
the Internet" sent it DNS requests instead?  i.e.

GOOG=$(dig +short @8.8.8.8 google.com)
if [ -z "$GOOG" ] ; then
  echo FAIL
fi Would that make things better or worse for GOOG (Trading lots more 
DNS requests for the ICMP echo requests)?


Could work for devices, but more difficult for Jane.




8.8.8.8 is already anycasted.  What if each large ISP (for whatever 
definition of large floats your boat) setup their own internal 
instance(s) of 8.8.8.8 with a caching DNS server listening, and 
handled the traffic without bothering GOOG?  For users using 8.8.8.8 
as a lighthouse, this would change the meaning of their test...i.e. a 
response means their connection to their ISP is up, and the ISP's 
network works at least enough to reach an internal 8.8.8.8, but the 
question of their connectivity to the rest of the Internet would be 
unanswered.


Something tells me Google (or Cloudflare, or Quad9, or e.t.c.) would not 
consider that a good thing, for them :-).


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/11/22 15:33, Tom Beecher wrote:


I respectfully strongly disagree on 'need'.

Let's perform a thought experiment. Assert that 8.8.8.8 was expressly 
codified by Google to be a designated ICMP endpoint, and that for 100% 
of ICMP echo requests they receive, they guarantee an echo-reply will 
be sent. There are countless reasons , even with that (unreasonable) 
assumption of 100% uptime of the endpoint, that echo-requests may not 
reach them, or that echo-replies may be sent but not reach the 
originating source. Extend this idea even further. Assert that it is 
now not just Google running it, and the largest networks in the world 
all agree to anycast it from their networks.Assert is still guaranteed 
to respond to 100% if all echo requests it receives, wherever it 
receives. ( An even more unreasonable assertion than before!) There 
are STILL countless reasons why an endpoint may, at times, have that 
simple ICMP check fail.


The prediciate assumption that "pinging one destination is a valid 
check that my internet works' is INCORRECT. There is no magical 
unicorn that could be built that could make that true, and 'they're 
gonna do it anyways' is a poor excuse to even consider it.


This is a mistake many of us have made. I'll openly admit I made it 20 
years ago. Like someone on the outages list I think mentioned, I had 
built a couple SLA checks that triggered some routing changes to occur 
based on their status, and I thought I was super hot shit. Until I had 
to drive an hour through a blizzard to bring my routers back up after 
my incorrect assumptions knocked my entire company (an ISP) offline. 
Sometimes these are lessons people need to learn, but it's also 
helpful to point out to others why what they are trying to do is a bad 
idea so they can( if they chose to) learn from our prior mistakes.


I said "liveliness detection", not that "is the Internet working?".

The most basic thing is to check that the link between your device and 
your ISP is working, and a simple ping (of 8.8.8.8, nowadays) is 
typical, either by hand, or by your CPE. It does not guarantee that the 
rest of the Internet is alive, but it does tell you that if there is a 
problem further upstream, it's not yours, but likely either your ISP's, 
or the remote network you are trying to reach.


There is a need for that. It just so happens that 8.8.8.8 fills that 
need, at present. If 8.8.8.8 goes away, folk will find something else to 
use for first-line liveliness detection.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[sronan]

Usage of 1.1.1.1 has been widespread amongst wireless controllers for a very 
long time, as an address for their captive portals.

Shane


> On Feb 11, 2022, at 3:44 PM, Mike Lewinski via NANOG  wrote:
> 
> On a related note, I just discovered a NID that has 1.1.1.1 assigned to the 
> outband interface by default, and it is apparently not user modifiable. So, 
> not only can these devices never use 1.1.1.1 for name resolution, but 
> attempts to determine "is the circuit up" by pinging it will always return 
> bad information. To really pour salt on the wound, this device has no 
> physical outbound interface (likely why the UI doesn't allow changing it).
> 
> Bug report filed. I don't really want to use it for either purpose, but 
> hopefully a fix saves someone else the headache. And it really chaps my  
> when public addresses get used this way.

RE: Authoritative Resources for Public DNS Pinging

[Mike Lewinski via NANOG]

On a related note, I just discovered a NID that has 1.1.1.1 assigned to the 
outband interface by default, and it is apparently not user modifiable. So, not 
only can these devices never use 1.1.1.1 for name resolution, but attempts to 
determine "is the circuit up" by pinging it will always return bad information. 
To really pour salt on the wound, this device has no physical outbound 
interface (likely why the UI doesn't allow changing it).

Bug report filed. I don't really want to use it for either purpose, but 
hopefully a fix saves someone else the headache. And it really chaps my  
when public addresses get used this way.

Re: Authoritative Resources for Public DNS Pinging

[Grant Taylor via NANOG]

On 2/11/22 7:58 AM, Jon Lewis wrote:
8.8.8.8 is already anycasted.  What if each large ISP (for whatever 
definition of large floats your boat) setup their own internal 
instance(s) of 8.8.8.8 with a caching DNS server listening, and handled 
the traffic without bothering GOOG?


I've pontificated doing this.  On one hand I think it's a neat technical 
solution.  On the other hand I think how ... displeased I would be if 
someone were to anycast one of my services without my knowledge, much 
less consent for them to do so.  Thus I've never done it where I had a 
choice.


I believe that anycasting resources from another organization /without/ 
their consent is a hard fail and non-starter.  Independent of how pure 
the intentions are.


For users using 8.8.8.8 as a lighthouse, this would change the meaning 
of their test...i.e. a response means their connection to their ISP is 
up, and the ISP's network works at least enough to reach an internal 
8.8.8.8, but the question of their connectivity to the rest of the 
Internet would be unanswered.


I say "where I had a choice" because I have anycasted 8.8.8.8 (for ICMP 
and DNS) in an offline lab ~> D.R. exercise environment /explicitly/ 
because other systems therein had been configured to test reach ability 
to 8.8.8.8 et al.  Thus my hand was forced /inside/ the D.R. environment.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authoritative Resources for Public DNS Pinging

[Kord Martin]

On 2022-02-11 10:11 a.m., Mike Hammett wrote:
A system always checking to see if "Internet" is up is different than 
"I think something is wrong, let me check".


Yeah. I've had ping tests fail in false-positive and false-negative 
scenarios and the take away isn't that there IS a problem, but rather an 
investigation should probably take place. I don't think anybody here is 
trying to argue that pings (or DNS lookups) are an infallible 
reachability index for "the internet".



When it comes to customers, ping tests are a non-issue because the 
complaint is normally that YouTube, Facebook, or whatever service isn't 
available and therefore the "internet is down". At some point you have 
to weight the cost/benefit of explaining to customers that the internet 
is a large collection of interconnected networks and not some "cloud" 
that we tap into. It is a series of tubes after all.



K

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Huh


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.






> On Feb 11, 2022, at 09:10, Tom Beecher  wrote:
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> To be fair, I don't think this is unique to this community. Plenty of 
> conversations on the IETF lists that are fundamentally the same. ( Proposals 
> to change X or implement standard Y to solve something that is already 
> solvable with current tech and standards. ) Really it's just the complexity 
> of the existing solution that's different. :) 
> 
> On Fri, Feb 11, 2022 at 9:51 AM james.cut...@consultant.com 
>  wrote:
> On Feb 11, 2022, at 8:33 AM, Tom Beecher  wrote:
>> 
>> The prediciate assumption that "pinging one destination is a valid check 
>> that my internet works' is INCORRECT. There is no magical unicorn that could 
>> be built that could make that true, and 'they're gonna do it anyways' is a 
>> poor excuse to even consider it. 
>> 
> 
> The predicate assumption that unsuccessful pinging one destination is a valid 
> check that my internet DOES NOT work' is  ALSO INCORRECT. Still no magical 
> unicorn. 
> 
> I am disappointed but not surprised to see this discussion on NANOG. 
> Encouraging Users to use a tool (that is often ignored by the hardware 
> targeted) by providing a non-revenue-creating special target does not make 
> business sense.
> 
> An allied issue is educating ‘Users’ about traceroute AKA sequential ping 
> with TTL progression:
> 
>   •  Seeing missing or excessively long traceroute results from 
> intermediate nodes does NOT indicate a real problem, especially when the 
> target node is reachable with acceptable delay. 
> 
> I’ve lost count of my replies on user forums explaining this issue, even to 
> otherwise well educated users. 
> 
> To be blunt, browsing to amazon.com, apple.com or another vendor site is a 
> simple and easy to teach Internet aliveness check and, at least, offers the 
> chance for the targeted vendor site to receive revenue from sales. I have no 
> crisis of conscience from clicking an vendor shortcut for a basic end-to-end 
> Internet functional test. Or for teaching a User to do the same. This meets 
> the business purpose locally and requires no $pecial effort from Users, 
> network providers, or target systems. This precludes memorization of IP 
> addresses by end Users thus reducing the offered load from the likes of 
> excessive ping 8.8.8.8. 
> 
> I would expect NANOG members to have favorite ping target addresses based on 
> their environment, e.g., default router and a few designated targets. These 
> are useful for manual debugging but, as mentioned previously, are not 
> suitable as singular input to network monitoring.

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

I think we need to deliniate the conversation for human-memorable, on-demand 
needs vs. always-on configured needs. 




A system always checking to see if "Internet" is up is different than "I think 
something is wrong, let me check". 


For the always-on systems, how extensive do you want to get? What is your 
action if it's up? What is your action if it's down? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mike Hammett"  
To: nanog@nanog.org 
Sent: Tuesday, February 8, 2022 11:56:44 AM 
Subject: Authoritative Resources for Public DNS Pinging 


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? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

>
> I am disappointed but not surprised to see this discussion on NANOG.
> Encouraging Users to use a tool (that is often ignored by the hardware
> targeted) by providing a non-revenue-creating special target does not make
> business sense.
>

To be fair, I don't think this is unique to this community. Plenty of
conversations on the IETF lists that are fundamentally the same. (
Proposals to change X or implement standard Y to solve something that is
already solvable with current tech and standards. ) Really it's just the
complexity of the existing solution that's different. :)

On Fri, Feb 11, 2022 at 9:51 AM james.cut...@consultant.com <
james.cut...@consultant.com> wrote:

> On Feb 11, 2022, at 8:33 AM, Tom Beecher  wrote:
>
>
> The prediciate assumption that "pinging one destination is a valid check
> that my internet works' is INCORRECT. There is no magical unicorn that
> could be built that could make that true, and 'they're gonna do it anyways'
> is a poor excuse to even consider it.
>
>
> The predicate assumption that unsuccessful pinging one destination is a
> valid check that my internet DOES NOT work' is  ALSO INCORRECT. Still no
> magical unicorn.
>
> I am disappointed but not surprised to see this discussion on NANOG.
> Encouraging Users to use a tool (that is often ignored by the hardware
> targeted) by providing a non-revenue-creating special target does not make
> business sense.
>
> An allied issue is educating ‘Users’ about traceroute AKA sequential ping
> with TTL progression:
>
>
>-  Seeing missing or excessively long traceroute results from
>intermediate nodes does NOT indicate a real problem, especially when the
>target node is reachable with acceptable delay.
>
>
> I’ve lost count of my replies on user forums explaining this issue, even
> to otherwise well educated users.
>
> To be blunt, browsing to amazon.com, apple.com or another vendor site is
> a simple and easy to teach Internet aliveness check and, at least, offers
> the chance for the targeted vendor site to receive revenue from sales. I
> have no crisis of conscience from clicking an vendor shortcut for a basic
> end-to-end Internet functional test. Or for teaching a User to do the same.
> This meets the business purpose locally and requires no $pecial effort from
> Users, network providers, or target systems. This precludes memorization of
> IP addresses by end Users thus reducing the offered load from the likes of
> excessive ping 8.8.8.8.
>
> I would expect NANOG members to have favorite ping target addresses based
> on their environment, e.g., default router and a few designated targets.
> These are useful for manual debugging but, as mentioned previously, are not
> suitable as singular input to network monitoring.
>

Re: Authoritative Resources for Public DNS Pinging

[Joe Greco]

On Fri, Feb 11, 2022 at 09:58:19AM -0500, Jon Lewis wrote:
> So...here's a pair of "what if"s:
> 
> What if instead of pinging 8.8.8.8, all these things using it to "test the 
> Internet" sent it DNS requests instead?  i.e.
> GOOG=$(dig +short @8.8.8.8 google.com)
> if [ -z "$GOOG" ] ; then
>   echo FAIL
> fi 
> Would that make things better or worse for GOOG (Trading lots more DNS 
> requests for the ICMP echo requests)?


ping is relatively ubiquitous.  There are certainly platforms on which
it isn't installed, but compare/contrast to the DNS options.  Is it
host?  nslookup?  dig?  No tool?

"ping internet" or "ping 8.8.8.8" are fairly straightforward by
comparison. 

> 8.8.8.8 is already anycasted.  What if each large ISP (for whatever 
> definition of large floats your boat) setup their own internal instance(s) 
> of 8.8.8.8 with a caching DNS server listening, and handled the traffic 
> without bothering GOOG?  For users using 8.8.8.8 as a lighthouse, this 
> would change the meaning of their test...i.e. a response means their 
> connection to their ISP is up, and the ISP's network works at least enough 
> to reach an internal 8.8.8.8, but the question of their connectivity to 
> the rest of the Internet would be unanswered.

Certainly that is true.  Hijacking of any mechanism is a potential risk.
Tying it into the DNS somehow at least introduces the opportunity for
DNSSEC to reduce the chance of an ISP to muck with the intended result.

We could even call it the Enhanced Link Verification Internet Service.

"ping elvis"  :-P

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Authoritative Resources for Public DNS Pinging

[Jon Lewis]

On Fri, 11 Feb 2022, Mark Tinka wrote:


100% - and this is the crux of the issue.

As a community, it is clear that there is a need for this, and if 8.8.8.8 
stops being an anchor for liveliness detection, users will find something 
else to replace it with. And we can bet all our Kwacha that it won't have 
been designed for that purpose, either.


I have to admit, I haven't read most of this thread, but I am well aware 
of the issues with both end users and "routers" / firewalls pinging 
8.8.8.8 as a means of verifying "that path to the Internet is working".  I 
know GOOG doesn't appreciate the amount of ICMP echo requests their 
8.8.8.8 instances receive, and that at various times/places, that ICMP 
traffic is/has been policed by GOOG.


So...here's a pair of "what if"s:

What if instead of pinging 8.8.8.8, all these things using it to "test the 
Internet" sent it DNS requests instead?  i.e.

GOOG=$(dig +short @8.8.8.8 google.com)
if [ -z "$GOOG" ] ; then
  echo FAIL
fi 
Would that make things better or worse for GOOG (Trading lots more DNS 
requests for the ICMP echo requests)?


8.8.8.8 is already anycasted.  What if each large ISP (for whatever 
definition of large floats your boat) setup their own internal instance(s) 
of 8.8.8.8 with a caching DNS server listening, and handled the traffic 
without bothering GOOG?  For users using 8.8.8.8 as a lighthouse, this 
would change the meaning of their test...i.e. a response means their 
connection to their ISP is up, and the ISP's network works at least enough 
to reach an internal 8.8.8.8, but the question of their connectivity to 
the rest of the Internet would be unanswered.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Authoritative Resources for Public DNS Pinging

[james.cut...@consultant.com]

On Feb 11, 2022, at 8:33 AM, Tom Beecher  wrote:
> 
> The prediciate assumption that "pinging one destination is a valid check that 
> my internet works' is INCORRECT. There is no magical unicorn that could be 
> built that could make that true, and 'they're gonna do it anyways' is a poor 
> excuse to even consider it. 
> 

The predicate assumption that unsuccessful pinging one destination is a valid 
check that my internet DOES NOT work' is  ALSO INCORRECT. Still no magical 
unicorn. 

I am disappointed but not surprised to see this discussion on NANOG. 
Encouraging Users to use a tool (that is often ignored by the hardware 
targeted) by providing a non-revenue-creating special target does not make 
business sense.

An allied issue is educating ‘Users’ about traceroute AKA sequential ping with 
TTL progression:

 Seeing missing or excessively long traceroute results from intermediate nodes 
does NOT indicate a real problem, especially when the target node is reachable 
with acceptable delay. 

I’ve lost count of my replies on user forums explaining this issue, even to 
otherwise well educated users. 

To be blunt, browsing to amazon.com, apple.com or another vendor site is a 
simple and easy to teach Internet aliveness check and, at least, offers the 
chance for the targeted vendor site to receive revenue from sales. I have no 
crisis of conscience from clicking an vendor shortcut for a basic end-to-end 
Internet functional test. Or for teaching a User to do the same. This meets the 
business purpose locally and requires no $pecial effort from Users, network 
providers, or target systems. This precludes memorization of IP addresses by 
end Users thus reducing the offered load from the likes of excessive ping 
8.8.8.8. 

I would expect NANOG members to have favorite ping target addresses based on 
their environment, e.g., default router and a few designated targets. These are 
useful for manual debugging but, as mentioned previously, are not suitable as 
singular input to network monitoring.

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

>
> As a community, it is clear that there is a need for this, and if
> 8.8.8.8 stops being an anchor for liveliness detection, users will find
> something else to replace it with. And we can bet all our Kwacha that it
> won't have been designed for that purpose, either.
>

I respectfully strongly disagree on 'need'.

Let's perform a thought experiment. Assert that 8.8.8.8 was expressly
codified by Google to be a designated ICMP endpoint, and that for 100% of
ICMP echo requests they receive, they guarantee an echo-reply will be sent.
There are countless reasons , even with that (unreasonable) assumption of
100% uptime of the endpoint, that echo-requests may not reach them, or that
echo-replies may be sent but not reach the originating source. Extend this
idea even further. Assert that it is now not just Google running it, and
the largest networks in the world all agree to anycast it from their
networks.Assert is still guaranteed to respond to 100% if all echo requests
it receives, wherever it receives. ( An even more unreasonable assertion
than before!) There are STILL countless reasons why an endpoint may, at
times, have that simple ICMP check fail.

The prediciate assumption that "pinging one destination is a valid check
that my internet works' is INCORRECT. There is no magical unicorn that
could be built that could make that true, and 'they're gonna do it anyways'
is a poor excuse to even consider it.

This is a mistake many of us have made. I'll openly admit I made it 20
years ago. Like someone on the outages list I think mentioned, I had built
a couple SLA checks that triggered some routing changes to occur based on
their status, and I thought I was super hot shit. Until I had to drive an
hour through a blizzard to bring my routers back up after my incorrect
assumptions knocked my entire company (an ISP) offline. Sometimes these are
lessons people need to learn, but it's also helpful to point out to others
why what they are trying to do is a bad idea so they can( if they chose to)
learn from our prior mistakes.

On Fri, Feb 11, 2022 at 3:29 AM Mark Tinka  wrote:

>
>
> On 2/10/22 20:27, Tom Beecher wrote:
>
> >
> > 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.
>
> 100% - and this is the crux of the issue.
>
> As a community, it is clear that there is a need for this, and if
> 8.8.8.8 stops being an anchor for liveliness detection, users will find
> something else to replace it with. And we can bet all our Kwacha that it
> won't have been designed for that purpose, either.
>
> Mark.
>

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

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"  
To: "Lady Benjamin Cannon of Glencoe"  
Cc: "NANOG Operators' Group"  
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 < 
l...@6by7.net > wrote: 




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 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.” 
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ 






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




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? 





Seems like a lot of overhead for zero benefit. 


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




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 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.” 
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ 







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


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



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



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 - j...@west.net 
Network Engineering - CCIE #7880 
503 897-8550 - WB6RDV 

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/10/22 19:42, John Todd wrote:


I think it would be fair to say that ICMP echo to easy-to-remember 
internet resources is tolerated, but not encouraged, and is probably 
not a good idea unless one knows and very well understands the 
implications of failure (or success!) modes that don’t match the 
conditions that are expected. Terrible monitoring is easy; good 
monitoring is quite difficult.


It is reasonable to expect operators of systems designed for one type 
of service to quickly rate-limit or entirely filter non-critical 
alternate capabilities in the event of resource exhaustion or other 
type of risk to the primary service - this applies to web severs, DNS 
servers, NTP servers, etc. Also, choosing as an indicator a response 
from a protocol such as ICMP echo/reply which has had a historical 
risk of flooding attacks and which may have rapid clamping of traffic 
seems to be also a large check mark in the “do not use” column. ICMP 
echo stands real risks of not providing expected results for reasons 
that are known only to the target operator, and which do not take your 
non-obvious intentions into consideration.


More central to the issue: “The Prudent Mariner never relies solely on 
any single aid to navigation” (hi, Ken!) is an applicable quote here. 
Nothing is immune from interruption of service, especially as it 
becomes more distant from your administrative control. I see all too 
often people using ICMP to a nameserver, or a query to a nameserver, 
or a socket request to port 80 of some well-known name as the only 
method utilized for determining if a larger set of systems are 
available. This is not typically a good idea. I shudder to think what 
would happen if certain well-known domains were to be unavailable due 
to one of a dozen different potential failure cases. There are far too 
many poorly-written stacks that assume some singular conditions are 
“impossible” unless as a result of local failure, and that always ends 
in sadness and late nights spent writing root-cause analysis reports.


Further adding to this complexity is the benefit or detraction of 
anycast for many of these larger public services. What is “up” and 
what is “down”? What is the signal generated or inferred by presence 
or absence of this monitoring sample? The question typically generates 
lively debate within a network or monitoring team. I am pretty sure 
that “But I could ping x.x.x.x” is not typically a statement that has 
much weight when considering overall reachability. I do admit it is a 
hint, but not the answer, for many network conditions, but probably 
not by itself should any system consider that result canonical for 
anything other than that exact result.


If one is going to use responses of exterior (not within the same 
organizational control) services as an indicator of reachability, then 
a broad spectrum of tests are probably the only way to have anything 
approaching certainty or knowledge upon which action could be based, 
and even that will always have a shadow of a doubt. In that mix, ICMP 
echo/reply to public nameservers is probably not the best indicator to 
add in a monitoring suite, though it may appear to be perfectly OK… 
until it isn’t. DNS queries to DNS servers seems to be the most 
reasonable thing to use as test material, rather than ICMP, if one 
were building a rickety monitoring house out of the resources at-hand.



Additionally: The suggestions of building some new ICMP-responding 
service may end up being counter to the goals of the people using 
external tests, so careful what is wished for. Witness everyone 
installing various “speed testing” servers in their own networks, 
which may not truly provide accurate measurements of anything other 
than local loop speeds, which now sort of defeats the purpose of the 
speed test for anything other than the most local set of results.




Well, the issue is being able to test at the lowest level possible, and 
with the lowest common denominator.


While I agree that testing an application (like DNS) makes sense, it is 
not simple, and is a lot higher up in the layers, where a lot more 
things need to work reasonably well for that test to be successful.


Ping, on the other hand, is so basic, that barring rate-limiting or 
outright blocking, is a decent indicator of liveliness between source 
and destination.


I'm all for pulling together as many tools as we can to detect 
liveliness, for I don't see Ping going anywhere, anytime soon.


Heck, e-mail has been "dying" for decades, and yet it's still here.

Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/10/22 22:20, Brian Knight via NANOG wrote:

On 2022-02-10 11:42, John Todd wrote:

"The Prudent Mariner never relies solely on any single aid to 
navigation"


It's best to ping multiple targets, and take action only if all 
targets do not return replies.


For the odd random ping just to see if routing works, sure.

But as a permanent monitoring technique for an IT head and their 
devices, not something we want to encourage, unless that is the business 
of the target.





For route tracking a la $VENDOR_C's IP SLA, if possible, we'll ping 
next-hop IP, one target on our network, and one off our network.  
Withdraw the default route only if all three targets fail to return 
replies.


Just put this issue into context - we have a customer who (without us 
knowing) pings our side of the p2p link. In recent days, we've had RPD 
issues (a story for another day), which has forced us to re-prioritize 
CPU resources to RIB function, and not ICMP. The customer assumed our 
network was falling over, due to the increased latency from their 
monitoring, but we cleared that up with an explanation, as revenue 
traffic is unaffected.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/10/22 20:27, Tom Beecher wrote:



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.


100% - and this is the crux of the issue.

As a community, it is clear that there is a need for this, and if 
8.8.8.8 stops being an anchor for liveliness detection, users will find 
something else to replace it with. And we can bet all our Kwacha that it 
won't have been designed for that purpose, either.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 18:19, Joe Greco wrote:


So what people really want is to be able to "ping internet" and so far
the easiest thing people have been able to find is "ping 8.8.8.8" or
some other easily remembered thing.


Pretty much - both people and "things".



Does this mean that perhaps we should seriously consider having some
TLD being named "internet", with maybe a global DNS redirector that lets
service providers register appropriate upstream targets for their
customers, and then maybe also allow for some form of registration such
that if I wanted to provide a remote ping target for AS14536, I could
somehow register "as14536.internet" or "solnet.internet"?

Fundamentally, this is a valid issue.  As the maintainer of several BGP
networks, I can't really rely on an upstream consumer ISP to be the
connectivity helpdesk when something is awry.  It would really be nice
to have a list of officially sanctioned testing points so that one could
just do "ping google.internet" or "ping level3.internet" or "ping
comcast.internet" or "ping aws.internet" and get a response.

The problem with this is that someone will try to make what could be a
relatively simple thing complicated, and we'll end up needing a special
non-ping client and some trainwreck of names and other hard-to-grok
garbage, and then we're perilously close to coming back to the current
situation where people are using arbitrary targets out on the Internet
for connectivity testing.


Totally agree - we need to be deliberate about creating something that 
is not only simple, but memorable, in addition to being built for purpose.


But I also agree that this will likely create an opportunity to 
over-complicate what should be simple. We'll need to put in as much 
effort into resisting complexity, as we will designing a solution.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Brian Knight via NANOG]

On 2022-02-10 11:42, John Todd wrote:

"The Prudent Mariner never relies solely on any single aid to 
navigation"


It's best to ping multiple targets, and take action only if all targets 
do not return replies.


For route tracking a la $VENDOR_C's IP SLA, if possible, we'll ping 
next-hop IP, one target on our network, and one off our network.  
Withdraw the default route only if all three targets fail to return 
replies.



John Todd - jt...@quad9.net
General Manager - Quad9 Recursive Resolver


./btk

Re: Authoritative Resources for Public DNS Pinging

[John Todd]

I think it would be fair to say that ICMP echo to easy-to-remember 
internet resources is tolerated, but not encouraged, and is probably not 
a good idea unless one knows and very well understands the implications 
of failure (or success!) modes that don’t match the conditions that 
are expected. Terrible monitoring is easy; good monitoring is quite 
difficult.


It is reasonable to expect operators of systems designed for one type of 
service to quickly rate-limit or entirely filter non-critical alternate 
capabilities in the event of resource exhaustion or other type of risk 
to the primary service - this applies to web severs, DNS servers, NTP 
servers, etc. Also, choosing as an indicator a response from a protocol 
such as ICMP echo/reply which has had a historical risk of flooding 
attacks and which may have rapid clamping of traffic seems to be also a 
large check mark in the “do not use” column. ICMP echo stands real 
risks of not providing expected results for reasons that are known only 
to the target operator, and which do not take your non-obvious 
intentions into consideration.


More central to the issue: “The Prudent Mariner never relies solely on 
any single aid to navigation” (hi, Ken!) is an applicable quote here. 
Nothing is immune from interruption of service, especially as it becomes 
more distant from your administrative control. I see all too often 
people using ICMP to a nameserver, or a query to a nameserver, or a 
socket request to port 80 of some well-known name as the only method 
utilized for determining if a larger set of systems are available. This 
is not typically a good idea. I shudder to think what would happen if 
certain well-known domains were to be unavailable due to one of a dozen 
different potential failure cases. There are far too many poorly-written 
stacks that assume some singular conditions are “impossible” unless 
as a result of local failure, and that always ends in sadness and late 
nights spent writing root-cause analysis reports.


Further adding to this complexity is the benefit or detraction of 
anycast for many of these larger public services. What is “up” and 
what is “down”? What is the signal generated or inferred by presence 
or absence of this monitoring sample? The question typically generates 
lively debate within a network or monitoring team. I am pretty sure that 
“But I could ping x.x.x.x” is not typically a statement that has 
much weight when considering overall reachability. I do admit it is a 
hint, but not the answer, for many network conditions, but probably not 
by itself should any system consider that result canonical for anything 
other than that exact result.


If one is going to use responses of exterior (not within the same 
organizational control) services as an indicator of reachability, then a 
broad spectrum of tests are probably the only way to have anything 
approaching certainty or knowledge upon which action could be based, and 
even that will always have a shadow of a doubt. In that mix, ICMP 
echo/reply to public nameservers is probably not the best indicator to 
add in a monitoring suite, though it may appear to be perfectly OK… 
until it isn’t.  DNS queries to DNS servers seems to be the most 
reasonable thing to use as test material, rather than ICMP, if one were 
building a rickety monitoring house out of the resources at-hand.



Additionally: The suggestions of building some new ICMP-responding 
service may end up being counter to the goals of the people using 
external tests, so careful what is wished for. Witness everyone 
installing various “speed testing” servers in their own networks, 
which may not truly provide accurate measurements of anything other than 
local loop speeds, which now sort of defeats the purpose of the speed 
test for anything other than the most local set of results.


JT

--
John Todd - jt...@quad9.net
General Manager - Quad9 Recursive Resolver


On 8 Feb 2022, at 9:56, Mike Hammett wrote:


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?





-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

>
> 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 <
l...@6by7.net> wrote:

> 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
> b...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME
> 
>
> FCC License KJ6FJJ
>
>
> On Feb 9, 2022, at 12:15 PM, Tom Beecher  wrote:
>
> 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?
>>
>
> Seems like a lot of overhead for zero benefit.
>
> On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe <
> l...@6by7.net> wrote:
>
>> 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
>> b...@6by7.net
>> "The only fully end-to-end encrypted global telecommunications company
>> in the world.”
>> ANNOUNCING: 6x7 GLOBAL MARITIME
>> 
>>
>> FCC License KJ6FJJ
>>
>>
>>
>> On Feb 9, 2022, at 9:38 AM, Jay Hennigan  wrote:
>>
>> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
>>
>> The only problem is the less friendly IP address (although this will
>> be less and less a problem with IPv6, since 2001:4860:4860:: is
>> not really friendly).
>>
>>
>> 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 - j...@west.net
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV
>>
>>
>>
>

Re: Authoritative Resources for Public DNS Pinging

[Lady Benjamin Cannon of Glencoe]

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 
b...@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ


> On Feb 9, 2022, at 12:15 PM, Tom Beecher  wrote:
> 
> 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?
> 
> Seems like a lot of overhead for zero benefit.  
> 
> On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe  > wrote:
> 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 
> b...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME 
> 
> FCC License KJ6FJJ
> 
> 
> 
> 
>> On Feb 9, 2022, at 9:38 AM, Jay Hennigan > > wrote:
>> 
>> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
>> 
>>> The only problem is the less friendly IP address (although this will
>>> be less and less a problem with IPv6, since 2001:4860:4860:: is
>>> not really friendly).
>> 
>> 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 - j...@west.net 
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV
> 

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

>
> I'm not going to opinion on the quantity of benefits, but this thought
> could lend a razor from Occam.
>

I always enjoy a good shave from ol' Occam,no worries.

On Thu, Feb 10, 2022 at 2:54 AM Saku Ytti  wrote:

> On Wed, 9 Feb 2022 at 22:19, Tom Beecher  wrote:
>
> >> 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?
> >
> > Seems like a lot of overhead for zero benefit.
>
> I'm not going to opinion on the quantity of benefits, but this thought
> could lend a razor from Occam. NPU based boxes, like JNPR Trio, NOK
> FP, Huawei Solar, CSCO Lightspeed et.al. could easily respond to ICMP
> echo and TTL exceeded in NPU for microseconds of delay and nanoseconds
> of jitter at higher performance and lower cost compared to transing
> it, i.e. ping responder would become negative cost. Only reason they
> don't is because customers are not asking for it.
>
> Further, we could have a global anycast address, like we already have
> for 6to4 relays, where a well-known ping responder exists. And anyone
> who welcomes responding to pings, configures this address to all the
> device loopbacks which they want to include, advertise those loopbacks
> in IGP or iBGP and advertise the /24 aggregate in eBGP.
>
> --
>   ++ytti
>

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

No doubt there would be a very long tail, but...

1) Create alternative.
2) Get Google, Cloudflare, PCH, etc. to say that per whatever new standard, 
this is the new way to do this, leave my stuff alone.
3) Lots of peer pressure.
4) ???
5) Profit



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -
From: Mark Delany 
To: nanog@nanog.org
Sent: Wed, 09 Feb 2022 17:21:26 -0600 (CST)
Subject: Re: Authoritative Resources for Public DNS Pinging

On 09Feb22, Joe Greco allegedly wrote:

> So what people really want is to be able to "ping internet" and so far
> the easiest thing people have been able to find is "ping 8.8.8.8" or
> some other easily remembered thing.

Yes, I think "ping internet" is the most accurate description thus far. Or 
perhaps "reach
internet".

> Does this mean that perhaps we should seriously consider having some
> TLD being named "internet"

Meaning you need to have a functioning DNS resolver first? I'm sure you see the 
problem
with that clouding the results of a diagnostic test.

> service providers register appropriate upstream targets for their 
> customers, and then maybe also allow for some form of registration such
> that if I wanted to provide a remote ping target for AS14536, I could
> somehow register "as14536.internet" or "solnet.internet"?

Possibly. You'd want to be crystal clear on the use cases. As a starting point, 
maybe:

1. Do packets leave my network?
2. Do packets leave my ISP's network?
3. Mainly for IOT - is the internet reachable?

Because of 2 and 3. I don't think creative solutions such as ISPs any-casting 
some
memorable IP or name will do the trick. And because of 1. anything relying on 
DNS
resolution is probably a non-starter. Much as I like "ping ping.ripe.net" it 
alone is too
intertwined with DNS resolution to be a reliable alternative.


> Fundamentally, this is a valid issue.

Yup. There are far more home-gamers and tiny network admins (the networks are 
tiny, not
the admins) who just want to run a reachability test or add a command to a 
cheap network
monitor cron job. Those on this list who can - or should - do something more 
sophisticated
are numerically in the minority of people who care about reachability and are 
not really
the target audience for a better "ping 8.8.8.8".

> and we'll end up needing a special non-ping client and some trainwreck of 
> names and
> other hard-to-grok

I'm not sure the two are fundamentally intertwined tho it could easily be an 
unintended
consequence. However, being constrained to creating a new ping target does 
severely limit
the choices. And including ipv6 just makes that more complicated.

The other matter is that the alternative probably has to present a compelling 
case to
cause change in behavior. I can see an industry standard ping target being of 
possible use
to tests built into devices. But again it'd have to be compelling for most 
manufacturers
to even notice.

But for humans, I'd be surprised if you can create a compelling alternative ping
target. For them, I'd be going down the path of a "ping-internet" command which 
answers
use-cases 1. & 2. while carefully avoiding the second-system syndrome - he says 
with a
laugh.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

Except that the very reason This Thread started was because 8. 8. 8. 8 was not 
responding to pings and cause issues with many facturar hard-coded destinations.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest-IX
http://www.midwest-ix.com

- Original Message -
From: Lady Benjamin Cannon of Glencoe 
To: Christopher Morrow 
Cc: NANOG Operators' Group 
Sent: Wed, 09 Feb 2022 14:29:58 -0600 (CST)
Subject: Re: Authoritative Resources for Public DNS Pinging

Exactly.  8.8.8.8 isn’t going down anytime soon, also is geographically 
redundant; even if half the internet is dead, it’ll still be there.It’s 
somewhat hard to duplicate that cheap.

What else is like that and easy to remember and isn’t 1.1.1.1 ?

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
6x7 Networks & 6x7 Telecom, LLC 
CEO 
b...@6by7.net
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>

FCC License KJ6FJJ




> On Feb 9, 2022, at 12:25 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Feb 9, 2022 at 2:10 PM Lady Benjamin Cannon of Glencoe  <mailto:l...@6by7.net>> wrote:
> 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?
> 
> 
> I suspect that half the reason: "ping 8.8.8.8" (do not do this!) is used is: 
> "easy to remember 8.8.8.8"
> and half is: "Well, that IP is well connected enough that you are reasonably 
> assured that: 'enough of the internet is up '" if it replies.
> 
> (maybe it's 75/25? or 80/20 not 5050... but you get my point) 

Re: Authoritative Resources for Public DNS Pinging

[Saku Ytti]

On Wed, 9 Feb 2022 at 22:19, Tom Beecher  wrote:

>> 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?
>
> Seems like a lot of overhead for zero benefit.

I'm not going to opinion on the quantity of benefits, but this thought
could lend a razor from Occam. NPU based boxes, like JNPR Trio, NOK
FP, Huawei Solar, CSCO Lightspeed et.al. could easily respond to ICMP
echo and TTL exceeded in NPU for microseconds of delay and nanoseconds
of jitter at higher performance and lower cost compared to transing
it, i.e. ping responder would become negative cost. Only reason they
don't is because customers are not asking for it.

Further, we could have a global anycast address, like we already have
for 6to4 relays, where a well-known ping responder exists. And anyone
who welcomes responding to pings, configures this address to all the
device loopbacks which they want to include, advertise those loopbacks
in IGP or iBGP and advertise the /24 aggregate in eBGP.

-- 
  ++ytti

Re: Authoritative Resources for Public DNS Pinging

[Josh Luthman]

4.2.2.2 is definitely anycast, I've used that one since I think before
Google was founded...

On Wed, Feb 9, 2022 at 5:01 PM Mike Lewinski via NANOG 
wrote:

> > What else is like that and easy to remember and isn’t 1.1.1.1 ?
>
> 4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1.
>
> Muscle memory still favors it. I think 4.2.2.2 might be anycast the same
> but never really looked hard at it.
>

Re: Authoritative Resources for Public DNS Pinging

[Lukasz Bromirski]

Mark,

> On 9 Feb 2022, at 16:02, Mark Tinka  wrote:
> On 2/9/22 16:53, Łukasz Bromirski wrote:
>> Yup. And Google folks accounted for the world pinging them all day long.
>> 
>> I wouldn't call using DNS resolvers as best "am I connected to internet over 
>> this interface" tool though. A day, year or 5 years from now the same team 
>> may decide to drop/filter and then thousands of hardcoded "handmade 
>> automation solutions" will break. And I believe that's closer to what 
>> Masataka was trying to convey.
> I get that, but what I'm saying is that users tend to expect things to remain 
> the same. […] If it can serve some other purpose (like liveliness detection), 
> they will use it for that purpose in the hopes that it will always be there, 
> for that purpose.

…aaand I absolutely agree with you on all of the points.

-- 
./

Re: Authoritative Resources for Public DNS Pinging

[Mark Delany]

On 09Feb22, Joe Greco allegedly wrote:

> I dunno.  I think I'd find that being unable to resolve a hostname or
> being unable to exchange packets result in a similar level of Internet
> brokenness.

Sure. The result is the same, but as a discriminator for diagnosing the problem 
it's quite
different. If a support rep hears "cannot reach fatbook" vs. ping 8.8.8.8 fails 
they'll
hopefully go down a different diagnostic route.

In large partI think of this sort of tool as a "what next" helper or "where do 
I look
next" helper.

> It is going to be hard to quantify all the things you might
> want to test for.  You already enumerated several.  But if it has to be
> a comprehensive "Internet is fully working" test, what do you do to be
> able to detect that your local coffee shop isn't implementing a net nanny
> filter?  Just to take it too far down the road.  ;-)

Well comprehensive might be a bit much, but useful info for a support rep or a 
tech forum
helper, well, that's a different matter. The Ocean boiling we aint.

In many ways the idea is simply to automate the basic steps that most of us 
would take to
diagnose a connectivity issue:

for ip in 4, 6
  1a) Can I reach first hop - check
  1b) Can I reach ISP first hop - check

  2a) Can I reach a resolver - check

  3a) Can I resolve ISP end-points - check
  3b) Can I reach ISP end-points - check

  4a) Can I resolve ping.ripe.net - check
  4b) Can I reach ping.ripe.net end-points - check
done


Or similar. The tool bootstraps its way up rather than offering just a binary
yeah/nay. The output might simply be the above. I reckon if you saw that sort 
of output
you'd be able to make a pretty informed guess as to where the problem might be 
- or at
least what to do next. Which is the goal. We know we have a problem, we want to 
zero in on
it.

>From an automation POV it's nothing more than a bit of data-gathering and 
>issuing pretty
standard network exchanges in sequence. By way of example, on FreeBSD13, ping 
is 4,000+
lines of C. I'm certain the above could be implemented in far fewer ELOCs in a 
modern
language.

And, if these basic steps are augmented by ISPs adopting one or two conventions 
such as
well-defined DNS names and end-points, then such a tool could offer a lot of 
insights
for that inevitable support call: "I ran 'ping-internet [sol.net]' and it said: 
...".

As J. Hellenthal mentioned earlier, I think there's an argument here for why 
ISPs might
encourage such a beast. What do you think?


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Joe Greco]

On Wed, Feb 09, 2022 at 11:21:26PM +, Mark Delany wrote:
> On 09Feb22, Joe Greco allegedly wrote:
> 
> > So what people really want is to be able to "ping internet" and so far
> > the easiest thing people have been able to find is "ping 8.8.8.8" or
> > some other easily remembered thing.
> 
> Yes, I think "ping internet" is the most accurate description thus far. Or 
> perhaps "reach
> internet".
> 
> > Does this mean that perhaps we should seriously consider having some
> > TLD being named "internet"
> 
> Meaning you need to have a functioning DNS resolver first? I'm sure you see 
> the problem
> with that clouding the results of a diagnostic test.

Perhaps.  As I noted,

The problem with this is that someone will try to make what
could be a relatively simple thing complicated

and you're already implying the first step down that road, which is
trying to do something more than a simple pass/fail test.

> > service providers register appropriate upstream targets for their 
> > customers, and then maybe also allow for some form of registration such
> > that if I wanted to provide a remote ping target for AS14536, I could
> > somehow register "as14536.internet" or "solnet.internet"?
> 
> Possibly. You'd want to be crystal clear on the use cases. As a starting 
> point, maybe:
> 
> 1. Do packets leave my network?
> 2. Do packets leave my ISP's network?
> 3. Mainly for IOT - is the internet reachable?
> 
> Because of 2 and 3. I don't think creative solutions such as ISPs any-casting 
> some
> memorable IP or name will do the trick. And because of 1. anything relying on 
> DNS
> resolution is probably a non-starter. Much as I like "ping ping.ripe.net" it 
> alone is too
> intertwined with DNS resolution to be a reliable alternative.

I dunno.  I think I'd find that being unable to resolve a hostname or
being unable to exchange packets result in a similar level of Internet
brokenness.  It is going to be hard to quantify all the things you might
want to test for.  You already enumerated several.  But if it has to be
a comprehensive "Internet is fully working" test, what do you do to be
able to detect that your local coffee shop isn't implementing a net nanny
filter?  Just to take it too far down the road.  ;-)

> > Fundamentally, this is a valid issue.
> 
> Yup. There are far more home-gamers and tiny network admins (the networks are 
> tiny, not
> the admins) who just want to run a reachability test or add a command to a 
> cheap network
> monitor cron job. Those on this list who can - or should - do something more 
> sophisticated
> are numerically in the minority of people who care about reachability and are 
> not really
> the target audience for a better "ping 8.8.8.8".

Well, that's sorta true.

> > and we'll end up needing a special non-ping client and some trainwreck of 
> > names and
> > other hard-to-grok
> 
> I'm not sure the two are fundamentally intertwined tho it could easily be an 
> unintended
> consequence. However, being constrained to creating a new ping target does 
> severely limit
> the choices. And including ipv6 just makes that more complicated.
> 
> The other matter is that the alternative probably has to present a compelling 
> case to
> cause change in behavior. I can see an industry standard ping target being of 
> possible use
> to tests built into devices. But again it'd have to be compelling for most 
> manufacturers
> to even notice.

Change happens.  Look at pool.ntp.org.

> But for humans, I'd be surprised if you can create a compelling alternative 
> ping
> target. For them, I'd be going down the path of a "ping-internet" command 
> which answers
> use-cases 1. & 2. while carefully avoiding the second-system syndrome - he 
> says with a
> laugh.

Well, I've lamented many times over the years about how we (as a network
operations community) have failed to address issues in a meaningful way.

End users are using "ping 8.8.8.8" to test basic connectivity.

I'm happy to see the development of resources such as the RIPE Atlas
monitor, because for too many years I've had to guess at strategic
points to monitor.

However, tools for the average end user that could also be used by the
more experienced folks would be nice.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Authoritative Resources for Public DNS Pinging

[Mark Delany]

On 09Feb22, Joe Greco allegedly wrote:

> So what people really want is to be able to "ping internet" and so far
> the easiest thing people have been able to find is "ping 8.8.8.8" or
> some other easily remembered thing.

Yes, I think "ping internet" is the most accurate description thus far. Or 
perhaps "reach
internet".

> Does this mean that perhaps we should seriously consider having some
> TLD being named "internet"

Meaning you need to have a functioning DNS resolver first? I'm sure you see the 
problem
with that clouding the results of a diagnostic test.

> service providers register appropriate upstream targets for their 
> customers, and then maybe also allow for some form of registration such
> that if I wanted to provide a remote ping target for AS14536, I could
> somehow register "as14536.internet" or "solnet.internet"?

Possibly. You'd want to be crystal clear on the use cases. As a starting point, 
maybe:

1. Do packets leave my network?
2. Do packets leave my ISP's network?
3. Mainly for IOT - is the internet reachable?

Because of 2 and 3. I don't think creative solutions such as ISPs any-casting 
some
memorable IP or name will do the trick. And because of 1. anything relying on 
DNS
resolution is probably a non-starter. Much as I like "ping ping.ripe.net" it 
alone is too
intertwined with DNS resolution to be a reliable alternative.


> Fundamentally, this is a valid issue.

Yup. There are far more home-gamers and tiny network admins (the networks are 
tiny, not
the admins) who just want to run a reachability test or add a command to a 
cheap network
monitor cron job. Those on this list who can - or should - do something more 
sophisticated
are numerically in the minority of people who care about reachability and are 
not really
the target audience for a better "ping 8.8.8.8".

> and we'll end up needing a special non-ping client and some trainwreck of 
> names and
> other hard-to-grok

I'm not sure the two are fundamentally intertwined tho it could easily be an 
unintended
consequence. However, being constrained to creating a new ping target does 
severely limit
the choices. And including ipv6 just makes that more complicated.

The other matter is that the alternative probably has to present a compelling 
case to
cause change in behavior. I can see an industry standard ping target being of 
possible use
to tests built into devices. But again it'd have to be compelling for most 
manufacturers
to even notice.

But for humans, I'd be surprised if you can create a compelling alternative ping
target. For them, I'd be going down the path of a "ping-internet" command which 
answers
use-cases 1. & 2. while carefully avoiding the second-system syndrome - he says 
with a
laugh.


Mark.

RE: Authoritative Resources for Public DNS Pinging

[Mike Lewinski via NANOG]

> What else is like that and easy to remember and isn’t 1.1.1.1 ?

4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1. 

Muscle memory still favors it. I think 4.2.2.2 might be anycast the same but 
never really looked hard at it.

Re: Authoritative Resources for Public DNS Pinging

[Grant Taylor via NANOG]

On 2/9/22 1:29 PM, Lady Benjamin Cannon of Glencoe wrote:
Exactly.  8.8.8.8 isn’t going down anytime soon, also is geographically 
redundant; even if half the internet is dead, it’ll still be there.   
  It’s somewhat hard to duplicate that cheap.


And yet here we are having a thread where part of the motivation was 
systems having problems /because/ 8.8.8.8 had problems in some capacity.


Evil idea:  What if an ISP anycasts 8.8.8.8 (et al.) to their own bog 
standard recursive DNS server?  Then pings to it won't test greater 
Internet reach ability.  (I'm assuming that it's only available to their 
clients and not anycasted out to the Internet at large.)



What else is like that and easy to remember and isn’t 1.1.1.1 ?


I wonder how much of the problem is /human/ /interactive/ pings as 
opposed to automation / monitoring / probe pings.  I think the former 
greatly benefits from having something easy to remember.  I also think 
the latter doesn't actually care if it's easy for the human to remember 
or not.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authoritative Resources for Public DNS Pinging

[Jay Hennigan]

On 2/9/22 12:31, Lady Benjamin Cannon of Glencoe wrote:
Perhaps owning a (small but global) cloud computing & telecom company 
has spoiled me, but it seems like a trivial amount of resources to me 
for any moderately sized company let alone a large tech/telecom like 
anything you’d have heard of.


In a similar thread on the Outages list, I suggested that it could be 
something that Cloudflare might want to pursue. If it were to become 
popular, there would be a lot of data that could be mined such as rather 
detailed real-time outage data, BGP shifts, etc. that would be cool from 
a geeky standpoint and could possibly be monetized. They've already got 
a very well dispersed set of anycast hosts, and they have 1.1.1.1 .


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Authoritative Resources for Public DNS Pinging

[Aaron Wendel]

I'd just like to mention that PornHub is always up. (Pun intended)  Ping it.

Aaron


On 2/9/2022 2:43 PM, Tom Beecher wrote:
I mean if you own it, it's your money. But I think I anyone else would 
have a difficult time making a business or technical case to justify 
setting up and maintaining a large scale echo-reply endpoint for... 
what exactly?


On Wed, Feb 9, 2022 at 3:32 PM Lady Benjamin Cannon of Glencoe 
 wrote:


Perhaps owning a (small but global) cloud computing & telecom
company has spoiled me, but it seems like a trivial amount of
resources to me for any moderately sized company let alone a large
tech/telecom like anything you’d have heard of.

-LB

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


FCC License KJ6FJJ




On Feb 9, 2022, at 12:15 PM, Tom Beecher  wrote:

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?


Seems like a lot of overhead for zero benefit.

On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe
 wrote:

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
b...@6by7.net
"The only fully end-to-end encrypted global
telecommunications company in the world.”
ANNOUNCING: 6x7 GLOBAL MARITIME


FCC License KJ6FJJ




On Feb 9, 2022, at 9:38 AM, Jay Hennigan  wrote:

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


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


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 - j...@west.net

Network Engineering - CCIE #7880
503 897-8550 - WB6RDV






--

Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

I mean if you own it, it's your money. But I think I anyone else would have
a difficult time making a business or technical case to justify setting up
and maintaining a large scale echo-reply endpoint for... what exactly?

On Wed, Feb 9, 2022 at 3:32 PM Lady Benjamin Cannon of Glencoe 
wrote:

> Perhaps owning a (small but global) cloud computing & telecom company has
> spoiled me, but it seems like a trivial amount of resources to me for any
> moderately sized company let alone a large tech/telecom like anything you’d
> have heard of.
>
> -LB
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> b...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME
> 
>
> FCC License KJ6FJJ
>
>
>
> On Feb 9, 2022, at 12:15 PM, Tom Beecher  wrote:
>
> 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?
>>
>
> Seems like a lot of overhead for zero benefit.
>
> On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe <
> l...@6by7.net> wrote:
>
>> 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
>> b...@6by7.net
>> "The only fully end-to-end encrypted global telecommunications company
>> in the world.”
>> ANNOUNCING: 6x7 GLOBAL MARITIME
>> 
>>
>> FCC License KJ6FJJ
>>
>>
>>
>> On Feb 9, 2022, at 9:38 AM, Jay Hennigan  wrote:
>>
>> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
>>
>> The only problem is the less friendly IP address (although this will
>> be less and less a problem with IPv6, since 2001:4860:4860:: is
>> not really friendly).
>>
>>
>> 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 - j...@west.net
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV
>>
>>
>>
>

Re: Authoritative Resources for Public DNS Pinging

[Lady Benjamin Cannon of Glencoe]

Perhaps owning a (small but global) cloud computing & telecom company has 
spoiled me, but it seems like a trivial amount of resources to me for any 
moderately sized company let alone a large tech/telecom like anything you’d 
have heard of.

-LB

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

FCC License KJ6FJJ




> On Feb 9, 2022, at 12:15 PM, Tom Beecher  wrote:
> 
> 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?
> 
> Seems like a lot of overhead for zero benefit.  
> 
> On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe  > wrote:
> 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 
> b...@6by7.net 
> "The only fully end-to-end encrypted global telecommunications company in the 
> world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME 
> 
> FCC License KJ6FJJ
> 
> 
> 
> 
>> On Feb 9, 2022, at 9:38 AM, Jay Hennigan > > wrote:
>> 
>> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
>> 
>>> The only problem is the less friendly IP address (although this will
>>> be less and less a problem with IPv6, since 2001:4860:4860:: is
>>> not really friendly).
>> 
>> 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 - j...@west.net 
>> Network Engineering - CCIE #7880
>> 503 897-8550 - WB6RDV
> 

Re: Authoritative Resources for Public DNS Pinging

[Lady Benjamin Cannon of Glencoe]

Exactly.  8.8.8.8 isn’t going down anytime soon, also is geographically 
redundant; even if half the internet is dead, it’ll still be there.It’s 
somewhat hard to duplicate that cheap.

What else is like that and easy to remember and isn’t 1.1.1.1 ?

-LB

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

FCC License KJ6FJJ




> On Feb 9, 2022, at 12:25 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Wed, Feb 9, 2022 at 2:10 PM Lady Benjamin Cannon of Glencoe  > wrote:
> 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?
> 
> 
> I suspect that half the reason: "ping 8.8.8.8" (do not do this!) is used is: 
> "easy to remember 8.8.8.8"
> and half is: "Well, that IP is well connected enough that you are reasonably 
> assured that: 'enough of the internet is up '" if it replies.
> 
> (maybe it's 75/25? or 80/20 not 5050... but you get my point) 

Re: Authoritative Resources for Public DNS Pinging

[Christopher Morrow]

On Wed, Feb 9, 2022 at 2:10 PM Lady Benjamin Cannon of Glencoe 
wrote:

> 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?
>
>
I suspect that half the reason: "ping 8.8.8.8" (do not do this!) is used
is: "easy to remember 8.8.8.8"
and half is: "Well, that IP is well connected enough that you are
reasonably assured that: 'enough of the internet is up '" if it replies.

(maybe it's 75/25? or 80/20 not 5050... but you get my point)

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

>
> 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?
>

Seems like a lot of overhead for zero benefit.

On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe 
wrote:

> 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
> b...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company
> in the world.”
> ANNOUNCING: 6x7 GLOBAL MARITIME
> 
>
> FCC License KJ6FJJ
>
>
>
> On Feb 9, 2022, at 9:38 AM, Jay Hennigan  wrote:
>
> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
>
> The only problem is the less friendly IP address (although this will
> be less and less a problem with IPv6, since 2001:4860:4860:: is
> not really friendly).
>
>
> 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 - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
>
>
>

Re: Authoritative Resources for Public DNS Pinging

[Lady Benjamin Cannon of Glencoe]

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 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ




> On Feb 9, 2022, at 9:38 AM, Jay Hennigan  > wrote:
> 
> On 2/8/22 23:42, Stephane Bortzmeyer wrote:
> 
>> The only problem is the less friendly IP address (although this will
>> be less and less a problem with IPv6, since 2001:4860:4860:: is
>> not really friendly).
> 
> 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 - j...@west.net 
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV

Re: Authoritative Resources for Public DNS Pinging

[Jay Hennigan]

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


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


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 - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Re: Authoritative Resources for Public DNS Pinging

[Joe Greco]

On Wed, Feb 09, 2022 at 05:02:01PM +0200, Mark Tinka wrote:
> 
> 
> On 2/9/22 16:53, ??ukasz Bromirski wrote:
> 
> >Yup. And Google folks accounted for the world pinging them all day long.
> >
> >I wouldn't call using DNS resolvers as best "am I connected to internet 
> >over this interface" tool though. A day, year or 5 years from now the same 
> >team may decide to drop/filter and then thousands of hardcoded "handmade 
> >automation solutions" will break. And I believe that's closer to what 
> >Masataka was trying to convey.
> 
> I get that, but what I'm saying is that users tend to expect things to 
> remain the same. In reality, they don't, because as abstract as the 
> Internet seems to most users, it is run by actual people, who have to 
> apply mind and muscle to not only stand things up, but keep them 
> standing. The movement of those people has an impact on that, even in 
> very well established institutions.
> 
> So unless there is some specific accommodation from Google et al, that 
> the servers they run for one service can be used for liveliness 
> detection, expect breakage when that changes, at their whim. Until then, 
> do not expect users to honour the original intent of the service. If it 
> can serve some other purpose (like liveliness detection), they will use 
> it for that purpose in the hopes that it will always be there, for that 
> purpose.

So what people really want is to be able to "ping internet" and so far
the easiest thing people have been able to find is "ping 8.8.8.8" or
some other easily remembered thing.

Does this mean that perhaps we should seriously consider having some
TLD being named "internet", with maybe a global DNS redirector that lets
service providers register appropriate upstream targets for their 
customers, and then maybe also allow for some form of registration such
that if I wanted to provide a remote ping target for AS14536, I could
somehow register "as14536.internet" or "solnet.internet"?

Fundamentally, this is a valid issue.  As the maintainer of several BGP
networks, I can't really rely on an upstream consumer ISP to be the
connectivity helpdesk when something is awry.  It would really be nice
to have a list of officially sanctioned testing points so that one could
just do "ping google.internet" or "ping level3.internet" or "ping
comcast.internet" or "ping aws.internet" and get a response.

The problem with this is that someone will try to make what could be a
relatively simple thing complicated, and we'll end up needing a special
non-ping client and some trainwreck of names and other hard-to-grok
garbage, and then we're perilously close to coming back to the current
situation where people are using arbitrary targets out on the Internet
for connectivity testing.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Not to mention. It is viable traffic to monitor, if I know that I get X
number of icmp traffic through a point in tranfer consistently and that
starts to drop off considerably that it may be a failing connection due
to some circumstance I should start checking that equipment.

And if im that connection in the middle... that is money !

On Wed, Feb 09, 2022 at 03:02:19PM +, J. Hellenthal wrote:
> 
> Just think of all the smokeping probes that are out there plus services
> like UptimeRobot and similiar.
> 
> you can't just put something up as a provider of a service and say ...
> ya know im not going to plan for this... traffic for them of any kind is
> money... not only to them but to their IX's as well.
> 
> ya just don't willy nilly cut that shit down and not expect a huge
> blowup to happen.
> 
> On Wed, Feb 09, 2022 at 03:53:15PM +0100, Łukasz Bromirski wrote:
> > 
> > Yup. And Google folks accounted for the world pinging them all day long.
> > 
> > I wouldn't call using DNS resolvers as best "am I connected to internet 
> > over this interface" tool though. A day, year or 5 years from now the same 
> > team may decide to drop/filter and then thousands of hardcoded "handmade 
> > automation solutions" will break. And I believe that's closer to what 
> > Masataka was trying to convey.
> > 
> > — 
> > Łukasz Bromirski
> > 
> > > On 9 Feb 2022, at 14:23, Mark Tinka  wrote:
> > > 
> > >> On 2/9/22 15:00, Masataka Ohta wrote:
> > >> 
> > >> 
> > >> Wrong. It is not bad, at least not so bad, pinging properly
> > >> anycast DNS servers.
> > >> 
> > >> The point of anycast is resistance to DDoS.
> > >> 
> > >> But, relying on hard coded 8.8.8.8 is not a good idea because
> > >> DNS service of the address may be terminated.
> > >> 
> > >> Instead, properly anycast root name servers are authoritative
> > >> resources provided for public DNS queries which can be used for
> > >> pinging, though pinging so with ICMP should be less painful
> > >> for the servers.
> > > 
> > > That's like saying you won't have an egg for dinner because it's 
> > > typically had for breakfast.
> > > 
> > > Users don't care what infrastructure has been designated for. If they can 
> > > find another use for it other than designed, which serves their 
> > > interests, they will use it.
> > > 
> > > We need to allow, and account, for that.
> > > 
> > > Mark.
> 
> -- 
> The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
> lot about anticipated traffic volume.



-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


signature.asc
Description: PGP signature

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 16:53, Łukasz Bromirski wrote:


Yup. And Google folks accounted for the world pinging them all day long.

I wouldn't call using DNS resolvers as best "am I connected to internet over this 
interface" tool though. A day, year or 5 years from now the same team may decide to 
drop/filter and then thousands of hardcoded "handmade automation solutions" will break. 
And I believe that's closer to what Masataka was trying to convey.


I get that, but what I'm saying is that users tend to expect things to 
remain the same. In reality, they don't, because as abstract as the 
Internet seems to most users, it is run by actual people, who have to 
apply mind and muscle to not only stand things up, but keep them 
standing. The movement of those people has an impact on that, even in 
very well established institutions.


So unless there is some specific accommodation from Google et al, that 
the servers they run for one service can be used for liveliness 
detection, expect breakage when that changes, at their whim. Until then, 
do not expect users to honour the original intent of the service. If it 
can serve some other purpose (like liveliness detection), they will use 
it for that purpose in the hopes that it will always be there, for that 
purpose.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Łukasz Bromirski]

Yup. And Google folks accounted for the world pinging them all day long.

I wouldn't call using DNS resolvers as best "am I connected to internet over 
this interface" tool though. A day, year or 5 years from now the same team may 
decide to drop/filter and then thousands of hardcoded "handmade automation 
solutions" will break. And I believe that's closer to what Masataka was trying 
to convey.

— 
Łukasz Bromirski

> On 9 Feb 2022, at 14:23, Mark Tinka  wrote:
> 
>> On 2/9/22 15:00, Masataka Ohta wrote:
>> 
>> 
>> Wrong. It is not bad, at least not so bad, pinging properly
>> anycast DNS servers.
>> 
>> The point of anycast is resistance to DDoS.
>> 
>> But, relying on hard coded 8.8.8.8 is not a good idea because
>> DNS service of the address may be terminated.
>> 
>> Instead, properly anycast root name servers are authoritative
>> resources provided for public DNS queries which can be used for
>> pinging, though pinging so with ICMP should be less painful
>> for the servers.
> 
> That's like saying you won't have an egg for dinner because it's typically 
> had for breakfast.
> 
> Users don't care what infrastructure has been designated for. If they can 
> find another use for it other than designed, which serves their interests, 
> they will use it.
> 
> We need to allow, and account, for that.
> 
> Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 15:00, Masataka Ohta wrote:



Wrong. It is not bad, at least not so bad, pinging properly
anycast DNS servers.

The point of anycast is resistance to DDoS.

But, relying on hard coded 8.8.8.8 is not a good idea because
DNS service of the address may be terminated.

Instead, properly anycast root name servers are authoritative
resources provided for public DNS queries which can be used for
pinging, though pinging so with ICMP should be less painful
for the servers.


That's like saying you won't have an egg for dinner because it's 
typically had for breakfast.


Users don't care what infrastructure has been designated for. If they 
can find another use for it other than designed, which serves their 
interests, they will use it.


We need to allow, and account, for that.

Mark.

Re: Authoritative Resources for Public DNS Pinging

[Masataka Ohta]

Mike Hammett wrote:


Yes, pinging public DNS servers is bad.


Wrong. It is not bad, at least not so bad, pinging properly
anycast DNS servers.

The point of anycast is resistance to DDoS.

But, relying on hard coded 8.8.8.8 is not a good idea because
DNS service of the address may be terminated.

Instead, properly anycast root name servers are authoritative
resources provided for public DNS queries which can be used for
pinging, though pinging so with ICMP should be less painful
for the servers.

Masataka Ohta

Re: Authoritative Resources for Public DNS Pinging

[Robert Kisteleki]

On 2022-02-09 10:32, Brian Turnbow via NANOG wrote:


It wouldn't be too hard for ripe to setup a dns record for  ping.ripe.net and  
point it towards a local anchor for each request.


Yes this is possible and it's an interesting engineering problem (as we 
also have 11000 vantage points with known geolocation and topolocation 
to help here).


The idea will need vetting with the [atlas [anchor]] community though.


I think it could generate some interesting data for the atlas project as well.


It certainly would!


Once it becomes popular the anchor hosters may not be so happy  about the 
traffic they receive , but that is another story.


I imagine we could provide a means for anchors to opt out of this.

Robert

Re: Authoritative Resources for Public DNS Pinging

[J. Hellenthal via NANOG]

Anyone willing to write a icmp(8/0) concatenation/concentration/proxy tool ? 
That can be deployed at the provider edge ?

Catch all the packets !!!

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.

> On Feb 8, 2022, at 21:18, Mike Hammett  wrote:
> 
> 
> 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.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Mark Delany" 
> To: "NANOG" 
> Sent: Tuesday, February 8, 2022 5:13:30 PM
> Subject: Re: Authoritative Resources for Public DNS Pinging
> 
> On 08Feb22, Mike Hammett allegedly wrote:
> 
> > Some people need a clue by four and I'm looking to build my collection of 
> > them. 
> 
> > "Google services, including Google Public DNS, are not designed as ICMP 
> > network testing services"
> 
> 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.
> 

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 11:32, Brian Turnbow wrote:


It wouldn't be too hard for ripe to setup a dns record for  ping.ripe.net and  
point it towards a local anchor for each request.
I think it could generate some interesting data for the atlas project as well.
Once it becomes popular the anchor hosters may not be so happy  about the 
traffic they receive , but that is another story.


I suppose my point is as long as we have a deliberate solution that 
solves specifically for this, we shall be in a better place than we 
currently are.


Mark.

RE: Authoritative Resources for Public DNS Pinging

[Brian Turnbow via NANOG]

> On 2/9/22 09:30, Stephane Bortzmeyer wrote:
> 
> >
> > Let me repeat that there is a service which is officially intended to
> > be pinged/queried/etc, the RIPE Anchors.
> 
> Yeah, but how do we get out there in a manner that Jane can easily find and
> use, like she does 8.8.8.8?

It wouldn't be too hard for ripe to setup a dns record for  ping.ripe.net and  
point it towards a local anchor for each request.
I think it could generate some interesting data for the atlas project as well.
Once it becomes popular the anchor hosters may not be so happy  about the 
traffic they receive , but that is another story.

Brian

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 10:12, Matthew Walster wrote:




But yes, that would be the easiest way around it. If only ping.network 
didn't look as though it was squatting on the name for it's resale 
value...


As is ping.net.

Mark.

Re: Authoritative Resources for Public DNS Pinging

[Matthew Walster]

On Wed, 9 Feb 2022, 07:42 Stephane Bortzmeyer,  wrote:

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


Au contraire, I find 2600:: easy to remember :P

This can be partially mitigated with nice domain
> names, that an access or service provider can set up.
>

The problem with a domain name is that you then have to rely on your DNS
resolver. By directly specifying an IP address, you know that you are
testing the internet, not your resolver.

But yes, that would be the easiest way around it. If only ping.network
didn't look as though it was squatting on the name for it's resale value...

M

>

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 09:42, Stephane Bortzmeyer wrote:


I don't think that John (who is probably no more clueful than Jane)
knows about Google Public DNS either.


It's less about Jane and John than it is about a number of techs and IT 
folk who are not interested in global Internet operations. Those folk 
will ask Jane and John to "ping 8.8.8.8". Do it enough times, and Jane 
and John will be able to do it themselves, next time, as they hold on 
the phone for the tech to get to their spot in the queue.


Same goes for CPE vendors... they don't necessarily care about global 
Internet operations... they just follow the trend, and that's how Jane 
and John become part of the problem.




The only problem is the less friendly IP address (although this will
be less and less a problem with IPv6, since 2001:4860:4860:: is
not really friendly). This can be partially mitigated with nice domain
names, that an access or service provider can set up.


This.

Mark.

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Wed, Feb 09, 2022 at 09:37:02AM +0200,
 Mark Tinka  wrote 
 a message of 18 lines which said:

> > Let me repeat that there is a service which is officially intended to
> > be pinged/queried/etc, the RIPE Anchors.
> 
> Yeah, but how do we get out there in a manner that Jane can easily find and
> use, like she does 8.8.8.8?

I don't think that John (who is probably no more clueful than Jane)
knows about Google Public DNS either.

The only problem is the less friendly IP address (although this will
be less and less a problem with IPv6, since 2001:4860:4860:: is
not really friendly). This can be partially mitigated with nice domain
names, that an access or service provider can set up.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 09:30, Stephane Bortzmeyer wrote:



Let me repeat that there is a service which is officially intended to
be pinged/queried/etc, the RIPE Anchors.


Yeah, but how do we get out there in a manner that Jane can easily find 
and use, like she does 8.8.8.8?


RIPE's probes are great, but only if you know about them, and how to use 
them.


Jane doesn't know what she doesn't know, and I'm not certain she would 
know how to use them, even if she did.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Wed, Feb 09, 2022 at 09:08:04AM +0200,
 Mark Tinka  wrote 
 a message of 25 lines which said:

> It's terrible behaviour, but unless we offer a more "official"
> alternative, it won't end.

Let me repeat that there is a service which is officially intended to
be pinged/queried/etc, the RIPE Anchors. 

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 07:32, Matthew Walster wrote:



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. 


Not a serious problem for you and me, who are operators that know how to 
do this and understand it well.


For Jane, down the road, who doesn't care and just wants her MTV, she's 
not interested in what a DNS query is. All she is know is the 
tech-support on the other end of the horn asked her to "ping 8.8.8.8".


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 07:24, Grant Taylor via NANOG wrote:



The entrenched, pervasive, Internet-wide behavior used to be to use 
any convenient SMTP server to relay mail too.


The entrenched, pervasive, -wide behavior used to be to 
smoke on planes too.


Things change with the times.


Yep. And we would do well to change, as well. We can't keep fighting 
reality, and reality is that CPE vendors (including the big ones like 
the Meraki's of the world) hard-code 8.8.8.8 as a test target in their 
software.


It's terrible behaviour, but unless we offer a more "official" 
alternative, it won't end.


Google may stop it, but the public will simply turn to something else, 
and that target will not have been expecting it.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 07:24, Grant Taylor via NANOG wrote:



The entrenched, pervasive, Internet-wide behavior used to be to use 
any convenient SMTP server to relay mail too.


The entrenched, pervasive, -wide behavior used to be to 
smoke on planes too.


Things change with the times.


Yep. And we would do well to change, as well. We can't keep fighting 
reality, and reality is that CPE vendors (including the big ones like 
the Meraki's of the world) hard-code 8.8.8.8 as a test target in their 
software.


It's terrible behaviour, but unless we offer a more "official" 
alternative, it won't end.


Google may stop it, but the public will simply turn to something else, 
and that target will not have been expecting it.


Mark.

Re: Authoritative Resources for Public DNS Pinging

[Matthew Walster]

(as posted to outages)

On Wed, 9 Feb 2022, 04:53 Mark Tinka,  wrote:

> 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

>

Re: Authoritative Resources for Public DNS Pinging

[Grant Taylor via NANOG]

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


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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authoritative Resources for Public DNS Pinging

[Grant Taylor via NANOG]

On 2/8/22 3:48 PM, Mike Hammett wrote:
I was more here to find ammunition to show someone that they were doing 
something wrong than to build anything myself.


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.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Authoritative Resources for Public DNS Pinging

[Mark Tinka]

On 2/9/22 01:13, Mark Delany wrote:


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?


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.

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

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. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Mark Delany"  
To: "NANOG"  
Sent: Tuesday, February 8, 2022 5:13:30 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 

On 08Feb22, Mike Hammett allegedly wrote: 

> Some people need a clue by four and I'm looking to build my collection of 
> them. 

> "Google services, including Google Public DNS, are not designed as ICMP 
> network testing services" 

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. 

Re: Authoritative Resources for Public DNS Pinging

[Lady Benjamin Cannon of Glencoe]

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 
b...@6by7.net 
"The only fully end-to-end encrypted global telecommunications company in the 
world.”
ANNOUNCING: 6x7 GLOBAL MARITIME 

FCC License KJ6FJJ


> On Feb 8, 2022, at 12:39 PM, Lukas Tribus  > wrote:
> 
> Hello,
> 
> On Tue, 8 Feb 2022 at 18:56, Mike Hammett  > wrote:
>> 
>> 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?
> 
> This was just posted by Matthew Walster on the outages list (since
> 8.8.8.8 stopped responding to ICMP somewhere):
> 
> https://peering.google.com/#/learn-more/faq 
> 
> 
> 
> Lukas

Re: Authoritative Resources for Public DNS Pinging

[Ross Tajvar]

Meraki finally allowed an operator to stop this a few years ago, but it's
still the default.

On Tue, Feb 8, 2022 at 6:34 PM Mike Lewinski via NANOG 
wrote:

> Anyone swinging a clue-by-four it going to hit Meraki real hard.
>
>
> https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491
>

Re: Authoritative Resources for Public DNS Pinging

[William Herrin]

On Tue, Feb 8, 2022 at 2:49 PM Mike Hammett  wrote:
> I was more here to find ammunition to show someone that they were doing 
> something wrong than to build anything myself.

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.


--
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Authoritative Resources for Public DNS Pinging

[Randy Bush]

> I was more here to find ammunition to show someone that they were
> doing something wrong than to build anything myself.

this is just s classic.  mind if i quote you?

randy

RE: Authoritative Resources for Public DNS Pinging

[Mike Lewinski via NANOG]

Anyone swinging a clue-by-four it going to hit Meraki real hard.

https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491

Re: Authoritative Resources for Public DNS Pinging

[Peter Beckman]

On Tue, 8 Feb 2022, Christopher Morrow wrote:


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


 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
---
Peter Beckman  Internet Guy
beck...@angryox.comhttps://www.angryox.com/
---

Re: Authoritative Resources for Public DNS Pinging

[Mark Delany]

On 08Feb22, Mike Hammett allegedly wrote:

> Some people need a clue by four and I'm looking to build my collection of 
> them. 

> "Google services, including Google Public DNS, are not designed as ICMP 
> network testing services"

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.

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

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. 






- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Christopher Morrow"  
To: "Mike Hammett"  
Cc: "Tom Beecher" , "NANOG"  
Sent: Tuesday, February 8, 2022 4:35:16 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 







On Tue, Feb 8, 2022 at 4:05 PM Mike Hammett < na...@ics-il.net > wrote: 




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










- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 



From: "Tom Beecher" < beec...@beecher.cc > 
To: "Mike Hammett" < na...@ics-il.net > 
Cc: "NANOG" < nanog@nanog.org > 
Sent: Tuesday, February 8, 2022 3:01:27 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 




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. 


On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett < na...@ics-il.net > wrote: 




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? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: Authoritative Resources for Public DNS Pinging

[Christopher Morrow]

On Tue, Feb 8, 2022 at 4:05 PM Mike Hammett  wrote:

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



>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
> <https://www.linkedin.com/company/intelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> ----------
> *From: *"Tom Beecher" 
> *To: *"Mike Hammett" 
> *Cc: *"NANOG" 
> *Sent: *Tuesday, February 8, 2022 3:01:27 PM
> *Subject: *Re: Authoritative Resources for Public DNS Pinging
>
> 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.
>
> On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett  wrote:
>
>> 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?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions <http://www.ics-il.com/>
>> <https://www.facebook.com/ICSIL>
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>> <https://twitter.com/ICSIL>
>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswisp>
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>>
>
>

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

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" 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Beecher"  
To: "Mike Hammett"  
Cc: "NANOG"  
Sent: Tuesday, February 8, 2022 3:01:27 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 




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. 


On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett < na...@ics-il.net > wrote: 




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? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

Re: Authoritative Resources for Public DNS Pinging

[Tom Beecher]

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

On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett  wrote:

> 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?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
>

Re: Authoritative Resources for Public DNS Pinging

[Lukas Tribus]

Hello,

On Tue, 8 Feb 2022 at 18:56, Mike Hammett  wrote:
>
> 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?

This was just posted by Matthew Walster on the outages list (since
8.8.8.8 stopped responding to ICMP somewhere):

https://peering.google.com/#/learn-more/faq


Lukas

Re: Authoritative Resources for Public DNS Pinging

[Mike Hammett]

I'm not looking to do the pinging myself. I have my own destinations I use. I 
also use the RIPE system on occasion. 





- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Stephane Bortzmeyer"  
To: "Mike Hammett"  
Cc: nanog@nanog.org 
Sent: Tuesday, February 8, 2022 12:46:54 PM 
Subject: Re: Authoritative Resources for Public DNS Pinging 

On Tue, Feb 08, 2022 at 11:56:44AM -0600, 
Mike Hammett  wrote 
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)? 

Re: Authoritative Resources for Public DNS Pinging

[Stephane Bortzmeyer]

On Tue, Feb 08, 2022 at 11:56:44AM -0600,
 Mike Hammett  wrote 
 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)?

Authoritative Resources for Public DNS Pinging

[Mike Hammett]

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? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP