On Jul 3, 2005, at 7:36 PM, John Palmer (NANOG Acct) wrote:

ICANN has no right to claim that they are the authority for the namespace. They are NOT.

Horse == dead.

Also note the word PUBLIC in PUBLIC-ROOT.

My i18n must be broken. All I see is SNAKE-OIL. -david ulevitch

----- Original Message ----- From: "Mark Andrews" <Mark_Andrews@isc.org> To: "Joe Shen" <joe_hznm@yahoo.com.sg> Cc: <bind-users@isc.org>; "NANGO" <nanog@merit.edu> Sent: Sunday, July 03, 2005 9:12 PM Subject: Re: Enable BIND cache server to resolve chinese domain name?

...

...

Hi,

Some of our customer complaint they could not visit back to their web site, which use chinese domain name. I google the net and found some one recommend to use public-root.com servers in hint file.

I found domain name like xn--8pru44h.xn--55qx5d could not be resolved either.

Our cache server runs BIND9.3.1 with root server list from rs.internic.net.

Do I need to modify our cache server configuration to enable it?

regards

Joe

Only if you wish to do all your other customers a disfavour by configuring your caching servers to support a private namespace then yes.

I would have thought the Site Finder experience would have stopped people from thinking that they can arbitarially add names to to the public DNS.

Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

!DSPAM:42c8a103122651094118373!

At 8:46 PM -0700 2005-07-03, william(at)elan.net wrote:

On Sun, 3 Jul 2005, John Palmer (NANOG Acct) wrote:

...

ICANN has no right to claim that they are the authority for the namespace. They are NOT. Also note the word PUBLIC in PUBLIC-ROOT.

Yeh, that's just great - "PUBLIC" being used in propoganda compaign to create what appears to be private internet in China...

Sounds kind of like the People's Democratic Republic of China, to me. In that it is neither democratic nor a republic, that is. Lots of words tend to get highly abused in this world, many times to mean anything but the original usage. Public is one of them. CAN-SPAM now means "I *can* spam". Nothing new here, move along.... -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.

On Mon, 4 Jul 2005, Mark Andrews wrote:

...

Some of our customer complaint they could not visit back to their web site, which use chinese domain name. I google the net and found some one recommend to use public-root.com servers in hint file.

I found domain name like xn--8pru44h.xn--55qx5d could not be resolved either.

Our cache server runs BIND9.3.1 with root server list from rs.internic.net.

Do I need to modify our cache server configuration to enable it?

Only if you wish to do all your other customers a disfavour by configuring your caching servers to support a private namespace then yes.

There's no particular technical magic to the ICANN-run roots, except that it's what just about everybody else is using. This means that if you enter the same hostname on two computers far away from each other, you're probably going to end up at the same place, or at least at places run by the same organization. This standardization is valuable, so anybody trying to make a different standard that isn't widely used compete with it is going to have a hard time convincing people to switch. That doesn't mean a competing system wouldn't work, for those who are using it. They'd just be limited in who they could talk to, and that generally wouldn't be very appealing. That said, a big country implementing a new DNS root on a national scale may not have that problem. The telecom world is already full of systems that don't cross national borders. In the US case, think of all the cell phones that have international dialing turned off by default, and all the 800 numbers whose owners probably aren't at all bothered by their inability to receive calls from other countries. A system that would limit my ability to talk to people in other countries doesn't sound very appealing to me. On the other hand, the Chinese government has been trying hard to limit or control communications between people in China and the rest of the world for years. In that sense, maintaining their own DNS root, incompatible with the rest of the world, might be seen as a considerable advantage. If they don't care about breaking compatibility with the DNS root the rest of the world uses, the disadvantages of such a scheme become fairly moot. -Steve

On 04/07/05, Michael.Dillon@btradianz.com <Michael.Dillon@btradianz.com> wrote:

I think that the marketing people are going to win this one. There is no marketable benefit to the ICANN root zone but there are clear advantages for countries using non-Latin alphabets to switch to a root zone that allows for their own language to be used in domain names. Turkey was recently mentioned and that is also a country that uses a non-Latin alphabet.

There is a lot of IDN fun to be had with several competing - and incompatible - technologies, each pushed by rival providers so that there is practically no incentive to interoperate. Some amusingly planted puff pieces, and other clumsy attempts at PR as well .. http://www.circleid.com/article/1074_0_1_0_C/ for example Ignore them and they'll either go the hell away or spend some time fighting against each other and kill each other off. And the public root people can continue using their intranet domains I guess. -- Suresh Ramasubramanian (ops.lists@gmail.com)

Ignore them and they'll either go the hell away or spend some time fighting against each other and kill each other off.

I'm sure that they will NOT go away and I doubt that they will kill each other off. This is more of an evolutionary type struggle and not a physical combat. They are battling it out in the marketplace and one of the IDN solutions will evolve to the point where the market considers it clearly superior. This may be the IETF-blessed solution and it may not. One only has to browse through the RFC archives to see that RFC status is no guarantee that something will be widely adopted. Personally, I think that the Internet is too young and we have too little experience with multilingual naming to engineer an Internationalised Domain Naming solution that solves the problem once and for all. This means that we should be ready for more than one iteration to get to the solution. --Michael Dillon

On Mon, Jul 04, 2005 at 01:25:57PM +0100, Michael.Dillon@btradianz.com wrote:

Personally, I think that the Internet is too young and we have too little experience with multilingual naming to engineer an Internationalised Domain Naming solution that solves the problem once and for all. This means that we should be ready for more than one iteration to get to the solution.

Alas, we didn't get it done before the 'consumers' noticed... which means there will be much more pain involved in getting the engineering right. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

On Mon, Jul 04, 2005 at 05:21:47PM +0000, Paul Vixie <vixie@vix.com> wrote a message of 6 lines which said:

...

Every public root experiment that I have seen has always operated as a superset of the ICANN root zone.

not www.orsn.net.

You are playing with words. ORSN serves the same data as ICANN. So, it is a superset, albeit a strict one.

# > You are playing with words. ORSN serves the same data as ICANN. So, # > it is a superset, albeit a strict one. # # (The excellent readers of NANOG already saw the bug by themselves, I # presume.) I wanted to say that ORSN is *not* a strict superset but is # nevertheless a superset. for those excellent readers who didn't follow this, here's an excerpt from <http://european.de.orsn.net/faq.php#opmode>: | What's the meaning of the status indication "ICANN BASED" and "INDEPENDENT"? | | ICANN BASED is the "normal" mode of ORSN which means that our database will | be synchronized with the root zone information provided by ICANN once a | day. A parser checks for differences between our database and the data that | we download by FTP from ICANN. However, removed TLDs won't be considered but | future TLDs (e.g. .EU) will automatically be added to our data base, linked | with nameserver data-records and finally, a new ORSN root zone will be | generated. Changed TLDs are processed this way too. This process (parsing, | database update and generation of the root zone) is automatic. | | The operating mode INDEPENDENT deactivates the (automatic) mechanism | described above and sets ORSN to independent operation. This mode is | activated whenever the political situation of the world - in our opinion - | makes this step necessary because the possibility of a modification and/or a | downtime of the ICANN root zone exists or we does not want that our root | zone will rebuild automatically. what this means is, it can't conflict with ICANN data other than that if ICANN deletes something it might not show up in ORSN. mathematically speaking that's a superset, but politically speaking it's not at all like an alternative root.

On Sun, Jul 03, 2005 at 10:20:13PM -0700, Steve Gibbard wrote:

On Mon, 4 Jul 2005, Mark Andrews wrote:

...

...

Do I need to modify our cache server configuration to enable it?

Only if you wish to do all your other customers a disfavour by configuring your caching servers to support a private namespace then yes.

There's no particular technical magic to the ICANN-run roots, except that it's what just about everybody else is using. This means that if you enter the same hostname on two computers far away from each other, you're probably going to end up at the same place, or at least at places run by the same organization. This standardization is valuable, so anybody trying to make a different standard that isn't widely used compete with it is going to have a hard time convincing people to switch.

That doesn't mean a competing system wouldn't work, for those who are using it. They'd just be limited in who they could talk to, and that generally wouldn't be very appealing.

Well, Steve; that reply is a *little* disingenuous: all of the alternative root zones and root server clusters that *I'm* aware of track the ICANN root, except in the rare instances where there are TLD collisions. I'm not aware of any such specific collisions; I stopped tracking that area when NetSol shutdown that mailing list without warning several years ago. I merely observe that they're possible.

A system that would limit my ability to talk to people in other countries doesn't sound very appealing to me. On the other hand, the Chinese government has been trying hard to limit or control communications between people in China and the rest of the world for years. In that sense, maintaining their own DNS root, incompatible with the rest of the world, might be seen as a considerable advantage. If they don't care about breaking compatibility with the DNS root the rest of the world uses, the disadvantages of such a scheme become fairly moot.

Eric Raymond, that polarizing ambassador for open source, likes to disseminate the word (and concept) "conflating" -- that being the habit, or attempt, by an arguer of a point to hook together two related but distinct concepts that may both be involved in a topic, but may not have the cause and effect relationship being implied by said arguer. This is a good example, IMHO: Even if China *did* maintain their own root, unless they also maintained their own copies of the 2LD's, like .com, they couldn't snip out *specific* sites they didn't want people to see. But the whole "there's a non-ICANN root: the sky is falling" thing is an argument cooked up to scare the unwashed; us old wallas don't buy it. I just hope none of the unwashed *press* decide to blow the lid off of it; the public's lack of understanding of the underpinnings of the net is painful enough now... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Designer +-Internetworking------+----------+ RFC 2100 Ashworth & Associates | Best Practices Wiki | | '87 e24 St Petersburg FL USA http://bestpractices.wikicities.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me

At 10:32 PM -0400 2005-07-04, Jay R. Ashworth wrote:

But the whole "there's a non-ICANN root: the sky is falling" thing is an argument cooked up to scare the unwashed; us old wallas don't buy it.

That's because you understand the underlying technology, and you understand how to deal with the problem (including understanding that you may just have to live with it). Most people don't understand the underlying technology or the true nature of the problem, nor are they capable of doing so. All they know is that their e-mail doesn't work, or they can't get to the web pages they want. And for them, this is a very real problem. Since there's a lot more of them than there are of us, and we're the ones who are likely to be operating the systems and networks where these people are our customers, when they have a problem, that creates a problem for us. Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible. Okay, the sky may not be falling. Maybe it's just the Cyclorama, or the fly grid. But when the actors are on stage and one of these things falls, there's not much practical difference. And us techies are the ones that have to pick up the pieces and try to put them back together again. -- Brad Knowles, <brad@stop.mail-abuse.org> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info.