Latest news of the domain name industry

Recent Posts

Verisign targets bank claims in name collisions fight

Kevin Murphy, September 15, 2013, 16:29:01 (UTC), Domain Tech

Verisign has rubbished the Commonwealth Bank of Australia’s claim that its dot-brand gTLD, .cba, is safe.
In a lengthy letter to ICANN today, Verisign senior vice president Pat Kane said that, contrary to CBA’s claims, the bank is only responsible for about 6% of the traffic .cba sees at the root.
It’s the latest volley in the ongoing fight about the security risks of name collisions — the scenario where an applied-for gTLD string is already in broad use on internal networks.
CBA’s application for .cba has been categorized as “uncalculated risk” by ICANN, meaning it faces more reviews and three to six months of delay while its risk profile is assessed.
But in a letter to ICANN last month, CBA said “the cause of the name collision is primarily from CBA internal systems” and “it is within the CBA realm of control to detect and remediate said systems”.
The bank was basically claiming that its own computers use DNS requests for .cba already, and that leakage of those requests onto the internet was responsible for its relatively high risk profile.
At the time we doubted that CBA had access to the data needed to draw this conclusion and Verisign said today that a new study of its own “shows without a doubt that CBA’s initial conclusions are incorrect”.
Since the publication of Interisle Consulting’s independent review into root server error traffic — which led to all applied-for strings being split into risk categories — Verisign has evidently been carrying out its own study.
While Interisle used data collected from almost all of the DNS root servers, Verisign’s seven-week study only looked at data gathered from the A-root and J-root, which it manages.
According to Verisign, .cba gets roughly 10,000 root server queries per day — 504,000 in total over the study window — and hardly any of them come from the bank itself.
Most appear to be from residential apartment complexes in Chiba, Japan, where network admins seem to have borrowed the local airport code — also CBA — to address local devices.
About 80% of the requests seen come from devices using DNS Service Discovery services such as Bonjour, Verisign said.
Bonjour is an Apple-created technology that allows computers to use DNS to automatically discover other LAN-connected devices such as printers and cameras, making home networking a bit simpler.
Another source of the .cba traffic is McAfee’s antivirus software, made by Intel, which Verisign said uses DNS to check whether code is virus-free before executing it.
While error traffic for .cba was seen from 170 countries, Verisign said that Japan — notable for not being Australia — was the biggest source, with almost 400,000 queries (79% of the total). It said:

Our measurement study reveals evidence of a substantial Internet-connected infrastructure in Japan that lies beneath the surface of the public-facing internet, which appears to rely on the non-resolution of the string .CBA.
This infrastructure appear hierarchical and seems to include municipal and private administrative and service networks associated with electronic resource management for office and residential building facilities, as well as consumer devices.

One apartment block in Chiba is is responsible for almost 5% of the daily .cba queries — about 500 per day on average — according to Verisign’s letter, though there were 63 notable sources in total.
ICANN’s proposal for reducing the risk of these name collisions causing problems would require CBA, as the registry, to hunt down and warn organizations of .cba’s impending delegation.
Verisign reiterates the point made by RIPE NCC last month: this would be quite difficult to carry out.
But it does seem that Verisign has done a pretty good job tracking down the organizations that would be affected by .cba being delegated.
The question that Verisign’s letter and presentation does not address is: what would happen to these networks if .cba was delegated?
If .cba is delegated, what will McAfee’s antivirus software do? Will it crash the user’s computer? Will it allow unsafe code to run? Will it cause false positives, blocking users from legitimate content?
Or will it simply fail gracefully, causing no security problems whatsoever?
Likewise, what happens when Bonjour expects .cba to not exist and it suddenly does? Do Apple computers start leaking data about the devices on their local network to unintended third parties?
Or does it, again, cause no security problems whatsoever?
Without satisfactory answers to those questions, maybe name collisions could be introduced by ICANN with little to no effect, meaning the “risk” isn’t really a risk at all.
Answering those questions will of course take time, which means delay, which is not something most applicants want to hear right now.
Verisign’s study targeted CBA because CBA singled itself out by claiming to be responsible for the .cba error traffic, not because CBA is a client of rival registry Afilias.
The bank can probably thank Verisign for its study, which may turn out to be quite handy.
Still, it would be interesting to see Verisign conduct a similar study on, say, .windows (Microsoft), .cloud (Symantec) or .bank (Financial Services Roundtable), which are among the 35 gTLDs with “uncalculated” risk profiles that Verisign promised to provide back-end registry services for before it decided that new gTLDs were dangerous.
You can read Verisign’s letter and presentation here. I’ve rotated the PDF to make the presentation more readable here.

Tagged: , , , , , , ,

Comments (5)

  1. Steve DelBianco says:
    September 15, 2013 at 7:01 pm

    As Kevin says, the next big question is: What are the costs of collisions, in terms of business interruption, changing internal domains, and then re-programming everything to use new internal names?
    Guess we won’t know till collisions start happening, since nobody has studied that question yet.
    But we do know this much: New TLD applicants are responsible for whatever costs occur. The new TLD registry agreement says “Registry Operator shall indemnify and defend ICANN and its directors, officers, employees, and agents from and against any and all third-party claims, damages, liabilities, costs, and expenses…” (7.1)
    Bottom line: Commonwealth Bank of Australia makes just 6% of the colliding queries, but they’ll be responsible for 100% of the costs of .cba collisions around the world.

    Reply
    • Rubens Kuhl says:
      September 15, 2013 at 8:44 pm

      Repeating Fadi’s comment on this: “But who told users they had a right to use such domains ?” Except for RFC-defined internal names (which include .home, .corp etc.), expecting a suffix to be internal was a bad network design decision. The fact that the costs of those bad decisions will know come to light isn’t anybody’s but the designer’s fault.

      Reply
      • John Berryhill says:
        September 16, 2013 at 5:24 pm

        That’s been ICANN policy for 13 years. Again quoting from ICP-3:
        “Some of these operators and their supporters assert that their very presence in the marketplace gives them preferential right to TLDs to be authorized in the future by ICANN. They work under the philosophy that if they get there first with something that looks like a TLD and invite many registrants to participate, then ICANN will be required by their very presence and force of numbers to recognize in perpetuity these pseudo TLDs, inhibiting new TLDs with the same top-level name from being launched through the community’s processes.
        No current policy would allow ICANN to grant such preferential rights.”
        So, let me get this straight – a couple of network administrators for apartment buildings in Chiba, Japan, hold a TLD veto?

        Reply
  2. theo says:
    September 15, 2013 at 8:46 pm

    Judging Steve’s comment (makes sense), the registry operator should be prepared for the fallout and pass the buck.

    Reply
  3. John Berryhill says:
    September 16, 2013 at 5:21 pm

    Can someone explain this to me:
    1. Alternate root operators and users, who have premised their expectations and reliance on the non-existence of certain TLD’s in the ICANN root, are pointed to ICANN ICP-3 “A Unique, Authoritative Root for the DNS” which says, “As described in a recent proposal within the IETF,11 this “class” facility allows an alternate DNS namespace to be operated from different root servers in a manner that does not interfere with the stable operation of the existing authoritative root-server system. To take advantage of this facility, it should be noted, requires the use of client or applications software developed for the alternate namespace (presumably deployed after responsible testing), rather than the existing software that has been developed to interoperate with the authoritative root.”
    2. Notwithstanding point 1, we should otherwise defer to those who nonetheless have expectation and reliance interests in the non-existence of TLD’s, because it creates a security issue.
    Can someone explain to me, in technical terms, what is the difference between these two classes of internet users?

    Reply

Add Your Comment