Domisfera

(Nota importante: Este post es algo técnico y es una continuación de este otro: link Antes de seguir leyendo, para comprender mejor lo que a continuación explico y entender mejor el funcionamiento de los dominios en Internet, recomiendo un artículo que es muy interesante: link ) Actualmente, cuando se escribe en un navegador -con soporte para IDN- un dominio IDN, éste convierte el nombre del dominio escrito en Unicode (Juego de caracteres local de país, por ejemplo alfabeto chino) a Punycode (caracteres ASCII ) para que posteriormente algún Servidor Raíz de Dominio (DNS Root Servers) pueda interpretar o comprender el nombre dominio que se busca. En resumen, al Servidor Raíz de Dominio debe llegarle el dominio que se le solicita a través del navegador en caracteres ASCII para que éste pueda establecer dónde se encuentra el hosting o alojamiento asociado a ese dominio. Sin embargo, en estos momentos, el problema de Internet reside en que los Servidores Raíz de Dominio (DNS Root Servers) sólo reconocen y son capaces de interpretar extensiones: gTLDs (.com, .net, .org…), sTLDs (.mobi, .cat…) y ccTLDs (.es, .de, .br…) compuestas con caracteres latinos. Así pues, si se pone en un navegador -con soporte IDN- un dominio con una extension IDN, por ejemplo: 您所提供的資料.公司, se enviará esa extensión .公司 en Punycode (ASCII) al Servidor Raíz de Dominio (DNS Root Servers), sin embargo, éste no será capaz de reconocerla.

Y esto es precisamente lo que la ICANN quiere solventar para finales del año que viene, lo que se pretende ahora es normalizar y conseguir que, además de los nombres de dominio, las extensiones puedan ser también IDN, esto es, que se puedan enviar también peticiones desde los navegadores a los Servidores Raíz del siguiente modo: dominio-IDN.extension-IDN Por lo que sé, se han puesto dos métodos sobre la mesa para solventar este problema que tienen los Servidores Raíz de Dominio (DNS Root Servers) y que puedan así, interpretar los dominios en la forma mencionada: dominio-IDN.extension-IDN El primer método consiste en usar Punycode para resolver la extensión IDN (por ejemplo con caracteres chinos) en el propio Servidor Raíz de Dominio. Esta solución implicaría la creación de tantas extensiones nuevas por cada gTLD, ccTLD y sTLD como alfabetos haya ( birmano, hindú, armenio, georgiano, griego, judio, arabe, cirílico, chino, japonés, coreano, etc….) El segundo método se basa en usar tablas de correspondencia para decidir a que gTLD, ccTLD o sTLD ya existente le corresponden los caracteres Punycode (ASCII) enviados por el navegador. A este método se le llama DNAME y fue propuesto por Verisign. Si se introduce esta versión para la normalización, habrá miles de nombres virtuales (dominio-IDN.extension-IDN) que serían alias de los "actuales" (dominio-IDN.extensión-NO-IDN). Probablemente, este segundo método sea el que finalmente se termine implantando porque si se utilizara el primero, habría que crear un nuevo gTLD, ccTLD y sTLD por cada alfabeto diferente. Por ejemplo, para el caso del gTLD .com habría que crear: .公司 : .com (en chino) .회사 : .com (en koreano) … : .com (en griego) … : .com (en japonés) etc… Parece ser que los dominios IDN dejarán de ser noticia, salvo en España claro está.