.CO domains in, .TEL domains are out.
As is customary here when it comes to new top-level domain rollouts, we’ve added support for .CO domains now that the registry has launched real-time live registrations. As we mentioned in previous posts, we are recommending that if you operate a serious net presence under .COM, you should if you can pickup the corresponding .CO to defend your mark. Hopefully Cameroon doesn’t rebrand .CM anytime soon or we have to go through this again.
On a related note, we are dropping support for new .TEL registrations. At the time we added support we frankly didn’t realize how broken the .TEL implementation is, but as a DNS hosting provider, we are ideologically opposed to a registry that won’t let you set your own nameservers. Existing .TEL domains will continue to be supported.
Zak Muscovitch for CIRA Board
It’s that time of year again when CIRA holds it’s elections for seats on the Board. As I never tire of relating: when I was on the CIRA Board, I got the opportunity to travel across the country and meet .CA domain holders from all walks of life. When the Board held open forums in various venues, the turnout was usually pretty good, and people had a lot to say. Then, near the end of the forum I would always ask the room: Who here voted in the last CIRA election? Very few hands would go up.
The .CA space is unique in that it is one of the very few top-level domains that provide direct member input via the public consultations and the Board elections. I think all interested parties should avail themselves of that opportunity.
Every year the CIRA members (that’s pretty well anybody who holds a .CA domain name) can put one candidate onto the ballot, in addition to the slate of candidates proffered via the CIRA NomCom (Nomination Committee). The member nominees this year are numerous, and I recognize a few names there. It’s a shame we can only show our support for one member nominee at this stage of the game.
So, who should you support from the members’ side of the slate this year?
We had a brief blip on the outbound mail system for “legacy” retail users at the address mailout.easydns.com. We have restarted the responsible service and mail should be flowing again without issue.
Thanks for your patience.
[UPDATE – September 1 @ 1:40pm] – This issue has been resolved. More details about what steps are to be taken are located here:
"Greylisting" on the new mail system
The “Greylisting” service on the new mail system has been disabled for the moment as we troubleshoot some odd results we have been getting with it.
Customers should expect a little bit more spam, but we hope to have the weirdness ironed out by this weekend.
[UPDATE – September 1 @ 1:39pm] – Greylisting has been re-enabled on the new mail system, and we’re also incidentally increasing the capacity of this mail pool preemptively.
DOS Attacks and DNS: How to Stay Up If Your DNS Provider goes DOWN
Nameservers and DNS services are one of the most popular attack vectors for Denial of Service Attacks. Since we wrote the original article, the types of attacks against DNS infrastructure have since bifurcated into two distinct types.
There are basically two reasons why your DNS servers may be attacked:
- To take you down. If not you, then to take down somebody else using the same nameservers you are. So for example, an attack may be directed against the nameservers for a specific vendor, like a DNS provider, a domain registrar, a web hosting provider, an ISP or anybody else hosting multiple domains on behalf of numerous clients. Often times if the attack is successful, the damage goes beyond the target, some or all of the other domains using the same vendor will be impacted
- Amplification and reflection attacks: On the surface similar to above, in that the attack will affect one or more specific vendors, but they differ at the point of the target, which is someplace else entirely. In these attacks the vendors nameserver infrastructure is being leveraged to attack somebody else. It can still affect your vendor and inflict widespread collateral damage, but perhaps more pernicious because neither you nor anybody else sharing the same vendor is the target.
In either case, if your DNS solution gets hit with either of these, you’re the one who suffers the impact if they can’t fully mitigate the attack.
There is a magic bullet to avoid this, and you can ensure you will always have functional DNS no matter what happens to any specific vendor.
That magic bullet is this: