Authoritative Resources for Public DNS Pinging

Mark Delany k3f at november.emu.st
Thu Feb 10 01:29:37 UTC 2022


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.


More information about the NANOG mailing list