Re: Am I the only one who thinks this is disconcerting?

[Mark Andrews]

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  wrote:
> 
> On Wed, Nov 8, 2023 at 2:12 AM Bryan Fields  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.

Re: Am I the only one who thinks this is disconcerting?

[Matthew Pounsett]

On Wed, Nov 8, 2023 at 2:12 AM Bryan Fields  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.

Re: AS8003 mysteries

[Christopher Morrow]

On Wed, Nov 8, 2023 at 4:51 PM Dave Taht  wrote:
>
> Anyone have an update as to where this effort, announcing qute a bit
> of usa government space, stands?
>

they stopped their internet telescope project?

> https://www.kentik.com/blog/the-mystery-of-as8003/
> --
> Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
> Dave Täht CSO, LibreQos

Re: Am I the only one who thinks this is disconcerting?

[Bryan Fields]

On 11/8/23 2:25 PM, o...@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

AS8003 mysteries

[Dave Taht]

Anyone have an update as to where this effort, announcing qute a bit
of usa government space, stands?

https://www.kentik.com/blog/the-mystery-of-as8003/
-- 
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

Re: Am I the only one who thinks this is disconcerting?

[owen--- via NANOG]

> On Nov 7, 2023, at 23:09, Bryan Fields  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 
 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

Spoofer Report for NANOG for Oct 2023

[CAIDA Spoofer Project]

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Oct 2023:
ASNName   Fixed-By
10796  TWC-10796-MIDWEST  2023-10-19
23483  SHASTACOE  2023-10-19
11878  TZULO  2023-10-24

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Oct 2023:
ASNName   First-Spoofed Last-Spoofed
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2023-10-26
20412  CLARITY-TELECOM   2016-09-30   2023-10-31
25787  ROWE-NETWORKS 2016-10-21   2023-10-29
11427  TWC-11427-TEXAS   2016-10-21   2023-10-09
271BCNET 2016-10-24   2023-10-29
6461   ZAYO-6461 2017-06-21   2023-10-11
14031  SCXY  2018-10-18   2023-10-24
55016  IMPER-AS-12021-05-18   2023-10-14
469972021-12-22   2023-10-26
394414 E2WS  2022-05-08   2023-10-26
400517   2022-10-03   2023-10-08
12183  TALKIE-COMMUNICATIONS 2022-12-10   2023-10-31
3701   NERONET   2023-04-18   2023-10-26
400282   2023-04-27   2023-10-27
46690  SNET-FCC  2023-05-20   2023-10-28
36687  WILINE2023-08-02   2023-10-10
394660 CHOICETEL-ER  2023-10-07   2023-10-07
19126  KIZAWIRELESS  2023-10-16   2023-10-24
185262023-10-17   2023-10-17
393899 RWLV  2023-10-17   2023-10-17
20119  ARROW 2023-10-19   2023-10-21
23483  SHASTACOE 2023-10-19   2023-10-19
12129  123NET2023-10-20   2023-10-20

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Please send any feedback or suggestions to spoofer-i...@caida.org