The US National Telecommunications and Information Administration has formally thrown its weight behind the community-led proposal that would remove the US government, itself in effect, from DNS root oversight.
Assistant secretary Larry Strickling held a press conference this afternoon to confirm the hardly surprising development, but dodged questions about a Republican move to scupper the plan in Congress.
The IANA transition plan, which was developed by the ICANN community over about two years, meets all the criteria NTIA had set out in its surprise 2014 announcement, Strickling confirmed.
Namely, NTIA said in a press release that the the plan would:
- Support and enhance the multistakeholder model;
- Maintain the security, stability, and resiliency of the Internet DNS;
- Meet the needs and expectations of the global customers and partners of the IANA services; and
- Maintain the openness of the Internet.
Probably more importantly, NTIA agrees with everyone else that the plan does not replace NTIA’s role with more government meddling.
US Sen. Ted Cruz and Rep. Sean Duffy see things differently. They yesterday introduced the Protecting Internet Freedom Act, which would stop the transition going ahead.
Strickling said that NTIA has been talking to Congress members about the transition, but declined to “speculate” about the new bill’s likelihood of success.
“We’ve been up on the Hill doing briefings and will continue to do so with any member that wants to talk to us,” he said.
Currently, NTIA is forbidden by law from spending any money on the transition, but that prohibition expires (unless it is renewed) at the end of the current federal budget cycle.
The plan is to carry out the transition after that, Strickling said.
The current IANA contract expires September 30. It may be extended, depending on how quickly ICANN and Verisign proceed on their implementation tasks.
The world’s third-largest mobile phone company, worth some $14 billion a year, is the first new gTLD registry operator to refuse to pay ICANN fees.
That’s according to ICANN’s compliance department, which last night slapped Bharti Airtel with the new gTLD program’s first public contract breach notices.
The notices, which apply to .bharti and .airtel, claim that the Indian company has been ignoring demands to pay past due fees since February.
The ICANN quarterly fee for registries is $6,250. Given .airtel and .bharti were delegated 11 months ago, the company, which has assets of $33 billion, can’t owe any more than $37,500.
Bharti Airtel is, according to Wikipedia, the third largest mobile network operator in the world and the largest in India, with 325 million subscribers.
Yet ICANN also claims it has had terrible difficulty getting in touch with staff there, saying:
ICANN notes that Bharti Airtel exhibits a pattern of non-response to ICANN Contractual Compliance matters and, when responses are provided to ICANN, they are often untimely and incomplete.
The compliance notices show that ICANN has also communicated with Verisign, the registry back-end operator for both gTLDs, to try to get the matters resolved.
According to ICANN, the registry is also in breach of terms that require it to publish links to its Whois service, abuse contacts and DNSSEC practice statements on its web site.
The sites nic.airtel and nic.bharti don’t resolve (for me at least) with or without a www., but the Whois services at whois.nic.airtel and whois.nic.bharti appear to work.
These are the first two registries of any flavor emerging from the 2012 application round to receive public breach notices. Only one pre-2012 gTLD, .jobs, has the same honor.
ICANN has given Bharti Airtel 30 days from yesterday to come back into compliance or risk losing its Registry Agreements.
Given that both gTLDS are almost a year old and the nic. sites still don’t resolve, one wonders if the company will bother.
Verisign has revived its old name collisions security scare story, publishing this week a weighty research paper claiming millions are at risk of man-in-the-middle attacks.
It’s actually a study into how a well-known type of attack, first documented in the 1990s, might become easier due to the expansion of the DNS at the top level.
According to the paper there might be as many as 238,000 instances per day of query traffic intended for private networks leaking to the public DNS, where attackers could potentially exploit it to all manner of genuinely nasty things.
But Verisign has seen no evidence of the vulnerability being used by bad guys yet and it might not be as scary as it first appears.
You can read the paper here (pdf), but I’ll attempt to summarize.
The problem concerns a virtually ubiquitous protocol called WPAD, for Web Proxy Auto-Discovery.
It’s used by mostly by Windows clients to automatically download a web proxy configuration file that tells their browser how to connect to the web.
Organizations host these files on their local networks. The WPAD protocol tries to find the file using DHCP first, but fails over to DNS.
So, your browser might look for a wpad.dat file on wpad.example.com, depending on what domain your computer belongs to, using DNS.
The vulnerability arises because companies often use previously undelegated TLDs — such as .prod or .global — on their internal networks. Their PCs could belong to domains ending in .corp, even though .corp isn’t real TLD in the DNS root.
When these devices are roaming outside of their local network, they will still attempt to use the DNS to find their WPAD file. And if the TLD their company uses internally has actually been delegated by ICANN, their WPAD requests “leak” to registry or registrant.
A malicious attacker could register a domain name in a TLD that matches the domain the target company uses internally, allowing him to intercept and respond to the WPAD request and setting himself up as the roaming laptop’s web proxy.
That would basically allow the attacker to do pretty much whatever he wanted to the victim’s browsing experience.
Verisign says it saw 20 million WPAD leaks hit its two root servers every single day when it collected its data, and estimates that 6.6 million users are affected.
The paper says that of the 738 new gTLDs it looked at, 65.7% of them saw some degree of WPAD query leakage.
The ones with the most leaks, in order, were .global, .ads, .group, .network, .dev, .office, .prod, .hsbc, .win, .world, .one, .sap and .site.
It’s potentially quite scary, but there are some mitigating factors.
First, the problem is not limited to new gTLDs.
Yesterday I talked to Matt Larson, ICANN’s new vice president of research (who held the same post at Verisign’s until a few years ago).
He said ICANN has seen the same problem with .int, which was delegated in 1988. ICANN runs one of .int’s authoritative name servers.
“We did a really quick look at 24 hours of traffic and saw a million and a half queries for domain names of the form wpad.something.int, and that’s just one name server out of several in a 24-hour period,” he said.
“This is not a new problem, and it’s not a problem that’s specific to new gTLDs,” he said.
According to Verisign’s paper, only 2.3% of the WPAD query leaks hitting its root servers were related to new gTLDs. That’s about 238,000 queries every day.
With such a small percentage, you might wonder why new gTLDs are being highlighted as a problem.
I think it’s because organizations typically won’t own the new gTLD domain name that matches their internal domain, something that would eliminate the risk of an attacker exploiting a leak.
Verisign’s report also has limited visibility into the actual degree of risk organizations are experiencing today.
Its research methodology by necessity was limited to observing leaked WPAD queries hitting its two root servers before the new gTLDs in question were delegated.
The company only collected relevant NXDOMAIN traffic to its two root servers — DNS queries with answers typically get resolved closer to the user in the DNS hierarchy — so it has no visibility to whether the same level of leaks happen post-delegation.
Well aware of the name collisions problem, largely due to Verisign’s 11th-hour epiphany on the subject, ICANN forces all new gTLD registries to wildcard their zones for 90 days after they go live.
All collision names are pointed to 127.0.53.53, a reserved IP address picked in order to catch the attention of network administrators (DNS uses TCP/IP port 53).
Potentially, at-risk organizations could have fixed their collision problems shortly after the colliding gTLD was delegated, reducing the global impact of the vulnerability.
There’s no good data showing how many networks were reconfigured due to name collisions in the new gTLD program, but some anecdotal evidence of admins telling Google to go fuck itself when .prod got delegated.
A December 2015 report from JAS Advisors, which came up with the 127.0.53.53 idea, said the effects of name collisions have been rather limited.
ICANN’s Larson echoed the advice put out by security watchdog US-CERT this week, which among other things urges admins to use proper domain names that they actually control on their internal networks.
The 1,000th new gTLD from the 2012 application round was delegated yesterday.
It was either .shop or .realestate, appropriately enough, which both appear to have been added to the DNS root zone at about the same time.
Right now, there are actually only 999 new gTLDs live in the DNS. That’s because the unwanted .doosan was retired in February.
During its pre-launch planning for the new gTLD program, ICANN based its root zone stability planning on the assumption that fewer than 1,000 TLDs would be added to the root per year.
In reality, it’s taken much longer to reach that threshold. The first few new gTLDs were added in late October 2013, 945 days ago.
On average, in other words, a new gTLD has been added to the root slightly more than once per day.
Over that same period, nine ccTLDs — internationalized domain names applied for via a separate ICANN program — have also gone live.
The 1,000th new gTLD to be added to the IANA database was .blog.
There are 1,314 TLDs in the root all told.
In a surprising move towards further transparency, the ICANN board of directors has decided to start publishing transcripts and possibly recordings of its meetings.
It passed a resolution during a meeting in Amsterdam this week stating:
the Board directs the President and CEO, or his designee(s), to work with the Board to develop a proposed plan for the publication of transcripts and/or recordings of Board deliberative sessions, with such plan to include an assessment of possible resources costs and fiscal impact, and draft processes to: (i) ensure the accuracy of the transcript; and (ii) for redaction of portions of the transcript that should be maintained as confidential or privileged.
Transcription services can be picked up dirt cheap, so I can’t see money getting in the way of this proposal becoming a reality.
A question mark of course hangs over the “confidential or privileged” carve-out, of course. ICANN is sometimes over-generous with what it considers redactable material.
Still, it’s great news for the ICANN community, which has been calling for greater board transparency for years.
When I started covering ICANN back in 1999, board sessions at the then four-times-a-year public meetings were conducted in the open; all the thinking was done aloud.
At some point in the early 2000s that stopped, however, and the board’s public sessions became a case of rubber-stamping resolutions that had already been debated behind closed doors.
Minutes, staff-prepared briefing materials and broad-stroke narrative reports have been published, but they give limited insight into the depth of the discussions.
Chair Steve Crocker has even stated in recent years that its goal was to make these public sessions “as boring as possible”.
That’s obviously no good for those of us who’d like to know how top-level decisions at ICANN actually get made.
The plan is for new CEO Goran Marby, who starts on Monday, to come up with a proposal before the Helsinki meeting next month, with a view to start publishing transcripts not long thereafter