Vixie declares war on domain name crooks

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.

Browser makers brush me off on DNSSEC support

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.

ICANN chief to address hackers at Black Hat

Globe-trotting ICANN president Rod Beckstrom is heading to Vegas this week, to participate in a panel discussion on DNS security at the Black Hat conference at Caesar’s Palace.
He’ll be joined by Dan Kaminsky, discoverer of the notorious DNS vulnerability that bears his name, and is expected to sing the praises of the new DNSSEC security standard.
Also on tomorrow’s panel, entitled “Systemic DNS Vulnerabilities and Risk Management” are DNS inventor Paul Mockapetris, VeriSign CTO Ken Silva and NERC CSO Mark Weatherford.
ICANN and VeriSign recently signed the DNS root using DNSSEC standard. The challenge they face now is persuading everybody else in the world to jump on the bandwagon.
It’s likely to be slow going. DNSSEC has more than its fair share of skeptics, and even fierce proponents of the standard sometimes acknowledge that there’s not a heck of a lot in the way of a first mover advantage.
I’ll be interested to see if the subject of a DNS-CERT – a body to coordinate DNS security efforts – is raised either during the panel or the subsequent press conference.
From a policy point of view, DNSSEC is pretty much a done deal, whereas a DNS-CERT is still very much a matter for debate within the ICANN community.
I believe this is the first time ICANN has talked publicly at Black Hat. Beckstrom himself has taken the stage under his previous roles in government, but not as ICANN’s top dog.
Despite its name, Black Hat is a pretty corporate event nowadays. In my experience, the proper black/gray hats show up (or swap their lime green corporate polo shirts for Metallica T-shirts) at the weekend for Def Con, which is usually held at a cheaper venue around the corner.

Oh, yeah, and the DNS root got signed

It happened yesterday night.
To crushing silence from ICANN.

ICANN to stream DNSSEC ceremony live

ICANN is to webcast the second of its root server DNSSEC key generation ceremonies, this coming Monday.
You’ll be able to find the stream here, from 2000 UTC, according to a message ICANN’s DNS director Joe Abley just sent to the DNS-Ops mailing list.
The ceremony, which will likely take several hours, takes place in El Segundo, California.
In it, staff will create the Key Signing Key used in cryptographically signing the very root of the DNS according to the DNSSEC standard.
The first such ceremony took place last month at a facility in Virginia. While it was recorded, as well as witnessed by several well-known security experts, it was not streamed live.
The full transition to a validatable DNSSEC-signed root is still scheduled for next Thursday, July 15.
Abley’s update is likely to be available here shortly.

ICANN creates DNSSEC root keys

ICANN took the penultimate step towards adding DNSSEC to the root of the domain name system, during in a lengthy ceremony in Virginia yesterday.
The move means we’re still on track to have the DNSSEC “trust anchor” go live in the root on July 15, which will make end-to-end validation of DNS answers feasible for the first time.
DNSSEC is an extension to the DNS protocol that enables resolvers to validate that the DNS answers they receive come from the true owner of the domain.
Yesterday, ICANN generated the Key Signing Key for the root zone. That’s one of two keys required when adding DNSSEC to a zone.
The KSK is used to sign the DNSKey record, the public half of a key pair used to validate DNS responses. It has a longer expiration date than the Zone Signing Key used to sign other records in the zone, so its security is more important.
The videotaped ceremony, held at a facility in Culpeper, Virginia, was expected to take six hours, due to a lengthy check-list of precautions designed to instil confidence in the security of the KSK.
ICANN said:

During the ceremony, participants were present within a secure facility and witnessed the preparations required to ensure that the so-called key-signing-key (KSK) was not only generated correctly, but that almost every aspect of the equipment, software and procedures associated with its generation were also verified to be correct and trustworthy.

Ten hand-picked independent observers were present to bear witness.
ICANN expects to perform the ceremony four times a year. The second will be held at a backup facility in California next month.

ICANN staff need to get their pee tested

I imagine it’s a pretty hard job, largely thankless, working at ICANN. No matter what you do, there’s always somebody on the internet bitching at you for one reason or another.
The job may be about to get even more irksome for some staffers, if ICANN decides to implement new security recommendations made by risk management firm JAS Communications.
In a report published yesterday, JAS suggests that senior IANA staff – basically anyone with critical responsibilities over the DNS root zone – should be made to agree to personal credit checks, drug screening and even psych evaluations.
To anyone now trying to shake mental images of Rod Beckstrom peeing into a cup for the sake of the internet, I can only apologise.
This is what the report says:

JAS recommends a formal program to vet potential new hires, and to periodically re‐vet employees over time. Such a vetting program would include screening for illegal drugs, evaluation of consumer credit, and psychiatric evaluation, which are all established risk factors for unreliable and/or malicious insider activity and are routinely a part of employee screening in government and critical infrastructure providers.

