Re: [council] Re: Regarding issues report on IDNs
- To: "Sophia B" <sophiabekele@xxxxxxxxx>
- To: owner-council@xxxxxxxxxxxxxx
- To: "John Klensin" <klensin@xxxxxxx>
- Subject: Re: [council] Re: Regarding issues report on IDNs
- From: "Marilyn Cade" <marilynscade@xxxxxxxxxxx>
- Date: Sat, 4 Feb 2006 15:19:35 +0000 GMT
- Cc: "Patrik Faitstrom-Area Director-IETF" <paf@xxxxxxxxx>
- Cc: "Tina Dam" <dam@xxxxxxxxx>
- Cc: "GNSO Council" <council@xxxxxxxxxxxxxx>
- Cc: "Cary Karp" <email@example.com>
- Importance: Normal
- Sender: owner-council@xxxxxxxxxxxxxx
- Sensitivity: Normal
I am much appreciative of this kind of exchange which can advance the
understanding of many of the non technical councilors, and our constituency
Sophie, I think you have identified a concern I personally have abt DNAMES as I
understand them, but I must study further. Does a DNAMES approach advance an
extension of present Latin character gTLDs into non Latin character, but do not
expand the underlying infrastructure competition.
Or do more?
For instance, when we created the policy guidance for sTLDs, and
unrestricted/open TLDS, my view was that to fully understand and take into
account the implications of whether policy for non Latin character strings
policy was needed to determine issues such as:
1) extend operation of non Latin versions to that registry operator 2)
prohibit that string in non Latin character 3) assume new policy that would ask
4) Address non-Latin chacteri gTLDs as is presently being studied.
DNAMES is a technological solution to address the IDN challenges in a
The questions asked by Sofia -- and asked in the recent international meetings
I attended on Internet governance -- are broader. And need to be understood.
There may be technical realities to what answers "work". I find this dialogue
of considering the options, most welcomed.
From: Sophia B <sophiabekele@xxxxxxxxx>
Date: Fri, 3 Feb 2006 20:38:01
To:John C Klensin <klensin@xxxxxxx>
Cc:Patrik Fältström <paf@xxxxxxxxx>, Tina Dam <dam@xxxxxxxxx>,
council@xxxxxxxxxxxxxx, Cary Karp <firstname.lastname@example.org>
Subject: Re: [council] Re: Regarding issues report on IDNs
Thanks for your reply and your point well taken...specially about the
complexities of IDNs and getting to know it better. While we are certainly not
members of the flat earth society, we do desire to keep both feet on the ground
as well. As such, the I do not see the DNAME dealing with greater problems
of addressing a 'solution'.
The DNAME may be ok solution from a technical point of view, as each current
TLD can have equivalent TLD domain names in ALL languages, IDNs in ALL
languages pointing to English domain names, but would present a greater issue
from a the perspective of policy, politics, control, competition etc.
This creates BIG problems, a political one I must say, as for eg. US would have
an equivalent in Chinese, Arabic, and others managed by Neustar. I am not sure
if the Chinese or Arabs will like that. On the other hand - Iran and Syria
will have a Hebrew TLD - I am note sure the Israelis would like that.
Without being a cause for WWIII, how could we resolve the issues of 'why should
Verisign have.com in all languages? Don't they have half the domain names in
the world already? I suppose some people have their eye on the end of the
rainbow, rather than t rained on the cobble stones looking out for the next
stray copper penny.
But, these are some of the problems I believe made DNAME unpopular, even if it
is OK technically. As you have already said John, - all technologies have pros
and cons (and we know them already...)
Finally, should NOT the above be one of the main reasons as to why the testbeds
should be considered to be open for eveyone, as oppose to only existing TDLs?
or even a consideration for entirely dropping it and go for policy making?
Have a nice weekend.
On 30/01/06, John C Klensin <klensin@xxxxxxx> wrote:
--On Monday, 30 January, 2006 22:15 +0100 Patrik Fältström
<paf@xxxxxxxxx > wrote:
> On 30 jan 2006, at 18.07, John C Klensin wrote:
>> Sophia, there are two main groups of issues with DNAMEs. Let
>> me see if I can oversimplify and summarize them (please see
>> footnote below):
>> (1) If I have a domain a.b.c.d. and want to make a DNAME
>> reference from y.z pointing to b, I set up a DNAME record
>> x.y.z. IN DNAME b.c.d.
> Hmm...I am confused of your example,
Fooey. I got it wrong and thought I had corrected it. I knew I
was a bit too tired when I wrote it, sorry... See below
> if you want the domain
> name anything.b.c and anything.x.y be the same, for any value
> of anything, you can do one of three things:
> (1) Have records anything.b.c and anything.x.y in the zones
> b.c and x.y respectively. There is in this case nothing that
> synchronize the two records with each other. The records are
> two completely different ones.
> (2) Have CNAME for anything.b.c -> anything.x.y . This requires
> addition of CNAME (and removal) in the b.c zone anytime any
> record is added (or removed) in the x.y zone.
> (3) Have a DNAME for b.c -> x.y which will make sure that
> anything.b.c. is rewritten to anything.x.y and the query is
> restarted, just like CNAME but without any need for CNAME RR's
> for all of the RR's in the x.y zone.
This is what I meant to write above.
> This implies that the zone owner for x.y have an alias that is
> b.c. Anyone can query for anything.b.c. and get responses for
>> The zone files for y.z. and c.d. may be located on different
>> servers, with different connectivity, different refresh
>> intervals, different TTLs, different administrations, etc.
>> This raises a number of issues that are long-standing topics
>> in the study of fully-distributed databases (not hierarchies
>> with a single point of control for each node such as the
>> DNS). The solutions for some of those topics are well
>> understood but the DNS doesn't have the necessary tools for
>> dealing with them. Others remain research problems. I won't
>> even try to begin to try to explain them but suffice it to
>> say that it becomes very hard to tell when changes that occur
>> somewhere, especially if e.b.c.d is, itself, a label on a
>> DNAME record pointing into yet another part of the tree.
>> But a reference within a single zone file, e.g., a DNAME
>> record in the root zone that points to a name in the root
>> zone, doesn't raise any of those issues (although, if I were
>> asked for recommendations about how to be very conservative,
>> I'd tell people to be very careful about DNAME entries in any
>> subdomain for which a superior domain is pointed to by a
> The safe usage of a DNAME that we know of is to have in one
> zone the following (for example):
> $ORIGIN foo.com.
> fratz IN DNAME bratz
> bratz IN NS ns.bratz
> This implies when one look up foo.fratz.foo.com the lookup
> will in reality be for foo.bratz.foo.com. It is even said it
> can be resolved by having synthesized CNAME be returned to
> the client.
Yes. I was trying to avoid quite that much detail (and I try to
never use $ORIGIN statements in examples but only FQDNs), but
this may help make it more clear.
> The record in the example itself is in the zone bratz.foo.com.
> No RR exist with the owner foo.fratz.foo.com.
Right. Again, sorry about the confusion.