|
Did you know that we are swimming in Domain Name System abuse? As an Internet user, you probably were not aware. Apparently, doomsday is near, and the Internet is going to explode in our face if we do not do something about “domain name system abuse.” This doomsday narrative has nearly jeopardized multistakeholder governance. However, it may also compel us to reconsider the multistakeholder model and its relevance in governing the Internet and its associated technologies.
One of the most important properties of the Internet is the domain name system (DNS). You almost always interact with the domain name system when you go online. A very limited part of the domain name system is governed by an organization called Internet Corporation for Assigned Names and Numbers (ICANN). The organization runs on a multistakeholder governance structure where the government advisory committee, non-commercial stakeholders groups and commercial ones get involved with setting policies for the allocation of domain names.
I won’t tell you what DNS abuse is because different policy positions result in different definitions. You can read my opinion here. However, domain name abuse should not be regulated by ICANN as long as it relates to regulation of content and services online. This is a very delicate distinction, and sticking to the technical definition of abuse is difficult. This is especially true as certain stakeholders, such as intellectual property stakeholders, almost always want to expand the mission of ICANN and argue that intellectual property abuse is DNS abuse.
We don’t want ICANN to be a content regulator because we don’t want a centralized body that can be a global police that takes down domain names and polices the registries and registrars (the companies and operators of domain names). Autonomy is good, and suspension of services on the Internet is bad for speech, creativity, business, and for keeping the Internet global and open.
I am not denying that DNS abuse exists. We operate on the global Internet, and most of us want to keep it like that. When technical abuse happens, actors are involved mostly globally, and it happens in a shared space. So it is important through collective action to clean up the house.
However, it is worth noting that DNS abuse did not increase even during and after COVID-19, when we saw an unprecedented usage of the Internet. Despite this, Intellectual Property lawyers, commercial security companies and public safety working group at the Government Advisory Committee at ICANN urged the registries and registrars to do something about DNS abuse. The registries and registrars held many meetings with the non-commercials and other stakeholders.
The non-commercial group maintained that since abuse has not increased even during COVID-19, what is there to be done, and why do we have to do something about it at ICANN? But the political will has won. Registries and registrars have started bilateral negotiations with ICANN (not through the multistakeholder model, however, after getting a blessing from the multistakeholder arm of a council at ICANN) to change their contracts to add more provisions about DNS abuse.
The contractual amendment is up for public comment stating 1) not to include content (which would not have been valid anyway because ICANN bylaws won’t allow them) in the definition of DNS abuse, and 2)recommends adding a limited definition of spam; 3) it suggests changing the term from “security threat” to “DNS abuse.” The rationale behind this change is “This clarifies that registry operators must periodically conduct a technical analysis to assess whether domains in the top-level domain (TLD) are being used to perpetrate DNS Abuse and maintain statistical reports on identified DNS Abuse.” It is not very clear why the term needs to change to require registry operators conduct technical analysis. They can be required to conduct the analysis without having to call it “DNS abuse.”
As the call for comments expresses: “The proposed amendments would enhance obligations by requiring registrars and registry operators to promptly take reasonable and appropriate action to stop or otherwise disrupt DNS Abuse.” It then claims that it relies on a definition from the security and stability advisory committee, (a closed group of security and stability professionals at ICANN) to add spam to the definition, but as long as spam is used for delivery of DNS abuse. When looking at the paragraph mentioned in the SSAC document, SSAC actually refers to other initiatives where it has gotten the definition from. This is important, because it seems like they have not done a lot of direct consultation with technical experts to provide the limited definition of spam. As the definition stands for now, it is very much prone to over-reporting as the spam might not be used for DNS abuse right away but potentially used in the future to deliver malware, phishing and other technical abuse. It should be noted that this definition of Spam is also mentioned in other ICANN security programs.
My impression is that ICANN is more and more turning into a trade association with multistakeholder theater to grant legitimacy to its decisions. Obviously, we have failed to solve “DNS abuse” through a multistakeholder approach, but through multistakeholder pressure, we have made registries and registrars take action (unnecessary but still). I believe at ICANN, we did not need to do anything. There are arguments to be made that the 2013 contractual clause was ambiguous about what the registrars should do, and this limited ICANN’s Compliance team’s ability to enforce the contract. However, would it have been better to work on compliance interpretation and get the collective action going (like we did in the case of Conficker in 2008) or open up a can of worms that really went against the spirit of the multistakeholder model? The sooner we admit how the multistakeholder model of the Internet has evolved, the sooner we can decide whether it makes sense to have a trade association with multistakeholder theater that provides registries and registrars with advice, which they can take or leave.
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byVerisign
Sponsored byIPv4.Global
Sponsored byRadix
Sponsored byWhoisXML API
Sponsored byCSC