I’ve gone for the cheap headline here, obviously, but there’s plenty in this report to take seriously, if you can penetrate the management consultant yadda yadda.
There are eight other recommendations not related to stoners running the root, covering contingencies such as IANA accidentally unplugging the internet and Los Angeles sinking into the Pacific.
Probably most interesting of all is the bit explaining how ICANN’s custom Root Zone Management System software, intended to reduce the possibility of errors creeping into the root after hundreds of new TLDs are added, apparently isn’t being built with security in mind.
“No formal requirements exist regarding the security and resiliency of these systems, making it impossible to know whether the system has been built to specification,” the report says.
It also notes that ICANN lacks a proper risk management strategy, and suggests that it improve communications both internally and with VeriSign.
It discloses that “nearly all critical resources are physically located in the greater Los Angeles area”, which puts the IANA function at risk of earthquake damage, if nothing else.
JAS recommends spreading the risk geographically, which should give those opposed to ICANN bloat something new to moan about.
There’s a public comment forum over here.
UPDATE (2010-06-13): As Michael Palage points out over at CircleID, ICANN has pulled the PDF from its web site for reasons unknown.
On the off-chance that there’s a good security reason for this, I shall resist the temptation to cause mischief by uploading it here. This post, however, remains unedited.

US government requests root DNSSEC go-ahead

The National Telecommunications and Information Administration, part of the US Department of Commerce, has formally announced its intent to allow the domain name system’s root servers to be digitally signed with DNSSEC.
Largely, I expect, a formality, a public comment period has been opened (pdf) that will run for two weeks, concluding on the first day of ICANN’s Brussels meeting.
NTIA said:

NTIA and NIST have reviewed the testing and evaluation report and conclude that DNSSEC is ready for the final stages of deployment at the authoritative root zone.

DNSSEC is a standard for signing DNS traffic using cryptographic keys, making it much more difficult to spoof domain names.
ICANN is expected to get the next stage of DNSSEC deployment underway next week, when it generates the first set of keys during a six-hour “ceremony” at a secure facility in Culpeper, Virginia.
The signed, validatable root zone is expected to go live July 15.

Symantec gets into the DNS game with Dyn

Symantec has partnered with Dyn to offer a free DNS service to mobile Norton users.
As part of its new mobile strategy, expected to be announced later today, Symantec will provide free DNS resolution with a built-in filter that blocks potentially dangerous domains.
Dyn.com will provide the back-end, which will compete with the likes of OpenDNS and Google’s DNS service.
Non-technical users will be able to download a client application that configures their local DNS to work with the service, which drops one barrier to entry.
Symantec reportedly expects to earn revenue from advertising links – presumably by intercepting NXDOMAIN responses and providing sponsored error pages.
So the deal could be a bit of a money-spinner for Dyn; it’s certainly a further validation of its service.
But is it sexy? Hmm…

Four of the top 100 brands have insecure domain names

Some of the world’s most famous global brands have domain names that are still vulnerable to the Kaminsky exploit and could be hijacked by others.
Earlier today, I ran all of the brands on Deloitte’s list of the top 100 brands through a vulnerability testing tool provided by IANA.
The results show that four of these brands – all household names – have domains classed as “highly vulnerable” to the Kaminsky exploit.
If the IANA test is reliable, this means that false data could be injected into their name servers, potentially redirecting users to a web site belonging to the attacker.
Another eight brands had domains that the IANA tool reported might be “vulnerable” to attacks, but which had measures in place to mitigate the risk.
The Kaminsky bug has been public for almost two years. It’s a cache poisoning attack in which a recursive name server is tricked into providing false data about a domain.
It becomes particularly scary when a domain’s authoritative name servers also have their recursive functions turned on. A successful attack could redirect all traffic to a compromised domain to a server managed by the attacker.
The surest way to avoid vulnerability is to turn off recursion. IANA says: “Authoritative name servers should never be configured to provide recursive name service.”
Alternatively, a method known as source port randomization can make the risk of being compromised by the Kaminsky exploit so small it’s barely a threat at all.
The IANA tool reports that four of the top 100 brands have at least one “highly vulnerable” authoritative name server that has recursion enabled and no source port randomization.
The other eight “vulnerable” domains were identified as running on at least one authoritative server that had recursion turned on and source port randomization enabled.
I’m not an expert, but I don’t believe this second category of companies has a great deal to worry about in terms of Kaminsky.
I picked the Deloitte brand list for this experiment because it is the list of brands Deloitte believes require the most trademark protection under ICANN’s new TLD process.
.CO Internet is already using the list during its sunrise period for the .co domain.
Michele Neylon of Blacknight has found some more vulnerable servers over here.