Categories
Announcements Changes

Mail Services: Whitelist Behavior Change

We’re changing the behavior of the whitelist for the “All Filters” entry type to now include the Antivirus filter when whitelisting.

The original behavior for the last decade or so has been to continue applying the antivirus filter while whitelisting everything else unless a second whitelist entry was added explicitly for the antivirus filter. Lately we’ve spent too much time explaining this, so we’ve decided the time has come to change the behavior so that an “All Filters” whitelist entry now truly means all filters (including antivirus).

Categories
Announcements

Transport to Los Angeles

On or after May 2, 2019 we will be turning up a layer 2 transport circuit between our colocaiton facility in Reno and CoreSite LA1/LA2 in Los Angeles.

  • LA1 is the famous One Wilshire building
  • LA2 is 900 N. Alameda (CoreSite)

LA1 and LA2 are connected with high count fiber and are effectively a single virtual campus. We’re installing this for internal transit and peering purposes, but since there will be excess capacity on it we’ll be able to offer it up for transport service, too.

The current plan is to charge $325/mo for transport circuits. This will be an all inclusive month-to-month price for the local cross connect in the Reno MMR and the long haul transport. The underlying carrier will be AT&T. We’ll post an update once our equipment is online in LA.

UPDATE: We’re online and accepting transport orders to LA1/LA2 as of May 7, 2019.

UPDATE 2: Los Angeles POP Shutdown

Categories
Announcements Changes Status

Routing Policy Change for AS20115 Charter/Spectrum

With the activation of the Hurricane Electric POP in Reno, NV the time has finally come to turn down our transit connection to AS20115 Charter/Spectrum. We’ve given our required 30 day termination notice to Charter/Spectrum effective today, April 9, for a end of service date of May 10, 2019.

In the meantime, our routing policy for AS20115 will change to that of a local peering type connection for data collection purposes. We’re curious how much utilization we will see if we restrict it for its last month. Incoming announcements from AS20115 will be filtered with an as-path-access-list of “permit ^20115$” and outgoing announcements will be tagged with community 20115:666 (Do not advertise outside of Charter AS). We will also move the physical connection away from the border router where our policy is one provider per router – a role now assigned to Hurricane Electric on that router – and over to our core peering router. With these filters we only expect to see about 2700 IPv4 prefixes. Charter’s IPv6 BGP session is broken again, but it’s not worth the fight to fix it so this exercise will be IPv4 only.

While we would like to maintain a regional peering connection with Charter/Spectrum, our previous account reps were not able to understand our needs (and our customer’s needs) to successfully negotiate a renewal for interconnection and peering over simply “buying internet”, the latter of which is no longer interesting to us as a colocation datacenter operator.

UPDATE: Effective 4/10/2019, AS20115 has been moved to our core peering router where it will remain until it’s shut down for good.

UPDATE 2: As soon as our Any2 peering port is ready we will remove our connection to Charter/Spectrum. (5/7/2019)

UPDATE 3: Shut down BGP to AS20115. (5/8/2019)

UPDATE 4: Our port to AS20115 Charter/Spectrum is now unplugged and cross connects removed: disconnect complete. (5/8/2019)

Categories
Q&A

Checking DNSSEC Domains

Recently we’ve started to receive support requests about DNS problems that turn out to be broken DNSSEC. Unfortunately we can’t fix DNSSEC problems on external domains, but you can run the following tests:

These tools will also show if a domain does not have DNSSEC. Running DNSSEC checks is particularly handy when using another tool that is not DNSSEC aware. Test tools that are not DNSSEC aware may return false positives when validation is broken.

Categories
Announcements Changes

Primary DNS DNSSEC Supported Algorithms Update

We’ve made a few changes to the DNSSEC Supported Algorithms.

  • Added support for ECDSA P-256 with SHA256
  • Added support for ECDSA P-384 with SHA384
  • Removed ECC-GOST (algorithm 12) as an option for KSK and ZSK

RFC6986 deprecates the use of GOST R 34.11-2012, and the Algorithm Implementation Requirements and Usage Guidance for DNSSEC intends to move DNSSEC ECC-GOST support in signers to the ‘MUST NOT’ category. Existing GOST keys should be rolled to another key type.