ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    The Big Picture Building the alternative to DNS
    posted by michael on Thursday August 01 2002, @03:56AM

    odonnell writes "The time has come to solve the DNS/ICANN mess, not by fighting ICANN, not by reforming ICANN, but by deploying a new network identifier service to devalue DNS and TLDs."



    Mission

    As Milton Mueller observed in Ruling the Root, "Intrinsically, not much is in domain names. Their value as locators, identifiers and navigation aids is very much overrated." DNS combines two logical functions, which can better be engineered separately:

    1. it provides portable unique identifiers for entities and services, independent of the routing concerns that affect the assignment of IP numbers;
    2. it provides a directory of sort-of-meaningful names for entities and services.

    The time has come to separate these two functions. The strategic step is to deploy a new design and implementation for function #1, portable unique identifiers. A number of directory and search engine services are already competing to provide function #2, directory; some of them are arguably surpassing DNS as directory services. But DNS remains a bottleneck because it includes the only effective implementation of portable unique identifiers, and because of the inertial prestige invested in TLDs. By providing an alternate implementation of portable unique identifiers, we should be able to break this bottleneck, and let DNS compete directly with other directory services.

    Disclaimer

    No, I'm not proposing that people will have to remember, or guess, these meaningless portable unique identifiers, any more than we try to remember or guess IP numbers. They provide an intermediate level of addressing. Directories map names to portable unique identifiers, the new service maps PUIs to IP numbers.

    Design and implementation

    I will write up more detail on the requirements for a good design and implementation of portable unique identifiers, divorced from directory services, after I see the initial response to this proposal. I think that a lot of the features have already been proposed, and the basic idea is not difficult.

    Design

    • PUIs are arbitrarily long lists of arbitrarily large integers, e.g. 476.8337942.42.1.83675.
    • A root service assigns top-level integers promiscuously to all who request them. The holder of a top-level integer assigns lower hierarchical levels at will. Top-level integers have no greater value than lower hierarchical levels, so there is no incentive to hoard the top level.
    • PUIs map to instructions for requesting connections/services. At first, these are just IP numbers. Later, we will expand them to include things like hunt lists, tuples of the form < IP number, port number, parameters>, etc.

    Implementation

    • Bootstrap from DNS. We start by establishing PUIs within an existing domain (it needn't be a TLD), call it netids.goodguys.org. We convert the PUI 476.8337942.42.1.83675 from a sequence of integers to a character string, expand it to 476.8337942.42.1.83675.netids.goodguys.org, and ship it off as a normal DNS query.
    • The owners of goodguys.org support a DNS server mapping top-level integers (83675.netids.goodguys.org) to hierarchical DNS servers operated by their owners.
    • We provide an automated server that provides new top-level unique integers on request.
    • Replace the DNS implementation with a native server.
    • Distribute the root tables as necessary to handle volume, probably just by subranges of top-level integers.
    • Expand the types of information associated with PUIs.

    Mike O'Donnell

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • Mike O'Donnell
  •  
    This discussion has been archived. No new comments can be posted.
    Building the alternative to DNS | Log in/Create an Account | Top | 26 comments | Search Discussion
    Click this button to post a comment to this story
    The options below will change how the comments display
    Threshold:
    Check box to change your default comment view
    The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
    Pointer to details
    by odonnell (michael_odonnell@acm.org) on Sunday August 04 2002, @05:10PM (#8367)
    User #3447 Info | http://people.cs.uchicago.edu/~odonnell/

    I am working out my thoughts in more detail on my good old Web page. So far, I have a very preliminary draft of definitions and requirements, probably missing a lot of points. Warning: this is real detailed and pedantic stuff, for those interested in technicalities. I will write stuff that's intended to be widely readable later, and I may or may not succeed.



    Mike O'Donnell
    [ Reply to This | Parent ]
    Re: Building the alternative to DNS
    by PeterBarron (pebarron@hotmail.com) on Thursday August 01 2002, @08:29AM (#8266)
    User #3240 Info | http://www.icannwatch.org/
    Give me the telephone numbers for those same businesses, please. From memory.

    You're making a rather irrelevant argument.

    Domain names are valuable because they provide an easy way to remember something that you wish to remember, or that the advertiser wants you to remember.

    Saying and remembering numberoneautorepair.com is easier than 18003862548, believe it or not.

    ++Peter
    [ Reply to This | Parent ]
    Re: Building the alternative to DNS
    by odonnell (michael_odonnell@acm.org) on Thursday August 01 2002, @09:33AM (#8267)
    User #3447 Info | http://people.cs.uchicago.edu/~odonnell/

    DC says,




    However, the value of domain names as " ... locaters and identifiers ..." is NOT "overrated".


    I don't think that the value of "locators, identifiers, and navigation aids" is at all overrated. Rather, I think that the value of domain names for these purposes is overrated. Independent directory services, such as Google, Yahoo, RealNames (yes, I know they went under), have a good chance to become much better. For most of my purposes, Google is already better, but it doesn't satisfy all possible needs for directory lookup. Jon posted an interesting brief comparison of DNS with search engines earlier.




    Leave the DNS alone. It remains a viable option for consumers and businesses.


    This is precisely what I propose to do. Let the DNS alone, and let it compete freely with other directory lookup services. I expect that it will survive and be useful for the foreseeable future, but that it will cease to be the dominant directory lookup service.



    While leaving DNS, and particularly its directory lookup function, totally alone, I propose to offer a separate implementation of its portable unique identifier function, divorced from meaningful directory lookup. If my reasoning is correct, the value of the domain name x.com will go down a lot in the new regime, and people will fight over it a lot less, but I don't see any reason for it to go away entirely, unless and until a new service is so much more attractive that DNS is not worth maintaining.







    Mike O'Donnell
    [ Reply to This | Parent ]
    Folks, this is merely an intermediate level of ind
    by BradNeuberg on Thursday August 01 2002, @11:28AM (#8273)
    User #3449 Info
    Folks, this doesn't necessarily replace the DNS. It is an _intermediate_ layer of indirection between IP and DNS. It seperates somethings _name_ from its _handle_. A handle could be thought of as a unique GUID, a number. CORBA has something similar, as does DCOM. The name is then mapped to a handle, which is then mapped to a service endpoint.

    There are some very good reasons to have such a system, and some concerns as well. The good reasons is that it adds another layer above IP. This means that you can now have a unique, long-lived handle that refers to services, devices, and sites that are independent of whether the underlying IP address changes or even if the underlying user even has an IP address (if they are NATed or firewalled). Even deeper, the handle could actually map to something non-IP, such as a SOAP endpoint running at the end of an HTTP URL or something else wierd. It also means that several competing directory services could be instituted that map to the given handle. For example, let's say I have a website with the handle 234234234 (some random GUID); I could have a DNS like system that maps the website name www.acme.company or www.sieraclub.environment to this handle, or I could have an LDAP like naming service that maps ldap://o=Siera Club,c=US that maps to the same GUID. The point is that innovators are now free to implement their own directory service, but they don't have to start over in terms of the objects they point to.

    My concerns are twofold: performance and the "everything as a URI" argument of Tim Berners-Lee.

    First, performance. With indirection you always impose a whammy, both in terms of storage space and performance. To dereference the domain name www.bradneuberg.love, for example, you would first need to contact the Naming Service and get the handle, such as 23423423. Then you would need to contact the Handle Service and get the actual IP address or service endpoint. Latency latency latency, which already plagues DNS, would get you as well, so even if the servers are hierarchical you still get the inherent latency. I am personally building a naming system that is distributed (its called the Distributed Domain Name System) and which runs above peer to peer, which already is going to be tough to get to run at DNS speeds, so imposing another layer of indirection might not be feasible. You also have the problem of maintaining the storage space for these two sets of tables, Name to Handle and Handle to Service Endpoint. That would mean squaring the size of the existing DNS system; big stuff.

    The other issue is more abstract. TBL (Tim Berners Lee) has the dream of everything being addressable through URIs, because if something has an address, "we can talk about it." So when I create a tag library in XML for my newspaper, lets say the Newspaper Markup Language, and have the tag <Article>, this tag actually derefences to the full URI http://mynewspaper.org/NewspaperMarkupLanguage/Article.
    How would this scheme of everything as a URI tie into a Handle scheme? Would that URI above actually be some handle, 213423423? It seems messy.

    Hope all is well,
    Brad Neuberg
    codinginparadise.org
    [ Reply to This | Parent ]
  • 1 reply beneath your current threshold.

  • Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com