NinerNet Communications™
Blog

Corporate Blog

Zambian domain registrars again taking detrimental action

28 November 2020 04:23:18 +0000

In April we informed you that we had achieved ZICTA accreditation through our partner Preworx. The primary motivation for doing this was to provide reliable domain registration service to Zambians because, as is shown in this blog, the Zambian ccTLD (country code top-level domain) has been very badly managed by the accredited/registered ISPs that provide registrar service. By becoming an accredited registrar ourselves we hoped (and continue to hope) that we could bring our legendary customer service to dot-zm registrants, to give them peace of mind that their domains will operate as expected.

Since April we have taken a number of actions to provide improved service to dot-zm registrants:

  • We have rescued quite a number of domains that were registered through Coppernet,
  • We have helped the registrants of some domains that were previously hosted with or registered through Microlink,
  • We set up an example domain at example.com.zm,
  • We have updated the WHOIS information for all domains that we’ve transferred in from other registrars, so that they are using current and correct contact information and are compliant with all expected norms as far as contact information is concerned,
  • Many domains transferred in from other registrars had expiry dates as long as ten years ago, but all domains have been renewed up to the present, and
  • We have brought some domains “home” from overseas where they were managed by companies gouging Zambians for hundreds of US dollars per year for domain registrations.

We have also been able to use our status as a registrar with direct and established contact with ZICTA to address a number of situations where dot-zm domains were unduly taken offline due to actions taken by their previous registrars. Most recently this took place yesterday (27 November) when domains that are with the registrar AfriConnect (officially, but also known as iConnect and now “inq.”) were taken offline because their nameservers were changed by iConnect/inq without request or authorisation from the registrants. This took these domains offline all day yesterday until finally, at the end of the day, they were restored to working condition again.

Similar issues have taken place with Zamnet and Coppernet in the past, although the latter is no longer in business and the issues with the former took place before our accreditation, so we were not able to do anything except sit on the sidelines and shout! In one recent case a client’s dot-co.zm domain, registered with Zamnet, was down for over a month before it was sorted out by Zamnet! The expiry date on that domain still shows as 2015 in the WHOIS!

These situations are all examples of the fact that dot-zm domains registered with anyone other than NinerNet are in jeopardy of going offline at any time with no notice to the registrants or NinerNet. This is intolerable. Although it is not a technical requirement, ever since April we have insisted that new clients transferring in existing dot-zm domains to our hosting service also transfer their domain registration for management by NinerNet/Preworx. Any existing clients who choose not to transfer their domain registrations to NinerNet will be pointed to this blog post to ensure that they are aware of the risk they are taking if they leave their dot-zm domain registered with another registrar.

Finally, we are continuing to sell dot-zm domain registrations, renewals and transfers for K175.00 per year (50% off!) until 31 December 2020. Contact NinerNet today to arrange for the registration, renewal or transfer of your dot-zm domain!

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.

We now offer dot-zm domain registrations

25 April 2020 01:56:29 +0000

As some of you are aware, we have been pursuing accreditation with ZICTA so that we can register and manage dot-zm domains. In order to accomplish this we partnered with registered ISP Preworx, and our application was recently approved.

This will be particularly good news for those of you who have dot-zm domains registered with a certain registrar who suspends and deletes domains without notice and without billing registrants, as happened most recently in February and will undoubtedly happen again in the future.

We have already transferred those domain registrations for which we are responsible. At the same time we have corrected the registration information for these domains to ensure they are registered by the correct organisations, and are using current contact information.

While we have not recommended dot-zm domains in the past for both technical and administrative reasons, the technical reasons were addressed by ZICTA within the last few years. The administrative reasons are primarily related to poor management by registrars, such as the aforementioned registrar that suspends domains without notice and without issuing invoices. This, as all NinerNet clients know, is not how we conduct business.

Also in the past we have not been able to offer any assistance — only advice — when clients had issues with their dot-zm registrations and registrars. Now, for those clients who have dot-zm domains, if you transfer your dot-zm registration to NinerNet/Preworx, you will be assured of the same service and attention to detail that you are used to with your hosting and other domain registrations. In fact, while it is ultimately your choice whether or not you transfer your dot-zm domain under the management of NinerNet/Preworx, we do strongly recommend that you do.

