Enable BIND cache server to resolve chinese domain name?

Mailman List Mirror (Read Only)
1

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

2

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.

3

Hi,

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

The problem is chinese domain name is hosted and could
be registered by people around.

So, we just have to enable service as more as
possible.

Joe

Send instant messages to your online friends http://asia.messenger.yahoo.com

4

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

5

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

6

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

7

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....

8

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.

The fact is that most Chinese people want to access the same
Internet resources as most Americans. Namely, those resources
that exist in their own country in their own language. So if
someone offers a root zone that contains everything in the
ICANN zone plus additional zones that give access to resources
for a specific language group, i.e. Chinese-speakers, then
it doesn't seem farfetched for all Chinese-speaking countries
to use that extended root zone. And it also does not seem farfetched
for American ISPs who market access services to the Chinese
speaking community in the USA to also use that extended root zone.

A system that would limit my ability to talk to people in other

countries

doesn't sound very appealing to me.

Every public root experiment that I have seen has always
operated as a superset of the ICANN root zone. In the past they
often have not had good ways to deal with TLD collision but
this may well have changed. Certainly, the xn-- TLDs seem
rather unlikely to collide with ICANN TLDs.

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.

--Michael Dillon

9

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.

10

Is draft-klensin-idn-tld-05.txt likely to get any traction?

Tony.

11

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

12

We should be careful to distinguish between i18n and localization. These
private alternative DNS roots are specific to a particular set of users,
so they implement DNS l10n which is not appropriate for a system that is
supposed to be international. Slogan: localization is balkanization.

Tony.

13

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

not www.orsn.net.

14

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.

15

a message of 12 lines which said:

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.

16

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

17

>> 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

18

And *that* is just a tad disingenuous itself. If you have 1 alternate root
that tracks ICANN's dozen-ish TLDs and the country-code TLDs, and then adds 2-3
dozen of its own, there's little room for amusement. If however, you have a
Turkish root that tracks ICANN's dozen, and then adds 50 or 60 of its own, and
a Chinese root that tracks ICANN's dozen, and then adds 75 or 100 of its own,
it becomes interesting to watch a Turkish user try to reach one of those 75
Chinese TLDs, or the Chinese user try to reach one of the 50 Turkish additions,
or either of those users trying to reach the *.special-sauce domain the first
alternate root created.

A collision isn't the only failure mode to worry about....

19

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.

20

william(at)elan.net wrote:

for those excellent readers who didn't follow this, here's an excerpt from
<http://european.de.orsn.net/faq.php#opmode&gt;:

[skip]

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.

While I doubt ICANN would delete a TLD zone (and if that happened it would
presumably be for "dead" tld which no requests are expected to come to),
I'm concerned that their system might work in regards to to host glue
records which there are quite a number of in root zone. If some nameserver
is no longer used by TLD and and now it wants to change its ip address, it would presumably request deletion of its glue record from root zone and then be able to change ip with no effect on anyone on the net. But
if ORSN does not pick it up this would mean they will continue to use
old ip address and that would cause inconsistency (which I suspect will not be easy to track either).

check_soa from the O'Reilly book 'DNS and Bind' will do or dig XXX +nsserach

What I don't understand why for their project they don't just go ahead
and copy ICANN root zone as-is.

Copyright reasons.

But nevertheless those 261 zones are watched to be synchronous to the
ICANN root. And there is another check that sees when suddenly a new
zone appears like it did for '.eu' some month ago.

Both Public-Root and ORSN had it the very same day.

I have seen when ORNS and ICANN were out of sync ORSN hat the information
from the zone file for 'at', '.de' and '.gr' while ICANN had stale
information for a very long time.

Same went for '.ke' and the Public-Root for a month or two.

Regards,
Peter and Karin Dambier