Corporate Blog

Quarterly kwacha rate review, Q4 2023

2 October 2023 09:55:53 +0000

Based on the current value of the Zambian kwacha in US dollars and recent trends, we are increasing our retail kwacha prices effective today and until the next quarterly review by about 19%. The base USD rates remain the same, as do our kwacha rates for the Zambian TLDs, dot-zm and dot-zam.co.

Some sample rates:

webONE hosting plan (monthly): ZMW 325.00
mailONE hosting plan (monthly): ZMW 215.00
gTLD domain (annually): ZMW 410.00

Our new kwacha rates will be online within 24 hours.

Update, 2023-10-05: Corrected mailONE rate, as it was miscalculated.

Tags: accounts receivable, billing, kwacha, quarterly kwacha rate review, rates, transparency
Categories: Notices, Updated posts
Comments Off

Compromised email accounts are being accessed via webmail

29 August 2022 11:01:18 +0000

It is becoming more and more common, once an email account has been compromised by a computer virus or other malware, for the email account in question to be accessed through the webmail. When this happens, one or all of three things (and sometimes more) happen:

The criminal behind the virus/malware uses your webmail account to send spam or more viruses (the viruses will be stopped by our server though, but sometimes some spam will still get through),
The criminal poses as you (or one of your employees) and dupes your customers into sending payments to their bank account(s), and/or
The criminal creates filters in your email account to siphon off email to external email accounts they or their associates control.

While all are very negative and need to be stopped quickly — and this is why a compromised email account’s password must be changed, and the old password never used again — the last is particularly insidious as you might not use the filters, or you may not even know that they exist! Filters are a legitimate tool for people to use to handle some email in an automated fashion, and they have been around as long as email has been around.

The bottom line is that a compromised email account is a very serous matter. Your machines and devices need to be protected, by security software (anti-virus software, firewalls, encryption, anti-malware software, etc.), physically (access control, passwords, physical locks, etc.), and with education, knowledge and vigilance. If an email account is compromised the reason should be determined and the cause fixed or addressed in some other way. You then also need to examine the (now formerly) compromised account; one of the first things you should check is the integrity of the account’s filters. If unauthorised filters remain in place, the account is still compromised.

It is vital that you not gloss over an email account compromise as a “cost of doing business” and just carry on as usual after the inconvenience in your day. If you do not take all of the above steps your lack of action will come back to bite you in the buttocks, as Forrest Gump said. And this bite could cost your business in money, goodwill and business.

Another thing to consider is that the mail server’s control panel allows its users to designate any email account as a “domain admin”. We have always discouraged this, instead creating dedicated accounts for domain admins, but it’s a popular and widely used feature. However, consider this: If you designate bob@example.com as a “domain admin”, and Bob’s account is compromised, then the criminal behind the compromise will have access to all of the email accounts on the example.com domain. The results could be significantly more than just the inconvenience of having one email account compromised.

Something else for you to consider is how you can protect your employees from phishing emails. (Please see our “scams” section for many examples of scam emails, many of which are phishing emails.) Phishing emails try to get their recipients to click a link where they are asked to enter their email address and email password. Of course, none of us would be fooled by this, but many people a day are. How the page where people are asked to enter their log-in information looks depends on the nature of the email. If it was allegedly from a bank, the log-in page will be an exact copy of the log-in page for the bank they’re trying to present themselves as. If they’re trying to get your email password, everything will look like a webmail log-in page. It’s convincing. When you enter your log-in information, either nothing will happen, or your browser will be redirected to a legitimate webmail log-in page, but you won’t (of course) be logged in. In the meantime, your log-in information will be saved, and available for the scammer to use.

If this happens to you, you must immediately change the password on your account.

But back to the original question: How can you protect your company from your employees potentially falling for this phishing scam? One way is to not give your employees their email passwords. If they don’t have it, they can’t enter it in a phishing form. Of course, you need to weigh the advantages and disadvantages of this. A disadvantage is that you or your IT person will have to enter it for them when setting up their email account on their machine and/or phone, but the advantage is that they won’t be able to make the mistake of inadvertently providing their password.

If you haven’t recently, it’s probably a good idea to check the filters in your webmail account right now to confirm that you put them all there and that you still need them. And while you’re at it, change your email password too! Make sure it’s at least 12 characters long, includes upper- and lower-case letters, numbers and special characters. And use a password manager too. We use and strongly recommend KeePass.

Tags: compromise, control panel, domain admin, email filtering, encryption, fraud, malware, password, security, spam, viruses, webmail
Categories: Updated posts, Warnings
Comments Off

Quarterly kwacha rate review, Q4 2021

1 October 2021 06:15:51 +0000

Based on the current value of the Zambian kwacha in US dollars and recent trends, we are excited to announce that we are lowering our retail kwacha prices (for the first time since 2017) effective today and until the next quarterly review by 26%!

Some sample rates:

webONE hosting plan (monthly): ZMW 262.00
mailONE hosting plan (monthly): ZMW 175.00
gTLD domain (annually): ZMW 333.00

Our new kwacha rates will be online within 24 hours.

Tags: accounts receivable, billing, kwacha, quarterly kwacha rate review, rates, transparency
Categories: Notices, Updated posts
Comments Off

Quarterly kwacha rate review, Q1 2021

1 January 2021 09:06:44 +0000

Based on the current value of the Zambian kwacha in US dollars and recent trends, we are increasing our retail kwacha prices effective today and until the next quarterly review by about 7%.

Some sample rates:

webONE hosting plan (monthly): ZMW 330.00
mailONE hosting plan (monthly): ZMW 220.00
gTLD domain (annually): ZMW 425.00

Our new kwacha rates will be online within 24 hours.

Tags: accounts receivable, billing, kwacha, quarterly kwacha rate review, rates, transparency
Categories: Notices, Updated posts
Comments Off

Microlink has apparently shut down

14 September 2020 03:24:27 +0000

Microlink last week apparently sent an email to their customers stating that they were suddenly “shutting down their hosting services”. According to some reports, there weren’t many customers left to send the emails to. However, one of them contacted us and with cooperation from ZICTA we were able to transfer their dot-zm domain under our management, and we got them back online the same day.

However, another former Microlink customer who contacted us wanted to get their @microlink.zm email address working again. We had to inform them that we are unable to do that, because we don’t manage the microlink.zm domain and its DNS and email accounts. It remains under the management of Microlink, or whatever is left of it.

We did contact the (apparently) former IT manager at Microlink (Sanjeev) to offer assistance with moving clients to new hosting and to host email on microlink.zm, but we have not had a response … and quite frankly don’t expect one.

If you are a former hosting customer of Microlink — i.e., you have your own domain, dot-zm or otherwise — that was hosted with them, please contact us and we will assist you in getting your domain back online as quickly as possible. We have the expertise and experience.

Update, 2020-09-18: Although we can’t replace what you lost when Microlink shut down unexpectedly, we can try and ease your pain. If you contact us and sign up before the end of September 2020, we will host you for no charge for ONE YEAR (for a maximum of 25 email addresses), including bringing your dot-zm domain registration up to date. Click here to contact us by email now.

Tags: abandoned domain customers, abandoned hosting customers, domain registration, domain renewals, domains, dot-zm domains, hosting transfer, icann, microlink, registrar transfers
Categories: Notices, Updated posts
Comments Off

Mail server in and out of capricious blacklist

10 March 2020 02:33:48 +0000

As you’re aware, we work hard to ensure that our mail servers do not get into blacklists. On the rare occasion that one of our IP addresses is blacklisted, we investigate the cause of the problem, fix the problem (often a client with a compromised machine) and (if possible) try to have our IP address removed from the blacklist. Often though, manual removal from the blacklist is unnecessary, as modern, well-maintained blacklists are automated, and offending IP addresses are removed very soon after they no longer show any signs of sending spam.

It’s not often any more that we run into old-style blacklists — blacklists that are poorly maintained, that blacklist huge swathes of the Internet, or that offer no discernible removal process — but there are still some of them out there. Not many are used by mail servers that accept email on behalf of any sizeable number of users, but we have run into one that happens to fit that exact trifecta: urbl.hostedemail.com.

This blacklist is used by Hostedemail(.com), a subsidiary of OpenSRS/Tucows. Good luck getting to their website though, as one doesn’t exist. Their email hosting service is a white-label service sold by their resellers, and they don’t even have a way for other mail server administrators to contact them, to search their blacklist or ask to be taken out of it.

Thankfully though, we are still hanging onto our own long-established reseller account with OpenSRS, and we contacted them about this block of our (non-resold) primary mail server (NC036). We first did this in February when we noticed that email from some clients was being blocked with this error message:

host mx.DOMAIN.com.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [178.62.195.26] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted

(It was the reference to being “manually blacklisted” that really got our attention, as this is a hallmark of the aforementioned poorly maintained blacklists.)

OpenSRS responded quickly, and we were removed from the blacklist within about eight hours. But we were surprised to see, a couple of weeks later in March, that we were blacklisted again, so we contacted OpenSRS yet again. The response this time was much slower, but we have again been removed. This time, however, we pressed for an explanation for the block, as we are not listed in about 300 other blacklists that are more widely used. This is part of their response:

I am just replying back on the RBL listing you inquired about and I can confirm the IP was once again de-listed but I did get some additional information for you as requested. I needed to do a bit of checking but the IP 178.62.195.26 is provided by RIPE Network Coordination Centre, the IP assigned to the user by the hosting provider carries the reputation of the rest of the CIDR. The nature of VPS/Shared IPs is to be disposable …. But of course for the time being we have de-listed the IP but assuming nothing changes its [sic] likely it will be listed again in the future.

