Tina Dam answers: Are existing gTLDs going to be aliased to IDN extensions or not?

[Explorer]

Originally Posted by zfreud

RE: "If verisign wants to alias, and give free domains to .com holders"

yes, but this is NOT aliasing by registry. This is simply granting new TLDs to existing verisign clients who can then choose, or not, to point their domains to the same location. Meaning this would allow for client side aliasing, or CNAME. Which is obviously already an established protocol.

True aliasing, whether via DNAME or some other method, requires support in a zone’s authoritative server. Any solution like that will need to march through the ICANN swamp.

This is why I keep saying: new space idn TLDs are a foregone conclusion at this stage.

Which leaves a pretty messy IP landscape ahead. I think it is also open to debate whether Verisign opts to grant existing IDN.com stakeholders the equivalent domain in whatever foreign script. There are arguments from a profit perspective for and against doing that. And we all know that when it comes to Verisign, profit will be what drives the decision making process.

But if they do give exsiting IDN.com stakeholders access to the equivalent IDN.IDNcom what do you think the odds are that Verisign would give those new TLDs away for free? If you say zero, you're getting warm.

I might be wrong, but I think the majority of IDN holders will gladly pay what Verisign asks (shouldn't be more than a reg fee, no?) to get the equivalents of their IDN .coms. Would you pay $8 to get realestate.ком if you had realestate.com in Russian? You bet. So, if this is the case, then the whole discussion about “will we get it for free or will we have to pay” is pretty meaningless, in my opinion.

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

[zfreud]

RE: "Verisign cannot and won't allocate TLDs to anyone. Only ICANN can do that."

Duck, you misunderstood me. Obviously Verisign would need to apply to ICANN for any IDN gTLD for and be granted said IDN gTLD. After that, however, of course Verisign may choose to allocate this new gTLD to their existing clients if they felt it made business sense. For example, if they apply for and are granted multiple foreign script 'equivalents' of .com. Will they then leave the existing IDN.com holders holding the bag (foreign script .com is a different space entirely) or will they grant (or give first crack at) those existing IDN.com holders the foreignscript .com?


RE "The other thing that occurs to me is that whilst the C Name protocol obviously exists in the Registry Servers, whether or not they have the authority to use it in this way must be covered by their Registry Agreement with ICANN."

Again, no one will need the authority here? Verisign doesn't have to do anything. They can leave it up to the domain name holder. If you want to point IDN.com and IDN.IDNCOM to different places, that will be your choice.

RE: "Also if this was their master plan, why bother putting forward the DNAME proposal. Just doesn't make sense!"

This wasn't their master plan. Battlefields change all the time. DNAME was clearly a solution that favored Verisign and as such they pushed. I think they've lost that battle and are now putting their efforts into securing new space .com equivalents in foreign script that aren't disadvantaged by fast track ccTLDs. I think they're going to lose that battle as well, but that's another story.

And Explorer, I agree with you whether one has to pay the additonal fee is meaningless. What is meaningful however is whether Verisign chooses to treat their inevitable new IDN gTLDs as brand new, or as equivalent to existing idn.com registrations. meaning, there isn't much stopping them from saying that idn.com is different from idn.idncom

As for the ball being in Verisigns court....I see the ball being in CNNICs court.

[Rubber Duck]

Yes, and of course for Cyrillic you are only going to get .ком and if the ASCII dot Com isn't getting little or no traffic, you would just dump it. So would they actually gain very much? What would be the point, except to greatly devalue their major brand.?

Originally Posted by Explorer

I might be wrong, but I think the majority of IDN holders will gladly pay what Verisign asks (shouldn't be more than a reg fee, no?) to get the equivalents of their IDN .coms. Would you pay $8 to get realestate.ком if you had realestate.com in Russian? You bet. So, if this is the case, then the whole discussion about “will we get it for free or will we have to pay” is pretty meaningless, in my opinion.

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

[Jay]

Just to ward off another argument over aliasing based merely on speculation, can I point out that Tina Dam was only presenting the notion of operators doing their own aliasing as one possibility already available. It's hard to tell from her comments if ICANN have discussed this and agree to it in principle, or if it's just an idea that she is passing along out of interest and that ICANN might consider this if an operator applies to do it. This is what I mean by her comments being vague.

As for aliasing using DNAME, she has definitively stated in her blog (http://blog.icann.org/?p=261) that ICANN have not yet made a decision about this. What I'm hoping is that she gives some sort of indication of where that decision-making process is at. Has it been put on the backburner, is it a few weeks away, have they given up? Hopefully we can get some sensible discussion about this on the blog and find out where ICANN are at.

[Fka200]

This is OLD NEWS. I mentioned this before!

[Jay]

Originally Posted by Fka200

This is OLD NEWS. I mentioned this before!

I know, but I fear people have forgotten. By the way, here's the latest from Tina Dam in response to "Sean":

"I am saying that it could be either one. It is important to talk about alaising and what functionality is really meant behind it. This is what the policy development bodies are doing today. Then once the policy is decided and the term defined then we can talk about what technical solution can provide that function. DNAME has been reviewed a few times as a potential solution to aliaising, but as you point out with your examples, it depends on how one defines aliasing."

In other words, nothing is decided, and she doesn't know what will be proposed (as she's not involved in the policy area). Oh well, it was worth asking.

[Rubber Duck]

DNAME is still live. Latest draft 5 Feb 2008, as I have repeatedly posted. But clearly most people on here either can't or just don't read.

http://www.ietf.org/internet-drafts/...s-dname-09.txt

Tina has NOT stated that Registries may do back-end Aliasing. These are merely totally unsubstantiated assertion mostly from Touchring and Michael Jackson. Her comments are vague and frankly are much more likely to refer to Aliasing within the Root Zone which has previously been discussed at IDN workshops.

In the meantime, if you have no fact to report, can we just avoid trying imagine scenarios and then peddling them as done deals?

Originally Posted by Jay

Just to ward off another argument over aliasing based merely on speculation, can I point out that Tina Dam was only presenting the notion of operators doing their own aliasing as one possibility already available. It's hard to tell from her comments if ICANN have discussed this and agree to it in principle, or if it's just an idea that she is passing along out of interest and that ICANN might consider this if an operator applies to do it. This is what I mean by her comments being vague.

As for aliasing using DNAME, she has definitively stated in her blog (http://blog.icann.org/?p=261) that ICANN have not yet made a decision about this. What I'm hoping is that she gives some sort of indication of where that decision-making process is at. Has it been put on the backburner, is it a few weeks away, have they given up? Hopefully we can get some sensible discussion about this on the blog and find out where ICANN are at.

[zfreud]

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN TLDs or the code necessary to make DNAME aliasing work. And while DNAME is still being worked on as a technical standard, and may indeed one day see the light of day, it will be long after ccTLDs have been inserted as new space records.

That, obviously is conjecture based on a cool look at the landscape at present and where we all seem to be going... But then so is my belief in IDN.com.

[Rubber Duck]

Well Verisign almost certainly have the capability to do aliasing at the back-end if they were permitted to do it, and assuming they held all the respective TLDs. But if they were permitted to do it at the back-end, who is to say they would not deliver DNAMES?

Originally Posted by zfreud

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN TLDs or the code necessary to make DNAME aliasing work. And while DNAME is still being worked on as a technical standard, and may indeed one day see the light of day, it will be long after ccTLDs have been inserted as new space records.

That, obviously is conjecture based on a cool look at the landscape at present and where we all seem to be going... But then so is my belief in IDN.com.

[zfreud]

where exactly does one find this mythical backend? it's not as if we all stop by the Verisign office everytime we type .com.

If Verisign is "permitted" to do aliasing, then they will be using a standard like DNAME or some other agreed upon method. A standard which would need to be approved as all the root servers would need updating. Verisign can't magically turn on DNAME like turning on lights in their office.

[Rubber Duck]

A DNS is basically a system that turns Names into IPs and back again.

This is a layman's perspective:

The ICANN Root Servers effective direct the traffic to the Registries which hold the IP Directories. If it is a dot Com the query gets sent to the Verisign Servers, if it is a dot Info, it gets sent to Affilias. The Registry servers effectively just deliver an IP address back to the Root so the traffic can be directed to where it needs to go. It is almost like playing trains.

If Verisign controls more than one registry but only one has registrants, then it can link across to the one holding the master directory by making a query in much the same way that the query comes from ICANN in the first place. If you had a .kom registry and it were linked to .com then the query would go from the Root to the .kom servers, which instead of sending back an IP from their own records would forward the query to the .com registry, who would send the IP to the .kom registry that would then send it back to ICANN. It is a lot more complicated than that because there is two way verification going on at each stage.

Now you have the situation of C- Name and D-Name aliasing which are just two protocols. Under C-Names, the .kom servers would check their own database to see which records needed to be forwarded to the .com servers and which one would simply return an IP directly. Under D-Names everything would be referred directly to the dot com master directory. In many ways, as complicated as D-Names is, if it works it is going to be a hell of lot easier to administer than C-Name aliasing.

Of course from ICANN's perspective, it may actually prefer to let Verisign run it this way as a Test-Bed before being tempted to try to introduce the technology itself. For all we know, Verisign might already be running mock-ups of DNAMES.

Originally Posted by zfreud

where exactly does one find this mythical backend? it's not as if we all stop by the Verisign office everytime we type .com.

If Verisign is "permitted" to do aliasing, then they will be using a standard like DNAME or some other agreed upon method. A standard which would need to be approved as all the root servers would need updating. Verisign can't magically turn on DNAME like turning on lights in their office.

[Drewbert]

Originally Posted by zfreud

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN

I guess you'd better complain to the USPTO regarding their awarding Snapnames a patent for "parallel registry technology" then, since you think aliasing can't be done via the registry databases.

[jacksonm]

Originally Posted by Drewbert

I guess you'd better complain to the USPTO regarding their awarding Snapnames a patent for "parallel registry technology" then, since you think aliasing can't be done via the registry databases.

Right.

ZFreud, RD, etc - I explained it once already and it was a very simple explanation - completely out of ICANN's hands. If you all can't understand what I said, it's not my fault.

.

[zfreud]

Drewbert and Duck, I stand corrected. I was new spacing my thoughts when I should have been aliasing...

grrrr....

jacksonm, i suspect it's not completely out of ICANN's hands. For the same reason Verisign had to pull back on wild carding .com, I don't think they will be allowed to alias without ICANN authorization.

[Rubber Duck]

Originally Posted by zfreud

Drewbert and Duck, I stand corrected. I was new spacing my thoughts when I should have been aliasing...

grrrr....

jacksonm, i suspect it's not completely out of ICANN's hands. For the same reason Verisign had to pull back on wild carding .com, I don't think they will be allowed to alias without ICANN authorization.

Correct. ICANN have a level of contractual control that extends across the entire DNS, not just the Root, even if they don't administer all the servers themselves. Which is precisely why Touchring and MJ are talking rubbish.

[jacksonm]

The model I explained before is simply selling names in a new extension to the owner of the label in another extension. It is nothing more than sales. Everybody gets their money.

The only difference in what I explained to normal sales is that these sales would be restricted to the label owner in another extension, e.g. dot com. It's blindingly simple.

.

[blastfromthepast]

Originally Posted by Explorer

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

Right on, an effort should me made to get some assurances from Verisign and to lobby them.

And now for zfreud:

Originally Posted by zfreud

Join Date: Sep 2005
Posts: 83
Rep Power: 0

Drewbert and Duck, I stand corrected. I was new spacing my thoughts

Once again there, you come out of the woodwork... go back to sleep.

Originally Posted by zfreud

Blast: "First Grade? What's that? Can you alias that too?!"

Now, speaking of the first grade, my elementary school's first grade tuition cost more than the two years you most likely spent at community college.

[zfreud]

"my elementary school's first grade tuition"

Now there was some money well spent.

[jacksonm]

Yes, perhaps we do need to get up to speed on the terminology because the explanations so far have been way off base.

DNS is the only thing which we deal with that is a protocol. The DNS protocol is a standardized communications interface to a database full of standardized record types. You communicate with the DNS service in a standardized manner, and you can query standardized record types. DNS does not use TCP/IP as an underlying transport protocol - it uses UDP. Very simple.

The DNS protocol provides transparent access to a geographically distributed, hierarchical database. The top of the database is called ".". The "." zone is managed by ICANN and replicated to "root" servers around the world. Under ".", you have entries like ".com" and ".jp". Under those entries, you have domain names like "foo.com" and "ne.jp".

A DNS server may contain many types of records:

A (Address) - this record type maps a hostname to an IP address. You query a DNS server for an A record of "www.foo.com" and you get back the IP address "216.234.246.150". The hostname in this example is "www". An A record is the standard entry to give a hostname to an IP address.

PTR (Pointer Record) - this record type allows you to do reverse DNS lookups (query an IP and get back a hostname). This is called reverse mapping. You create a PTR record for "216.234.246.150" and give it a value of "www.foo.com". Not all people who manage DNS servers actually create reverse records for the hostnames in the database, although they really should. PTR records point to A records.

CNAME (Canonical Name) - this record type lets you create aliases for an existing A record. With this record, you can alias additional hostnames to a single IP address which already has an A record. For example, you can alias the names "ftp" and "mail" to "216.234.246.150". Now you have one IP address which answers for three names: www, ftp, and mail in the foo.com domain.

DNAME - this record type lets you map an entire subtree of the DNS name space to another domain. If you map foo.com to bar.com then you have renamed foo.com to become bar.com, while leaving the foo.com names answering (good for transitions, etc). You can query www.foo.com, and the request for the hostname "www" is automatically queried from the "bar.com" zone. In the event of DNAME adoption, all DNAME records would go inside of the "." zone (in the root servers).

NOTE that a single DNS server can handle an arbitrarily large number of different domains. For example, the "." server has all ccTLD and all gTLD domains, as well as .gov, .edu, etc.


Stay tuned for lesson 2, where we will study delegation and recursive resolving.

.

[Wot]

Originally Posted by zfreud

"my elementary school's first grade tuition"

Now there was some money well spent.

i orsa wena skule wen i wuz a chilen.