easyDNS Blog - Industry Watch

Whois Privacy brings a lawsuit down on Registrar

nospam@example.com (Mark Jeftovic) — Sat, 30 May 2009 09:30:00 -0400

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 cant 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.

DNS cache poisoning exploit released

nospam@example.com (Simon Carr) — Wed, 23 Jul 2008 20:52:51 -0400

Hi There,

There is a new DNS Cache poisoning disclosure that has been inadvertently leaked before it was scheduled to be released by Dan
Kaminsky (IOActive). This is a very serious flaw in the DNS protocol that impacts caching resolvers, like the resolvers hosted at your
service provider that help your workstation resolve IP addresses to domain names.

This bug does not directly impact authoritative name servers like the ones used to host your domain names at EasyDNS. Our name servers do not
request answers from external sources, and rely entirely on internal cache files to offer answers. So for example, nobody will be able to change your IP information on our end. That part of the bug is unfortunately located at the caching end.

That being said; this is still a serious flaw, and we are taking this opportunity to upgrade the DNS software on our authoritative name servers to ensure that we are 100% compatible across the board with the newly upgraded caching name servers located at your Internet Service Provider. These upgrades should not impact name resolution if you are using more than one of our name servers to serve answers for your domain name (actually, please ensure that you are).

To make sure your Internet Service Provider is up to speed, you can use Dan Kaminsky's test script at DoxPora Research. If your Internet Service Provider is not yet up to speed, you may want to give them a nudge and/or change your DNS resolver configuration to a more trusted service.

Update It is now making news that an exploit to this attack has been released., please see our post about our newly launched DNSresolvers.com if you are looking for safe resolvers.

.ME Top Level Domain launch indicative of new TLD rollouts

nospam@example.com (Mark Jeftovic) — Thu, 17 Jul 2008 07:52:00 -0400

We've gotten a few invitations to apply to be a .ME top-level domain registrar, to which we assigned no urgency after we took a straw poll internally and found that pretty well zero of our customers were asking for it. Today, Techcrunch reports that the .ME landrush, at least through one large operator, had degraded into a fracas. We have an unwritten policy here: new Top Level Domain roll outs are to be avoided until they i) get past sunrise without erupting into a malestrom of lawsuits and ii) get past "go-live" without imploding.

It runs contrary to industry standards where registrars whip their customer base into a frenzy over an exaggerated need to protect one's trademarks and claim one's stake in the latest "must have" TLD. The fact is, all you really need to care about are .COM, .NET and .ORG plus the ccTLD of the country you live in or do a lot of business in. (I will probably catch flack for saying .BIZ and .INFO are not crucial must-haves to your domain portfolio - we grabbed ours, at considerable expense in the case of .INFO and it was our experience in the roll out of these two that largely formed our policy.)

That most of these new TLDs roll out with initial 2-year registration period minimums are just an outright cash grab from the registry that most participating registrars are happy to join in on. They know that the sunrise and landrush frenzies they hope to whip up are the single greatest revenue events these TLDs ever experience. After the hoopla dies off and organizations realize how unimportant owning say ".ZX" is in their overall domain strategy and the domainers who piled in find out the aftermarket for the TLD is lackluster at best, the renewal rates predictably fall off a cliff.

So when the next "must have" TLD comes along and participating registrars start lovebombing their customers with reasons why they absolutely must "protect their name" in the new TLD, we often commit the egregious sin among investment bankers, VC's and pundits - that of "leaving money on the table" and we just don't rush in and push the new TLD. If it prevents us from leading our members off a ciff in to a major debacle, we consider ourselves as having done our job. (This was a similar rationale to why we never entered the IDN space, as long as you need a browser plug-in to make internationalized domain names even borderline usable they are, in our opinion, of marginal utility - we stayed out of it)

This is in line with our lifelong strategy of cultivating members who actually use their domains rather than pushing the "get your name before its gone" angle for every TLD under the sun on anybody who can fog a mirror. When we launched back in '98, we couldn't even register domains at all, so our member base was exclusively people who were actively using their domains and wanted outsourced DNS and/or forwarding. That set the tone for our positioning and culture ever since, and while now we do have a lot of customers using us "as registrar", our core is always the active domain users.

We have almost zero "domainers" with large portfolios of parked domains and speculative registrations because our model simply doesn't work for those types of users. It's not a judgement against domainers, it's just not where we came from.

All that said, you would probably think we are opposed to the new "free-for-all" TLD expansion policy hinted to in the recent ICANN meeting in Paris. We are not. We would welcome this new tlds policy (if it ever actually happens) because it removes the artifical scarcity and counteracts that "cashgrab" mentality we sniff at the root of many a new TLD. If new TLDs are coming out all over the place, two things happen:

1) Organizations realize that it is no longer practical to attempt to "protect their name" in every TLD space, so they stop trying. This removes a lot of the "easy money" underwriting new TLDs, some of which would otherwise launch for the thinly disguised reason of trying to milk the Sunrise for all its worth.

2) The above impetus gone, new TLDs will have to compete in a much more open market. Registries, while having de facto localized monopolies within their own TLDs will have to provide actual value to compete with other TLDs.

That appeals to our sense of market freedom: less artificial barriers compelling a drive toward providing more value and benefits. The winners in the end should be the domain registrants, who are, let's not forget, our customers.

Please note: ORDB anti-spam list no longer operational...

nospam@example.com (easyDNS Support) — Wed, 26 Mar 2008 14:46:17 -0400

A number of our customers who maintain their own mailservers have called reporting issues with the delivery of their email in the last 24 hours. If you are experiencing something similar, please ensure that you are not using the ORDB anti-spam list.

The ORDB anti-spam list was shut down in December 2006, and in an effort to fully deactivate the list, ORDB is now sending out false positives. This means that if your mailserver relies on the ORDB anti-spam list, your mailserver is more than likely rejecting ALL EMAIL that is being relayed to it.

Please ensure you remove your mailserver's dependence on ORDB, as this will correct this specific issue.

Discussion about this recent development with ORDB can be found at the following URL upon Slashdot:

http://it.slashdot.org/article.pl?sid=08/03/25/2124224

Enhanced DNS resolution using OpenDNS

nospam@example.com (Mark Jeftovic) — Mon, 10 Jul 2006 17:04:00 -0400

OpenDNS is an enhanced DNS resolver open to the public (as of today) and free to use. It contains a number of enhancements such as typo correction and phishing protection.

It is also fully configurable for the end users, so individual features can be turned off at the users' discretion.

I've also posted a comment on CircleId explaining why OpenDNS is not Sitefinder 2.0



(By way of quick explanation to the layman, there are three kinds of nameservers that affect your life:



Root nameservers: which top level domain registries operate, such as the root nameservers for .com or .ca

Authoritative nameservers: for individual domains. This is the business easyDNS is in: answering DNS queries authoritatively for its member domains. 

Recursive nameservers or resolvers: these nameservers find out DNS info on behalf of its users. Usually these are transparent to end-users and supplied by ISPs, often via DHCP. OpenDNS is now in this business. )

China Top Level Domain news

nospam@example.com (Mark Jeftovic) — Tue, 28 Feb 2006 06:32:59 -0500

There has been a remarkable lack of chatter today around domain policy circles, given the rather stunning announcement out of china that starting tomorrow, China will be launching its own Top Level Domain roots for the .COM, .NET TLDs so that "[Chinese] Internet users don't have to surf the Web via the servers under the management of the Internet Corporation for Assigned Names and Numbers (ICANN) of the United States."

Up until now, the underlying premise was that no matter what happened to naming policies, nothing would ever be done to change the tenet that (aside from deliberate design decisions like esoteric routing, geo-targetting, anycasting, etc) any two people typing "example.com" into their application could always expect the same results, forever.

Not so after tomorrow, when according to the one single article at the root of all this, China will be introducing .COM and .NET of their own.

CIRA Board member and internet governence commentator Michael Geist comments on the development here, and another domain insider I'll leave nameless (since it came in a private mail) said

Although innocuous you should mark and remember this day as the day the root
was fractured - it is a big deal....

I'm still trying to verify for myself that this is happening in the way it's been interpreted.

As I write this, it's approximately 2:45am March 1st in China and I'm not seeing any alternative root glue for .com or .net in the .cn root nameservers, which I was expecting to see. (It also begs the question: how will they backport a new root hints file into every single DNS resolver in the country?)

When I started this post, the soa on cn was



 a.dns.cn. root.cnnic.cn. 2006022806 7200 3600 2419200 21600

and since I've been writing it has been changed to



a.dns.cn. root.cnnic.cn. 2006030101 7200 3600 2419200 21600

And also, since I've started this post, under the new SOA serial there are now these:



$ host -t soa com.cn

com.cn SOA a.dns.cn. root.cnnic.cn. 2006030101 7200 3600 2419200 21600

and



$ host -t soa net.cn

net.cn SOA a.dns.cn. root.cnnic.cn. 2006030101 7200 3600 2419200 21600

So I'm withholding reaction on this as I begin to suspect a poorly translated article was in reality announcing .com.cn and .net.cn subdomains which are non-events by comparison.

Update:

It has become clearer after trading a couple emails around that the news is indeed that China has added com.cn and net.cn as well as their own alternate character set implementations for com and net.

