NinerNet Communications™
Blog

Corporate Blog

Office hours

23 April 2015 20:24:50 +0000

NinerNet‘s offices will be closed from Friday, 24 April and will re-open on Monday, 4 May. Emergency support will continue to be available 24/7, but routine emails and enquiries will be dealt with on Monday, 4 May. Thank-you.

Office hours

20 March 2015 04:54:14 +0000

NinerNet‘s offices will be closed for the week of 23-27 March. Emergency support will continue to be available 24/7, but routine emails and enquiries will be dealt with on Monday 30 March. Thank-you.

Delaying tactics by Network Solutions

21 January 2015 23:55:41 +0000

Businesses hate to lose customers, there’s no question of that. We hate to lose customers, there’s also no question of that. When a client tells us that they will be closing their account with us for one reason or another — it happens! — we’ll ask if there is anything we can do to keep their business. More often than not we’ll learn (often to our surprise) that the client is actually closing shop, and they’re not moving to another hosting provider — which is a bit of a relief (to us) in that we know they’re not leaving because of something we did, or something we didn’t do.

Sometimes, of course, the client is actually moving to a new hosting provider. As we’ve stated before, we do say that we’re sorry to see them go — and we mean it — and we ask if there’s anything we can do to keep their business, but if they’re committed then we back off. Importantly, we also don’t do anything to impede their progress into the sunset. In our opinion, that would be unprofessional, and we’d then deserve to lose that business. And given the number of clients that end up returning to us months or a year or two later, we’d be idiots to burn that bridge.

So it was interesting to learn today that Network Solutions (owned by Web.com) has apparently (at some point) implemented a three day waiting period if you ask for the “auth code” for a domain registered through them. (The authorisation code is required to effect a domain transfer from one registrar to another.) Now, it is our assertion that every domain name owner should ask for and make a note of the auth code for their domain as soon as it’s registered, and should also change it (if permitted by the registry) after a registrar transfer. (There is a long history of domain owners being caught flat-footed in times of crisis without this information.) But most of our incoming clients have not done that, and so now this client is being held hostage by Network Solutions for three days, waiting for the information — information they already own — that they need to effect the transfer they want to make. Network Solutions give the following reason, after a couple of screens of FUD-generating warnings of imminent Armageddon that are clearly designed to scare the domain owner into not obtaining the information to which they are entitled:

Your request for an Auth Code has been received and your information will be validated to ensure the security of your account. If your request is approved, you will receive your Auth Code by email in 3 days.

To cancel this request, please call one of our Customer Service Representatives at 1-800-779-4903.

Thank you.

Now, it’s all well and good that Network Solutions claims (or hides behind) the excuse of “[ensuring] the security of your account” (which is not surprising, considering they were responsible for one of the biggest screw ups in domain history when they allowed the fraudulent registrant transfer of a domain registered with them back when they held the monopoly on gTLD registrations), but this is clearly a delaying tactic to give the customer time to lose the will to transfer because now it’s just too much of a problem, too much effort, too complicated, too time-consuming … or whatever negative feeling develops in the mind of the domain owner as he or she spends three days mulling over (and perhaps having nightmares about) the things they read in the two screens of dire warnings before finally screwing up the courage to click the “yes, I really do want my auth code” button.

Shame on you, Network Solutions, for impeding the progress of this customer who has decided — as they’re free to do — to move their business to a competitor. But this is not surprising of a company that has a longer list of “controversies” listed in their Wikipedia article than most companies, along with those of their former parent company Verisign. They both also appear prominently in the “Domain name scams” article, as well as here on our own blog.

Christmas and New Year Hours and Wishes

23 December 2014 23:24:57 +0000

I’m taking this opportunity to thank you for your business in 2014 and to say that I look forward to continuing to earn your business in 2015.

We wish you and your families and employees a very happy Christmas, and all the best for the New Year.

Our office will be closed until Monday 5 January, but our systems will be monitored 24/7 (as always) and support will continue to be available 24/7 for emergent requests.

