CaveBear Blog

Removing IDN Test TLDs

There are 11 "test" top level domains (TLDs) in the ICANN/NTIA/Verisign domain name system (DNS) root.  (See Root Zone Database and click on the "IDNs" tab.)

Those TLDs were put there to perform testing of the internationalized domain name (IDN) concept.

Time has advanced; IDNs are not longer a test concept, yet the "test" TLDs remain.

Why?

It seems to me that unless they can enunciate some compelling reasons why to retain them that ICANN and/or IANA ought to remove those "test" TLDs.

GrassRoots2 Update

I've been writing a new version of the "grassroots" system that was on the net around 1998 but which has since disappeared.

The GrassRoots2 system is a tool that allows anyone to create their own domain name system (DNS) root and populate it with whatever top level domains (TLDs) that they chose to include - not merely ones approved by ICANN (and one could, if one desired, elide some approved by ICANN, such as .xxx.)

Some people think that this is a form of internet anathema.  But it's really nothing new, and is, in fact a return to the idea of innovation by users at the edges of the net - it reifies the IETF's slogan that it "rejects kings".

Since the start of the domain name system it has always been possible for anyone to establish their own DNS root - but to do so required some technical expertise.  I ran my own root servers for myself and my companies for several years.

Grassroots2 does not open any new doors; it merely tries to lower the level of expertise - and even then, it will still require a fair amount of technical ability for a person to run the underlying machinery and put it on the public side of any NAT boundary.

The original Grassroots tool was a website that offered a list of top level domains that were available.  The list at that time was about 2000 names.  There were, as one would expect, some top level domain names that were offered by different people, i.e. a conflict.

The original system let people pick and chose - and resolve the conflict by picking which one, if any, they wanted.  In other words it was user choice, not central authority, that resolved fights over names.

(Trademark law offered a gloss - anybody offering a name that offended against a right recognized by a law, if within the reach of that law, is subject to that law.)

The original system produced a collection of configuration files suitable for use to set up ISC's Bind DNS software as a root offering the given set of top level domains.

My rewrite follows the same paradigm - it produces the files needed to fire up Bind as a root server that knows about the user's choice of top level domains.  Actually running the name server as a root - and making it accessible - is an exercise left to the user.

In my rewrite the focus is on a "catalog" that contains all the known top level domains being offered.  The catalog is merely a local database; there is no central authority.  A person may construct a his own catalog using all or parts of catalogs provided by other people.  Sharing of DNS TLDs could become a kind of social networking activity.  I also have tools to build partial catalog entries by doing DNS queries or zone transfers from name servers.