This kind of outdated thinking is another of the hallmarks of old-style blacklists: blacklisting half of the Internet based on some outmoded way of thinking that died off around the end of the twentieth century. Essentially, Hostedemail.com is blacklisting all IP addresses in major data centres around the world, which is very counterproductive for their own customers.

We’ll be contacting individual clients whose emails were blocked by this blacklist to point them to this post, and we recommend that if your email is blocked with the above message you contact your correspondent by some other means to advise them to move to a more enlightened mail service provider.

Update, 2019-03-19: Our primary mail server is again blacklisted by this one mail provider in the world out of about 300 major blacklists we have checked. OpenSRS/Tucows/Hostedemail warned us this would happen, so we’re not surprised. We can take no further logical action against an illogical practice. We’re sorry to those clients who are affected, but we again suggest that you tell your correspondents to move to an email service provider that doesn’t run their mail servers based on practices from the last century.

Tags: blacklist, blacklisting, blocklist, dnsbl, email, email filtering, reputation
Categories: Notices, Updated posts
Comments Off

WordPress “PHP Update Required”

8 June 2019 09:26:11 +0000

WordPress warning.

A number of clients have contacted us because they’ve noticed that WordPress is now displaying an ominous message on their dashboard that states, “WordPress has detected that your site is running on an insecure version of PHP.” This, unfortunately, is gratuitous, self-serving fearmongering (often referred to as “FUD“) on the part of WordPress the organisation. However, what is true is that version 5.2 of WordPress requires a higher version of PHP than our operating system vendor currently supplies. Therefore, providing the necessary version of PHP will require more work than just clicking a mythical “upgrade PHP” button somewhere, as some assume we just need to do.

Please be assured that we are alive to this issue, and are working to address it as soon as we can. However, it will likely take at least a couple of weeks.

Thank-you for your patience.

Update, 2021-06-28: The usual list of “requirements” that WordPress users look at is the one at wordpress.org/about/requirements, that helpfully includes an email you can send to your hosting company demanding … err … asking for certain versions of the necessary software. A more nuanced (and intelligent) version of this page is available at make.wordpress.org/hosting/handbook/server-environment. It contains far better language and explanations that mirror anything a thinking hosting company will tell you about the demands made by the WordPress organisation.

Tags: upgrade, web hosting, wordpress
Categories: Notices, Updated posts
Comments Off

Spam and virus filtering on the mail server

11 October 2018 15:15:22 +0000

Over the last five months we’ve been monitoring the effectiveness of the anti-spam systems on server NC036 with a view to setting the point at which emails are considered by the system to be spam. We have slowly lowered the cut-off point from the default of 6.2 to 3.0, and have found that at 3.0 the rate of legitimate email caught in the filter rises sharply. Therefore we have now set the default, server-wide level at 3.5. At this point we’re blocking about one thousand to fifteen hundred spams a day, and anywhere from a handful to a few dozen viruses a month.

You can set a different cut-off point for spam to your domain(s) as follows:

Log into the mail server control panel.
Click “Domains & Accounts”.
Click the domain you want to manage.
Click “Spam Policy”.
Enter a different number in the “Classify mail as spam when score is >=” field.
Click the green “Save changes” button.

In short, the lower you set the score the more spam is caught, but the greater the likelihood of legitimate email being classified as spam. Conversely, the higher the score you set the less spam will be caught and the lower the likelihood of legitimate email being classified as spam.

You can also manage other aspects of the spam filter on this page, but we recommend that you do not. The server-wide defaults are to enable all four checks (spam, virus, bad headers and banned files) and to quarantine spam and viruses. If you want to allow any of those four classes of undesirable emails through on your domain that’s your call, but you take full responsibility for the results. The results include everything from annoyance to compromised machines, devices and accounts. NinerNet does charge for time spent recovering and cleaning up compromised accounts.

Please note that the spam and virus filters monitor both incoming and outgoing email.

We strongly recommend, now that we have finished our evaluation, that you conduct your own evaluation of the situation with undesirable email on your own domain or domains. Once logged into the mail server control panel, please navigate to System -> Quarantined Mails. There you will find spam and virus emails to and from your domain(s) for approximately the last week. As mentioned above, if you find that too many legitimate emails are being classified as spam, you have two options: 1) Increase the score at which messages are considered spam, and/or 2) Whitelist any legitimate senders or domains that consistently receive high scores. To whitelist a “sender” (a single email address) or a domain or a domain and all of its sub-domains, follow these instructions:

Log into the mail server control panel.
Click “Domains & Accounts”.
Click the domain you want to manage.
Click “White/Blacklist”.
Follow the instructions on the right of the page to add records to the appropriate whitelist, incoming or outgoing.

Please note that it might be tempting to add something like @yourdomain.com to the outgoing whitelist (thereby whitelisting all addresses on your domain), but we strongly advise you not to. If you do, and a machine on your network is infected with a virus or is compromised and starts spamming, the system will follow your instructions and let it all through. Please see above about our fees for cleaning up after a mess like this. The emails will likely be blocked on the receiving server anyway, and your domain possibly blacklisted. You don’t want you domain (or our mail server) blacklisted, so not whitelisting all of your users is a defence against getting your domain (and our mail server) blacklisted.