Configuring our servers against “POODLE”, SSL/TLS, and email security

24 October 2014 15:52:19 +0000

The maintenance to protect against the “POODLE” exploit has been finished, as we’ve noted on our status blog. While I’d like this to be a short post stating just that, like the maintenance itself, there is more to it than meets the eye.

What was anticipated to take about an hour during a scheduled weekend maintenance window ended up taking much longer as we waded through the pros and cons of configuring some or all services to disable SSL version 3. (Of course, very few people know about and can prepare for these things in advance.) First, there was some debate in information security circles about just how serious this issue was/is, how quickly it needed to be addressed, and by whom. In short, some took it more seriously than others, but there was general agreement that other issues (Heartbleed and Shellshock, for example) were much bigger. Those that didn’t feel it was that serious had their reasons, but we’re not in business to gamble with your security.

While this is a vulnerability in a protocol (SSL version 3) that is (or has been) used to secure different types of connections, the main area of concern was with HTTPS connections — i.e., web browsing. To my knowledge, the only known exploit of this protocol vulnerability uses JavaScript, and only over HTTPS connections. In other words, there is currently no known issue with using SSLv3 to secure non-HTTPS connections — e.g., email.

To that end SSLv3 will still work on some of our mail servers. How this is handled — if your email program can’t use TLS — differs between email programs, with some email clients failing silently and establishing a non-secure connection instead, and some failing completely to connect. We expect that most email programs using our existing suggested configurations will continue to work across all of our servers. However, while we have not had any reports of issues from clients, one of the reasons this took longer than anticipated was the surprising number of current or recent email clients that stopped working when we disabled SSLv3 on the mail servers. Connections by email clients configured to use SSLv3 still work on server NC018, while on NC027 they will fail silently as described above. This is related to the differing behaviour of the software running these two mail servers.

All web servers (including control panels) were configured to deny SSLv3 connections by Monday this week. Web browser developers seem to have kept up with and done a better job implementing TLS in current versions than some email client developers. As we’ve stated several times previously, Outlook 2003 should be relegated to the past, along with Microsoft Internet Explorer version 6. The latter uses only SSL (and has TLS disabled) by default. Microsoft, of all people, have actually had an active campaign to discourage the use of MSIE 6 since 2009 with their ie6countdown.com website; according to that website, only 3.3% of users worldwide are still using MSIE 6, and about three quarters of them are in China. Put it this way, using MSIE 6 today is like trying to drive a Model T Ford on modern roads among modern cars, expecting to go as fast as modern cars and to be serviced by modern mechanics. In short, using certain software today is simply a bad idea, even if it still appears to some people to work.

Another thing I’d like to address here is the difference between SSL (secure sockets layer) and TLS (transport layer security) … or, more correctly, the perceived difference. There is no difference. They are essentially the same thing. For all intents and purposes, the lay person can consider TLS version 1.0 to be SSL version 4.0. That’s not true from a technical standpoint, but as someone who deals every day with clients who just want their computers to work and are more concerned about the intricacies of their trucking business (for example), they do the same thing: encrypt your Internet connections. TLS, as the successor to SSL, is newer and better (as the “SSL version 4.0″ comparison above makes clear), and you should use TLS in preference to SSL any time you have a choice.

Finally, a word about email security. It has become more and more clear to me over the years that the trend in software development is to hide things from the average user. There is a point to which this is good; after all, if you had to type in all of the commands that your email program (for example) uses to connect to the mail server to download or send your email, you might as well write a letter with a quill and ink and send it via carrier pigeon. However, if your email program is going to fail silently and send your message in the clear — i.e., over an unencrypted connection — that’s something you probably want to know about if you thought you were using an encrypted connection. But this is not something you will read about in glossy brochures extolling the virtues of this email program or that. The fact is, most people will never be aware of such an issue, and those that have the most to fear — for example, people living in or reporting on dictatorships — will only realise they have a problem when there is that ominous knock at the door that reveals their communications have been compromised.

