Latest news of the domain name industry

Recent Posts

Afilias develops IDN email software

Kevin Murphy, October 29, 2010, Domain Tech

Afilias, the .info registry, has created software that will enable emails to be sent and received using fully internationalized domain names.

The company has demonstrated a practical application using Jordan’s recently implemented Arabic TLD. There’s a video of the demo here.

The software, built on an open-source code base, comprises webmail, desktop, mail server and a management interface.

Afilias is looking for beta testers, and a spokesperson tells me it will also try to license the software to third parties.

IDNs are tricky because while users see characters in Arabic or Cyrillic, say, the underlying DNS handles them as encoded ASCII, with the translation happening the client.

VeriSign to deploy DNSSEC in .com next March

Kevin Murphy, October 29, 2010, Domain Tech

VeriSign is to start rolling out the DNSSEC security protocol in .net today, and will sign .com next March, the company said today.

In an email to the dns-ops mailing list, VeriSign vice president Matt Larson said that .net will get a “deliberately unvalidatable zone”, which uses unusable dummy keys for testing purposes, today.

That test is set to end on December 9, when .net will become fully DNSSEC-compatible.

The .com TLD will get its own unvalidatable zone in March, but registrars will be able to start submitting cryptographic keys for the domains they manage from February.

The .com zone will be validatable later in March.

The DNSSEC standard allows resolvers to confirm that DNS traffic has not been tampered with, reducing the risk of attacks such as cache poisoning.

Signing .com is viewed as the last major registry-level hurdle to jump before adoption kicks off more widely. The root zone was signed in July and a few dozen other TLDs, such as .org, are already signed.

DNSSEC to kill the ISP wildcard?

Kevin Murphy, October 19, 2010, Domain Tech

Comcast is to switch off its Domain Helper service, which captures DNS error traffic and presents surfers with sponsored search results instead, as part of its DNSSEC implementation.

The ISP said yesterday that it has started to roll out the new security mechanism to its production DNS servers across the US and expects to have all customers using DNSSEC by the “early part of 2011”.

The deployment will come in two phases. The first phase, expected to last 60 days, sees DNSSEC turned on for subscribers who have previously opted out of the Domain Helper system.

After that, Comcast will continue the rollout to all of its customers, which will involve killing off the Domain Helper service for good.

As the company says in its FAQ:

# We believe that the web error redirection function of Comcast Domain Helper is technically incompatible with DNSSEC.
# Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented.
# The production network DNSSEC servers do not have Comcast Domain Helper’s DNS redirect functionality enabled.

When web users try to visit a non-existent domain, DNS normally supplies a “does-not-exist” reply. Over recent years it has become increasingly common for ISPs to intercept this response and show users a monetized search page instead.

But DNSSEC introduces new anti-spoofing features that require such responses to be cryptographically signed. This, it seems, means ISPs will no longer be able to intercept and monetize error traffic without interfering with the end-to-end functionality of DNSSEC.

Comcast, which has been trialing the technology with volunteers for most of the year, says that to do so “breaks the chain of trust critical to proper DNSSEC validation functionality”.

It looks like it’s the beginning of the end of the ISP error wildcard. That’s got to be a good thing, right?

IPv4 pool to dry up in 2011

Kevin Murphy, September 14, 2010, Domain Tech

ICANN has confirmed that it will run out of unassigned IPv4 address space some time next year.

In an update to its Plan for Enhancing Internet Security, Stability and Resiliency, published yesterday, ICANN said it “expects to make the last allocations of IPv4 unicast space to the Regional Internet Registries (RIRs) during the calendar year 2011.”

While this means ICANN will largely be out of the IPv4 business, it does not of course mean that there will be no IPv4 address space left to be allocated to ISPs and businesses.

ICANN points out that the RIRs will still have their pools of unallocated addresses, and that they’ve been drawing up plans to hand out smaller blocks to new ISPs as well as allowing the transfer of IPv4 addresses between networks.

The confirmation that 2011 is the year that IPv4 dries up is not unanticipated. ICANN has been flagging it up as the likely timeframe for a few years now.

The solution to the problem is IPv6, which is large enough to never run out of addresses. The trick is making sure the new protocol is universally supported, so IPv6 networks can talk to IPv4 networks and vice versa.

The updated security plan document contains a few other nibbles of interest.

For instance, the security budget for the next year is down slightly on the last, $11.52 million versus $12.8 million, largely due to a requirement last year to build out a secure data center.

There’s also the admission that ICANN has developed an as-yet unpublished “Meetings Security Plan”, presumably in response to the terrorism fears that kept many constituents at home for the Nairobi meeting in March.

Afilias adds DNSSEC to .info zone

Kevin Murphy, September 9, 2010, Domain Tech

The .info domain has become the latest gTLD to be signed with DNSSEC, the security standard for domain name lookups.

Afilias, which runs the .info registry, said today that it has signed its zone and added the necessary records to the DNS root.

DNSSEC is designed to prevent cache poisoning attacks, which can be used to hijack domain names and carry out phishing campaigns.

For registrants, DNSSEC in .info doesn’t mean much in practical terms yet. If you have a .info, you’ll have to wait for registrars to start to support the standard.

At the moment, only 19 second-level .info domains, including afilias.info and comcast.info, have been signed, as part of a “friends and family” testbed program.

The .org zone, which Afilias also provides the back-end for, was signed in June.

Neustar added full DNSSEC support for .biz in August, according to an announcement this week.

For .com and .net, VeriSign is currently planning to roll out the technology in the first quarter of 2011.

Go Daddy files for patent on available domain ads

Kevin Murphy, September 2, 2010, Domain Tech

Go Daddy has applied for a US patent on a system that automatically inserts available domain names into banner ads based on the dynamic content of a web page.

The application “Generating online advertisements based upon available dynamic content relevant domain names” was filed in February 2009 and published today.

The patent would cover a way to analyze the content of a web page, perhaps using image identification technology, then generate keywords and check for available domain names to put in the ad.

Instead of a standard Go Daddy banner, visitors to a web page would be shown a custom ad offering an available or aftermarket domains relevant to the content of the page.

The application also seems to cover an API whereby an advertising network, such as Google, would also be able to offer available domains via Adsense.

Registrars “unprepared” for DNSSEC

Kevin Murphy, August 23, 2010, Domain Tech

Only one in 10 domain name registrars believes it is fully prepared to offer DNSSEC services today, according to new research out from Afilias, the .info registry.

The Registrar DNSSEC Readiness Report (pdf) also shows that a perceived lack of customer demand for the technology has translated into ambivalence at most registrars.

DNSSEC is a standard extension to DNS that helps prevent domain name hijacking through man-in-the-middle attacks.

The survey shows that 9.86% of registrars say they are “fully prepared” to offer DNSSEC to customers now, with 52.2% saying they were “somewhat” prepared. The remainder were not at all prepared.

A little over a quarter of respondents rated DNSSEC a “high” priority for the next 12 months, with less than 3% saying it was an “extremely high” priority.

Two of the biggest reasons for the lack of urgency were lack of customer demand – 59% of registrars said they saw no demand at all – and difficulties developing key management systems.

Despite this, when asked the question “Should TLD registries support DNSSEC?”, a whopping 80% responded in the affirmative.

I expect interest in the technology will pick up early next year, when VeriSign signs the .com zone.

The Afilias survey was conducted electronically earlier this month. The sample size was quite small, with only 71 respondents, and most of them were on the smaller side by domain count.

The report was released to coincide with Afilias’ launch of a broad effort to add DNSSEC support to all of the TLDs for which it provides registry services.

The company already offers the technology in .org, and that will now be extended to gTLDs including .info and ccTLDs such as .in. You can read the release at CircleID.

Russian domain crackdown halves phishing attacks

Kevin Murphy, August 20, 2010, Domain Tech

Phishing attacks from .ru domains dropped by almost half in the second quarter, after tighter registration rules were brought in, according to new research.

Attacks from the Russian ccTLD namespace fell to 528, compared to 1,020 during the first quarter, according to Internet Identity’s latest report.

IID attributed the decline to the newly instituted requirement for all registrants to provide identifying documents or have their domains cancelled, which came into effect on April 1.

The report goes on to say:

Following a similar move by the China Internet Network Information Center in December 2009, spam researchers suggested that this tactic only moves the criminals to a new neighborhood on the Internet, but has no real impact on solving the problem.

I wonder whose ccTLD is going to be next.

The IID report also highlights a DNS redirection attack that took place in June in Israel, which I completely missed at the time.

Apparently, major brands including Microsoft and Coca-Cola started displaying pro-Palestine material on their .co.il web sites, for about nine hours, after hackers broke into their registrar accounts at Communigal.

McAfee calls for ICANN spam crackdown

Kevin Murphy, August 10, 2010, Domain Tech

The security company McAfee has claimed that ICANN needs to try harder in the fight against spam by cracking down on rogue registrars.

In a report released today, the company makes the bold assertion that ICANN “holds the trump card to the spam problem” and that it should step up its compliance efforts.

Although ICANN cannot stop spam itself and does not link spammers to the Internet, it does accredit the registrars that sell the domains that cybercriminals use to fill our inboxes with advertisements and malware

McAfee notes that ICANN has previously de-accredited spammer-friendly registrars such as the notorious EstDomains, but that it needs to do more.

ICANN needs to continue this trend against registrars that knowingly provide domain services to cybercriminals. The organization also needs to harden its policies that define under what circumstances an accreditation can be revoked, so that it can take quicker action against rogue registrars.

The claims come in a report entitled “Security Takes The Offensive”, available here.

The report does not lay all the blame for spam at ICANN’s door, of course. The author also goes after ISPs and the SMTP protocol itself.

The report does not point out that there are 250-odd TLDs over which ICANN has no registrar accreditation powers whatsoever.

Despite my best efforts with Google, I’ve been unable to find a single instance of McAfee publicly participating in ICANN policy-making, so I have to wonder how serious it is.

At least guys like KnuJon are not afraid to show up at meetings and stir things up a bit.

Vixie declares war on domain name crooks

Kevin Murphy, July 30, 2010, Domain Tech

Bad news for domain name speculators?

Paul Vixie of the Internet Systems Consortium has plans to bring the equivalent of an anti-spam blacklist to the DNS itself.

The Response Policy Zones spec, drafted by Vixie and Vernon Schryver of Rhyolite, is designed to allow ISPs, for example, to block domains based on standardized reputation data.

In this blog post, Vixie writes that the next version of BIND will include the technology. ISC has also made patches available for those who want to test RPZ now.

This kind of technology has been available for mail servers for years, and can be found to an extent in desktop software and search engines, but RPZ would bake it into the DNS itself.

For users behind a recursive name server implementing RPZ, domains with bad reputations would either not resolve or would be redirected elsewhere.

It would not, however, provide a mechanism to wildcard non-existent domain data and bounce surfers to search/advertising pages. Many ISPs already do that anyway.

If you speculate at all in domain names, the opening paragraphs are probably the most interesting part of the post (my emphasis):

Most new domain names are malicious.

I am stunned by the simplicity and truth of that observation. Every day lots of new names are added to the global DNS, and most of them belong to scammers, spammers, e-criminals, and speculators.

I’m sure there’s a fair few law-abiding speculators reading this who won’t be happy being lumped in with criminals and spammers.

Luckily for them, Vixie said that the ISC will limit itself to providing the technology and the specification; it will not act as a reputation service provider.

The ISC is the Microsoft of the DNS, BIND its Windows, so we could expect a fairly broad level of adoption when the technology becomes available.

Vixie’s post, also published at CircleID, is well worth a read. If anything, it certainly goes a way to cement Vixie’s reputation as the grumpy old man of the DNS.