Something else to note is that it’s fairly pointless to blacklist spammers and virus senders. If you blacklist bob@example.com because he sent a virus that the virus scanner caught, you’ll also block the legitimate email he sends once he cleans up his machine and sends you an email to apologise. Similarly, spammers rarely use the same email address or domain more than a few times, so you’ll just be filling your blacklist with a lot of crap. Of course, if a persistent spammer keeps getting through the spam filter, then go ahead and blacklist them if they’re actually using the same email address or domain.

Please monitor your quarantine on a regular basis so that you notice trends and compensate for them. With our evaluation ended we will only occasionally monitor the quarantine to make human judgement calls about letting some emails through, as we have been doing over the last five months.

It is worth noting here a couple of points. One is that no spam filter is perfect. During our evaluation we have seen spam come in that was scored less than 3.5, and so will make it through the filter now that we have settled on a cut-off of 3.5. Another is that some legitimate email from senders hosted on this server — i.e., you and your colleagues and employees — has been scored above 3.5 and so has been (or will be) quarantined instead of being delivered to the sender’s mail server. This is why you need to keep an eye on the quarantine for the domains under your account, and if necessary release legitimate emails for delivery. This is how you release emails:

Log into the mail server control panel.
Navigate to System -> Quarantined Mails.
Select the legitimate email or emails.
At the bottom of the page select “release selected” from the “Choose Action” drop-down list.
Click the green “Apply” button.

The emails will then disappear from the quarantine and will be delivered to the recipients. You may also select one of the other three “release” options if you want to release the email and add the sender to your whitelist if their email is consistently being scored highly. As mentioned above, it’s generally a waste of time to select one of the blacklisting options; there’s also no need to manually delete items from the quarantine, as they are rotated out after about a week.

With respect to your own emails being marked as spam, there are some glaring spam markers that we’ve seen commonly used that you and your colleagues and employees can avoid by following these suggestions:

Don’t use blank subjects.
Don’t use ALL CAPITALS subjects. If you do, keep in mind that your method of trying to get the recipient’s attention might fail completely if your message is blocked as spam.
Avoid using very short subjects.
Avoid using “Dear xxxx” in your salutations. Email is a less formal mode of communication than letters, and opening an email with “Dear” is a classic spam marker and will give your email enough extra points that it could push it over the cut-off score, especially when combined with other spam markers listed here.
- Update: Thanks to a client for pointing out that “Dear Bob” or “Dear Mrs. Smith” are not scored as badly as generic salutations such as “Dear sir”, “Dear madam”, “Dear investor”, “Dear home owner”, “Dear winner”, “Dear beneficiary”, “Dear friend”, “Dear you@example.com”, etc.
Don’t send blank emails with only an attachment.

Please note that we don’t read your email. This data is gleaned from the spam reports and the reasons that certain messages were blocked because they were classified as spam.

This spam filter is much better than what we had on the old email server, and now you have access to the information it contains and control over how it works. If you have any questions or concerns, please contact NinerNet support. Thank-you.

Tags: blacklist, blacklisting, email quarantine, security, spam, spam filtering, spam markers, viruses, whitelist, whitelisting
Categories: Notices, Updated posts
Comments Off

Change of domain registrar

28 June 2018 06:39:22 +0000

Over the next year, starting today, we will be migrating all domain registrations under our management to a different domain registrar. For the most part these migrations will take place as the domains are renewed.

To be clear about NinerNet‘s position in the domain ecosystem, we are a reseller of domain registrations, reselling domains registered with domain name registrars, who in turn register domains from domain name registries. For the last seventeen years we have been a reseller for OpenSRS, a subsidiary of Tucows; going forward we will be a reseller for RRPproxy, a subsidiary of Key-Systems, a member of the KeyDrive Group.

Automated emails about your domains will continue to be sent from the same email address we’ve been using for years: domainsupport on the niner.net domain. You will notice a change in the format and language used in these emails. At least initially, links in those emails — such as those requesting you to validate your email address — will be on domains controlled by RRPproxy; however, we will work on using the niner.net domain at some point in the future, but we don’t have a timetable for that yet. The domain used in links in the email address validation emails that you may receive after your domain is transferred is currently ~~emailverification.info~~. (See update below.)

Unless otherwise notified, you will continue to manage your domain registration through the interface at manage.niner.net. Within the next six months the interface at that address will change.

We are looking forward to an improved experience for all clients (except those using dot-zm domains, of course) as a result of this move. If you have any questions or concerns, please let us know. As always, if you are concerned about the legitimacy of an email you’ve received that pertains to your domain or hosting account with us, please forward it to us and we will advise you accordingly.

Thank-you for your business.

Update, 2018-06-29: Please note that, despite our best efforts, the transfer confirmation emails you will receive from our current registrar are sent from two different email addresses not on the niner.net domain: noreply@opensrs.email and transfers@opensrs.org. The inability of OpenSRS to consistently use our domain in messaging over the years (or even just one of their own domains) is a significant symptom of the problems that have led us to make this decision to move. Our apologies for the confusion.

Update, 2018-09-25: Links in the “Request for email address validation” emails are now on the niner.net domain.

Tags: domain registration, domain renewals, domains, registrar transfers
Categories: Notices, Updated posts
Comments Off

Yet more problems with dot-zm (Zambian) domains

9 December 2015 14:33:02 +0000

Back on 16 September a client with a dot-zm domain hosted with us came to us with a problem that had started the day before. The majority of this post documents the details of the monumental effort we had to expend to get the domain registrar (Realtime/Hai) and registry (ZICTA, the Zambia Information & Communications Technology Authority) to do their jobs and provide a working domain.

However, the reason for the timing of this post (which we should have made two months ago) is that we are seeing these same problems again with dot-zm domains. Emails sent to existing dot-zm domains, hosted with different hosting companies, are bouncing because these dot-zm domains seem not to exist on the Internet because the dot-zm nameservers are reporting differing, incomplete or even incorrect information for them.

Unfortunately there is nothing that we can do on our servers when ZICTA’s dot-zm nameservers report — incorrectly! — that a dot-zm domain does not exist or directs traffic to the wrong servers.

Our recommendation for years now, due to the shocking unreliability of dot-zm domains, is that you simply should not register dot-zm domains. This seems awfully unpatriotic — after all, you.co.zm is supposed to be a proud acknowledgement of your association with Zambia — but the sad fact of the matter is that your dot-zm domain is actually an embarrassment and a disservice to you, your business and your country.

We have written about this over and over again over the years. Here’s a recap of some of what we’ve written on our blogs (there’s more lost in the mists of time and in emails sent before we set up our corporate and status blogs):

2010-08-16: Problems with .com.zm domains
2010-08-16: Issues with some .com.zm domains explained
2012-07-27: Dot-zm domains down again
2012-07-27: Dot-zm domains back
2013-06-11: Massive, unannounced deletion of dot-zm domains by Zamnet
2013-06-14: Deletion of domains by Zamnet continues

We also have over 50 MB of raw data (some of it compressed) dating back to 2008 documenting problems with dot-zm domains, including all dot-zm domains going down worldwide. It’s the kind of material with which we could write a thesis about TLD mismanagement, if we had the time … but we don’t.

So what happened in September?

Back on 16 September a client with a dot-zm domain hosted with us came to us with a problem that had started the day before. They were suddenly receiving very little email, and they were being told by some of their correspondents that emails sent to their domain were bouncing. Of course, this galvanised us immediately, and we checked all aspects of their domain’s configuration on our nameservers and mail servers. We could find nothing wrong. However, the problem was undeniable; some mail sent to this client’s domain was indeed bouncing.

So we started digging deeper. We found that, without being asked to do so by the domain registrant (our client), the dot-zm domain registry (ZICTA, whose website is again down as I write this) had changed the nameservers of our client’s domain to those of their domain registrar, Realtime Technologies Ltd., now doing business as Hai Alive Telecommunications — whose websites on both of their domains are also down right now. (Seeing a pattern here?) Both the registrar and the registry denied being responsible for changing the nameservers and refused to explain how it happened. The nameservers were changed back to ours, but the problem persisted.

What we found was that the problem was intermittent, hence the fact that some email was getting through and some was being bounced. An intermittent problem is the worst kind of problem because when things are working there is no problem to find, and when things aren’t working you don’t know when the problem will go away and whether or not you’ll find the problem before it disappears. On top of that mail from multiple different and unrelated sources was being bounced, so we couldn’t blame a particular sender’s improperly configured mail server for the problem.

Seeing as the registrar (Realtime/Hai) blamed NinerNet for the problem, and the registry (ZICTA) refused to deal with us, telling us we had to seek help from the registrar (Realtime/Hai) who was too busy blaming us to investigate, some more investigation by NinerNet revealed that one of the six nameservers that run the dot-zm country-code top-level domain (as of today they’re now down to four) was still broadcasting to the world that the authoritative nameservers for the domain were hosted at Realtime/Hai, which was the result of the unauthorised change to the nameservers a couple of days earlier. (One of the six was failing, and one wasn’t providing the information it was supposed to provide, meaning that three of the six nameservers for dot-zm domains were not working properly!)

There was an easy temporary solution to this problem, seeing as ZICTA was being uncooperative: A few keystrokes by someone at Realtime/Hai could have set up the client’s domain on their nameservers, so that when a mail server was incorrectly directed there it would have received the correct information that we would provide to Realtime/Hai. However, Realtime/Hai refused to help unless the client signed a hosting contract with them and paid money up front, despite the fact that the client/registrant had already paid them for a working domain that they expected to work for the entire length of the contract for that domain. This, of course, was an outrageous attempt at extortion and was rejected.