Basically, this comes down to similar efforts over the years to launch competing or expanded root domains. What does make this interesting is that, while typically these enterprises are carried out by net.kooks, this is being done by a government. My guess is they will get some more traction than earlier efforts but what will eventually happen is ICANN (or whoever) will come to the table at some point and a way will be negotiated to maintain visibility and continuity in the root.

But for now, there is no fragmentation and no collision crisis to speak of.

Update #2 (7:30pm EST):

Michael Geist just forwarded me this, the salient bit being:

The new domain name system also sets three temporary top-level domain names "China", "Company" and "Network". This means from now on, the routing of these websites will go directly through the Chinese domestic analysis server instead of the ones used by ICANN. In effect, these three create an intranet within China.

This is tough to assess because I'm still unsure if this applies to the alternate character set com and net TLDs or if we're really talking about alternative com's and net's in China, which is pretty radical.

This article re-iterates that the .com and .net TLDs are in the alternative chinese character set.

<speculation>
The excerpt above about the "domestic analysis server" makes me curious. Do they intend to somehow reroute requests inside China for the legacy .com and .net TLDs into the chinese charset ones? That would be extreme.
</speculation>

Another source whom I know likes to stay anonymous just emailed me:

Subject: sigh

I'm so surprised people didn't know China directs almost all root server requests to their own root?

They may not be taking over .com. but they have an alternate root for a while now..

Still digging...(jeez, no pun intended)

Yahoo and AOL's paid email delivery system

nospam@example.com (Mark Jeftovic) — Mon, 06 Feb 2006 08:34:02 -0500

An interesting turn of events surfaced over the weekend with AOL and Yahoo's announced plans to charge a fraction of a cent for "preferred delivery" of email.

Both companies will still accept unpaid email, but by paying the charges, senders will be able to bypass inbound spam filters and have their mail delivered directly to the user's inbox.

The predictable backlash will come from this, but in terms of what we think about it here at easyDNS, we're ambivalent. We should go on record to our users now to state that we will not pay AOL or Yahoo on a per-email basis to get forwarded mail through. Mail passing through our forwarders will still be accepted by Yahoo and AOL, but if they add additional restrictions to it based on the fact that we haven't paid for preferred delivery, I foresee a mass exodus of email accounts from both services.

