In this article I will explain the motivations behind the SocialDNS Project. I will justify why the DNS system is NOT the phone book of the Internet. More concretely, DNS is not a public directory nor enables search mechanisms over meta-information related to domains.

In this line, I will present the advantages of SocialDNS, a naming and directory system that aims to become the phone book of the Web. SocialDNS is NOT another alternative DNS root nor aims to replace the current DNS for resolving domain names. It complements the existing DNS to offer advanced services that are beyond the scope of the existing infrastructure for Web settings.

A bit of History: the DNS controversy

The Domain Name System (DNS) is a core component of the Internet and the World Wide Web. The DNS system converts names to IP addresses and it is used to resolve domain names in Web URLs (Uniform Resource Locators) like http://www.socialdns.net.

A domain name consists of several labels separated by dots. The rightmost label conveys the Top Level Domain or TLD (.com, .net) and each label to the left specifies a subdomain of the domain above it. The DNS system distributes the responsability for assigning domain names and managing them to Authoritative Name Servers for each domain. In the case of TLDs, they are maintained by a set of replicated root servers distributed around the world. In this line, the root authority decides which TLDs can exist and who manages them. In the beginning this authority was controlled by the Internet engineering community but the US Government took control of the Root Authority in the nineties due to the increasing importance of the Internet.

The DNS controversy erupted in 1995 between leaders of the Internet engineering community in one side and the US Government and commercial interests (trademarks) in the other side. The major conflict arose around the creation and management of new TLDs. In 1996, the engineering community lead by Jon Postel adopted a plan to create seven new TLDs (arts, firm, info, nom, rec, shop and web) and reconstitute .com,.net and .org as globally shared resources, all under non-profit administration. In 1997, several international parties ratified a document called the Generic Top Level Domains Memorandum of Understanding (gTLD-MoU) and deposited it in the International Telecommunications Union (ITU).

The problem grow when Jon Postel planned with the Internet Society to create a Geneva-based society called the Council of Registrars (CORE), 88 companies that would register under seven new gTLDs using a centralized database. Postel assured these companies that he had the power to add these new gTLDs for them. However, the government rejected this idea and instead recommended that NSI (Network Solutions, Inc.) keep the .com, .org and .net domains and maintain the control of the Root Authority.

In this context, Jon Postel made a risky step. Postel, as head of the Internet Assigned Numbers Authority (IANA), sent an email to all root server administrators ordering them to reconfigure their machines to point to them at an IANA server. Only four regional servers (NASA, US Military, Ballistics Research Lab, NSI) continued to recognize US control over the root and the rest complied with Postel’s request. He had taken control over the Root Authority.

The solution to the DNS controversy was solved by the US Government: Postel had to rectify and ICANN ( Internet Corporation for Assigned Names and Numbers) was created to control the Root Authority. The consequence is that the creation of new TLDs is a complicated process following a slow pace. In 2000, ICANN issued the last call for TLDs registering only seven of forty seven proposals. Each requester paid a registration fee of $50,000 for entering the call.

In the recent ICANN meeting in Paris, ICANN has just approved the relaxation of the rules for the introduction of new Top-Level Domains. While this is a right step in the right direction, it seems that ICANN will continue earning a minimum of $50,000 per TLD and it will apply strong trademarks restrictions for assigning new TLDs. My opinion is tha ICANN will assign a maximum of tens of TLDs per year from the year 2009 (or a maximum of hundreds). This will create a selected elitistic group of big companies and organizations capable of paying the registration amounts for new TLDs. This is not a massive proliferation of TLDs but rather a small and controlled growth.

Nowadays, the reality is that creating new TLDs is a costly process, that .COM and .NET TLDs are doing good business and that it exists as a strong speculation over domain names in the Internet.

Why DNS is NOT the Phone Book of the Internet

Wikipedia literally says in the DNS entry that it “serves as the phone book for the Internet”. We believe that this definition is incorrect or not complete. In a phone book, every user registers his name (domain in DNS) and associate a phone number (IPs in DNS). Moreover, users also add their physical address to the phone book. In the case of yellow pages directories, companies also specify the category to be classified (restaurant, hotel, ...). Phone books are public and every user can query or search the book for meta-information (restaurants in their locality for example).

DNS is simply a naming service for the Internet that converts domain names to IP addresses. But the DNS is not public, TLDs do not make available the list of domains that they contain. VeriSign (current owner of .COM) is even planning commercial benefits from selling part of the domain list to third parties.

