Re: plea for comcast/sprint handoff debug help

[Christopher Morrow]

On Fri, Nov 6, 2020 at 3:09 PM Randy Bush  wrote:
>
> >> really?  could you be exact, please?  turning an optional protocol off
> >> is not a 'failure mode'.
> > I suppose it depends on how you think you are serving the data.
> > If you thought you were serving it on both protocols, but 'suddenly'
> > the RRDP location was empty that would be a failure.
>
> not necessarily.  it could merely be a decision to stop serving rrdp.
> perhaps a security choice; perhaps a software change; perhaps a phase
> of the moon.

right this is all in the same set of: "failure modes not caught"
(I think, I don't care so much WHY you stopped serving RRDP, just that
after a few failures
the caller should try my other number (rsync))

>
> as i do not see rrdp as a critical service, after all it is not mti,
> but i am quite aware of whether it is running or not.  the problem is
> that routinator seems not to be.

sure... it's just made one set of decisions. I was hoping with some
discussion we'd get to:
Welp, sure we can fallback and try rsync if we don't see success in  time.

Re: Phoenix-IX Contact

[Kate Gerry]

Is there anybody else even there? I thought that it was all Paul's show!

If I was able to (as in, had access to), I would offer to help/run with the IX. 
I may live in California, but it's a realistic car trip back and forth to 
Phoenix.

--
Kate