We are currently whitelisted by AOL, and I would even consider paying a monthly or annual license fee for that status based on our mail volumes, it would help us further differentiate as a premium domain manager and provide incentive to ramp up our spam filtering here (we're working on that as we speak). But the per-email delivery charge doesn't fit the model for mail forwarders and I see few, if any eager to assume those fees.

As mail forwarders, we're largely indifferent to where we forward our members' email to and our entire value proposition is based on the concept of giving our users the ability to route their email around network outages, localized ISP failures, and procedural and commercial roadblocks such as this.

Domain suffixes not an endangered species

nospam@example.com (Mark Jeftovic) — Mon, 28 Nov 2005 10:01:16 -0500

I've seen several references to the firm that wants to get rid of net suffixes over the weekend, and at the risk of sounding like a stuffy curmudgeon I have to state my suspicion that it is at least partially attributable to a "slow technews weekend" after the US Thanksgiving. From monday morning's vantage point this outfit's 15 seconds of fame have probably already expired.

At first glance I thought this was another doomed protocol to sit on top of the DNS layer like the long defunct Realnames but further reading reveals this to be just another alternate root server initiative.

Whenever these things are brought to my attention I am quick to concede a few points:

There is nothing revolutionary or innovative about creating an alternative root structure. All it takes is a nameserver. You can load anything you want into your root hints file and then try to convince people to use it.
The current state of the DNS and the internet naming structure is built entirely on consensus and held together by convention. Thus, it is theoretically possible to alter consensus and change convention.
There probably exist already "private" roots outside of the legacy namespace which are not visible to the world at large and this is intentional and by design (most VPNs can fit in the category but I suspect there are "pseudo-public" ones. My theoretical example has always posited the existence of a .CDC root for the Cult of the Dead Cow hacker group)

In practical terms, all you have to do is convince every nameserver operator in the world to change their root hints to [insert magic bullet solution to all the world's naming ills here] and if enough parties do it, absolute chaos will reign supreme until 100% uptake is achieved.

100% uptake will never be achieved. I have a friend who once made an apt analogy: "convince every car owner in the world to change their tires on the same day".

Thus, the best an alternative root structure can hope to achieve is to cause permanent and lasting damage, to in effect "break the internet".

If not enough parties do it, it will sink into the internet graveyard where all the other alternative root structures go to die. (It is a place that runs exclusively on IPv8 and INEGroup's Bindplus software has a de facto monopoly)

People may ask: Would easyDNS "support" these alternative roots? Our reply is that we'll provide DNS for anything our members want DNS for. If you want to give some company $1000 USD to register "mycompany" as a Top Level Domain in a namespace nobody else on the planet can see, we'll provide DNS for it on request. It's your money. (We will caution you up front that this borders on vapourware) but to us it's just another zone in our nameservers (one that doesn't get a whole lot of queries).

Domain name dispute in Canadian House of Commons

nospam@example.com (Blogmeister) — Fri, 03 Jun 2005 13:07:00 -0400

It'll be interesting to see what comes of the domain name dispute debate which took place in the House of Commons over same-sex marriage opponents who registered MP's names as domains and setup websites on them to drum up support for their cause.

As Michael Geist comments, the actions are nebulous and under the current rules in place at CIRA, these do not consitute "bad faith" registrations and thus not really eligible for action under the CDRP.

I don't expect this to be added to the agenda for next week's CIRA Board meeting in St. John's Newfoundland (my last one as a director), but we may get a few questions on it during the public forum.

What eludes me in this day and age is how semi-public figures like politicians don't bother registering their own names as domain names as a matter of course. At the very least they can avoid situations like this and at best the clueful (and bold) ones can run blogs on their own domain names.

Note: I later found out that this domain was registered and then allowed to lapse, where it subsequently washed out via TBR and was picked up by the current registrant. While there are, I am sure, other members of the politburo who have not adequately guarded their own named domains, this illustrates another point, that of formulating a coherent domain registration and retention policy within your organization, as described in our Domain Management Resources: 10 Domain Management Tips article.

Canadian Anti-Spam Task Force report

nospam@example.com (Blogmeister) — Thu, 19 May 2005 17:53:00 -0400

Yesterday Industry Canada's Anti-Spam Task Force delivered its report. Included therein was a group of industry best practices assembled by the Working Group on Network Technology sub-group which I was priviledged to take part in.

This analysis is posted on CircleId while Michael Giest, who was on the Task Force and chaired the Legal Issues Working Group, discusses next steps at his webpage.

In a nutshell, the ISP Best Practices are as follows:

1. All Canadian registrants and hosts of domain names should publish Sender Policy Framework (SPF) information in their respective domain name server zone files as soon as possible.
[Follow this link if you are interested in implementing SPF on your domains at easyDNS]

2. ISPs and other network operators should limit, by default, the use of port 25 by end-users. If necessary, the ability to send or receive mail over port 25 should be restricted to hosts on the provider's network. Use of port 25 by end-users should be permitted on an as-needed basis, or as set out in the provider's end-user agreement / terms of service.

3. ISPs and other network operators should block email file attachments with specific extensions known to carry infections, or should filter email file attachments based on content properties.

4. ISPs and other network operators should actively monitor the volume of inbound and outbound email traffic to determine unusual network activity and the source of such activity, and should respond appropriately.

5. ISPs and other network operators should establish and consistently maintain effective and timely processes to allow compromised network elements to be managed and eliminated as sources of spam.

6. ISPs and other network operators should establish appropriate intercompany processes for reacting to other network operators' incident reports.

7. ISPs, other network operators and enterprise email providers should communicate their security policies and procedures to their subscribers.

8. ISPs and other network operators should implement email validation on all their Simple Mail Transfer Protocol (SMTP) servers (inbound, outbound and relay).

9. Non-delivery notices (NDNs) should only be sent for legitimate emails.

10. ISPs and other network operators should ensure that all domain names, Domain Name System (DNS) records and applicable Internet protocol
(IP) address registration records (e.g. WHOIS, Shared WHOIS Project [SWIP] or referral WHOIS [RWHOIS]) are responsibly maintained with correct, complete and current information. This information should include points of contact for roles responsible for resolving abuse issues including, but not limited to, postal address, phone number and email address.

11. ISPs and other network operators should ensure that all their publicly routable and Internet-visible IP addresses have appropriate and up-to-date forward and reverse DNS records and WHOIS and SWIP entries. All local area network (LAN) operators should be compliant with Request for Comments (RFCs) 1918 ?"Address Allocation for Private Internets." In particular, LANs should not use IP space globally registered to someone else, or IP space not registered to anyone, as private IP space.

12. ISPs and other network operators should prohibit the sending of email that contains deceptive or forged headers. Header-tracing information should be correct and compliant with relevant RFCs, including RFC 822 and RFC 2822, and reference domains and IP addresses should have up-to-date, accurate registration information.

I'll follow up in a later post on my personal thoughts on these recommendations but I will mention here that I'm very happy to see #9. The amount of backscatter clogging up the net from broken spam and virus blockers is just compounding the problem and helping absolutely nobody.