IDN domains support without punycode

agency87

New member
Joined
Mar 3, 2010
Messages
1
Hi All,

My country has just released the new IDN rules for our top level domains. Now preople are buying these domains alot and they are parking them or hosting them at our company.

I've read all the topics regarding IDN on this forum and there is alot of talk about supporting it but it is never said when it will be implemented. That is why i am creating a new Thread.

The problem is that people have to enter for example xn--port-f6a.com (Punycode) instad of šport.com. Yes i know, in the end if you do enter šport.com it the page does show up but it changes the domain name in the browser address bar to the punycode - very anoying.

So I see that you support umlauts such as hörstel.com but not other special characthers like slovakian, croatian, greek, hebrev?

I would like to know if there is a solution to this, or if there is something in plan for future releases? Or if there are anykinds of workarounds to this?

Thank you very much,

We love directadmin btw. its perfect.

It's really painfull trying to
 
I'm also interested in knowing if there has been any progress in the development of a solution for IDNs. Argentina's NIC (Nic.Ar) launched IDNs some years ago (the implementation was finished in 2009) and we're currently have many clients who use them.

What we usually do is to let them create their domains with the special characters (á, é, í, ó, ú, ñ, etc.) and then create a domain pointer with the punycode. Then, since we use an external DNS, we don't have much trouble there.

However there are some problems that are sometimes annoying. On servers where we have IDNs, Bind doesn't work (it doesn't start complaining about "bad name"s). This isn't critical since we use an external DNS, but it's annoying to receive Directadmin's notice that named service is down (can this be disabled?).

Another thing I saw yesterday was that a client had two folders for the same domain, with the "ñ" character encoded differently. I think this might have happened because of some problem with his FTP client, but the result was that he had all his web files in one folder and Apache was looking at the other one. Moreover, this encoding stuff is hard to deal with from the command line, so I had to move around the folders to get it working at last.

I'm really looking forward for a solution on this matter and would be glad to help if I can in any way to speed this up.

Thanks!
 
For now current version of bind does not support national characters. Correct me if I'm wrong.

Thus you can build in JavaScript or PHP encoder.
 
Back
Top