After hammering away at ZICTA for over a week by email (while trying to get Realtime/Hai to take responsibility for addressing the problem, as the domain registrar is supposed to do) and being ignored (including receiving notifications that emails to them had been deleted unread) — except by one person, the head of “Consumer Protection”, who said that he would help me but then also continued to ignore me, never sending me another email again — I finally picked up the phone and eventually (after six tries and being disconnected twice; this is the “Communications Technology Authority”?!) reached a receptionist. (A month earlier when trying unsuccessfully to deal with ZICTA over another issue, the receptionist couldn’t put me through to the person who could help me with my issue because the whole organisation, except apparently the receptionist, was at a staff meeting!) After explaining the situation to the receptionist she stated that I had to deal with Realtime/Hai. After explaining that Realtime/Hai refused to help, she said that she would only continue to talk to me if I would lodge a complaint against Realtime/Hai, so I reluctantly agreed. After being on hold for over ten minutes while she did who knows what, she came back on the line. This time I literally pleaded with her to give me one minute to fully explain the problem and why the problem was caused by ZICTA and how it was within the power of only ZICTA to fix in less than two minutes.

My pleading must have had an effect, as she agreed to put me through to someone else. That person was apparently a “Cyber Security Analyst” with Zambia CIRT (Computer Incident Response Team, whose website is actually up!). I had to actually give him the computer commands to demonstrate the cause and location of the problem. Miraculously he agreed with my assessment — after eight days of banging my head against brick walls, someone finally understood and agreed! — but could do nothing to fix it right away because (although it was nine o’ clock in the morning) the person who was in charge of running the registry back end was not in yet. However, he did assure me that it would be dealt with that day, although it wasn’t until the next day that I finally received written acknowledgement from ZICTA of the problem they had caused, and it was another two days before they fixed it, twelve days after the problem was created!

So, let’s review …

… how a problem with a dot-zm domain is handled by the registry and its registrar, and how long it takes:

Day one: Client’s dot-zm domain stops working.
It is found that the nameservers for the domain have been changed to use the registrar’s (Realtime/Hai) nameservers instead of NinerNet’s, without the authority of the domain registrant.
Nameservers are changed back; registrar (Realtime/Hai) and registry (ZICTA) deny responsibility and refuse to explain.
Problem persists.
Registrar (Realtime/Hai) refuses to help, attempts to extort money from registrant for services (domain registration) already paid for.
Registry (ZICTA) finally responds, refers problem to registrar (Realtime/Hai). Will only address problem with a formal complaint about registrar (Realtime/Hai).
After pleading with registry (ZICTA) they relent and refer the matter to a staff member who can help.
We have to hold the hand of the person at the registry (ZICTA) to show him how to confirm the nature and location of the problem.
Day thirteen: Problem at ZICTA is finally fixed by ZICTA 3 days later, 12 days after they created the problem in the first place.

It is interesting to note that there is almost no information on the ZICTA website about the management of the dot-zm ccTLD (country-code top-level domain; compare that to, for example, the website of Nominet, the organisation that runs the dot-uk ccTLD), and their Facebook page contains nothing but pages and pages of repetitive so-called FAQs about mobile service, and not a single mention (going back to at least the end of 2014) of dot-zm domains and domain registration. Underneath almost all of the posts by ZICTA with FAQs are reams and reams of complaints about how useless ZICTA is and how they do nothing about consumer complaints. See for yourself.

Is there a solution?

Yes, there is. If someone in Zambia cannot be found to provide competent management and direction to ZICTA — and the wherewithal to whip registrars into shape and to educate them on the need to provide customer service without resorting to blaming hosting providers for issues that are demonstrably not theirs — then the job can and should be outsourced to a foreign company with a good track record.

Just on the other side of the boerewors curtain is ZADNA, the domain authority of South Africa. I don’t know if they offer their services to other national domain authorities to run their ccTLDs, but they’re doing a decent job of running their own (dot-za), have recently (in the last few years) launched a new competitive domain registration system, and launched the new TLDs dot-capetown, dot-durban and dot-joburg. They’re also the leading contender to run dot-africa, if ICANN ever fixes that mess and launches it.
In New Zealand is CoCCA Registry Services (NZ) Limited, with whom ZICTA already has a relationship as they’re using CoCCA’s registry software and have apparently provided some financial consideration for same. As you can see, CoCCA is already running the registries of at least ten TLDs, most of which are those of other small and developing countries.
In Canada there is OpenSRS who offer their services to registrars, but who may also be interested in providing service to a ccTLD registry.

