easyDNS Blog - Industry Watch

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.