[
10.159.192.in-addr.arpa
dnsviz.net
](10.159.192.in-addr.arpa | DNSViz)
Seems to report a bunch of errors in the DS records for 192.in-addr.arpa held in the in-addr.arpa zone.
I figured I’d wait a few days and try again the first few times I encountered this, but it’s persisted for more than two weeks now.
Owen
It’s one broken server or firewall dropping fragmented responses In front of it. Just open a ticket.
Could these be related to the fact that dnsvis.net is trying to reach these servers via IPv6 and I think they use Hurricane for transit. Since HE and Cogent is a major gap, this causes them to time out trying to reach the C root server over IPv6.
It could well be… I haven’t tried to research the hosting of the dnsviz.net web server I’m connecting to and I don’t know anything about how their backend is structured (whether it’s on the same server or somewhere else, for example).
However, c.root-servers.net is not the problem being reported. The servers that provide the zone in question are (reportedly):
arpa. 84508 IN NS a.ns.arpa.
arpa. 84508 IN NS b.ns.arpa.
arpa. 84508 IN NS c.ns.arpa.
arpa. 84508 IN NS d.ns.arpa.
arpa. 84508 IN NS e.ns.arpa.
arpa. 84508 IN NS f.ns.arpa.
arpa. 84508 IN NS g.ns.arpa.
arpa. 84508 IN NS h.ns.arpa.
arpa. 84508 IN NS i.ns.arpa.
arpa. 84508 IN NS k.ns.arpa.
arpa. 84508 IN NS l.ns.arpa.
arpa. 84508 IN NS m.ns.arpa.
c.ns.arpa does share an IPv6 address with c.root-servers.net, however, so yes, the Cogent peering issue could be part of it.
Seems irresponsible to me that a root-server (or other critical DNS provider) would engage in a peering war to the exclusion of workable DNS.
Owen
I've brought this up before and the root servers are not really an IANA function IIRC. There's not much governance over them, other than what's on root-servers.org. I think a case could be made that C is in violation of the polices on that page and RFC 7720 section 3.
Basically none of the root servers want to change this and thus it's never going to change. DNS will fail and select another to talk to, and things will still work.
We have a tunnel set up to allow DNSViz to reach C-root, however
anything else single-homed on Cogent is unreachable to DNSViz via
IPv6.
The other thing it could be is broken PMTUD / failure fragment at network MTU. We defined socket options to do this 2 decades ago.
At what point does HE just host a second C root and announce the same IPv6s? Might irritate Cogent, but its not more "bad" than Cogent failing to uphold the requirements for running a root server.
Matt
Matt,
Why would HE hijack Cogent’s IP space? That would end in a lawsuit and potentially even more de-peering between them.
I'd be very curious to see a lawsuit over an IP hijack that isn't interfering with the operation of any of Cogent's services and is restoring service to HE's customers. Doubly so if they prepend aggressively to avoid it being a preferred path (Cogent currently announces a /48 for the C root server, and I assume there's ~nothing else in that block, but dunno).
IANAL and really have no idea what the basis for that would be? I guess if its legacy space you might argue its property and theft?
Matt
I'd be very curious to see a lawsuit over an IP hijack that isn't interfering with the operation of any of Cogent's services and is restoring service to HE's customers. Doubly so if they prepend aggressively to avoid it being a preferred path (Cogent currently announces a /48 for the C root server, and I assume there's ~nothing else in that block, but dunno).
IANAL and really have no idea what the basis for that would be? I guess if its legacy space you might argue its property and theft?
Oh, duh, we're talking about v6, no such thing as legacy.
I guess ARIN might have something to say, but its definitely a questionable case to care about. Let them hash it out, for all ARIN should care.
It can’t be legacy space, there is no such thing in IPv6.
Legacy status only refers to IPv4 blocks that were issued by the predecessors to the current registry system and have not yet been placed under RIR contract.
Owen
On a related note, I recently noticed Google became reachable again over IPv6 from Cogent (I didn’t have any automated testing in place so this can well have happened long ago - last posts I can find about the issue are from mid-2020).
It’s apparently through Tata/6453 so looks like they figured it out. Does anyone have context on when / how this was done? Can’t find anything on the internet!
From Cogent’s LG:
6453 15169
2001:550:0:1000::261c:143 (metric 102020) from 2001:550:0:1000::261c:153 (38.28.1.67)
Origin IGP, metric 4294967294, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 175370
Community: 174:11401 174:20666 174:21100 174:22005
Originator: 38.28.1.67, Cluster list: 38.28.1.83