In the more immediate term NinerNet has provided, since 2010, the option of registering a dot-zam.co domain — e.g., ninernet.zam.co. We provide it expressly because of the ongoing, years old problems with the management and administration of the dot-zm ccTLD, not to mention the exorbitant cost of dot-zm domains. Instead of registering companyzambia.com (which is probably available, I should point out) you can instead register company.zam.co. It’s the same number of characters as company.com.zm, and only one more than company.co.zm. But more importantly, it’s reliable!

I should point out that we don’t expose the flaws in the dot-zm ccTLD in order to sell dot-zam.co domains; our setting up dot-zam.co is the result of these flaws. If the dot-zm domain system worked properly, we would never have thought to create the dot-zam.co alternative ccTLD, and we’d certainly have no reason to complain. Besides, having been created in 1994, dot-zm had a sixteen-year head start on dot-zam.co! Dot-zam.co is a long way from being a threat to ZICTA and dot-zm.

Finally, you can switch to a new, non-dot-zm domain. Ideally you would never have registered that dot-zm domain in the first place, but it’s an understandable and forgivable mistake. It’s not ideal to switch to a new domain, but where would you be if your domain went down for two weeks and nobody wanted to help you? Here’s how you do it:

Register your new non-dot-zm domain.
Have your hosting provider set up the hosting for it, and create all of the existing email address on your old domain (e.g., phiri@example.co.zm) on the new domain (e.g., phiri@example.zam.co).
Similarly you would upload your existing website to your new domain, reconfigured to use your new domain instead of your old dot-zm domain. (Doing this properly is a little more involved than what I have laid out here and there are options, but it’s very doable and quite straightforward from a technical point of view for a good host that knows what they’re doing.)
Disable your old dot-zm domain and “alias” it to your new domain. This means that all email to your old dot-zm domain is automatically redirected to your new domain, and all traffic to your old dot-zm website is redirected to your website on your new domain, preserving your ranking in the search engines and all existing links to your old dot-zm domain.
Start using your new domain for email by reconfiguring your email program to use the new domain. While your customers and other contacts may still email you at the old dot-zm domain, your replies will come from your new domain and so their future replies will go straight to your new domain. Of course, you would also advise your customers and contacts of your new domain by email and on your website, and in any other ways that you advertise your business.
Keep your old dot-zm domain for at least a year or two, aliased to your new domain. How long you keep your old dot-zm domain is up to you and would depend on a number of factors (we can advise on that), but the good thing is that when (not if) it goes down again, you will use that opportunity to reinforce with your customers and other contacts the importance of using your new domain.

While some less sympathetic hosting companies may charge you for the time involved in making this change (which is actually quite understandable), we will not charge you even one extra ngwee to make this change away from your old dot-zm domain. We also do not charge any extra hosting fees to alias your old dot-zm domain to your new domain. In other words, changing to a new domain will only cost you the price of the new domain.

Appendix

The email below, sent to the person we spoke to at ZICTA (who also seems to be associated with Zambia CIRT) after we finally managed to talk to him, documents the problem experienced by our client with their dot-zm domain. The client’s domain has been redacted for privacy reasons (changed to example.co.zm), as have the names and email addresses of individuals.

From: Craig Hartnett <hxxxxxxx _AT_ niner.net>
To: cxxxxx _AT_ cirt.zm
CC: exxxx.cxxxxxx _AT_ hai-alive.co.zm, exxxx.mxxxx _AT_ hai-alive.co.zm,
     exxxxxx _AT_ rtaa.com.zm, mxxxxxx _AT_ rtaa.com.zm,
     rxxxxx.zxxxx _AT_ hai-alive.co.zm, servicedesk _AT_ hai-alive.co.zm,
     servicedesk _AT_ rtaa.com.zm, cxxxx _AT_ zicta.zm, info _AT_ zicta.zm,
     kxxxxxx _AT_ zicta.zm, nxxxxx _AT_ example.co.zm, ixxxxxx _AT_ jxxxxxxxxx.com
Subject: Problem with example.co.zm domain
Date: Fri, 25 Sep 2015 09:21:22 +0200
Mailer:	Evolution 3.10.4-0ubuntu2
Organization: NinerNet Communications, www.niner.net

Dear Cxxxxx,

Thank-you for taking my call this morning.

As I explained, the nameservers for the dot-zm TLD are not properly
synchronised, and are therefore reporting different nameservers for the
example.co.zm domain. In particular, pch.nic.zm is reporting incorrect
nameservers.

Of course, this results in disruption of the example.co.zm domain, and
this has been the case since at least Tuesday 15 September. At one point
last week the WHOIS showed only Realtime nameservers for the
example.co.zm domain. Realtime claims that this was the result of some
sort of registry activity -- a reset of some sort if I remember
correctly. These were changed back to NinerNet's nameservers but, as I
explained on the phone, one of the dot-zm nameservers is still responding
with Realtime's nameserver instead of NinerNet's.

Realtime have refused to assist thus far -- even though they are the
registrar of this domain -- instead blaming us (NinerNet Communications,
the company hosting the domain) for the problems. However, this is
clearly refuted by the evidence below, which are fresh queries from a
few minutes ago (with date and time stamps) on all of the dot-zm TLD
nameservers.

