We've re-enabled access to viewing your DNS query counts online.

Unfortunately, the May numbers are out of whack: you'll see a large spike in your query counts between May 12 and May 19 which is actually each day's total carried forward and added to the next. This was due to a parser bug caused by a change in the output log format.

Sorry for the on-again/off-again nature of this feature and we should be good to go now.

Following on our explanation of why we do not offer whois masking here at easyDNS, we note tonight that Registrar Namecheap has been sued "over cybersquatting claims for a domain name registered under the NameCheap whois privacy services".

As we outlined in our original article: Whoever is listed as the Registrant in the domain's whois record, effectively owns the domain. If you own the domain, you get all the responsibilities for it. That's why most Registrars simply drop the whois mask at the slightest legal speedbump. Namecheap didn't, and so now it cuts the other way they get the sharp end of the legal stick being poked at the domain.

Technology lawyer Eric Goldman in his analysis of the matter under the subheading Why This is a Troubling Ruling noted:

Read literally, every proxy service is exposed to potential contributory ACPA liability for every domain name it services. I can’t imagine proxy service providers will be excited about that liability exposure, and some may choose to exit the business.

Some certainly should. Any of the proxy providers who basically viewed whois masking as an easy business which basically pulls in money for doing nothing (which is more or less how I view it, I'm sorry, but that's only my opinion) - should take this as their signal that the party's over and exit the business.

As I've noted before, in it's current implmentation: whois privacy doesn't actually protect the underlying registrant's privacy (because most proxy providers will drop the mask at the first sign of trouble) and if they don't, the proxy providers are exposing themselves to inordinate risk. Coupled with the fact that the whois mask puts the underlying registrant's rights to the name in question and the whole thing is just one big mess waiting to blow up.

Update: Catch-alls originating from EasyDNS to Comcast are now once-again unblocked. That being said, please minimize your usage of catch-all wildcard e-mail addresses where you can. It's good practice!

Original Post:

Greetings,

Comcast is currently blocking "catch-all" wildcard e-mail addresses originating from EasyDNS. If you have a wildcard e-mail address set up at EasyDNS, and that wildcard e-mail address points to a Comcast destination address, it will likely end up blocked, by comcast.

Important note: This block DOES NOT impact regular mail forwarding for target-specific e-mail address mailmaps.

The best solutions are to a) use a different destination service provider to funnel wildcard e-mail address at, or b) create specific mail-maps for those important addresses. The immediate fix to get your catch-all e-mail working again is to log in to your EasyDNS account, and edit the e-mail address your catch-all points to, to point at a provider other than Comcast.

We are working diligently with Comcast to get our catch-all processing system unblocked, but in the mean time, they are still blocking us.

Now, with all that being said...

A lot of people use wildcard e-mail addresses to "combat" spam, by creating unique e-mail addresses for every sign-up form. While that does have a limited positive impact for personal filtering, it just leaves you open to dictionary attacks and other uglies, like e-mail backscatter.

Catch-all wildcard e-mail addresses are generally a bad idea, because what they really do is increase your volume of spam exponentially. When you have a wildcard e-mail address implemented, spammers can send to any username at your domain, and our mail servers will accept it, and forward it on. So they don't even have to guess right!

My advice? Don't use part of your domain as a spam shield. You pay good money to own that property. It's impossible these days to keep your mail pristine, but using throwaway addresses in your own domain-space just opens you up to even more spam in places you don't want it to be.

- Do have a throwaway address.
- Don't host it in your domain-space.

If you need a semi-disposable address, GMail provides an excellent service. I wouldn't otherwise suggest you "point your spam at host X" but Google seems to eat it up.

As of tonight you may notice when you log into your member control panel a new item beside each of your domain names called "query usage".

This links you to a monthly histogram depicting the DNS query counts for the domain. Right now we are just compiling aggregate lookups across all
RR types and we it only counts the lookups that resulted in SUCCESS. To get the exact count for a specific day, hover your mouse over the date.

Use the "previous / next" text links in the lower right to scroll backward and forward by month. Keep in mind, we have no data available prior to March, so everything zeros out if you go back further than March 2009.

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.

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.

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

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=

