Cambios de comportamiento de DNS


Cambios en los servidores de nombres .com, .net y .edu como preparación para DNSSEC

El 1 de marzo de 2010, Verisign hizo dos cambios que afectaron el comportamiento de los servidores de nombres autorizados de las zonas .com, .net y .edu ([a-m].gtld-servers.net). Los cambios son un prerrequisito para implementar las DNSSEC en estas tres zonas. Los dos cambios son
Nuevo procedimiento de derivación y El registro de adherencia ya no se asciende al estado autorizado.

Nuevo procedimiento de derivación 

Antes, cuando se buscaba un registro A o AAAA existente que sirviera de adherencia (un registro de dirección en los registros de servidores de nombres (NS) o debajo de ellos, en un punto de delegación), los servidores de nombres autorizados para .com y .net respondían con el registro de adherencia en la sección de respuesta. Sin embargo, la respuesta no se marcaba como autorizada, en otras palabras, no se establecía el bit AA. Si bien este comportamiento cumplía con las normas del DNS, los servidores autorizados más actuales no respondían de esta forma. En cambio, cuando se les solicitaba un nombre en o bajo un punto de delegación, los servidores autorizados más actuales respondían con una derivación a la zona delegada. Este procedimiento también era compatible con las normas de DNS.

Los servidores [a-m].gtld-servers.net ahora han cambiado al segundo comportamiento de derivación: las consultas sobre registros de adherencia se responden con derivaciones en lugar de respuestas no autorizadas.

Note que este cambio afecta a la resolución de ciertos dominios dentro de .com y .net que dependen unos de otros. Por ejemplo, la siguiente configuración de zonas "ejemplo.com" y "ejemplo.net" interdependientes antes funcionaba bien:

ejemplo.com NS ns1.ejemplo.net.
ejemplo.com NS ns2.ejemplo.net.

ejemplo.net NS ns1.ejemplo.net.
ejemplo.net NS ns2.ejemplo.net.

Estos dos dominios se configuraron en un "ciclo": todos los servidores de ejemplo.com están en el dominio de ejemplo.net y todos los servidores de ejemplo.net están en el dominio de ejemplo.com. Tal configuración cíclica solía resolverlo porque [a-m].gtld-servers.net era autorizado para ambas zonas, .com y .net, y porque estos servidores devolvían las consultas de registro de adherencia como respuestas no autorizadas (como se describió anteriormente).

Para ilustrar exactamente por qué esta configuración funcionaba, considere los pasos que un sistema de resolución iterativo (la porción de un servidor de nombres recursivo que envía consultas) seguiría para resolver cualquier dato en "www.ejemplo.com":

  • El sistema de resolución iterativo le hace una consulta a un servidor de nombres autorizado .com pidiéndole "www.ejemplo.com" y recibe una derivación a "ejemplo.com" con una lista con servidores de nombre únicamente de "ejemplo.net".
  • Aunque la derivación incluye registros A para "ns1.ejemplo.net" y "ns2.ejemplo.net" en la sección adicional del mensaje DNS, los sistemas de resolución iterativos modernos ignoran estos registros como forma de defensa ante la infección del caché.
  • Tras descartar los registros A para "ns1.ejemplo.net" y "ns2.ejemplo.net", el sistema de resolución iterativo pasa a tener los nombres pero no las direcciones de los servidores de nombres "ejemplo.com". El sistema debe suspender temporalmente la consulta sobre "www.ejemplo.com" para buscar la dirección de uno de los servidores de nombre de "ejemplo.com". Asumamos que elige resolver "ns1.ejemplo.net".
  • El sistema de resolución iterativo consulta a un servidor de nombres autorizado .net sobre los registros A de "ns1.ejemplo.net". Con el comportamiento de derivación actual de [a-m].gtld-servers.net, el servidor .net devuelve una respuesta no autorizada para el registro A de "ns1.ejemplo.net". El sistema de resolución iterativo usa esta dirección para contactar a este servidor de nombres "ejemplo.com" y resuelve "www.ejemplo.com".

Sin embargo, desde el 1 de marzo de 2010, el servidor .net no devuelve el registro A para "ns1.ejemplo.net"; en cambio, devuelve una derivación a "ejemplo.net". Pero recuerde que todos los servidores de nombre "ejemplo.net" están en el dominio "ejemplo.com". La única razón por la que el sistema de resolución iterativa está intentando resolver "ns1.ejemplo.net" ahora es la de resolver la consulta inicial, "www.ejemplo.com", también en el dominio "ejemplo.com", obviamente. Así, con cada dominio dependiente del otro, ya no se puede alcanzar exitosamente una resolución.

Verisign ha creado dos listas de dominios .com y .net a las cuales puede afectar este cambio:

Lista 1: dominios que participan en ciclos

Los dominios de esta lista son mutuamente interdependientes, como se describió anteriormente. Por ejemplo, dada la situación descrita anteriormente, tanto "ejemplo.com" como "ejemplo.net" estarían en la lista N° 1.

Lista N° 2: Dominios que dependen exclusivamente de los dominios en ciclos

Los dominios en esta lista no son parte activa de un ciclo como los de la lista N° 1. En cambio, todos los dominios de la lista N° 2 usan exclusivamente servidores de nombre de dominios que son parte de un ciclo. En otras palabras, un dominio de la lista N° 2 tiene todos sus servidores de nombre en uno o más dominios de la lista N° 1. Siguiendo el ejemplo anterior, si el dominio "foo.com" tenía servidores de nombre "ns.1ejemplo.com" y "ns2.ejemplo.com", entonces "foo.com" aparecería en la lista N° 2.

Si un dominio aparece en una de las dos listas, el cambio del 1 de marzo requerirá que al menos uno de sus servidores de nombre se cambien ya sea para romper el ciclo (para los dominios de la lista N° 1) o para que se elimine la dependencia del dominio en un ciclo (para dominios de la lista N° 2).

Regresar al principio

El registro de adherencia ya no se asciende al estado autorizado 

En el sistema de registros .com/.net, un dominio se puede poner en estado de espera administrativo. Un dominio en espera no se publica: los registros NS que delegan el dominio se eliminan de la zona .com o .net. Por ejemplo, a veces los registradores ponen en espera a un dominio si está a punto de caducar, pero el registrante no ha respondido los pedidos de renovación, o si el dominio está siendo usado para actividades maliciosas.

Antes del cambio, cuando un dominio era puesto en espera, sus registros NS se eliminaban de la zona pero no se eliminaba ninguno de los registros A y AAAA de los servidores de nombres de ese dominio. Por ejemplo, considere cómo hubiese sido si el dominio "ejemplo.com" existía en el registro junto con el servidor de nombres "ns.ejemplo.com". (Nota importante: que la zona "ejemplo.com" misma use "ns.ejemplo.com" como uno de sus servidores de nombres autorizados es irrelevante al comportamiento descrito aquí. Lo que importa es que "ns.ejemplo.com" está en el dominio "ejemplo.com", esto es, debajo de él en el espacio de nombres del DNS).

Antes, si el dominio "ejemplo.com" era puesto en espera, los registros NS que lo delegaban se eliminaban de la zona .com. Los registros A y AAAA para "ns.ejemplo.com" quedaban en la zona. De hecho, debido a que estos registros ya no se encontraban bajo un punto de delegación, se los ascendió para que sean datos autorizados.

Desde el 1 de marzo de 2010, cuando se pone en espera un dominio, los registros NS que delegan el dominio se eliminan de la zona, y los registros A y AAAA para servidores de nombres bajo el dominio ya no son ascendidos al estado autorizado. Estos registros A y AAAA no se borran: si bien no aparecen directamente en una consulta, sí aparecen en la sección adicional de derivaciones que hacen referencia a ellos.

En el ejemplo anterior, si "ejemplo.com" pasara a estar en espera, se borrarían de la zona sus registros NS. Pero si el dominio "ejemplo.net" usa "ns.ejemplo.com" como servidor de nombre, una respuesta de derivación a "ejemplo.net" incluirá los registros A y AAAA para "ns.ejemplo.com" en la sección adicional.

Si tiene alguna pregunta sobre estos cambios, comuníquese con el grupo de atención al cliente de registro de Verisign.

Regresar al principio


¿NECESITA MÁS INFORMACIÓN?

  • +1-703-948-3200