I have copied this email to all of the people at Realtime who have been
involved thus far, as well as representatives of the registrant of the
domain.

This should take two minutes for someone with access to the pch.nic.zm
nameserver to fix. Please ensure that this is fixed today so that the
registrant of example.co.zm can get back to running their business.

Thank-you.

Craig Hartnett

[00:13:14 leftseat@wrathall ~]$ date -u
Fri Sep 25 07:13:19 UTC 2015
[00:13:19 leftseat@wrathall ~]$ dig example.co.zm ns @hippo.ru.ac.za

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @hippo.ru.ac.za
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63660
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; AUTHORITY SECTION:
co.zm.                  86400   IN      NS      pch.nic.zm.
co.zm.                  86400   IN      NS      ns-zm.afrinic.net.
co.zm.                  86400   IN      NS      ns1.zamnet.zm.

;; ADDITIONAL SECTION:
ns1.zamnet.zm.          86400   IN      A       196.46.192.26

;; Query time: 348 msec
;; SERVER: 146.231.128.1#53(146.231.128.1)
;; WHEN: Fri Sep 25 00:13:28 PDT 2015
;; MSG SIZE  rcvd: 137

[00:13:28 leftseat@wrathall ~]$ dig example.co.zm ns @ns1.coppernet.zm

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @ns1.coppernet.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17502
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; Query time: 586 msec
;; SERVER: 41.222.240.15#53(41.222.240.15)
;; WHEN: Fri Sep 25 00:13:32 PDT 2015
;; MSG SIZE  rcvd: 43

[00:13:32 leftseat@wrathall ~]$ dig example.co.zm ns @ns1.zamnet.zm

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @ns1.zamnet.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52796
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; AUTHORITY SECTION:
example.co.zm.         86400   IN      NS      ns2.niner.net.
example.co.zm.         86400   IN      NS      ns1.niner.net.

;; Query time: 320 msec
;; SERVER: 196.46.192.26#53(196.46.192.26)
;; WHEN: Fri Sep 25 00:13:38 PDT 2015
;; MSG SIZE  rcvd: 88

[00:13:38 leftseat@wrathall ~]$ dig example.co.zm ns @ns2.zamnet.zm

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @ns2.zamnet.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16638
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; AUTHORITY SECTION:
example.co.zm.         86400   IN      NS      ns1.niner.net.
example.co.zm.         86400   IN      NS      ns2.niner.net.

;; Query time: 338 msec
;; SERVER: 196.46.192.21#53(196.46.192.21)
;; WHEN: Fri Sep 25 00:13:42 PDT 2015
;; MSG SIZE  rcvd: 88

[00:13:42 leftseat@wrathall ~]$ dig example.co.zm ns @ns-zm.afrinic.net

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @ns-zm.afrinic.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36928
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; AUTHORITY SECTION:
example.co.zm.         86400   IN      NS      ns1.niner.net.
example.co.zm.         86400   IN      NS      ns2.niner.net.

;; Query time: 310 msec
;; SERVER: 196.216.168.44#53(196.216.168.44)
;; WHEN: Fri Sep 25 00:13:45 PDT 2015
;; MSG SIZE  rcvd: 88

[00:13:45 leftseat@wrathall ~]$ dig example.co.zm ns @pch.nic.zm

; <<>> DiG 9.9.5-3ubuntu0.5-Ubuntu <<>> example.co.zm ns @pch.nic.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37546
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.co.zm.                        IN      NS

;; AUTHORITY SECTION:
example.co.zm.         86400   IN      NS      dns2.hai-alive.zm.
example.co.zm.         86400   IN      NS      dns2.realtime.zm.
example.co.zm.         86400   IN      NS      dns1.hai-alive.zm.
example.co.zm.         86400   IN      NS      dns3.realtime.zm.
example.co.zm.         86400   IN      NS      dns4.realtime.zm.
example.co.zm.         86400   IN      NS      dns1.realtime.zm.
example.co.zm.         86400   IN      NS      dns4.hai-alive.zm.
example.co.zm.         86400   IN      NS      dns3.hai-alive.zm.

;; Query time: 17 msec
;; SERVER: 204.61.216.73#53(204.61.216.73)
;; WHEN: Fri Sep 25 00:13:49 PDT 2015
;; MSG SIZE  rcvd: 214

[00:13:49 leftseat@wrathall ~]$ date -u
Fri Sep 25 07:13:56 UTC 2015
[00:13:56 leftseat@wrathall ~]$

--
NinerNet Communications | Craig Hartnett
* http://www.niner.net | info _AT_ niner.net
Phone: +1 604 630 1772 | +260 21 1 255568 | 1 855 NINERNET

Update, 2016-12-12: Updated link to CoCCA “patrons” page.

Tags: domain registration, domains, dot-zm domains
Categories: Updated posts, Warnings
Comments Off