UPDATE: We are pushing this update to February the 7th 2009, at 10:00pm EST

Original notice below;

---

Greetings,

On Saturday January the 31st, 2009, at 10:00pm EST, the EasyDNS admin team will be doing maintenance on our retail members interface. This maintenance will impact members site access and dynamic DNS requests.

DNS queries, mail flow, and web forwarding services will not be impacted.

This maintenance will take between 40 minutes to as long as two hours.

One of the things I love about this business is finding out some of the ultra-cool websites who use us for DNS. The first couple years of this business I think I had every domain name on the system memorized, not so much now.

But I found out today that TedNugent.com uses easyDNS nameservers ROCK ON.

I always loved the Motor City Madman....

We are aware of an issue with our primary mailservers relaying email forwarded emails to destination email addresses within the AT&T network due to a block on their end. Affected destination email address domains are:

@bellsouth.net
@sbcglobal.net
@pacbell.net
@att.net
@ameritech.net
@swbell.net
@prodigy.net
@snet.net

Our sysAdmins have routed email to non-affected mailservers which will allow email to go through, and we are in contact with AT&T to resolve this issue as soon as possible.

We apologise for the inconvenience.

We get asked this a alot: Why do you guys not offer whois masking or whois contact privacy?

The brief background on this is: whenever you register a domain name, your contact details are published in a publicly visible database called "whois", where your contact details are instantly harvested by spambots and marketers who proceed to email and postal mail you marketing offers, deceptive "domain slamming" attempts, ads for dubious products, and perhaps even telemarketing calls.

Nobody likes that, so over the years people started resorting to various tactics to protect themselves from the deluge of crap that inevitably comes with simply registering a domain name: throwaway email addresses in whois records, fake postal addresses, fake phone numbers, etc. The problem is, Registrants are obligated under their various end user agreements to provide true and accurate data (not doing so is grounds to lose one's domain), and the US even passed legislation making it unlawful to use fake contact details in a domain name registration.

Our response to this, years ago, was MyPrivacy.ca which protects your email address from being harvested from your whois records, but leaves your other data intact. We didn't see it as a revenue opportunity, in fact we made it free and opened it up to competing registrars, many of whom started recommending it to their customers. We just wanted to drive a stake through the heart of the whois spammers.

It wasn't long though, before many registrars took it a step further and created the concept of "whois masking" or "contact privacy", where all of the domain-holder contact details would be masked from the public whois. Of course, this was heralded as a "value-add" and most outfits charge extra for it.

In today's long overdue post, we're finally revealing why so-called "whois privacy" puts your domains at risk, costs you more and doesn't really protect your privacy.

Continue reading "Why we do not offer Whois masking at easyDNS"

The issues we experienced with timeouts when querying ns2.easydns.com were cleared up as of approx 3:45pm(EST) on Tuesday Nov 11.

We are still working with our provider to determine the root cause of the issue.

We have been experiencing intermittent connecvtivity issues with
some of the nodes in our ns2.easydns.com anycast cluster.


We have escalated the issue to our providers and are working with
them to resolve the issue.


More info will be posted as it becomes available.

thank you
easyDNS

A number of customers have been registering domains to point to their new websites published via iWeb on their MobileMe accounts. Unfortunately, while MobileMe instructs how to point "www.yourdomain.com" to their services, they don't have a way to easily point just "yourdomain.com" to their services. This is especially important as not everyone on the internet will type "www" before a domain name when looking for a website (such as "www.google.com" versus "google.com").

Realising this is an issue for some of our customers who have DNS-Only services, we have implemented a work around. Simply follow the instructions on MobileMe to have your "www.yourdomain.com" CNAME point to "web.me.com". These are correct, and are very important. However, one last step is to leave your "yourdomain.com" record in the "hosts" block pointing to the word "PENDING". It should look something like this:

A record (host): yourdomain.com
Has IP: PENDING

...with your CNAME looking like this:

C name (alias): www.yourdomain.com
Points to A record (host): web.me.com

Once entered, click "next" to submit your changes, and "next" again after you have confirmed all looks well. These updates may take a few hours to propagate across the internet before you can see them.

If you have any questions at all, please contact our Support Dept., and we would be happy to assist you.