Recent Posts
- I just bought a new gTLD registry’s domain for $10
- Child abuse becoming big problem for new gTLDs
- Government gives auDA reform-or-die ultimatum
- Leaked memo alleges lavish travel spending at auDA
- dotFM offers $1.1 million stash of emoji domains
- Bling-maker kills off fifth dot-brand gTLD
- Now GNSO mulls emergency response to GDPR deadline
- auDA refers former directors to police
- CoCCA to charge trademark owners for Whois access
- Panic stations as Europe plays hardball on Whois privacy
- 101domain founder Wolfgang Reile dies at 67
- ICANN confirms GoDaddy Whois probe
- Grumpier Aussies call for more blood on the auDA boardroom floor
- Afilias scraps plan to scrap Whois
- auDA role “could have killed me” says resigning domainer
- Whois policy group closes down in face of GDPR
- Marby ponders emergency powers to avoid fragmented Whois
- ICANN heads to Mar-a-Lago for budget crisis talks
- Registrars will miss GDPR deadline by a mile
- ICANN chief begs privacy watchdogs for Whois advice
- Stéphane Van Gelder dies after motorcycle accident
- Some men at ICANN meetings really are assholes
- Cybersquatting cases up because of .com
- Privacy could be a million-dollar business for ICANN
- Three more dot-brands throw in the towel
- Is ICANN over-reacting to Whois privacy law?
- Now Latvia guts Whois to comply with GDPR
- A lazy blogger’s wish-list for ICANN remote participation
- Portugal joins the million-domain club
- Austria to stop publishing most Whois data
- Data leak security glitch screws up ICANN 61 for thousands
- CentralNic and KeyDrive in merger talks
- After long fight, Donuts adds .charity to its gTLD stable
- Lawyer: GoDaddy Whois changes a “critical” contract breach
- Now South Africa looks to second-level domain sales
- Next new gTLD round unlikely before 2022
- Donuts scraps 200 companies, consolidates under Binky Moon
- ICANNWiki fans protest funding cut
- Is ICANN still over-estimating revenue from “stagnating” gTLD industry?
- Community calls on ICANN to cut staff spending
- Amazon’s .amazon gTLD may not be dead just yet
- Namecheap’s Move Your Domain Day actually works
- ICANN mulls $68 million raid on auction war chest
- ICANN strikes back at “offensive” .gay bidder
- Namecheap accuses GoDaddy of delaying transfers
- Tech giants gunning for AlpNames over new gTLD “abuse”
- Get drunk on Neustar’s tab and it will donate money to hurricane relief
- Industry report show slightly stronger growth than Verisign’s
- Google’s $25 million .app domain finally has a launch date
- Whois privacy will soon be free for most domains
Reports: .gov fails due to DNSSEC error
The .gov top-level domain suffered a DNSSEC problem today and was unavailable to some internet users, according to reports.
According to mailing lists and the SANS Internet Storm Center, it appeared that .gov rolled one of its DNSSEC keys without telling the root zone about the update.
This meant that anyone whose DNS servers do strict DNSSEC validation — a relatively small number of networks — would have been unable to access .gov web sites, email and other resources.
As a matter of policy, all second-level .gov domains have to be DNSSEC-signed.
The problem was corrected quite quickly — looks like within an hour or two — but as SANS noted, caching issues may prolong the impact.
Both .gov and the root zone are managed by Verisign, which isn’t on the best of terms with the US government at the moment.
It is ironic that the very initiatives that are supposed to help security have introduced errors into the system, while those that are identified as likely to produce errors — for instance, the introduction of new gTLDs, in the context of name collision issues — have produced none.
The DNSSEC problem — that of needing a chain of trust to make it effective — has been frequently raised by registrars and others. This shouldn’t have been a surprise to anyone.
What is does show is that *if* there is a problem, it can be addressed quickly and without major repercussions. That is true of DNSSEC or of name collision. The ICANN staff obsession with risk — that is, in preventing *all* risk, rather than assessing its probability, severity, and ease of mitigation — seems to be limited to those areas where the ICANN corporation faces some liability. In contrast, ICANN appears to be blandly unconcerned in areas where they could have done something (I’m thinking of better planning and communication rolling out DNSSEC), but where they unlikely to be identified as a culprit.
ICANN needs some real risk assessment capabilities, instead of relying on risk assessment from a legal perspective, which typically is satisfied only with 0% risk — which is not a real-world position to take, especially in a field as fast moving, and as filled with so many unknowns as the Internet. They would then be able to communicate honestly to the world as to why they take certain positions, instead of pointing helplessly at nebulous unknowns. If ICANN *really* wants to secure the security and stability of Internet, it’s going to need to take risks — calculated ones. There is no zero-risk scenario where ICANN is effective.
Antony
Problem started somewhere between 2013-08-14 08:51:41 UTC and 2013-08-14 12:26:40 UTC. It persisted at least until 2013-08-14 13:49:03 UTC.
.gov DNSSEC snapshots:
http://dnsviz.net/d/gov/UgtFHg/dnssec/
http://dnsviz.net/d/gov/Ugt3gQ/dnssec/
http://dnsviz.net/d/gov/UguK0A/dnssec/
http://dnsviz.net/d/gov/UguRGg/dnssec/
Everything involves risk. Crossing the street involves risk. We humans are constantly assessing the risk vs the benefit.
Shall I cross this slightly trafficked street (very small probability but risk of very bad event happening – death) to make my meeting on time (some benefit)?
We have to assess not only 1) the risk (chance of it happening) but 2) the magnitude of the potential harm, and 3) the magnitude of the benefit.
In the DNSSEC case, the probability of a negative event happening is non-zero (as this event shows), the magnitude of the bad event is medium and the benefit is medium.
The benefits to DNSSEC outweigh the risks. But make no mistake, there are risks to implementing DNSSEC. In fact, comparing DNSSEC and new TLDs, the change DNSSEC imposed on the DNS is much much larger than the change that new TLDs impose on the DNS.
Therefore the risks to implementing DNSSEC is much larger than the risk of new TLDs.
Comparing the benefits of the two, there are net benefits that DNSSEC brings to the world (more security), but the net benefits that new TLDs bring are even larger (competition, innovation, etc).
So we, the ICANN community, implemented DNSSEC even thought the risks are more (more change to the DNS) and the benefits are less than new TLDs.
“Name collisions” have a non-zero probability of happening, true (they happen every day in .com for example). But the consequence of a “name collision” is small (in my opinion very small, which is why we allow them to happen in .com) and the benefits brought by new TLDs, such as .home and .corp are big.
The v6 and DNSSEC evangelicals successfully added their pet causes as mandatory-to-implement by new gTLD operators, even if (a) located where native v6 is not available and/or (b) for use models lacking valuable targets (e.g., community-based applications).
These new operators are compelled to waste resources on v4 exhaustion & security theater, and are likely to make more mistakes than experienced, highly capitalized operators.
I differ from Antony and Paul, who offer specific comparisons of argued risk, and offer, as a general error of staff the insertion of the v6 and DNSSEC requirements for new registry operators, for which little value at start-up (years 1-5) can be offered.
There is a chicken-and-egg situation happening with both IPv6 and DNSSEC that requires the industry to adopt those even its numbers would indicate otherwise. I think ICANN was right in requiring those to be deployed, but it could have lessened such burden by indicating that IPv6 tunneling was OK (it’s possible to get tunneled-IPv6 for free) and providing DNSSEC capacity building as another avenue of applicant support.