If you have an existing non-dot-zm domain that includes the word “Zambia” or “Africa” — e.g., company-zambia.com or company.africa — and would like to consider registering a dot-zm instead or as well, please contact us to advise us and we’ll respond with options for you. Your options include:

  • .ac.zm: Academic institutions
  • .biz.zm: Businesses
  • .co.zm: Commercial entities
  • .com.zm: Commercial entities
  • .edu.zm: Academic institutions
  • .gov.zm: Government
  • .info.zm: Information
  • .mil.zm: Military
  • .net.zm: Networks
  • .org.zm: Non-commercial organizations
  • .sch.zm: Schools

Of course, some of the above are restricted.

Pricing has been another reason that dot-zm domains have not been popular. To be frank, we don’t have any firm commitment from ZICTA on our pricing yet. We’d love to be able to say that we know what price we will be charging for domains next year and five years from now, but we can’t. However, as part of our application we did commit to pricing “in line with industry standards for most TLDs.” What this means for now is that we intend to charge the same price for a dot-zm domain that we currently charge for a dot-com, which is K351.50. Actually, considering we’re not paying for dot-zm domain registrations in forex, we’ll peg that at K350 per year unless and until ZICTA makes any significant change to their pricing model.

Even better is that — subject to ZICTA’s pricing — we will charge only half that, K175 for a year, for all transferred and new domains for the rest of 2020. This applies to all existing clients, and any new clients. And remember, we pay a 10% bounty for new clients — to both the referring client and the new client — based on the new client’s spending with us for their first six months.

Please contact us to transfer your existing dot-zm domain (if you have one), or register a new one. Thank-you.

Zamnet deleting dot-zm domains … again!

13 February 2020 05:34:35 +0000

Zamnet’s sleepy accounts receivable department has again risen from its seldom-interrupted slumber to suspend random dot-zm domains. This time they have suspended about 25 per cent of the dot-zm domains that NinerNet hosts — all without a shred of notice to any of their registrants (our hosting clients).

This results in days of downtime while these businesses — some with hundreds of employees and many hundreds of customers across southern Africa — scramble to get a few kwachas to Zamnet’s offices, and then Zamnet takes their time processing the payments. If Zamnet had bothered invoicing for the renewal of these domains in the first place this would likely have never happened. This is not the first time this has occurred; in June 2013 another significant tranche of dot-zm domains were taken offline by Zamnet until registrants coughed up extortionate sums of money (sometimes thirteen years’ worth!) to pay for all the years in which Zamnet didn’t bother to invoice for the renewal of the domains. While that’s the only example we have documented on this blog, it’s not the only example of Zamnet causing dot-zm domains to fail.

NinerNet, in partnership with registered ISP Preworx, are trying to become accredited with ZICTA to register and manage dot-zm domain registrations so that this kind of uncertainty and lack of reliability with dot-zm domain registrations and renewals can be stopped, at least for our clients and those who choose to register their dot-zm domains with us. We made the application in June 2019, but progress on the application has been held up by additional, undocumented steps we have had to take. Only yesterday we happened to submit additional paperwork in support of our application, and this morning we followed up with a complaint about this action by Zamnet and made clear that such an action would never happen under our watch. It is unclear to us what obstacles will be placed in our path now, but it is the incompetence demonstrated by incumbent registrars like Zamnet that drives us forward to our goal.

If you’d like to voice support for the application by Preworx to become a dot-zm domain registrar, we encourage you to voice this support through the ZICTA website. Thank-you.

Zambian domains update

27 December 2016 03:17:55 +0000

To update our earlier post, ZICTA finally contacted us on the afternoon of the 12th. Again — unbelievably — we had to explain basic networking concepts to them to help them understand why our client’s domain was not working.

However, they also explained or blamed part of the problem on Zamnet for not deleting the domain from their nameservers after they had hosted it previously. Zamnet are entrusted by ZICTA with the stability and security of two of the four nameservers that run the dot-zm ccTLD, and yet they apparently can’t perform basic nameserver maintenance. This is shocking to say the least.

Our client’s domain was finally back online again and stable and functioning properly by the 13th (after we contacted ZICTA on the 10th) … but for how long? It is only a matter of time before either our client’s dot-zm domain or another dot-zm domain goes down, again caused by mismanagement by ZICTA or one of the organisations they contract to provide name service.

Don’t register dot-zm domains. Seriously.

Zambian domains (.zm) are broken, don’t register them

12 December 2016 08:53:45 +0000

A little over a year ago we detailed the laborious process by which we managed to bypass an incompetent dot-zm domain registrar — Realtime Technologies Ltd. / Hai Alive Telecommunications — to speak directly to ZICTA (the Zambia Information & Communications Technology Authority) about a problem caused by ZICTA and misdiagnosed by Realtime/HAI.

You may or may not believe this, but the exact same thing is happening again, but with a different dot-zm domain registered through Realtime/HAI.

We contacted ZICTA and Zambia CIRT, through the same channels we used last time, early on the morning of Saturday 10 December. Over forty-eight hours later we still have not received an acknowledgement of our email, and the problem persists.

With the domain redacted to protect our client’s privacy, the evidence that is much the same as for the problem last year is presented below. What is particularly interesting about the information reported by one of the dot-zm nameservers (hippo.ru.ac.za) is that it is still reporting the pch.nic.zm and ns1.coppernet.zm nameservers as being authoritative for the dot-zm ccTLD. (See the IANA website for the nameservers for the dot-zm ccTLD.) The former was the problem nameserver last year, and was apparently promptly decommissioned after our report. However, I see that it is now back online at a new location. Ironically, this time it is actually reporting the correct DNS information for this domain. The latter belongs to the now-defunct Coppernet; although there is still an A record pointing ns1.coppernet.zm to 41.222.240.15, that nameserver simply does not respond at all.

We’ll post further updates when (or if) this problem is resolved. However, we really cannot emphasise strongly enough that you should not register dot-zm domains, and if you have one, you should transition away from it as soon as possible.


Update, 2016-12-27: Posted an update.


[00:00:05 leftseat@wrathall ~]$ whois zxxx.org.zm
Domain Name: zxxx.org.zm
Domain ID: 11559-zicta
WHOIS Server: whois.nic.zm
Referral URL:
Updated Date: 2016-11-29T11:40:45.292Z
Creation Date: 2015-05-12T09:27:15.528Z
Registry Expiry Date: 2017-05-12T09:27:15.611Z
Sponsoring Registrar: Realtime (Z)
Sponsoring Registrar IANA ID:
Domain Status: ok
Registrant Name: REDACTED
Registrant Organization: REDACTED
Registrant Street: lusaka
Registrant City: lusaka
Registrant State/Province: lusaka
Registrant Postal Code: 10101
Registrant Country: ZM
Registrant Phone: +260.REDACTED
Registrant Phone Ext:
Registrant Email: REDACTED
Name Server: ns1.niner.net
Name Server: ns2.niner.net
DNSSEC: unsigned
Additional Section
Sponsoring Registrar URL:
Sponsoring Registrar Country: ZM
Sponsoring Registrar Phone:
Sponsoring Registrar Fax:
Sponsoring Registrar Customer Service Contact:
Sponsoring Registrar Customer Service Email:
Sponsoring Registrar Admin Contact:
Sponsoring Registrar Admin Email:
>>> Last update of WHOIS database: 2016-12-12T07:31:46.321Z <<<

TERMS OF USE: You are not authorized to access or query our WHOIS database through the use of electronic processes that are high-volume and automated.  THis WHOIS database is provided by as a service to the internet community.

The data is for information purposes only. We do not guarantee its accuracy. By submitting a WHOIS query, you agree to abide by the following terms of use: You agree that you may use this Data only for lawful purposes and that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail, telephone, or facsimile; or (2) enable high volume, automated, electronic processes. The compilation, repackaging, dissemination or other use of this Data is expressly prohibited.
[00:00:14 leftseat@wrathall ~]$ dig zxxx.org.zm ns

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51871
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;zxxx.org.zm.			IN	NS

;; ANSWER SECTION:
zxxx.org.zm.		300	IN	NS	ns1.niner.net.
zxxx.org.zm.		300	IN	NS	ns2.niner.net.

;; Query time: 4627 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Dec 12 00:00:28 PST 2016
;; MSG SIZE  rcvd: 85

[00:00:28 leftseat@wrathall ~]$ dig zxxx.org.zm ns @ns1.niner.net

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns @ns1.niner.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34521
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

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

;; ANSWER SECTION:
zxxx.org.zm.		300	IN	NS	ns1.niner.net.
zxxx.org.zm.		300	IN	NS	ns2.niner.net.

;; ADDITIONAL SECTION:
ns1.niner.net.		300	IN	A	65.61.166.128
ns2.niner.net.		300	IN	A	65.61.166.129

