Latest news of the domain name industry

Recent Posts

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?

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