And the DNS is not a directory service nor aims to. It is not designed to store meta-information associated to domain names and to permit world wide queries over this metadata. DNS designers have stressed in the past that DNS does not aim to become a directory system. As stated in Signposts in Cyberspace, “as the Internet developed in size, scope, and complexity, the DNS was unable to satisfy many Internet user’s needs for navigational assistance”. In this scenario, search engines like Google or Yahoo have superseded the DNS as the de facto Internet directory.

The SocialDNS Project

The key idea behind the SocialDNS project is to create an entire new namespace for Web resources around the URL protocol handler go://. We have created browser plugins for Firefox and Internet Explorer that resolve domain names using the go:// protocol handler. It is thus possible to resolve names in our namespace in the browser window and even follow hyperlinks in Web pages that use this handler.

The notation of names is the same than in the existing DNS. The rightmost label conveys the Web Top Level Domain (Web TLD) and each label to the left specifies a subdomain of the domain above it. SocialDNS is a URL-to-URL indirection service that can coexist without problems with the underlying naming infrastructure. In this line, a Top Level Domain like go://socialdns can be mapped to http://www.socialdns.net or instead to http://130.206.36.42/socialdns. As we can see, this opens the way to short memorable names containing semantic information (go://nokia, go://ny, go://bcn, go://pedro). In some way it is similar to the TinyURL project but containing semantic content.

Furthermore, it is possible to Web TLD. Using an open standard based on Web protocols (HTTP, XML), every TLD can resolve its subdomains. In this line, the Nokia Web TLD can then assign for example go://n95.nokia to http://www.nseries.com/products/n95. Like in DNS, the resolution of names is delegated to Authoritative Web Servers and more levels could be created (go://es.n95.nokia).

But let us study the major innovations that justify the existence of SocialDNS:

Name restrictions, name speculation and Unlimited Web TLDs

By creating an entire new namespace we do not have any limitation for assigning names and TLDs. We do not depend on any government, institution or trademark policies for assigning names. We have completely opened the entire namespace so it is possible to register any domain and Web TLD without cost. All the name resolution conflicts will be handled by their own users with an open and transparent moderator system.

Furthermore, we have established simple rules to avoid name speculation and cybersquatting in our namespace. SocialDNS may face a big problem if it begins a gold rush for names due to the costless nature of the system. To avoid this, the conflict resolution rules make useless this name speculation: domain names must be linked to related contents and moderators can always remove ownership to speculators. We will prosecute and punish, with the help of users, any name speculation attempt.

The consequence of the open and costless process is that millions of Web TLDs can be created. We believe that every city (.ny, .bcn), company (.ibm, .nokia), organization (.ieee, .scout), and even end user (.pedro, .johnsmith) should manage one or more TLDs. In a network with more than 1,400,000,000 users and 135,000,000 web servers, domain names could flourish.

Finally, an interesting aspect to outline is that SocialDNS can use international names from the very beginning. By using the IDNA standard (International Domain Names in Applications) it is possible to assign domains in any language (chinese, arabic, ...). This opens the way to millions of names in different languages and cultures.

Directory Service and cloud search engine

A phone book for the Web should offer both naming and directory services. When you register a name you also add meta-information. In the yellow pages directory model, users introduce the meta-information that enables others to find them properly. SocialDNS follows the same approach of linking meta-information to domain names. When a user registers a domain, it must also include a list of tags and optionally, its geographic location coordinates (using Google Maps). This information is stored and indexed in a database and enables other users to locate this Web resource.

Furthermore, thanks to the semantic information contained in domain names, SocialDNS introduces the concept of “cloud Search”. Similar to Tag clouds, every query to the system will return a cloud of results. Unlike traditional search engines returning lists of results, the cloud enables to capture more information in a single screen. It also avoids information overload using size and colours to outline more relevant results. Currently, the system offers the cloud search engine, and cloud browsing in three clouds (domains, tags, geographic).

Finally, and although the system only includes meta-information fields like description, tags and geotags, it is designed to support more meta-data fields. In this line, semantic information (RDF) could be directly attached to web resources. The open APIs will also enable to add more sophisticated meta-fields for specific purposes associated to domain names.

Public and free Service based on open systems

Because SocialDNS aims to become a standard for the Web, all the information is public, the software is available as open source (WebTLD server) and we offer open APIs to access the system.

In the origins of the Internet, all names were stored in a public file called “hosts”. In SocialDNS, we follow this naming convention and every TLD (including the root) must publish an XML file named “hosts.xml” containing the TLD’s information (domains, mappings, meta-information). You can obtain the root file in http://www.socialdns.net/domains/hosts.xml and from that file it is possible to obtain all the information in the SocialDNS namespace (TLDs and subdomains).

