<div>Hi John,</div>
<div> </div>
<div>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.
<font size="2">  As such, the  I do not see the DNAME dealing with </font>greater problems of addressing a 'solution'.</div>
<div> </div>
<div>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.   
</div>
<div> </div>
<div>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.  
</div>
<div> </div>
<div>Without being a cause for WWIII, how could we resolve the issues of 'why should Verisign <a href="http://have.com">have.com</a> 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
<font size="2">rained on the cobble stones looking out for the next stray copper penny.  </font></div>
<div><font size="2"></font> </div>
<div><font size="2">But, t</font>hese 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...)
</div>
<div> </div>
<div>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?
</div>
<div> </div>
<div>Have a nice weekend.</div>
<div>Sophia  </div>
<div> </div>
<div><span class="gmail_quote">On 30/01/06, <b class="gmail_sendername">John C Klensin</b> <<a href="mailto:klensin@jck.com">klensin@jck.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><br>--On Monday, 30 January, 2006 22:15 +0100 Patrik Fältström<br><<a href="mailto:paf@cisco.com">paf@cisco.com
</a>> wrote:<br><br>> On 30 jan 2006, at 18.07, John C Klensin wrote:<br>><br>>> Sophia, there are two main groups of issues with DNAMEs.  Let<br>>> me see if I can oversimplify and summarize them (please see
<br>>> footnote below):<br>>><br>>> (1) If I have a domain a.b.c.d. and want to make a DNAME<br>>> reference from y.z pointing to "b", I set up a DNAME record<br>>><br>>>       
x.y.z.  IN DNAME b.c.d.<br>><br>> Hmm...I am confused of your example,<br><br>Fooey.  I got it wrong and thought I had corrected it.  I knew I<br>was a bit too tired when I wrote it, sorry... See below<br><br>> if you want the domain
<br>> name  anything.b.c and anything.x.y be the same, for any value<br>> of anything,  you can do one of three things:<br>><br>> (1) Have records anything.b.c and anything.x.y in the zones<br>> b.c and  x.y
 respectively. There is in this case nothing that<br>> synchronize the  two records with each other. The records are<br>> two completely different  ones.<br>><br>> (2) Have CNAME for anything.b.c -> anything.x.y
. This requires<br>> addition of CNAME (and removal) in the b.c zone anytime any<br>> record is  added (or removed) in the x.y zone.<br>><br>> (3) Have a DNAME for b.c -> x.y which will make sure that<br>> 
anything.b.c. is rewritten to anything.x.y and the query is<br>> restarted, just like CNAME but without any need for CNAME RR's<br>> for  all of the RR's in the x.y zone.<br><br>This is what I meant to write above.<br>
<br>> This implies that the zone owner for x.y have an alias that is<br>> b.c.  Anyone can query for anything.b.c. and get responses for<br>> anything.x.y.<br>><br>>> The zone files for y.z. and c.d. may be located on different
<br>>> servers, with different connectivity, different "refresh"<br>>> intervals, different TTLs, different administrations, etc.<br>>> This raises a number of issues that are long-standing topics
<br>>> in the study of fully-distributed databases (not hierarchies<br>>> with a single point of control for each node such as the<br>>> DNS).  The solutions for some of those topics are well<br>>> understood but the DNS doesn't have the necessary tools for
<br>>> dealing with them. Others remain research problems.  I won't<br>>> even try to begin to try to explain them but suffice it to<br>>> say that it becomes very hard to tell when changes that occur<br>
>> somewhere, especially if e.b.c.d is, itself, a label on a<br>>> DNAME record pointing into yet another part of the tree.<br>>><br>>> But a reference within a single zone file, e.g., a DNAME<br>>> record in the root zone that points to a name in the root
<br>>> zone, doesn't raise any of those issues (although, if I were<br>>> asked for recommendations about how to be very conservative,<br>>> I'd tell people to be very careful about DNAME entries in any<br>
>> subdomain for which a superior domain is pointed to by a<br>>> DNAME).<br>><br>> Correct.<br>><br>> The "safe" usage of a DNAME that we know of is to have in one<br>> zone  the following (for example):
<br>><br>> $ORIGIN <a href="http://foo.com">foo.com</a>.<br>><br>> fratz IN DNAME bratz<br>> bratz IN NS ns.bratz<br>><br>> This implies when one look up <a href="http://foo.fratz.foo.com">foo.fratz.foo.com
</a> the lookup<br>> will in  reality be for <a href="http://foo.bratz.foo.com">foo.bratz.foo.com</a>. It is even said it<br>> can be resolved  by having synthesized CNAME be returned to<br>> the client.<br><br>Yes.  I was trying to avoid quite that much detail (and I try to
<br>never use $ORIGIN statements in examples but only FQDNs), but<br>this may help make it more clear.<br><br>> The record in the example itself is in the zone <a href="http://bratz.foo.com">bratz.foo.com</a>.<br>> No RR  exist with the owner 
<a href="http://foo.fratz.foo.com">foo.fratz.foo.com</a>.<br><br>Right.  Again, sorry about the confusion.<br><br>   john<br><br>-- <br>Sophia Bekele<br>Voice/Fax: 925-935-1598<br>Mob:925-818-0948<br><a href="mailto:sophiabekele@gmail.com">
sophiabekele@gmail.com</a><br>SKYPE: skypesoph<br><a href="http://www.cbsintl.com">www.cbsintl.com</a><br></blockquote></div>