Hi,
DNS speaking, I can query G root servers; at least, that's the most important.
However, from several sites, either on IPv4 or IPv6, I cannot ping(6) them. Is it by design, or it's an issue?
Side question: even if it was by design, is it a good practice to completely restrict ICMP(v6)?
Thanks.
P.S: I sent the same email to dns-operations@lists.dns-oarc.net since 12 May 2023 but it's still in moderation.. If one admin is around .. 
Answering only your side question: there's a difference between
completely restricting ICMPv6 and restricting echo-request.
Restricting echo-request is more or less harmless. You deny
troubleshooters insight into your system, but that's a wash because
you deny hackers the same thing. And if you're popular enough to be a
target for "am I connected to the Internet right now" probes and don't
want to be, restricting it is not the worst idea.
Restricting all ICMPv6 is disastrous. Similar to IPv4, machines
running IPv6 require ICMPv6 packet-too-big messages to successfully
implement path MTU discovery. Without them, many protocols do not work
reliably. This includes TCP.
Regards,
Bill Herrin
However, from several sites, either on IPv4 or IPv6, I cannot ping(6) them. Is it by design, or it's an issue?
I believe g-root never answered ping requests. Others have been for a looong time (ever?) with some exceptions - those enabled it a few years ago.
Robert
It's certainly not an outage:
Lukas
So, DoD does NOT have capacity to answer those little ICMP echo
request packets? Heh.. Anyway, this is IMO terrible practice.
Many many times I have to deal w/ "products" that do exacly the same
because its so much "secure" to not respond to ping.
Any basic network security researcher know that they are various
more effective methods to poking around endpoint to check if its online.
Cutting PING means you are hurting your basic troubleshooting.
Is that thing even plugged in? Maybe Firewall misconfiguration?
If you are just user internet endpoint not serving anything, that
method might be useful, but you need to drop pretty much anything.
Hi Willy,
I will ping the OARC team on your email. Something might be up with the list.
So, DoD does NOT have capacity to answer those little ICMP echo
request packets? Heh.. Anyway, this is IMO terrible practice.
why?
Cutting PING means you are hurting your basic troubleshooting.
Is that thing even plugged in? Maybe Firewall misconfiguration?
it means you need to use the tool (dig, host, nslookup) that talks to
the service being offered.
ping is basically meaningless as a test for 'is the service working'
on a dns server.
Ping is used by some versions of traceroute which can help the
diagnostician figure out where the failure is happening. Which often
isn't at the server itself.
When working, it also lets the diagnostician know that the site's
firewall administrator didn't ignorantly decide to block all ICMP.
Which so very many ignorant firewall administrators do.
Regards,
Bill Herrin
> > Cutting PING means you are hurting your basic troubleshooting.
> > Is that thing even plugged in? Maybe Firewall misconfiguration?
>
> it means you need to use the tool (dig, host, nslookup) that talks to
> the service being offered.
> ping is basically meaningless as a test for 'is the service working'
> on a dns server.Ping is used by some versions of traceroute which can help the
I think you mean 'icmp' here. yes. I contend that traceroute (udp or
icmp or tcp)
TOWARDS a destination can be sometimes useful, sure.
This is different from: "i can ping g.root-servers.net so internet is up!"
if you care about how / when g.root-servers.net is working, dns packet
sending is the answer (and ideally listening to the replies!)
When working, it also lets the diagnostician know that the site's
firewall administrator didn't ignorantly decide to block all ICMP.
Which so very many ignorant firewall administrators do.
sure, but... 'ignorantly' seems to imply that their ideas of their best
practice(s) are different from yours. They may have a valid reason
to block icmp, even all icmp.
> Ping is used by some versions of traceroute which can help the
I think you mean 'icmp' here. yes. I contend that traceroute (udp or
icmp or tcp)
TOWARDS a destination can be sometimes useful, sure.
I mean ICMP echo-request, colloquially "ping." Traceroute using ICMP
needs the echo-reply from the destination to know that the trace
reached the destination, just like it needs port unreachable for UDP
and RST/SNYACK for TCP.
> When working, it also lets the diagnostician know that the site's
> firewall administrator didn't ignorantly decide to block all ICMP.
> Which so very many ignorant firewall administrators do.sure, but... 'ignorantly' seems to imply that their ideas of their best
practice(s) are different from yours. They may have a valid reason
to block icmp, even all icmp.
Since that breaks PMTUD on a public-facing service, I'm entirely
satisfied with my description of it being ignorant. There is, quite
simply, no valid reason to broadly block ICMP type 3 (destination
unreachable) messages to and from any public facing service. Not ever.
Regards,
Bill Herrin
Issue addressed on the dns-operations mailing list. Thanks for letting me know Willy.
I wanted to bring your attention to the DNS Affinity Group here in the NANOG Community https://community.nanog.org/c/dns/ and to the OARC Community Chat server https://chat.dns-oarc.net on our self-hosted Mattermost server. Our chat server is where OARC meets the wider DNS Community.
Also, I will be at NANOG 88 in Seattle in June if anyone would like to meet up.
Regards,
> > Ping is used by some versions of traceroute which can help the
>
> I think you mean 'icmp' here. yes. I contend that traceroute (udp or
> icmp or tcp)
> TOWARDS a destination can be sometimes useful, sure.I mean ICMP echo-request, colloquially "ping." Traceroute using ICMP
I find you are being oddly imprecise today!
"ping" is an application.
icmp type 0 code 0 is 'echo-reply'
icmp type 8 code 0 is 'echo' (request)
The traceroute application on some platforms defaults to UDP and
offers ICMP as a transport.
On some platforms it defaults to ICMP and (may) offer UDP as a transport.
I was simply trying to be clear about 'ping' being an application and
the underlying protocol (icmp)
being what traceroute be using.
needs the echo-reply from the destination to know that the trace
reached the destination, just like it needs port unreachable for UDP
and RST/SNYACK for TCP.> > When working, it also lets the diagnostician know that the site's
> > firewall administrator didn't ignorantly decide to block all ICMP.
> > Which so very many ignorant firewall administrators do.
>
> sure, but... 'ignorantly' seems to imply that their ideas of their best
> practice(s) are different from yours. They may have a valid reason
> to block icmp, even all icmp.Since that breaks PMTUD on a public-facing service, I'm entirely
blocking inbound (to your site) some/all ICMP is a decision that some
folk may choose
for a host of reasons. Since the tooling discussed so far isn't
sending icmp-unreachable types
at the g-root server we can't really know if they block 'all icmp', as much as:
  "well it sure seems like they drop icmp-echo!"
It seems like all we know so far is that G-root and/or its network
provider(s) don't like seeing
packets destined to their service which are not service bearing
packets, I don't think we have
evidence that they don't accept icmp unreachables though, I'd imagine
that as a root op they know
better than to drop unreachables since the may serve (probably have to
serve) edsn0 type replies at times.
The lion's share of traffic (actual dns traffic) to an authoritative
server is small inbound udp/53 (or tcp/53
for which I think OARC has numbers on ratios actually?) packets. Their
replies MAY be large(r) packets
which may be subject to pmtud problems, of which they'll be super
familiar with handling.