This design decision is very important because we open the SocialDNS database to the world. Third-party search engines and tools can parse and index this information without cost or restrictions. Note that search engines like Google or Yahoo protect their information as a company asset. I believe that the information belongs to all the users and because of that it must be public and free.

Furthermore, the WebTLD server software is available as open source in Sourceforge. Note that the WebTLD server software is the same that we use in the root server. This implies that everyone can study how the system works. This also opens up the possibility for every TLD manager to modify or extend the system for their requirements. We also publish the protocol between plugins and WebTLDs (HTTP, XML). This also implies that anyone can develop its own Web TLD server software.

Meta-Services associated to Domain names (example: Communication channels)

Finally, I believe that many meta-services can be developed around domain names. Examples of these services could be domain rating or communication channels but I am sure that others will devise more innovative applications.

We already implemented the communication channels around domains. We associate a public communication channel to every domain as a communication medium between users interested in this domain. Every channel generates a standard RSS file and external parties can subscribe to events in this channel. We believe that this communication tool can help to create communities around domains. We still have to explore the possibilities of social software and community building around domains and Web TLDs.

In fact every WebTLD can become a community hub for users interested in those contents (.java, .esperanto, .scout). Formerly, Usenet was a unified directory for conversations around topics (comp.lang.java.jdbc, comp.lang.java.j2ee). Now, SocialDNS name structure may also help users to find specific conversations (.java, jdbc.java, j2ee.java, ...).

Another useful meta-service is domain rating. If users can valuate domain quality, this can become a useful tool to order results obtained by the cloud search engine. As stated before, other meta-services can be developed around domains or tags like presence, collaborative browsing, annotation, wikis, domain graffities and others. If the system is a success I expect that many developers will contribute to the system.

Open Challenges

SocialDNS faces three major challenges that can hinder its correct development:

Conflict Resolution and Moderators

A potential risk can arise if it begins a gold rush for domain names. Speculators can register millions of domains due to the costless nature of domains. We need strong mechanisms to detect and ban these speculators from the system. If our reaction is not fast other users may be disappointed if too many domains are already reserved. We believe that our simple naming policies along with efficient conflict resolution schemes can avoid this useless gold rush.

Another challenge for SocialDNS is the selection and rewarding of moderators. If the system has to grow to millions, we need a lot of moderators from all cultures. We also need a transparent process to avoid bitter disputes over domain names. I will ask for the help of external users and organizations to participate in the moderation phase. This phase is completely necessary to make the system a success. I believe in a user-managed, open and efficient process that can lead to self-organization and system evolution. I do not believe in slow institutional or government lead bureaucracies to solve conflicts.

System Scalability

Another severe problem for SocialDNS is system scalability for the root TLD (socialdns.net). The system is not prepared now for massive usage and it would fall if we receive a slashdot effect. The natural solution is to rely on mature Content Distribution Networks like Akamai. Such CDNs could then balance the load around the world and guarantee rapid resolution times from different locations. Another alternative is to use Cloud Computing Services like Amazon EC. Finally, we can also consider in a future to delegate name resolution to TLDs and make them replicate the root XML file.

Conflicts with ICANN

Another potential risk if we have a lot of success is the radical opposition from ICANN and DNS registrars. Although SocialDNS is an indirection infrastructure for the Web that does not compete with DNS, they can see a potential menace to their commercial interests around TLDs. To avoid conflicts with ICANN, we will maintain ownership in our namespace for TLDs already assigned by ICANN. In fact, out WebTLD server software could be used by ICANN TLDs to create communities and search engines around them. Even a side effect of the massive success of SocialDNS could be to improve the existing ICANN restrictive naming policies in a future and open their domain information to the Internet.

Conclusions

In this article, I presented the SocialDNS project, a novel naming and directory system for the Web that aims to become an open standard with millions of Web TLDs. I explained four major advantages of the system: Unlimited Web TLDs, directory and cloud search engine, the public and open approach and the meta-services around domains.

I believe that SocialDNS can become a revolution for the Web changing the way we name resources and even how we search for information. It is a return to the origins of the Internet where the information is public and where users have the power over the system. I also foresee interesting possibilities for WebTLDs like cities, organizations or companies to build lively communities and search engines around their TLDs.

References

SocialDNS Web Site
Original article in SocialDNS Wiki
Signposts in Cyberspace: The Domain Name System and Internet Navigation
Who Controls the Internet, Jack Goldsmith
In whose domain: name service in adolescence, Don Mitchell, Scott Bradner, K Claffy (1996)
ICANN, Internet Stability and new Top Level Domains. Jonathan Weinberg
Overview of the DNS Controversy
ICANN Board Approves Sweeping Overhaul of Top-level Domains
IAB Technical Comment on the Unique DNS Root