Re: .mu update

From: S Moonesamy <sm+mu_at_elandsys.com>
Date: Tue, 17 Mar 2015 04:37:41 -0700

Hi Ish,
At 03:58 17-03-2015, Ish Sookun wrote:
>I find this ambiguous. Earlier you mentioned
> All the members present agreed that there was
> a problem. The only alternative is a re-delegation of the .mu ccTLD.
>Then you mention
>There was a suggestion that the technical
>operations for .mu be run by the existing .mu ccTLD.

I agree that it can be ambiguous. The
organisation which which .mu ccTLD might be
delegated to could reach any agreement with the
company running the .mu ccTLD for it to run the
technical operation of .mu. That company would
be paid for that work. I sent an email to the
other members of the .mu Select Committee to
inform them that it is the view of the Mauritius
Internet Users that the existing ccTLD should not
be involved in .mu. I still have to discuss with
the other members to find out what the .mu Select
Committee could agree to. I will take up the
concerns expressed in this mailing list as part of the discussions.

>Talking of risks for banks, I have noticed the following for mcb.mu:
>
>While using Google DNS (8.8.8.8) I get :
>
>; <<>> DiG 9.8.3-P1 <<>> _at_8.8.8.8 NS mcb.mu
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20923
>;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
>
>;; QUESTION SECTION:
>;mcb.mu.INNS
>
>;; ANSWER SECTION:
>mcb.mu.267INNSns0.dnsmadeeasy.com.
>mcb.mu.267INNSns1.dnsmadeeasy.com.
>mcb.mu.267INNSns2.dnsmadeeasy.com.
>mcb.mu.267INNSns4.dnsmadeeasy.com.
>mcb.mu.267INNSns3.dnsmadeeasy.com.
>
>;; Query time: 260 msec
>;; SERVER: 8.8.8.8#53(8.8.8.8)
>;; WHEN: Tue Mar 17 14:47:44 2015
>;; MSG SIZE Â rcvd: 129
>
>When using Mauritius Telecom's DNS (202.123.2.11), I get:
>
><<>> DiG 9.8.3-P1 <<>> _at_202.123.2.11 mcb.mu
>; (1 server found)
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35747
>;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>;; WARNING: recursion requested but not available
>
>;; QUESTION SECTION:
>;mcb.mu.INA
>
>;; ANSWER SECTION:
>mcb.mu.86400INA202.123.24.193
>
>;; AUTHORITY SECTION:
>mcb.mu.86400INNSdns2.intnet.mu.
>mcb.mu.86400INNSdns1.intnet.mu.
>
>;; ADDITIONAL SECTION:
>dns1.intnet.mu.86401INA202.123.2.6
>dns2.intnet.mu.86401INA202.123.2.11
>
>;; Query time: 473 msec
>;; SERVER: 202.123.2.11#53(202.123.2.11)
>;; WHEN: Tue Mar 17 14:48:38 2015
>;; MSG SIZE Â rcvd: 117
>
>I am not sure about it but I could conclude that
>MCB Ltd is trying to stay on the safe side if
>someday .mu is switched off. At least through MT
>it could continue serving its customers on the
>island (using MT's DNS). If the bank trusted the
>availability/efficiency of .mu, I don't think they'd adopt such measures.

I agree that the measures do look like the bank
trying to stay on the safe side. I would have to
analyze this before giving you a good answer.

>I don't know what was discussed on the 2009's
>approach. Is there any public information?

No. Although there has been discussions about
.mu over the years there is very little written
or public information about the matter.

>I have stated in the past, I can only comment as
>a user & an IT Professional. As a user I find
>.mu too expensive. A virtual server could cost
>me less than a .mu domain name (assuming I buy a server at $5/month).
>
>As an IT Professional, I can't digest that a
>registrar takes 3 days to update my DNS changes
>& the reason stated is the registry is "manual".

Thanks for the comments. It might be useful if
you also look at .mu as a domain name which you
would use in future and see whether the plan for
that future is reliable. I would like to see the
problem solved in a way where we won't have to
have major concerns about it in, for example,
five years time. It is not be a good idea to
have a disastrous disaster recovery plan. :-)

Regards,
S. Moonesamy
Received on Tue Mar 17 2015 - 11:38:16 PST