ICANN Tackles Name Collisions, to Registries' Delight
ICANN's decision to study potential impact of name collisions on security and stability of the domain name system is a positive step, said Donuts Vice President Communications Judith McGarry in an interview. Donuts is one of several registries that applied for generic top-level domains .home, .corp and .mail in the last round of applications, but ICANN held up the names over concerns they're at high risk of conflicting with internal or private name spaces such as corporate servers. The problem is caused by ICANN's mistaken belief DNS names are universal, global identifiers, said former board member Karl Auerbach, now InterWorking Labs chief technical officer.
Sign up for a free preview to unlock the rest of this article
If your job depends on informed compliance, you need International Trade Today. Delivered every business day and available any time online, only International Trade Today helps you stay current on the increasingly complex international trade regulatory environment.
ICANN considered the applications for .corp, .home and .mail several times but decided to defer delegation indefinitely because of collisions, the board said in a resolution approved at its Nov. 2 meeting (see 1711020003) in Abu Dhabi. A name collision occurs when an attempt to resolve a name used in a private name space results in a query to the public DNS, it said. Results of delegating these "collision strings" may be considered high-risk because, for example, a string appears frequently in queries to the DNS root servers or the user causing the collision is an emergency service, it said.
The board asked ICANN's security and stability advisory committee to answer questions about risks to users and end systems if .mail, .corp and .home, and other potentially high-risk names, are placed in the DNS root. The findings could lead to board action.
Name collisions are a valid concern, said McGarry. Donuts' position is if there's a workaround for the problem, ICANN should release the three gTLDs, and if not, it should do a study. Applicants for .home, .mail and .corp urged ICANN in August 2016 to commission a study on mitigation measures, saying recent developments showed risks anticipated by an earlier report "were grossly overstated." The concern was that ICANN kept hearing about the issue from registries but not doing anything, McGarry said. Donuts is delighted by the board's forward move, she said.
Software contains a sub-routine that goes by the name "gethostbyname," emailed Auerbach. Gethostbyname transforms a host name -- which isn't quite the same as a DNS name but often looks like one -- into an IP address, he said. "How that transformation occurs is where the name collision arises."
Operating systems make network connections on the basis of IP addresses, not host names, said Auerbach. It's up to the applications to figure out the best way to transform names users utter into those IP addresses, he said. For instance, a web application might pull a domain name out of the middle of a URL and pass that name-containing string to gethostbyname, he said. The application takes the resulting IP address and feeds it to the operating systems when it makes a connection. The name collision arises because gethostbyname has to do a lot of work to figure out what the name means, he said. Sometimes, the name the user supplied is just a word, and gethostbyname may try to append various extensions based on local considerations to come up with a fully qualified name that will generate an address. Over the years, many people created DNS-looking name structures, where .mail and .corp issues arise, he said. None of this interacts with or harms the actual mesh of DNS servers, Auerbach said.
"The problem is a clash between ICANN's belief that DNS names are universal, global identifiers and the internet notion that innovation ought to occur at the edges without being subject to a central authority," Auerbach said. The DNS has been used as a kind of authoritative system in which internet applications expect that mapping a name from a DNS name to an IP address will lead them to the service they want, but don't check after they connect to validate that they have reached the proper correspondent, he said. What's missing is a protocol layer where, once a connection is made, the two ends identify themselves and then prove that identity to one another, he said. With strong mutual identification and authentication, name look-up errors such as those caused by name collisions would be detected and bad connections denied, Auerbach said.