;; Query time: 97 msec
;; SERVER: 65.61.166.128#53(65.61.166.128)
;; WHEN: Mon Dec 12 00:00:36 PST 2016
;; MSG SIZE  rcvd: 117

[00:00:36 leftseat@wrathall ~]$ dig zxxx.org.zm ns @hippo.ru.ac.za

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

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

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

;; ADDITIONAL SECTION:
ns1.zamnet.zm.		86400	IN	A	196.46.192.26
ns1.coppernet.zm.	86400	IN	A	41.222.240.15
ns2.zamnet.zm.		86400	IN	A	196.46.192.21

;; Query time: 347 msec
;; SERVER: 146.231.128.1#53(146.231.128.1)
;; WHEN: Mon Dec 12 00:03:14 PST 2016
;; MSG SIZE  rcvd: 212

[00:03:14 leftseat@wrathall ~]$ dig zxxx.org.zm ns @ns1.zamnet.zm

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns @ns1.zamnet.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5881
;; 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:
;zxxx.org.zm.			IN	NS

;; AUTHORITY SECTION:
zxxx.org.zm.		86400	IN	NS	ns1.niner.net.
zxxx.org.zm.		86400	IN	NS	ns2.niner.net.

;; Query time: 330 msec
;; SERVER: 196.46.192.26#53(196.46.192.26)
;; WHEN: Mon Dec 12 00:03:35 PST 2016
;; MSG SIZE  rcvd: 85

[00:03:35 leftseat@wrathall ~]$ dig zxxx.org.zm ns @ns2.zamnet.zm

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

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

;; ANSWER SECTION:
zxxx.org.zm.		604800	IN	NS	ns2.zamnet.zm.
zxxx.org.zm.		604800	IN	NS	ns5.zamnet.zm.

;; Query time: 337 msec
;; SERVER: 196.46.192.21#53(196.46.192.21)
;; WHEN: Mon Dec 12 00:03:42 PST 2016
;; MSG SIZE  rcvd: 83

[00:03:42 leftseat@wrathall ~]$ dig zxxx.org.zm ns @ns-zm.afrinic.net

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns @ns-zm.afrinic.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43162
;; 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:
;zxxx.org.zm.			IN	NS

;; AUTHORITY SECTION:
zxxx.org.zm.		86400	IN	NS	ns1.niner.net.
zxxx.org.zm.		86400	IN	NS	ns2.niner.net.

;; Query time: 324 msec
;; SERVER: 196.216.168.44#53(196.216.168.44)
;; WHEN: Mon Dec 12 00:03:53 PST 2016
;; MSG SIZE  rcvd: 85

[00:03:53 leftseat@wrathall ~]$ dig pch.nic.zm any

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> pch.nic.zm any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 261
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;pch.nic.zm.			IN	ANY

;; ANSWER SECTION:
pch.nic.zm.		81758	IN	A	204.61.216.73

;; Query time: 10 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Dec 12 00:16:20 PST 2016
;; MSG SIZE  rcvd: 55

[00:16:20 leftseat@wrathall ~]$ whois 204.61.216.73

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=204.61.216.73?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#

NetRange:       204.61.208.0 - 204.61.217.255
CIDR:           204.61.216.0/23, 204.61.208.0/21
NetName:        WOODYNET-204-61-208-0-21
NetHandle:      NET-204-61-208-0-1
Parent:         NET204 (NET-204-0-0-0-0)
NetType:        Direct Assignment
OriginAS:
Organization:   WoodyNet (WOODYN)
RegDate:        1995-01-26
Updated:        2012-03-02
Ref:            https://whois.arin.net/rest/net/NET-204-61-208-0-1

OrgName:        WoodyNet
OrgId:          WOODYN
Address:        2351 Virginia St
City:           Berkeley
StateProv:      CA
PostalCode:     94709-1315
Country:        US
RegDate:        2001-05-16
Updated:        2013-04-02
Ref:            https://whois.arin.net/rest/org/WOODYN

OrgAbuseHandle: BW1324-ARIN
OrgAbuseName:   Woodcock, Bill
OrgAbusePhone:  +1-415-831-3103
OrgAbuseEmail:  woody_AT_pch.net
OrgAbuseRef:    https://whois.arin.net/rest/poc/BW1324-ARIN

OrgTechHandle: BW1324-ARIN
OrgTechName:   Woodcock, Bill
OrgTechPhone:  +1-415-831-3103
OrgTechEmail:  woody_AT_pch.net
OrgTechRef:    https://whois.arin.net/rest/poc/BW1324-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

[00:16:32 leftseat@wrathall ~]$ dig -x 204.61.216.73

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> -x 204.61.216.73
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;73.216.61.204.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
73.216.61.204.in-addr.arpa. 900	IN	PTR	pch.nic.zm.

;; Query time: 1670 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Dec 12 00:16:44 PST 2016
;; MSG SIZE  rcvd: 79

[00:16:44 leftseat@wrathall ~]$ dig zxxx.org.zm ns @pch.nic.zm

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns @pch.nic.zm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10234
;; 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:
;zxxx.org.zm.			IN	NS

;; AUTHORITY SECTION:
zxxx.org.zm.		86400	IN	NS	ns2.niner.net.
zxxx.org.zm.		86400	IN	NS	ns1.niner.net.

;; Query time: 11 msec
;; SERVER: 204.61.216.73#53(204.61.216.73)
;; WHEN: Mon Dec 12 00:17:20 PST 2016
;; MSG SIZE  rcvd: 85

[00:17:20 leftseat@wrathall ~]$ dig ns1.coppernet.zm any

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> ns1.coppernet.zm any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4953
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;ns1.coppernet.zm.		IN	ANY

;; ANSWER SECTION:
ns1.coppernet.zm.	86375	IN	A	41.222.240.15

;; Query time: 11 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Dec 12 00:36:07 PST 2016
;; MSG SIZE  rcvd: 61

[00:36:07 leftseat@wrathall ~]$ whois 41.222.240.15
% This is the AfriNIC Whois server.

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '41.222.240.0 - 41.222.241.255'

% No abuse contact registered for 41.222.240.0 - 41.222.241.255

inetnum:        41.222.240.0 - 41.222.241.255
netname:        CUNET-LSK-01
descr:          Allocation to CopperNET Solutions, an ISP in Zambia.
country:        ZM
admin-c:        KWC1-AFRINIC
tech-c:         KWC1-AFRINIC
status:         ASSIGNED PA
remarks:        Please send abuse notification to abuse@coppernet.zm
mnt-by:         COPSOL-MNT
source:         AFRINIC # Filtered
parent:         41.222.240.0 - 41.222.243.255

person:         Kasopa W Chisanga
address:        Silicon House, Kantanta Street
address:        P.O Box 22149, Kitwe
address:        ZM
phone:          +260-212-245011
phone:          +260-212-245200
phone:          +260-212-245222
nic-hdl:        KWC1-AFRINIC
remarks:        CopperNET Solutions.
source:         AFRINIC # Filtered

[00:36:20 leftseat@wrathall ~]$ dig -x 41.222.240.15

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> -x 41.222.240.15
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11716
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;15.240.222.41.in-addr.arpa.	IN	PTR

;; Query time: 1916 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Mon Dec 12 00:36:30 PST 2016
;; MSG SIZE  rcvd: 55

[00:36:30 leftseat@wrathall ~]$ traceroute 41.222.240.15
traceroute to 41.222.240.15 (41.222.240.15), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.372 ms  0.780 ms  0.781 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[00:37:15 leftseat@wrathall ~]$ dig zxxx.org.zm ns @ns1.coppernet.zm

; <<>> DiG 9.9.5-3ubuntu0.10-Ubuntu <<>> zxxx.org.zm ns @ns1.coppernet.zm
;; global options: +cmd
;; connection timed out; no servers could be reached
[00:38:21 leftseat@wrathall ~]$

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

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:

  1. Register your new non-dot-zm domain.
  2. 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).
  3. 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.)
  4. 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.
  5. 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.
  6. 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.

Deletion of domains by Zamnet continues

14 June 2013 14:32:22 +0000

Not satisfied with having deleted 37 per cent of domains earlier this week, it appears that Zamnet continue to delete even more domains! Today we find out that domains that were still working on Tuesday have now been deleted, causing more clients to scramble because their email and websites have suddenly stopped working. This brings the percentage of domains deleted without warning due to Zamnet’s incompetence to 42 per cent … almost half! When will this stop?!

