Do you really need to register your name under .tel?

We’ve turned up .tel registrations now that they’ve gone realtime and the initial registry implosion has stabilized. You may have noticed a distinct lack of urgency from us to light a fire under your keester to go register your name under .tel right now before somebody else takes it.

As we outlined previously, we find the hoopla around new top-level domain rollouts both tiresome and for the majority of domain holders, unnecessary. So we have a policy here that we generally a) don’t launch the new TLD until it goes realtime and is considered “stable” and b) we don’t try to whip our users into a hysterical frenzy ahead of time to register their domains under every new TLD.

The fact is, in the future there will be more top-level-domains, a lot more. So many of them that between obvious typos of one’s domain, one’s core domain or domains, and one’s local geographic top-level domain, it will be a fool’s errand to try and register your name under every new TLD that comes along just for the sake of “defending your mark”.

The other problem is, .tel is severely crippled

While we do find .tel slightly unique in the realm of new TLDs because it actually exists for a reason: to cultivate internet telephony usage. This isn’t some country-code ccTLD hiring out their namespace under some made-up reason (.me, .tv, .ws, et al) to draw in foreign registrants, it’s an actual TLD geared toward SIP, VOIP and telephony and exists for that reason.

But .tel isn’t doing anything under the space that can’t be done under any other domain name with the appropriate use of SRV or NAPTR records and to actually make matters worse, you are forced to use their nameservers and your domains are under an Acceptable Use Policy which forces you to use the name for certain things (basically as a “contact” switch rather than a “content” page).

While the objective may be laudable: giving a TLD an actual raison d’etre beyond “register your name before somebody else does!”, we don’t like that you’re forced to use their nameservers and don’t have total latitude with your .tel domains. It runs contrary to the ethos behind easyDNS which was, and still is to drive a stake through the heart of lock-in. (It’s not like we force everybody who registers a domain through us to use our nameservers because we’re an outsourced DNS host, in fact we even allow our members to mirror their DNS from our nameservers from outside DNS hosts).

As such we have not become directly accredited under .tel, instead we’re supporting them through our OpenSRS reseller tag, but the functionality is transparent.

Most of you reading this probably have no compelling reason to register your name under .tel unless 1) you like the TLD or 2) you have operations in the IP telephony space that would make sense segmenting under a .tel name and 3) you don’t mind the crippled functionality and lock-in.

Bug fixed for some dynamic DNS clients

If your dynamic DNS client suddenly started having trouble sending updates over the last few days it is probably because your client does not support SSL connections and it was encountering a “302 found” response from our end redirecting it to an https address which it couldn’t follow.

That should now be fixed and dynamic updates should be working as expected.

We’re sorry about any glitches this would have caused.

Hat tip to former easyDNS partner Colin Viebrock for the clue.

New easyDNS Member feedback survey

Many of you may not know that we have an ongoing member feedback survey where we ask for your thoughts and impressions of using easyDNS.

We try to make it as unobtrusive as possible, and for each respondent we make a $5 donation to a charity of your choosing (World Wildlife Fund, Children’s Wish Fund or Unicef).

We’ve recoded the survey using eSurveys.com. Feel free to give us your thoughts by taking it today.

easyDNS Member Survey

smtp.easydns.com and smtp2.easydns.com now rejecting mail from clients with no reverse lookups or bogus reverse lookups

Greetings everyone,

Due to a breathtaking number of new compromised PCs hitting our primary and secondary mail hubs, we are now rejecting e-mail from hosts that have no reverse lookup, or a bogus reverse lookup.

This means that if the IP address of your mail server does not have a legitimate reverse “PTR” record, we will reject your mail with a 450 error. This is a soft-bounce, meaning we will not instruct your mail server to discard the mail, rather we ask your mail server to try again later.

This gives everyone lots of time to resolve reverse lookup weirdness.

In the event that your mail server is being rejected by this new method, the best thing to do is to contact your service provider and have them set up a legitimate PTR record for your IP address that has a corresponding forward lookup.

So let’s say my mail server is mail.example.com: my IP address is 172.16.1.1.

If I do a “host” command to look up the PTR of 172.16.1.1, and my PTR record comes back as 172-16-1-1.provider.example.com, but then when I do a host on 172-16-1-1.provider.example.com, that record doesn’t exist, smtp.easydns.com will reject that mail with a 450 soft-bounce error.

The solution is to set a PTR record on 172.16.1.1 to mail.example.com. Either by doing it on your systems (if you have that access, great!) or by contacting your service provider to have that PTR record set up.

This policy stops two things; 1) Mis-configured or compromised hosts that were never supposed to send mail, but are sending mail, have a harder time sending us mail and 2) Malicious hosts that have fake PTR records like “totally-legit.mail.google.com” are not able to forge authenticity.

This is actually an industry norm; previously we haven’t turned this method up because we’ve had the capacity and tolerance to let it slide in the past, but the landscape of e-mail and SMTP based service has changed to the point where we don’t have that luxury anymore.

An example log line is included below;

Mar 6 06:26:08 mymailserver postfix/smtpd[21246]: NOQUEUE: reject: RCPT from unknown[172.16.1.1]: 450 4.7.1 Client host rejected: cannot find your hostname, [172.16.1.1]; from= to= proto=ESMTP helo=