Re: [council] Re: Regarding issues report on IDNs

[Sophia B <sophiabekele@xxxxxxxxx>]

Hi John,

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

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
> > anything.x.y.
> >
> >> 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
> >> DNAME).
> >
> > Correct.
> >
> > 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.
>
>    john
>
> --
> Sophia Bekele
> Voice/Fax: 925-935-1598
> Mob:925-818-0948
> sophiabekele@xxxxxxxxx
> SKYPE: skypesoph
> www.cbsintl.com
>