> On Nov 9, 2020, at 17:58, Mike Hammett  wrote:
> 
> Paul's LinkedIn seems to show that he checked out in April. Let me know if 
> you have any success reaching anyone there.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions 
>   
>  
>  
> 
> Midwest Internet Exchange 
>   
>  
> 
> The Brothers WISP 
>   
> 
> From: "Kate Gerry" mailto:kge...@outlook.com>>
> To: "Bill Woodcock" mailto:wo...@pch.net>>
> Cc: nanog@nanog.org 
> Sent: Monday, November 9, 2020 5:44:42 PM
> Subject: Re: Phoenix-IX Contact
> 
> Just a heads-up, I never heard a word from anybody at Phoenix-IX.
> 
> Is there anybody still running the IX? Or is it just on autopilot? It'd be 
> nice if anybody had some information on whatever happened to Paul. Hopefully 
> he is okay!
> 
> --
> Kate
> 
> On Sep 14, 2020, at 13:33, Kate Gerry  > wrote:
> 
> Thank Bill! I've been trying to reach Paul for ages now, hopefully he pops 
> back up again. We want to upgrade.
> 
> On an unrelated note, it looks like somebody has their ticket system 
> subscribed to the list... Awesome.
> 
> From: Dating Support  >
> Subject: [#WQV-291-95071]: Phoenix-IX Contact
> Date: September 14, 2020 at 12:43:20 PDT
> To: kge...@outlook.com 
> Reply-To: dating.supp...@csvwebsupport.com 
> 
> 
> Kate Gerry,
> 
> Thank you for contacting us. This is an automated response confirming the 
> receipt of your ticket. Our team will get back to you within 24 hours.
> 
> --
> Kate
> 
> 
> On Sep 14, 2020, at 12:48, Bill Woodcock  > wrote:
> 
> 
> 
> On Sep 14, 2020, at 9:31 PM, Kate Gerry  > wrote:
> 
> Does anybody have a contact who works at Phoenix-IX? I have been attempting 
> to reach somebody there for a while now without any luck.
> 
> Attempts to each out to peer...@phoenix-ix.net 
>  as well as Ninja-IX have been without any 
> luck. We also tried reaching out to Paul Emmons via LinkedIn mail and never 
> received a response.
> 
> Paul is the correct person.
> 
>-Bill



signature.asc
Description: Message signed with OpenPGP

Re: Phoenix-IX Contact

[Mike Hammett]

Paul's LinkedIn seems to show that he checked out in April. Let me know if you 
have any success reaching anyone there. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Kate Gerry"  
To: "Bill Woodcock"  
Cc: nanog@nanog.org 
Sent: Monday, November 9, 2020 5:44:42 PM 
Subject: Re: Phoenix-IX Contact 

Just a heads-up, I never heard a word from anybody at Phoenix-IX. 


Is there anybody still running the IX? Or is it just on autopilot? It'd be nice 
if anybody had some information on whatever happened to Paul. Hopefully he is 
okay! 


-- 
Kate 





On Sep 14, 2020, at 13:33, Kate Gerry < kge...@outlook.com > wrote: 



Thank Bill! I've been trying to reach Paul for ages now, hopefully he pops back 
up again. We want to upgrade. 


On an unrelated note, it looks like somebody has their ticket system subscribed 
to the list... Awesome. 





From: Dating Support < dating.supp...@csvwebsupport.com > 

Subject: [#WQV-291-95071]: Phoenix-IX Contact 

Date: September 14, 2020 at 12:43:20 PDT 

To: kge...@outlook.com 

Reply-To: dating.supp...@csvwebsupport.com 


Kate Gerry, 

Thank you for contacting us. This is an automated response confirming the 
receipt of your ticket. Our team will get back to you within 24 hours. 





-- 
Kate 






On Sep 14, 2020, at 12:48, Bill Woodcock < wo...@pch.net > wrote: 







On Sep 14, 2020, at 9:31 PM, Kate Gerry < kge...@outlook.com > wrote: 

Does anybody have a contact who works at Phoenix-IX? I have been attempting to 
reach somebody there for a while now without any luck. 

Attempts to each out to peer...@phoenix-ix.net as well as Ninja-IX have been 
without any luck. We also tried reaching out to Paul Emmons via LinkedIn mail 
and never received a response. 



Paul is the correct person. 

-Bill 

Re: Phoenix-IX Contact

[Kate Gerry]

Just a heads-up, I never heard a word from anybody at Phoenix-IX.

Is there anybody still running the IX? Or is it just on autopilot? It'd be nice 
if anybody had some information on whatever happened to Paul. Hopefully he is 
okay!

--
Kate

> On Sep 14, 2020, at 13:33, Kate Gerry  wrote:
> 
> Thank Bill! I've been trying to reach Paul for ages now, hopefully he pops 
> back up again. We want to upgrade.
> 
> On an unrelated note, it looks like somebody has their ticket system 
> subscribed to the list... Awesome.
> 
>> From: Dating Support > >
>> Subject: [#WQV-291-95071]: Phoenix-IX Contact
>> Date: September 14, 2020 at 12:43:20 PDT
>> To: kge...@outlook.com 
>> Reply-To: dating.supp...@csvwebsupport.com 
>> 
>> 
>> Kate Gerry,
>> 
>> Thank you for contacting us. This is an automated response confirming the 
>> receipt of your ticket. Our team will get back to you within 24 hours.
> 
> 
> --
> Kate
> 
> 
>> On Sep 14, 2020, at 12:48, Bill Woodcock > > wrote:
>> 
>> 
>> 
>>> On Sep 14, 2020, at 9:31 PM, Kate Gerry >> > wrote:
>>> 
>>> Does anybody have a contact who works at Phoenix-IX? I have been attempting 
>>> to reach somebody there for a while now without any luck.
>>> 
>>> Attempts to each out to peer...@phoenix-ix.net 
>>>  as well as Ninja-IX have been without any 
>>> luck. We also tried reaching out to Paul Emmons via LinkedIn mail and never 
>>> received a response.
>> 
>> Paul is the correct person.
>> 
>>-Bill
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: CNAME records in place of A records

[Arne Jensen]

Den 09-11-2020 kl. 01:10 skrev Matt Palmer:
> On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote:
>> Sorry if this is a bit OT. Recently several different vendors (in
>> completely different fields) where they white label for us asked us to
>> remove A records that we have going to them and replace them with CNAME
>> records. Is there anything *going around* in the security aranea  that has
>> caused this?
> The closest thing to a *security* issue I can think of is IP agility in the
> face of DDoS attacks -- most booter-style attacks are dumb as rocks, and
> null-routing the target IP and moving all the customers on that IP to
> another one is the easiest solution.

DNSSEC?

A lot of public sector/government stuff, at least around here, should
have had DNSSEC enabled already.

e-Boks, as being the stuff that all state/municipalities sends
electronic communication through (unless you're excluded from
"electronic mail"):

-> https://dnssec-analyzer.verisignlabs.com/www.e-boks.dk

Sure, there DNSSEC on the actual domain name, but the CNAME
*destination* does not.

Or for another examples:

-> https://dnssec-analyzer.verisignlabs.com/www.nsa.gov

There is also DNSSEC enabled on this domain too, but again, the CNAME
*destination* does not.


Wasn't there once a phrase saying something like "a chain is no stronger
than its weakest link"?

What if the SaaS provider is actually the weakest link?

> However, there are many *other* great reasons to get customers to CNAME onto
> their SaaS vendors, including:
>
> * No need to coordinate routine renumbering events;
> * IPv6 support;
> * CAA record (SSL cert issuance) support; and
> * no doubt a bunch of other reasons I've forgotten for the moment.

Renumbering and CAA record indeed two potential good reasons for using
the CNAME, as they wouldn't require clients to perform any manual
actions on their end.

However, I haven't seen anything pointing the direction that "IPv6
support" and "CNAME" would have anything to do with each other.

In the end, using A/ directly is the matter of knowing what you do,
and if you really do, IPv6 support with or without the CNAME wouldn't
really matter.

> Basically, if you sign up for a SaaS that uses your own domain and they
> *don't* give you a CNAME target to point at, I'd be very cautious, because
> they're either *very* new to the game, or they're probably also
> operationally deficient in a lot of other areas, too.

Providing the CNAME, or even requiring the use of it, could also mean
that you should indeed take a close look, at the areas where the SaaS
provider giving you them become "operationally deficient" too.

Hasn't DNS often been criticized of being one common thing that often
make websites slow?

-> https://github.com/PowerDNS/pdns/issues/6874

Real life example from one of the many "SaaS" vendors (in the example,
CDN providers) out there, providing the CNAME, and - obviously depending
on how you look at it, may operate certain things in a very silly way.


My truth? There is too many things out there, making it impossible to
blindly believe that SaaS vendors would always be right, or that their
decisions are always the best.

Your truth? I believe you need to figure out that one yourself.

Just my two cents.

-- 
Med venlig hilsen / Kind regards,
Arne Jensen

Spoofer Report for NANOG for Oct 2020

[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 2020:
ASNName   Fixed-By
14860  AS-SMARTCOM2020-10-15

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

Source Address Validation issues inferred during Oct 2020:
ASNName   First-Spoofed Last-Spoofed
54825  PACKET2016-04-15   2020-10-07
46562  TOTAL-SERVER-SOLUTIONS2016-04-26   2020-10-08
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2020-10-30
40676  AS40676   2016-08-29   2020-10-08
6128   CABLE-NET-1   2016-09-03   2020-10-31
20412  CLARITY-TELECOM   2016-09-30   2020-10-31
6181   FUSE-NET  2016-10-10   2020-10-29
14971  PINETEL   2016-10-21   2020-10-31
11427  TWC-11427-TEXAS   2016-10-21   2020-10-21
32440  LONI  2016-11-03   2020-10-26
12083  WOW-INTERNET  2016-11-09   2020-10-31
20473  AS-CHOOPA 2017-01-08   2020-10-27
9009   M247  2017-01-10   2020-10-08
25623  CISN2 2017-03-13   2020-10-26
63296  AWBROADBAND   2017-09-01   2020-10-27
546PARSONS-PGS-1 2017-11-20   2020-10-05
33452  RW2018-09-19   2020-10-31
20448  VPNTRANET-LLC 2018-09-20   2020-10-22
197706 KemiNet   2019-03-01   2020-10-08
8047   GCI   2019-04-11   2020-10-30
45671  AS45671-NET-AU2020-08-18   2020-10-08
199524 GCORE 2020-09-02   2020-10-08
132372 GBNETWORK 2020-10-08   2020-10-08
13739  DATACENTER-IP 2020-10-08   2020-10-08
395092 SHOCK-1   2020-10-10   2020-10-31
3491   BTN-ASN   2020-10-18   2020-10-28
23155  HTC-NET   2020-10-18   2020-10-18
63125  WICKED2020-10-26   2020-10-26

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

Re: Strange connectivity issue Frontier EVPL

[Tim Burke]

I'm amazed you can get *anything* to work with Logix involved. Haven't 
heard of many issues with PSLightwave in Houston, however... they seem 
to be one of the only halfway decent options here.


On 11/6/20 2:57 PM, aar...@gvtc.com wrote:

My coworker is having similar issues with PS Lightwave and Alpheus/Logix
from San Antonio to Houston whereas some things work and somethings don't

-Aaron