We encourage clients affected by these arbitrary and unannounced interruptions to their business to file a complaint with the Zambia Information and Communication Technology Authority. (UPDATE, 2013-06-28: The complaint form disappeared shortly after we posted this. Try their “Complaint Handling” page instead.)

Massive, unannounced deletion of dot-zm domains by Zamnet

11 June 2013 11:15:39 +0000

Over the last few days it has become apparent to us that Zamnet’s accounting department — just as Coppernet’s did almost three years ago — awoke from a long hibernation and realised that a chunk of active domains hadn’t been paid for. As a result, 37 per cent of the dot-zm domains hosted by NinerNet that are (or were) registered with Zamnet — which includes .co.zm, .org.zm and .sch.zm domains — were deleted by Zamnet, taking them off the Internet completely. One client tells us that Zamnet informed them, when they enquired, that they were supposedly four years behind! (UPDATE, 2013-06-28: Another client tells us they had not been invoiced for their dot-co.zm domain in thirteen years! They’ve since switched to a dot-com with “zambia” tacked onto their name, as so many people do to avoid the hassle and expense of registering a dot-zm domain.)

It seems unlikely to us that so many Zamnet customers had simply ignored their invoices for several years. It’s more likely that they were never invoiced. In fact, our own domain (ninernet.co.zm) came up for renewal over a month ago, and we still have not received an invoice. Perhaps Zamnet are too busy disabling over a third of the country’s Internet infrastructure to send out invoices! (CORRECTION, 2013-06-28: Oops, seems we hadn’t updated our records correctly. Zamnet [when they do invoice] bills for domains every two years. Ours does not expire until next year. Our apologies for the incorrect statement, although it doesn’t really change much!)

Screenshot of Zamnet home page, 11 June 2013.

Screenshot of Zamnet home page, 11 June 2013

Other countries take the management of their ccTLD (country code top-level domain) far more seriously than this. They have published rules and procedures governing what exactly happens after a domain expires. They also operate a WHOIS service so that the public can look up “who is” the owner of a domain and the dates that it was registered and will expire. Zamnet and Coppernet, as co-stewards of the dot-zm ccTLD — an odd arrangement that we are not aware of in any other country — do not provide any such information, at least to the public. In fact, judging by these arbitrary and cavalier mass deletions carried out by both companies, they don’t even have any such policies! They just seem to make this up as they go along.

Screenshot of ZICTA home page, 11 June 2013.

Screenshot of ZICTA home page, 11 June 2013

You would think that — given that deleting 37 per cent of the country’s domains has all of the appearance of a planned and concerted effort — Zamnet would, at the very least, post a prominent notice on the home page of their website. However, there is no such notice as of posting this. (Click on the thumbnail at left to see.) I’m also not aware of any notices posted in newspapers. So much for their laughable slogan: “Nobody delivers IT better.” Right now, more than a third of their customers are not getting anything delivered, and it’s clear that their slogan doesn’t apply to the delivery of invoices.

 

And where is ZICTA in all of this? You’d think they’d be interested in the disabling of 37 per cent of the country’s domains, but there’s nothing posted on the home page of their website either! Maybe a few complaints via their complaint form might get their attention. (UPDATE, 2013-06-28: Hmm, the complaint form disappeared shortly after we posted this. Try their “Complaint Handling” page instead.)

Please note that, if you did not register your dot-zm domain through NinerNet, we do not know when it is scheduled to expire and we cannot help you in dealing with Zamnet. We don’t know how effective it would be to request an update to the contact information for your domain so that we can monitor it, from an administrative (not technical) point of view, but if you’d like to try we’re certainly game to assist and cooperate. Let us know if you’d like to try.

Issues such as these mass and arbitrary deletions, as well as the entire dot-zm ccTLD going down occasionally, are the two main reason we discourage clients from registering dot-zm domains. This is unfortunate, of course, but clients expect their online services to actually be … online! It is also the reason that we created the alternative ccTLD for Zambia: dot-zam.co. They’re only K66 per year (as opposed to hundreds for a dot-co.zm and hundreds more for a dot-com.zm) and don’t require paperwork.

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 it entails. This includes concomitant industries and activities such as domain registration, SSL/TLS 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 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 icann invoices iphone kwacha maintenance paying your bill paying your invoice quarterly kwacha rate review rates registrar transfers reputation scams search engine optimisation search engine optimization security seo service hours spam ssl ssl/tls support transparency wordpress zamnet

Resources:

On NinerNet: