Vaya lío se inventaron para poder utilizar los símbolos como la ñ. Es algo así como que siempre se ha utilizado el codigo ASCII, pero solo tiene 7 bits, así que da para poco, y entre ese poco no aparece la ñ. Así que se inventaron un codigo con 16 bits, y se llamó unicode, es decir el unicode es como el ASCII pero con más bits, luego ahí ya puedo incluir la ñ. Una vez que tengo el codigo de pasar caracteres a unos y ceros, necesito saber como integro los nombres de urls antiguos sin ñ, con las urls con ñ, así que utilizo un programa que se llama punycode, de tal forma que si en la url no aparece la ñ, actuo de una forma, pero si aparece la ñ, la traduzco en signos unicode, para poderse enviar y entender en los sistemas. Todo lo que aparezca empezando por "xn--" significa que ha sido traducido a ASCII (mejor dicho unicode) utilizando punycode. En fín, habrá que seguir leyendo libros.
Nombre de dominio internacionalizado
Un nombre de dominio internacionalizado o Internationalized Domain Name (IDN) es un
nombre de dominio de Internet que (potencialmente) contiene caracteres no ASCII. Este tipo de
dominios puede contener caracteres con acento diacrítico, como se requiere en muchos
lenguajes europeos (entre ellos, el español), o caracteres de escrituras no latinas como la
árabe y las chinas. Sin embargo, el estándar para nombres de dominio no permite tales
caracteres, y la mayor parte del trabajo para elaborar una norma ha pasado por encontrar una
forma de solucionar este tema, bien sea cambiando el estándar o acordando una manera de
convertir los nombres de dominio internacionalizados en nombres de dominio en ASCII
estándar mientras se mantenga la estabilidad del sistema de nombres de dominio.
El estándar IDN fue propuesto originalmente en 1998. Después de mucho debate y propuestas
competidoras, un sistema llamado Internacionalización de Nombres de Dominio en
Aplicaciones (Internationalizing Domain Names in Applications - IDNA) fue adoptado como el
estándar elegido, y en el año 2005 empezó su presentación pública.
En IDNA, el término nombre de dominio IDN específicamente denota a cualquier nombre de
dominio que consiste solamente en etiquetas en las que el algoritmo IDNA ToASCII puede ser
exitosamente aplicado. ToASCII se basa en la codificación ASCII Punycode de cadenas
Unicode normalizadas.
Internacionalización de Nombres de Dominio en Aplicaciones
(IDNA)
Es un mecanismo definido en el año 2003 para manejar nombres de dominio IDN que
contienen caracteres no ASCII. Estos nombres de dominio no pueden ser manejados por la
existente infraestructura de resolución de nombres y DNS. En lugar de rediseñar la
infraestructura DNS existente, se decidió que los nombres de dominio con caracteres no-ASCII
deben ser convertidos a una forma basada en ASCII por los navegadores web y otras
aplicaciones de usuario; IDNA especifica como debe realizarse esta conversión.
IDNA fue diseñado para una máxima compatibilidad hacia atrás con el sistema DNS existente,
el cual fue diseñado para ser usado con nombres utilizando sólo un subconjunto de los
caracteres ASCII existentes.
Una aplicación habilitada para IDNA es capaz de convertir entre ASCII restringido y
representaciones no ASCII para un dominio, utilizando la forma ASCII en los casos donde se
Maestría de Derecho Informático – Universidad de Cuenca
Nombres de Dominios – Hugo Carrión G. 14
necesite (como el lookup DNS), pero que sea capaz de presentar la forma no ASCII de mejor
lectura a los usuarios. Las aplicaciones que no soporten IDNA no serán capaces de manejar
nombres de dominio con caracteres no ASCII, pero todavía serán capaces de acceder a tales
dominios si les es dado el equivalente ASCII (normalmente más críptico).
ICANN presentó guías de planeación para el uso de IDNA en Junio del 2004 y era posible
registrar dominios .jp usando este sistema en julio de 2004. Muchos otros registradores de
dominios de alto nivel comenzaron a aceptar registros en marzo de 2004.
Las primeras aplicaciones en soportar IDNA fueron Mozilla 1.4, Netscape 7.1 y Opera 7.11. Las
versiones de Internet Explorer anteriores a la 7 requieren un archivo adicional (plug-in) para
soportar IDNA. Navegadores que utilizan Internet Explorer como base una versión anterior a la
7 para desplegar páginas web, tales como Avant Browser, tampoco admiten esta tecnología.
Ejemplos:
• Español: realacademiaespañola.es, sucompañía.com, ñandú.cl,.
• Japonés: 日本語.jp, 読ませ大賞.jp, 日本レジストリサービス.jp.
• Chino simplificado: 北京大学.cn, 浙江大学.cn, 宜家.com.
• Chino tradicional: 中文.tw, 東華大學.tw, 重車地平線.tw
• Koreano: 한글.kr, 구글.kr.
• Sueco: stockholms.läns.museum
• Alemán: övv.at, stellenbörse.de, holzhäuser.biz
• Simbolos: ®.com, ©.com.
• Arabe: ربي ع.com, ا ايكي .com.
• Griego: ουτοπία.δπθ.gr.
• Hebreo: שלום .com, ישראל .com.
• Ruso: доменные-имена.com, ИКЕА.com.
• Persia: مپاد.وب رانیا.س .ir
• Tailandés: เกมส์.com, ก.com
ToASCII y ToUnicode
La conversión entre las formas ASCII y no-ASCII de un nombre de dominio se realiza mediante
algoritmos llamados ToASCII y ToUnicode. Estos algoritmos no se aplican a todo el nombre de
dominio en su conjunto, sino a etiquetas individuales. Por ejemplo, si el nombre de dominio es
www.ejemplo.com, entonces las etiquetas son www, ejemplo y com, y ToASCII o ToUnicode se
aplicarían a cada uno ellos por separado.
Los detalles de estos dos algoritmos son complejos, y están especificados en los RFC
enlazados al final de este artículo. A continuación se muestra una visión general de su
comportamiento.
ToASCII deja sin ningún cambio cualquier etiqueta ASCII, pero actuará si la etiqueta no es
utilizable para DNS. Si una etiqueta dada contiene al menos un carácter no ASCII, ToASCII
aplicará el algoritmo Nameprep (el cual convierte la etiqueta a minúsculas y realiza otra
normalización) y entonces se traducirá el resultado a ASCII usando Punycode antes de
anteponer la cadena de cuatro caracteres "xn--". Esta cadena de cuatro caracteres se llama el
prefijo ACE, donde ACE significa ASCII Compatible Encoding (Codificación Compatible ASCII),
y se utiliza para distinguir las etiquetas codificadas en Punycode de las etiquetas ASCII
ordinarias. Hay que notar que el algoritmo ToASCII puede fallar de muchas maneras; por
ejemplo, la etiqueta final puede exceder el límite de 63 caracteres de DNS. Una etiqueta en el
cual ToASCII falla, no puede ser utilizada en IDN.
ToUnicode revierte la acción de ToASCII, despojando el prefijo ACE y aplicando el algoritmo de
decodificación Punycode. No revierte el procesado de Nameprep, debido a que es simplemente
una normalización y es por naturaleza irreversible. Al contrario de ToASCII, ToUnicode siempre
acierta, porque simplemente retorna la cadena original si la decodificación llegara a fallar. Esto
significa que ToUnicode no tiene efecto en una cadena que no comienza con el prefijo ACE.
Maestría de Derecho Informático – Universidad de Cuenca
Nombres de Dominios – Hugo Carrión G. 15
Ejemplo de codificación IDNA
Como un ejemplo de como funciona IDNA, supongamos que el dominio a codificar es Ñandú.cl
(de hecho, dicho dominio existe). Este tiene dos etiquetas, Ñandú y cl. La segunda etiqueta es
ASCII pura, así que se deja sin cambios. La primera etiqueta es procesada por Nameprep para
devolver ñandú, y entonces mediante Punycode se obtiene and-6ma2c, y entonces se anexa
previamente xn-- para obtener xn--and-6ma2c. El dominio final utilizado para el uso de DNS es
xn--and-6ma2c.cl.
Consideraciones por engaños
Debido a que IDN permite a los sitios de Internet utilizar nombres completos en Unicode,
también es posible el registro de dominios que se parezcan a otros en su versión Unicode; no
obstante, la versión ACE del dominio es diferente, lo cual conlleva a descubrir las diferencias.
Este tipo de ataques no se deben a deficiencias técnicas en las especificaciones Unicode o
IDNA, sino al hecho de que diferentes caracteres en diferentes lenguajes pueden parecer
iguales, dependiendo de la fuente (tipo de letra) utilizada. Por ejemplo, el carácter Unicode
U+0430 ("a" cirílica minúscula), puede parecer idéntico al carácter Unicode U+0061 ("a" latina
minúscula, utilizada en el idioma español). Técnicamente, los caracteres que se ven parecidos
son conocidos como homógrafos. La similitud sólo se encuentra en la versión Unicode del
nombre de dominio, ya que la versión ACE de los dominios es diferente. Por ejemplo, sabiendo
que la primera "a" de pаypal.com es una "a" cirílica, la versión ACE del dominio es xn--pypal-
4ve.com.
Estos ataques de engaños (spoofing) potencialmente exponen a usuarios a ataques de
phishing
No hay comentarios:
Publicar un comentario