Am I the only one who thinks this is disconcerting?
https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/ 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. -- Mark Andrews
On 8 Nov 2023, at 07:29, Owen DeLong via NANOG <nanog@nanog.org> wrote:
10.159.192.in-addr.arpa dnsviz.net
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
On 11/8/23 1:29 AM, Owen DeLong via NANOG wrote:
https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/
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.
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. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
On Nov 7, 2023, at 23:09, Bryan Fields <Bryan@bryanfields.net> wrote:
On 11/8/23 1:29 AM, Owen DeLong via NANOG wrote:
https://dnsviz.net/d/10.159.192.in-addr.arpa/dnssec/ 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.
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 <http://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 <http://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 <http://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
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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.
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. Ryan Hamel ________________________________ From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matt Corallo <nanog@as397444.net> Sent: Monday, November 13, 2023 11:32 AM To: Bryan Fields <Bryan@bryanfields.net>; nanog@nanog.org <nanog@nanog.org> Subject: Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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.
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
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 On 11/13/23 12:38 PM, Ryan Hamel wrote:
Matt,
Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them.
Ryan Hamel
---------------------------------------------------------------------------------------------------- *From:* NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matt Corallo <nanog@as397444.net> *Sent:* Monday, November 13, 2023 11:32 AM *To:* Bryan Fields <Bryan@bryanfields.net>; nanog@nanog.org <nanog@nanog.org> *Subject:* Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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.
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
On 11/13/23 12:57 PM, Matt Corallo wrote:
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.
Matt
On 11/13/23 12:38 PM, Ryan Hamel wrote:
Matt,
Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them.
Ryan Hamel
---------------------------------------------------------------------------------------------------- *From:* NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matt Corallo <nanog@as397444.net> *Sent:* Monday, November 13, 2023 11:32 AM *To:* Bryan Fields <Bryan@bryanfields.net>; nanog@nanog.org <nanog@nanog.org> *Subject:* Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments.
On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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.
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
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 Nov 13, 2023, at 12:57, Matt Corallo <nanog@as397444.net> wrote:
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
On 11/13/23 12:38 PM, Ryan Hamel wrote:
Matt, Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them. Ryan Hamel ---------------------------------------------------------------------------------------------------- *From:* NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matt Corallo <nanog@as397444.net> *Sent:* Monday, November 13, 2023 11:32 AM *To:* Bryan Fields <Bryan@bryanfields.net>; nanog@nanog.org <nanog@nanog.org> *Subject:* Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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. 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
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 On 13/11/2023 20:38, Ryan Hamel wrote: Matt, Why would HE hijack Cogent's IP space? That would end in a lawsuit and potentially even more de-peering between them. Ryan Hamel -------------------------------- From: NANOG <nanog-bounces+ryan=rkhtech.org@nanog.org> on behalf of Matt Corallo <nanog@as397444.net> Sent: Monday, November 13, 2023 11:32 AM To: Bryan Fields <Bryan@bryanfields.net>; nanog@nanog.org <nanog@nanog.org> Subject: Re: Am I the only one who thinks this is disconcerting? Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On 11/8/23 2:23 PM, Bryan Fields wrote:
On 11/8/23 2:25 PM, owen@Delong.com wrote:
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.
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.
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 -- www: grg.pw email: me@grg.pw mobile: +44 7716 604314 / +39 393 1049073
On Wed, Nov 8, 2023 at 2:12 AM Bryan Fields <Bryan@bryanfields.net> wrote:
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.
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. -- Mark Andrews
On 9 Nov 2023, at 06:00, Matthew Pounsett <matt@conundrum.com> wrote:
On Wed, Nov 8, 2023 at 2:12 AM Bryan Fields <Bryan@bryanfields.net> wrote:
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.
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.
participants (8)
-
Bryan Fields -
Giorgio Bonfiglio -
Mark Andrews -
Matt Corallo -
Matthew Pounsett -
Owen DeLong -
owen＠Delong.com
-
Ryan Hamel