Latest news of the domain name industry

Recent Posts

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?

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.

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.

ICANN releases (censored) board briefing docs

Kevin Murphy, August 17, 2010, Domain Policy

ICANN has given an unprecedented glimpse into the workings of its board of directors, with the release of hundreds of pages of staff briefing papers.

But the documents are quite heavily redacted, particularly when it comes to some of the more controversial topics.

The documents show what ICANN staffers told the board in the run-up to the Nairobi and Brussels meetings, dealing with important decisions such as .xxx and internationalized domain names.

The Brussels decision to put .xxx back on the track to approval sees more than its fair share of blacked-out text, but the documents do show that ICANN general counsel John Jeffrey’s recommendations were pretty much in line with how the board eventually voted.

Other topics seeing redaction include the implementation of DNSSEC at the root, the activities of the Internet Governance Forum, and specific discussion of IDN ccTLD delegations.

Some topics are deemed so sensitive that even the titles of the pages have been blacked out. But in at least one case somebody apparently forgot to redact the title from the PDF’s internal bookmarks.

So we know, for example, that a section entitled “Chronological-History-ICM” is deemed entirely unpublishable, even though ICANN has previously published a document with pretty much the same title (pdf).

Browser makers brush me off on DNSSEC support

Kevin Murphy, July 29, 2010, Domain Tech

A couple of weeks back, I emailed PR folk at Microsoft, Mozilla, Google and Opera, asking if they had any plans to provide native support for DNSSEC in their browsers.

As DNS uber-hacker Dan Kaminsky and ICANN president Rod Beckstrom have been proselytizing this week at the Black Hat conference, support at the application layer is the next step if DNSSEC is to quickly gain widespread traction.

The idea is that one day the ability to validate DNSSEC messages will be supported by browsers in much the same way as SSL certificates are today, maybe by showing the user a green address bar.

CZ.NIC has already created a DNSSEC validator plugin for Firefox that does precisely that, but as far as I can tell there’s no native support for the standard in any browser.

These are the responses I received:

Mozilla: “Our team is heads down right now with Firefox 4 beta releases so unfortunately, I am not going to be able to get you an answer.”

Microsoft:
“At this stage, we’re focusing on the Internet Explorer 9 Platform Preview releases. The platform preview is a developer and designer scoped release of Internet Explorer 9, and is not feature complete, we will have more to share about Internet Explorer 9 in the future.”

Google: No reply.

Opera: No reply.

In 11 years of journalism, Apple’s PR team has never replied to any request for information or comment from me, so I didn’t bother even trying this time around.

But the responses from the other four tell us one of two things:

  • Browser makers haven’t started thinking about DNSSEC yet.

Or…

  • Their PR people were just trying to brush me off.

I sincerely hope it’s the former, otherwise this blog post has no value whatsoever.