At the ICANN meeting in Buenos Aires, US government confirmed the process of transition will extend beyond September this year, and experts think that several more intensive months will be needed
The root zone and root servers have traditionally attracted plenty of attention in policy and academic discussions. Some of the main debates have revolved around issues such as the risks associated with a possible collapse of root servers, and the feasibility and implications of alternative root systems.
The root zone is the highest level in the Domain Name System (DNS) technical structure. The root zone file contains the lists of names and Internet Protocol (IP) addresses of all top level domains (both generic top level domains - gTLDs and country code top level domains - ccTLDs) in the DNS.
The management of the root zone is carried out by the Internet Assigned Numbers Authority (IANA), whose functions are currently performed by the Public Technical Identifiers (PTI), an affiliate of the Internet Corporation for Assigned Names and Numbers (ICANN). In performing this role, PTI assigns the operators of top level domains and maintains a database with their technical and administrative details.
The maintenance of the root zone file itself is performed by Verisign, on the basis of an agreement with ICANN. Verisign’s role in this regard is to edit the file (at ICANN’s proposal), publish it, and distribute it to root server operators. (Prior to the IANA stewardship transition, the root zone maintainer function was subject of a contract between Verisign and the US government.)
The DNS root zone is served by root servers – also known as authoritative servers, which keep the public copy of the root zone file. There is a misconception that the total number of root servers is 13. The fact is that there are hundreds of root servers scattered at various locations around the world. The number 13 comes from the 13 different hostnames, due to a technical limitation in the design of the DNS. Twelve entities – academic/public institutions (6), commercial companies (3), and governmental institutions (3) – manage these primary instances and ensure that all root servers within the same instance have the updated copy of the root zone file.
If one of the 13 hostnames crashes, the remaining 12 would continue to function. Even if all 13 went down simultaneously, the resolution of domain names into IP addresses (the main function of root servers) would continue on other domain name servers, distributed hierarchically throughout the Internet.
The system of root servers is considerably strengthened by the Anycast scheme, which replicates root servers throughout the world. This provides many advantages, including an increased robustness of the DNS and the faster resolution of Internet addresses (with the Anycast scheme, the resolving servers are closer to the end-users).
Therefore, hundreds of domain name servers contain copies of the root zone file and an immediate and catastrophic collapse of the Internet could not occur. It would take some time before any serious functional consequences would be noticed, during which time it would be possible to reactivate the original servers or to create new ones.
While ICANN, via PTI, operates and manages the DNS root that most users of the public Internet rely on, there are also active alternative DNS roots. Organisations operating such roots offer their own top-level domains (usually different from the ones administered within the ICANN framework); end-users wishing to use such services need to reconfigure their network settings to deviate from the universal root to the alternative one. Examples of alternative roots include AlterNIC, Open NIC, New.net, and Name.space. Most of them were unsuccessful, accounting for only a few per cent of Internet users. One more recent project – the Yeti DNS Project – plans to ‘build a parallel experimental live IPv6 DNS root system to discover the limits of DNS root name service’.
Creating an alternative root name server system is technically straightforward. The main question is how many followers an alternative server would have, or, more precisely, how many devices on the Internet would point to it, when it came to resolving domain names. Without users, any alternative DNS becomes useless.
For a long time, the principle of the single root server was considered to be one of the main Internet mantras, which were not supposed to be touched or even discussed. Various arguments have been put forward in order to prevent any discussions about alternatives to the single root server. One argument is that the current (single root server) system prevents the risk of the DNS being used by some governments for censorship. However, this is losing ground on a functional basis. Governments do not need control over the DNS system or the root zone file in order to introduce censorship. They could rely on more effective tools, based, for example, on the filtering of web traffic.
A more solid argument is that any alternative root systems could lead towards the fragmentation and even, maybe, the ultimate disintegration of the Internet. Even though all root systems use the same system of IP numbers, they have different naming approaches and resolution techniques. It may happen that several root systems have the same domain names, but they resolve to different IP addresses (which host different content). Moreover, most of the alternative DNS roots are not interoperable – with ICANN’s DNS root or among themselves – thus breaking the principle of universal resolvability (according to which there is a single way to resolve a domain name into an IP address). Except for the cases when such alternative roots are used for strictly private purposes (e.g. within closed networks), their existence may prevent some parts of the Internet from reaching others. This fragmentation could endanger one of the core functions of the Internet – a unified global communication system.
The latest edition of glossary, compiled by DiploFoundation, contains explanations of over 130 acronyms, initialisms, and abbreviations used in IG parlance. In addition to the complete term, most entries include a concise explanation and a link for further information.
The book, now in its sixth edition, provides a comprehensive overview of the main issues and actors in the field of Internet governance and digital policy through a practical framework for analysis, discussion, and resolution of significant issues. It has been translated into many languages.
The report provides a snapshot of the state of deployment of DNSSEC as of the end of 2016. It addressed two main aspects for deployment of DNSSEC: DNSSEC signing (how many zones are signed using DNSSEC and have a chain of trust back to the DNS root), and DNSSEC validation (what recursive resolvers support DNSSEC, and how many clients are using DNSSEC-validating DNS resolvers).
The report outlines a series of recommendations for changing the DNSSEC root zone Key Signing Key (KSK). The process of changing the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties including Internet service and other DNS resolver operators, DNS resolver software developers, integrators, and distributors. The KSK is used to cryptographically sign the Zone Signing Key, which is used to sign the root zone of the Domain Name System.
The report provides information on the relationship between the US Government's National Telecommunications and Information Administration (NTIA) and the Internet Assigned Numbers Authority (IANA), as defined by the 'IANA FUnctions Contract'.
The report looks into the possible impact of the launch of new generic top level domains (gTLDs) on the Internet root server system.
There were several sessions on the subject of geographic names of countries and territories at the ICANN60 meeting held in Abu Dhabi. These include the Governmental Advisory Committee (GAC) meetings on two-character codes as second level domains (SLDs); country and territory names as SLDs; Working Group to examine the Protection of Geographic Names in any Future Expansion of generic Top Level Domains (gTLDs) Meeting; GAC meeting with the ICANN Board; and Generic Names Supporting Organization (GNSO) New gTLD Subsequent Procedures Policy Development Process (PDP) Working Group Face-to-Face Session II: Work Track 5 on Geographic Names at the Top Level.
During the GAC meeting on two-character codes as SLDs, several GAC members, including Argentina, Brazil, and Iran, raised the concern that the points mentioned in the GAC Communique of Johannesburg (ICANN59), which outlined the ICANN Board’s consent to taking into consideration the views of GAC members on the subject, and the ICANN CEO suggesting the formation of a task force to address concerns mentioned in Copenhagen (ICANN58), were not implemented. Further, there were concerns about lack of transparency, and also concerns that ICANN was discussing issues related to two character codes bilaterally with individual GAC members and not with the entire GAC group. ICANN staff further clarified that 25 governments were having bilateral communication with ICANN. Several countries, such as Portugal and Indonesia wanted to know the exact status of the issues raised by the governments, and how they would be resolved.
On the question about resolving the issue related to two characters at SLDs raised during the GAC meeting with the ICANN Board, Mr Goran Marby, CEO, ICANN, said that he would be commenting on this post-discussion with the ICANN Board. He further clarified that until then the current process related to protection of country and territory names would continue. Regarding concerns with country and territory names at the second level, he reminded GAC members that the ICANN Board had passed a resolution which authorised the release of country and territory names at the second level to a registry operator after the governments expressed their agreement to the release.
During the GAC meeting on country and territory names, Mr Thomas Scheinder, GAC chair, referred to the GAC position expressed in the ICANN59 communique on the matter. It was further clarified that for top level domains, the issue was taken up by the co-chairs of the new gTLD subsequent procedures PDP who proposed the initiation of a new work track in the PDP (work track (WT) 5) which would include one representative of the GAC. However, there were concerns raised from Iran about whether the GAC would be on equal footing with others in the working group. Argentina further clarified that Switzerland, in their proposal, had proposed a group of interested GAC members to be involved in the working group, as that would ensure different perspectives. India emphasised the need to amend the existing ISO 3166 list, used within ICANN as a basis for discussion on country and territory names, and expand it further to include territories whose names are not there. The GAC chair further clarified that the conditions for GAC participation in WT5 have been communicated to the concerned parties, and, if those conditions are not met, the committee will need to reconsider its approach.
At the meetings of the GAC Working Group to Examine the Protection of Geographic Names in any Future Expansion of gTLDs, there were discussions on ways for the GAC to participate in the WT5 on geographic names of the New gTLD Subsequent Procedures PDP Working Group. The GAC working group decided to ask the GAC leadership to constitute a small group of GAC members to participate in the WT5 .
During the GNSO New gTLD Subsequent Procedures PDP Working Group Face-to-Face Session II: Work Track 5 on Geographic Names at the Top Level meeting, the discussion was centred around the elements and terms of reference. The WT5 is dedicated to geographic names at the top level, and is expected to develop a consensus-driven set of recommendations/implementation guidance for subsequent procedures. On the question related to the decision making process, it was clarified that it would be either a consensus or rough consensus. On the question of who will be determining consensus, it was clarified that the co-leads would be the ones tasked with measuring consensus according to the definitions that are in the operating guidelines. Further, on the comments from the GAC, Country Code Names Supporting Organisation (ccNSO) and AtLarge representatives seeking time to consult with their communities and get back before sharing their view, Mr Jeff Neuman, co-chair of the New gTLD Subsequent Procedures PDP Working Group, stated that the GNSO would not wait for formal approval before moving forward. There were also queries raised as to whether this process is to be seen as a preventive mechanism or an engagement process. On the question related to the timeline for the process, it was to be decided by the working group. The call for volunteers is open till 20 November 2017.
Jurisdiction has been a ‘hot topic’ within the ICANN community for a long time. The ICANN60 meeting was no exception, and the issue was discussed in different frameworks: as part of the face-to-face meeting of the Cross Community Working Group on Enhancing ICANN Accountability (CCWG-Accountability), in the ‘Jurisdictional Challenges for ICANN’ cross-community session, and as part of the agenda of the Governmental Advisory Committee (GAC), among others.
This report focuses on the cross community session on ‘Jurisdictional Challenges for ICANN’, organised at the proposal of the GAC. The session was structured in two parts: the first focused on the jurisdiction-related recommendations of the CCWG-Accountability; and the second looked at broader community concerns based on the application of the laws of ICANN’s place of jurisdiction.
As part of its Work Stream 2 (WS2), the CCWG-Accountability has a sub-team focusing on jurisdiction-related issues. Recently, the sub-team produced a report with two sets of recommendations: one regarding licenses from the US Department of Treasury, Office of Foreign Asset Controls (OFAC), and the other one regarding choice of laws clause in ICANN’s Registry/Registrar Agreements. The sub-team’s report containing these recommendations has been approved in the CCWG plenary, on the basis of a rough consensus (with objections from the Brazilian government) and will soon be published for public comment.
Recommendations related to OFAC. As ICANN is a corporation based in California, it needs to comply with the sanctions imposed by OFAC (OFAC enforces economic and trade sanctions against targeted foreign countries, in line with US foreign policy and national security goals). The CCWG jurisdiction sub-team recommends that ICANN commits to making best efforts to apply for specific OFAC licenses that would allow the organisation to have relations with registrars based in countries affected by OFAC sanctions. As negotiations over obtaining an OFAC licence are a difficult and lengthy process, ICANN needs to be transparent and communicate regularly with regard to the process and progress achieved in securing such licences. The same should happen for future applicants for new generic top-level domains (gTLDs). It is also recommended that ICANN studies the costs and benefits of applying for a general OFAC licence.
Recommendations related to choice of laws in Registry/Registrar Agreements. The sub-team recommends that ICANN adopts a menu approach with regard to the choice of laws in Registry/Registrar Agreements. There are no specific recommendations as to what the menu should consist of, but it could include, for example, one country per ICANN region, several countries per ICANN region, the country of the registry’s/registrar’s home office, California/US law. With regard to the choice of venue for arbitrations, there is a recommendation that a venue menu could also be adopted. The current Registry Agreement calls for arbitration with a seat in Los Angeles. Instead, there could be a menu with options for other potential seats.
During the discussions, it was noted that the recommendations related to OFAC address real issues faced by registrars and registrants in countries affected by OFAC sanctions. In this sense, they are needed and could be seen as one of the most important steps in ‘neutralising’ any potential accountability bias coming from US jurisdiction, by allowing people in countries sanctioned by the USA to continue to have access to the DNS. With regard to the recommendations on the choice of laws, it was said the suggestion for menu options could affect how the governing law clause in the Registry/Registrar Agreements is fashioned, leading directly to how contracts are interpreted and enforced. For some, this could have an impact on accountability within the ICANN context.
Brazil explained that it had dissented from the jurisdiction-related recommendations not because it opposes the substance of the recommendations, but because it finds the recommendations to be incomplete, with some issues being inadequately addressed. The dissenting opinion, Brazil underlined, should not be seen as an attack on the multistakeholder model. The country is a supporter of this model, but it is concerned about how governments in this model can have even conditions and be on a truly equal footing. The opinion is also not about moving ICANN to a different jurisdiction, as Brazil accepts what was agreed as part of Work Stream 1, i.e. that ICANN should remain headquartered in the USA. What Brazil wants to see is a continuation of exploring a partial immunity solution for ICANN.
Another point made during the discussion was that, while the IANA stewardship transition process led to the elimination of US stewardship over the root zone, ICANN, as a corporation, has to be rooted somewhere, and it was broadly agreed in WS 1 that California is as good a jurisdiction as any other. Yet, there is still the possibility that the US government will regulate ICANN. But, wherever ICANN is located, there is the possibility that the government there could choose to regulate it or interfere with its operations. The question is how to deal with such possible situations.
On the issue of immunity, it was said that the problem within the sub-team was that there was no viable model identified for achieving it. Observations were made that careful consideration needs to be given to this concept, as immunity could also mean immunity from accountability. Some members of the sub-team were concerned that the concept of immunity could possibly release ICANN from the kind of accountability to basic forms of law that the community wants ICANN to have. Another aspect that was discussed was related to the international organisations’ immunity act in the USA: if this were to apply to ICANN, it would effectively mean having ICANN ask the US Congress what kind of immunities it could have. This was seen as reversing the IANA stewardship transition process.
Some commented that, if the issue of immunity is being discussed, it should be addressed from the standpoint of immunising ICANN from the jurisdiction of all countries (not only the USA).
During the discussions, many were in favour of continuing the debate on how to make progress on the issue of immunities. A point in this regard was to be added to the report of the jurisdiction sub-team: while the discussions on limited or impartial immunity for ICANN did not come to a conclusion during the work of the jurisdiction sub-team, the concerns raised were legitimate, and, as such, there should be a path forward for these concerns to be discussed beyond the CCWG-Accountability work. The issue of immunity was seen by many as being beyond the scope of the CCWG-Accountability, but the community was encouraged to build upon the work of the jurisdiction sub-team when addressing the issue in a different context. There was a suggestion for a new cross-community working group to be established with the sole purpose of exploring the immunity issue.
Discussions on jurisdiction issues were also held within the GAC. As reflected in the communique issued by the committee at the end of the Abu Dhabi meeting, some members welcomed the recommendations of the CCWG-Accountability jurisdiction sub-team, both concerning OFAC (and the efforts to be made by ICANN to apply for OFAC licenses), and the menu options for the choice of laws in Registry/Registrar Agreements. Other members were of the view that the recommendations were insufficient in addressing concerns related to ICANN being located in the USA. Several members expressed their wish for the ICANN community to continue discussions on the issue of limited or partial immunity for ICANN.
The ICANN60 Annual General Assembly Meeting had several sessions focusing on Domain Name System (DNS) abuse and mitigation. The first two workshops (WS 1 and WS 2), organised by Mr David Piscitello, Vice President, Security and ICT Coordination, ICANN, were held under the theme ‘How It Works: DNS Abuse’. Piscitello’s presentations explained various ways cybercriminals are using DNS fraud, hijacking via phishing, social engineering, and data breaches, and gave examples of the most prominent cases such as Avalanche and how it was tackled. Piscitello underlined challenges faced by law enforcement agencies, such as jurisdiction, lack of common criminal law, and the slowness of Mutual Law Enforcement Assistance, as criminals operate at Internet pace. Addressing privacy concerns as well as security, he pointed to alternatives such as tiered access to personal data. He mentioned another cause of security vulnerabilities: developers repeating their peers’ previous mistakes such as continuing using lax configurations.
The Domain Name Abuse Reporting System (DAAR) which uses public, open, and commercial sources such as DNS Zone data, WHOIS data and reputation blocklist (RBL) was the focus of the ‘Abuse Reporting for Fact-Based Policy Making and Effective Mitigation’ cross community session. DAAR and its planned open data initiative’s goal of ‘providing data to support community, academic, or sponsored research and analysis for informed policy consideration’ was discussed. Mr Rod Rasmussen, incoming chair, Security and Stability Advisory Committee (SSAC), stated that although the technological aspect of abuse (e-mails, browsers, firewalls detecting abuse in seconds) was solved, the policy aspect was not. He mentioned the use of reverse engineering domain name generators and observing the results to identify abusive users. Piscitello underlined this point saying that a system able to identify which policies worked and which did not was needed. The benefits of opening DAAR data to the public were listed as historical trend analysis, flagging registrars who are not responsive to abuse reports, contractual compliance reporting, and providing data for efficient policy making. Ms Tatiana Tropina, cybersecurity expert representing the Non-commercial User Constituency (NCUC), drew attention to the limited mission of ICANN, the dangers of blurring lines between DNS and content abuse, and risks related to self-policing by the domain name industry instead of law enforcement. Another participant stated that the data DAAR will open to the public was aggregate and could not be used for contractual compliance.
Ms Denise Michel, Business Constituency (BC), drew attention to data showing new generic top-level domains (gTLDs) experiencing 10 times higher abuse than legacy gTLDs, and stated that ICANN is planning to introduce a policy addressing this. How abuse reporting can support registries and registrars in their prevention and mitigation efforts was among the key questions discussed.
‘GAC discussion on DNS Abuse Mitigation’ was the final session of the annual meeting related to DNS abuse. Updates and action points of the Public Safety Working Group (PSWG) were presented to government representatives. The implications and possible benefits the DAAR and its planned open data initiative could have for domain names hosting child abuse material were among subjects flagged by Italy, the UK, Iran, and Australia’s GAC representatives.
The advisory, elaborated by the Root Server System Advisory Committee (RSSAC) of the Internet Corporation for Assigned Names and Numbers (ICANN), and addressed to the ICANN Board of Directors, contains recommendations on a set of parameters considered to be useful to monitor and establish a baseline trend of the root server system.
The guide provides basic information about the so-called IANA functions: protocol parameters, Internet number resources, and root zone management of the Domain Name System.
The proposal, elaborated by ICANN and Verisign, outlines a possible modality for removing US's government's administrative role associated with root zone management (in the overall context of the transition of the US government oversight role over key Internet domain name functions to the global multistakeholder community - the so called 'IANA stewardship transition process').
The presentation outlines the role of the US Government's National Telecommunications and Information Administration in the management of the Internet root zone file.
The brief outlines a number of policy suggestions for ensuring the global inviolability of the Internet root zone.
The paper provides a general overview of what teh Domain Name System is and how it works.