I'm hoping to allow a fairly flexible set of means for people to share information about top level domain offerings.  So far I've added channels that use JSON encoded text and QR codes - It seems kinda fun to think of DNS systems that disseminate the existence of, and properties of, a top level domain, via visual graphics that can be read by a smart phone.  (I've found that the QR code readers on the smart phones that I have are full QR code readers, they often can not handle more encoded bytes than are found in a typical URL, but I anticipate that as QR gets more popular that the smart phone tools for reading them will get more capable.)

These databases would be more than mere collections of top level domain names and lists of name servers; rather they would contain information about providers, what jurisdictions those providers live in, whether they are under an ICANN contract, and so forth.

My first cut at the database was simple Python language objects, but I'm moving onto an SQL (sqlite) base (the code remains Python.)

I'm using UUIDs to form the permanent handle to a TLD - it's part of what I anticipate to be a troublesome job of filtering out duplicates (although duplicates only add noise to the Grassroots system, they do not break it.)

The bigger challenge will be the generation of self-consistent root zone files.  Making sure that glue records are proper in the context of the set of top level domains that a user selects is going to be hard, really hard.

I am also leaving DNSSEC waiting in the wings, at least for a while.

The current code status is this - little pieces are in place, but it is still more a gleam in the eye than a real system.  And its claim on my available time is of middling priority.

Why am I doing this - It is because I believe in the end-to-end principle.  And I also believe that people have the right to do stupid things to themselves.

There's really no problem on the net if there are multiple DNS roots that are consistent with one another - ones that don't surprise users with wrong or malicious answers.  (The argument is not really about multiple roots, but about the meaning of "consistency".)

I trust law, lawyers, and cops to deal with people who try to create fraudulent DNS servers and lure people into harm - there have been laws about misrepresentation and fraud for centuries, the internet adds more ways to commit fraud, but the basic tort or crime is the same.

What I'm trying to do is to give a means around those who want to use DNS as a chokepoint to exert social control, extort money, spy on people's activities or use people's DNS queries to generate marketing data.

And I am not at all pleased that ICANN has created its own "pay-the-piper" chokepoint that places top level domain opportunities out of the reach of the typical internet user, or even a small business, and at the same time burdens DNS with a very limited business model and biased private law such as ICANN's UDRP and the mandatory publication of private personal data via "whois".

Nor am I pleased with some of the silly ideas contained in the proposed "PROTECT-IP" law now being considered by the US Congress.  Grassroots2 would be a tool that would demonstrate the technical fallacies underlying that bill.

I am not anticipating running code at any time soon - my spare time is too limited.

Code, when it is available, will be under a non-viral (i.e. non GPL) open license of one sort or another.

My Latest Video

I'm doing videos now - over at Page Fault Productions.

Here's my latest:

My comment to NTIA regarding IANA

In response to: Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions

My name is Karl Auerbach.  I reside in Santa Cruz, California.

I was the first, and only, publicly elected North American director on ICANN's Board of Directors.

I have been affiliated with the internet since the early 1970's.

I have created Internet Standard RFC's for the IETF and have made use of IANA protocol number assignments.

I have never understood the force of the argument made by ICANN that ICANN and the IANA function are best bound together into a single entity.

Indeed, I have always considered the more appropriate path to be that of separation.

There is essentially no cross-pollination of work or knowledge between ICANN and IANA except in one area: DNSSEC keys for the ICANN-NTIA-Verisign root zone of the domain name system.

Apart from that I perceive no particular technical value that ICANN brings to IANA, or IANA brings to ICANN.

Many of the jobs performed by IANA are largely clerical - in many instances protocol parameter assignments resemble the action of a "take a number" machine in a baker's shop.  It is true that sometimes IANA assignments are more complex than that; however the IETF has established a mechanism through which it provides experts and expertise to IANA in those situations.

There is, of course, a notable exception: the recognition of the rightful administrator of country code top level domains (ccTLDs).  This is a task that is in many regards more political than technical and perhaps more appropriate to be vested into an treaty body than in the informally grounded, and technically based, IANA.  (I am making the assumption that recognition of ccTLD administrators is more properly an IANA function than an ICANN one - given the commingling of functions under the ICANN umbrella it is not always clear whether a particular act of ICANN+IANA is done while wearing the ICANN hat or the IANA hat.)

ICANN has made use of its joint role as both ICANN and IANA in a kind of political shell game: for many years ICANN defended itself by using IANA as a pawn to raise the specter of internet collapse should anyone question or challenge ICANN's non-technical activities, such as ICANN's trademark-protective actions.  It does neither ICANN or IANA, or the internet, any good when ICANNs political and organizational interests are promoted via IANA as technical imperatives.

The famous architect Louis Sullivan observed that "form follows function".

That same principle ought to guide the future of IANA: IANA ought to be wrapped into an organizational structure - or structures - that best fit the tasks IANA is to perform.  The convenience of ICANN or NTIA ought to be subordinate.

As has been mentioned by others the IANA function is not a single task.

Consequently it may be most appropriate to shape IANA into distinct entities, each shaped around a particular task.

Of course, there are economies of scale that can be obtained by having fewer rather than more little IANA entities.  However, the decision whether to have a monolithic IANA or several functional units ought to be made with clear consideration of these issues rather than by silent default.

Many of the jobs performed by IANA are of a nature that rarely engenders conflicts.  Consequently, IANA need not be burdened with the massive procedural costs and delays that have become so much a part of the ICANN system.  Rather, IANA functions could function largely on a simple notice-and-comment system in which IANA decisions are subject only to review on the basis of abuse of discretion.

To a large degree many of the jobs performed by IANA could be done by any entity that has proven competence in keeping clear public ledgers and maintaining accurate audit trails - in other words something more like a bookkeeping firm than a high-tech enterprise.

With regard to DNSSEC numbers for the ICANN-NTIA-Verisign root zone, this may be one IANA function that perhaps ought to be carved off and left within ICANN.

If nothing else the outcome of this NOI ought to be to define very clear procedural interfaces between the various IANA (and ICANN) tasks.  This will greatly clarify the limits of authority and help identify gaps of authority.  It will also facilitate restructuring as the internet evolves.

The internet will be better served by an fast and inexpensive IANA rather than something that seems modeled after the Circumlocution Office of Dickens' book "Little Dorrit" - See http://www.cavebear.com/archive/cavebear/containing_the_whole_science_of_government.html

I fear that ICANN's empire building and Byzantine tendencies would result in the kind of IANA that we don't want, and that the internet does not need, were the two entities to remain bound together.

There remain unanswered questions:

• Is the L-Root server properly part of the IANA function or part of ICANN itself?  There is a seeming lack of documentation on this question.

• Is the IPv4 and/or IPv6 address space properly part of IANA or ICANN?  (It seems that the answer is "IANA" but much of that seems to arise from assertion rather than documented sources of authority.)

• Are the Regional Internet address Registries (RIRs) sub-entities of IANA, ICANN, or neither?

I have written previously on this topic:

• Structural Principles For Internet Governance - http://www.cavebear.com/archive/rw/igf-structural-principles-for-internet-governance.pdf

• Governing the Internet, A Functional Approach - http://www.cavebear.com/archive/rw/governance-structure-ITU-Feb26-27-2004.htm

• A Plan To Reform ICANN: A Functional Approach - http://www.cavebear.com/archive/rw/apfi.htm

The Royal ICANN

I just walked around the ICANN big-top - that's the tent that is now occupying most of San Francisco's Union Square (with a rather phallic pillar - the Dewey Memorial column - occupying the center of the arena, punching a hole through the roof, and extending towards the stars).  This will be used for ICANN's "gala" social event tomorrow night.

I wonder how much that thing is costing?

Of course I've been told "Verisign paid $500,000".

But would you think it a fair exchange if you gave someone $15 and they said, here I'm replaying you with this nice shiny one cent piece?"  Well, that's roughly the same ratio of the benefit that ICANN confers unto Verisign every year and the amount of Verisign's "sponsorship" amount, i.e. about 1500:1.

Basically, the munificence of this event reminds me less of words like "dignified" and more of words like "ostentatious".  Perhaps "corrupt"; certainly "for sale".

We of the internet community are paying for all of this.  And at risk of sounding like a Tea Party person (which I am most decidedly not), I do find ICANN's expenditures to be entirely out of line with its mission and its status as a non-profit, tax exempt, public-benefit organization.

New Video

I finished a my second video - it's about being annoyed at the poor performance of a geosynchronous link from a cruise ship and what can be done to ameliorate the problem.

It's sort of an informercial for our company - InterWorking Labs - to promote our network emulation and protocol testing products Maxwell and Mini Maxwel.

Other videos from IWL will appear on our company YouTube channel.

No Early Birds Here

In business the early bird catches the worm.  It seems, however, that in the domain name business that there are going to be a lot of uncaught worms.

If you were starting a new business would you sit on your hands waiting for an approval that you do not need, pay fees that you do not need to pay, publish your customer list to the public, risk having hour business name given to someone else, and be required to sell your product through a distribution chain that you do not control?

Of course you would not.

But I see that there is conference this week of people who are doing exactly that - .nxt A Conference About New Internet Extensions.

Don't these people realize that they can go into business today? That by so doing they can establish an early priority date for the start of use of their name in commerce thus putting any competition for the name of their business into a defensive posture?

This conference is for people who are sitting on their hands hoping to apply to ICANN for a new top level domain (TLD).

But ICANN is not the only game in town - Any one can set up an operating TLD business this afternoon.

That sounds like magic, but it is not.

ICANN (in conjunction with the US Dep't of Commerce and Verisign) constructs what is a called a "root zone file".  That is merely a textual computer file that lists all of the TLDs that that trio wants to recognize along with pointers to the domain name servers run by each TLD provider.  (There is other stuff in there pertaining to DNS Security, DNSSEC - I'll get to that in a bit.)

That zone file is picked up by an independent group of people who run what are collectively called "root servers".

What most people do not understand is that anyone can construct a root zone file and that anyone can run root and TLD servers.  There is neither a technical nor legal obstruction to doing so.  In fact such competing root zones, root servers, and TLDs have been out there for years.  But they have gained practically no market share because for the most part they were operated poorly, never promoted, and had to overcome the Fear, Uncertainty, and Doubt (FUD) spread by ICANN.

So let's put ourselves into the shoes of someone going to the .nxt conference who wants to run a top level domain call .cabbage.

If they follow the ICANN path they will construct a thick pile of paper demonstrating that they are willing to structure their business according to the ICANN approved business models, that they are willing to distribute their product through ICANN approved distributors over which they have no control, and to frost that paper cake with a check for $185,000 and a promise to pay ICANN a piece of the gross revenue from .cabbage.

And, of course, ICANN might sit on these applications, as they have done in the past, for more than a decade - there are people who applied in year 2000, paid the money, and who are still being strung along by ICANN.

OK, so what's the alternative?

First of all, the folks at .cabbage can set up operational servers for their TLD.  With today's ability to lease physical and virtual servers in "the cloud" the .cabbage folks could have a worldwide array of name servers for .cabbage up and running within a few hours.

They could begin accepting customers immediately - the registration system at first could be as crude as a stack of 3x5 index cards - automation can come later as the customer base expands.

Given that it is only right and proper to inform customers that .cabbage is not going to be seen by the current majority of network users the question is how to overcome that obstacle and get people to sign up.

The answer is the same one that has been used for years - give early customers a good deal.  Make the cost nil or very low, in perpetuity.  Or cut them in for part of the revenue or profit should .cabbage ever go big-time.  (Make sure that you check with you lawyer for details how to structure those sorts of things, you don't want to trip over a securities law.)

If you or your customers don't like publishing your customer list to the public via that thing called "whois" then don't - there is no legal obligation to do so.  That obligation only arises when you sign a contract with ICANN.

And how would you ever get ISP's to include your TLD (or root) into the constellation of TLD's that they export to their users? Again, it is easy, offer 'em a cut of the revenue or profit from .cabbage.

These things ought to sound familiar - they are - they are akin to the Google Adsense and Adwords ideas moved over to the domain name space.

Once you begin getting customers make sure you get 'em in all 50 states and in countries other than the US.  And in addition you may want to file fictitious name statements or set up corporate entities.  By so doing you will have an actual operational business-in-being that may be recognized as establishing priority rights to the name of your business in the state or country.

If ICANN then approves someone else under the same TLD name the promoter of that other TLD will have to overcome the possibility of being excluded from all of the states and countries that recognize your priority.

The largest and hardest issue is how to make money.

Nobody is going to get the windfall that was .com for Verisign.

So, take a cue from Google - there is gold in DNS queries.  Those queries represent an instant by instant view of the interests of users.  That data can be mined and sold.  (Play it safe - make sure that your sales contracts clearly disclose this to customers and ISPs, particularly if the resulting data stream could be tied to individual users.)

I said that I'd mention DNSSEC.  If you want to have a DNSSEC protected root zone you will have to generate the appropriate cryptographic keys and undertake the management tasks.  Those are not huge tasks, but they are obscure and known only to a few.

So, do you want to wait for an ICANN Godot who never shows up or do you want to get into business now and try to make some money?