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).

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)

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.

Secondary DNS Feature Realignment

We are working on feature realignment for Secondary DNS. Since it’s recently been migrated to paid-only, some options may still refer to requiring a paid account. Some of the paid vs. free features are are in the process of reevaluating are: TSIG support, master server settings, and zone file commands.

UPDATE:

  • DNS TSIG key support for zone transfers are now available on Basic level accounts.
  • A second master server is now allowed on Basic level accounts.

These features previously required a paid account of Personal or higher and were not available on free accounts. Since all Secondary DNS use now requires a paid account, these features have been realigned to an account level of Basic or higher.

Migration to HTTPS and Why HTTPS Everywhere

We’ve recently migrated all of our sites to HTTPS. The account control center and webmail will continue to use Extended Validation certificates like they always have, while everything else will now be using certificates from Let’s Encrypt.

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. This helps create a more secure and privacy-respecting web.

Why HTTPS Everywhere?

Recently there’s a lot of buzz about moving to an HTTPS-only web. Previously, the cost of obtaining lots of HTTPS certs, having to manually install them, renew them, and pay fees for them discouraged using HTTPS unless needed. Let’s Encrypt solves many of those problems. Deploying HTTPS does take a little more effort, but there’s another reason why you should do it even if you think your site isn’t really that important to go encrypted: to help protect your visitors from their ISP.

We’ve personally experienced content hijacking with Charter, the local cable provider in Reno, NV (that now likes to be called Spectrum but we’re still going to call them Charter). Charter, for example, will hijack HTTP requests on residential and business coax service to provide content other than what you’ve requested. This is not the same as DNS redirection. HTTPS not only protects your privacy, but encryption ensures that the content you’ve requested passes between you and the site in its original, unaltered form without being rewritten or hijacked by your ISP, in addition to preventing eavesdropping. This is also known as a “man in the middle” attack. References: here, here, here, and here (plus we’ve seen it ourselves on home cable).

It is our opinion that an ISP altering content is entirely unacceptable for any reason. The only way we can truly protect ourselves is with encryption, not laws or depending on ISPs to “do the right thing”. Read more at EFF: Encrypting the Web.