For this reason it is not enough to rely on your email service provider — not even NinerNet Communications — to secure your communications if you are, for example, an activist in a police state or a reporter with confidential sources. No, you have to take that responsibility on yourself by encrypting the actual messages you send before you send them. How to do this is certainly beyond the scope of this post, and even if you were to do it it may not be necessary for all of your communications. But going to this extent to protect yourself in this way takes extra time and effort and may require additional software on your computer, but at the end of the day you need to determine for yourself the pros and cons in your own cost-benefit analysis.

SSL version 3 “POODLE” vulnerability

17 October 2014 05:21:12 +0000

The latest in a series of recent vulnerabilities discovered in software commonly used on servers hosting websites and email (among other services) has reared its head. “POODLE” (conveniently discovered by the clever rhymers at Google) is a catchy name for a vulnerability found in a two-decade-old cryptographic protocol used to encrypt network connections. SSL — the secure sockets layer protocol — has become a household word over the years, and those three letters are still now used by many to refer generically to secure connections, even though SSL version 3.0 (published in 1996) was superseded by TLS (transport layer security) version 1.0 fifteen years ago (in 1999).

All of this introductory information is not intended to trivialise the problem, of course, but to give some background and illustrate how it can take a long time for new standards to be adopted, and old ones to be abandoned. Often, old standards live on simply because “if it ain’t broke, don’t fix it” … and now (well, three days ago) we find that the last version of SSL — version 3.0 — is indeed “broke”.

As such we will be re-configuring all of our servers still configured to allow SSL 3.0 connections to use TLS exclusively. This will require reconfiguring and restarting web servers, FTP servers and various email services. While we anticipate the work on all servers taking about an hour, interruptions in service — if there are any — should be brief and last only a few seconds at a time as services are restarted.

Of particular interest — due to a couple of recent support requests related to our newer mail server on NC027 — is that Microsoft Outlook 2003 users will likely no longer be able to connect securely to the mail servers on NC018 and NC023 (the relay server), as Outlook 2003 does not have support for TLS. Apparently a 2004 “hotfix” available from Microsoft will add TLS support to Outlook 2003, but we cannot vouch for this personally, nor are we aware of any clients who have used this. It should be noted that Microsoft stopped supporting Outlook 2003 earlier this year. It is obsolete software.

It is of interest to me personally that my favourite email program of all time — Eudora — will weather this storm and continue to flourish, as it does support TLS. However, sadly, even Eudora will eventually succumb to the ravages of time and the march of technology. In fact, I strongly suspect it only supports TLS version 1.0, and I have noticed that Google actively discourages connections from old email clients such as Eudora, probably because they likely suggest using an email client that supports at least TLS version 1.1. The latest version of TLS is 1.2, already six years old itself.

So, we will be using our weekend maintenance window to perform this maintenance. However, instead of starting at the usual time, this maintenance will begin at 21:00 UTC on Saturday, 18 October and, as stated above, should take roughly one hour. Please consult our status blog for updates on this maintenance, and please contact support if you have any questions or concerns.

“Shellshock” software bug

26 September 2014 14:17:06 +0000

You may have heard in the media about the so-called Shellshock security issue that affects a software package present on most Internet servers worldwide called “bash”. All of our servers run bash; it is a very basic building block on almost all UNIX- and Linux-based servers, which run most services on the Internet that you access every day. Bash can be loosely compared to the “command line” available on Windows-based computers.

Upon checking, we determined that the version of bash running on all of our servers was vulnerable to exploits aimed at the bug. All were immediately patched, and are no longer vulnerable. We continue to monitor security bulletins from the vendors of the operating systems we use for possible further patches related to newly-discovered vulnerabilities, should they materialise.

NinerNet takes keeping our servers updated and secure seriously. If you have any questions about this in general or this bug in particular, please contact us. Thank-you.

OpenSSL “Heartbleed” bug

9 April 2014 20:36:32 +0000

You may have read or heard reports in the media about a software bug in a widely-used program called OpenSSL used to secure SSL connections with and between servers.

While our servers do use OpenSSL, we have checked all of our systems and none of them are vulnerable to this bug.

If you have any questions or concerns, please let us know by contacting support.

New phone number

15 January 2014 13:58:41 +0000

We have a new phone number for our Vancouver, Canada, office, which we have added to the contact page on our website, but which has actually been on our invoices for some time now.

The new phone number is 604 630 1772. For those of you in North America but outside of the Vancouver local calling area, you can also still reach us using our toll-free number: 1 855 NINERNET (1 855 646 3763).

Those of you outside of North America may also be able to reach us using the toll-free number depending on the services available to you through your phone company or VoIP provider. If you can’t use the toll-free number, please use the 604 number after dialling your country’s international access code and the country code for North America (1).

The above two phone numbers are our only North American phone numbers. Please discard any old North American numbers that you may still have on file, as they no longer work or will cease to work shortly.

We continue to provide most support via email, and we encourage you to continue to submit support requests via email or through the contact form on our website at the above link.

Thank-you.

Domain contact information MUST be valid

15 January 2014 11:38:43 +0000

ICANN (the Internet Corporation for Assigned Names and Numbers) — the organisation in charge of all generic top-level domains (e.g., dot-com, dot-net, dot-org, etc., and the upcoming new gTLDs) — has introduced new rules that came into effect on 1 January.

The rule most likely to affect you at some point is the requirement for a valid email address associated with your domain. People generally register a new domain with a working email address, but over time that address may stop working for one reason or another. ICANN have taken steps to ensure that such a situation is not perpetuated.

Effective 1 January, if one of our automated emails to a contact address for your domain bounces, we are required to send you a verification email asking you to click a link in the email to confirm that your address does actually work. Of course, you’ll only receive that email if your email address has started working again in the meantime. Unfortunately, if you do not receive and act on the instructions in the verification email, we will have no choice but to suspend your domain, which will automatically happen fifteen (15) days after the first verification email is sent. If your domain is suspended, any services (email, websites, etc.) that rely on it will stop working until you respond and update the email address in your domain account. This is an ICANN rule applicable to all registrars and domain registrants, and we are contractually obligated to comply with it.

You may receive the same verification email when you register a new domain, when you transfer an existing domain into your domain account with NinerNet from another domain registrar, or when you change the contact information for your domain.

Please take this opportunity to log into your domain account (if your domain is registered with us) to check the contact information we have on record for your domain(s). If the contact email address you see there no longer works, exists or is no longer controlled by you, please update it immediately. (You will then receive a verification email, and you must follow the instructions in that email to complete the change to your contact details.) If you have multiple domains, you can update all of them at the same time. If you need the log-in information for your domain account sent to you, please advise us of that. Please note that your domain account is different and separate from your hosting account, and needs to be maintained separately by you. Thank-you for your understanding and cooperation.

If you have any questions, please contact support. Thank-you.

NinerNet home page

Subscriptions:

RSS icon. RSS

General Information:

This is the corporate blog of NinerNet Communications. It's where we post announcements, inform and educate our clients, and discuss issues related to the Internet (web and email) hosting business and all that that entails. This includes such concomitant industries and activities such a domain registration, SSL certificates, online back-up, virtual private servers (VPS), cloud hosting, etc. Please visit our main website for more information about us.

Search:

 

Recent Posts:

Archives:

Categories:

Tags:

accounts receivable apple billing branding cira client feedback contact information domain registration domain registry of canada domain renewals domains domain sales dot-ca domains dot-zm domains down time droc email encryption facebook google happy hosting customers hosting transfer internet registry of canada invoices iphone iroc maintenance new services paying your bill paying your invoice rates registrant transfers registrar transfers reputation scams search engine optimisation search engine optimization security seo service hours support testimonials transparency verisign wordpress

Resources:

On NinerNet: