Cambios en el comportamiento de los DNS


Cambios en servidores de nombres .com/.net/.edu en preparación para las extensiones de seguridad de DNS.

El 1 de marzo de 2010, Verisign realizó dos cambios que afectan al comportamiento de servidores de nombres oficiales para las zonas .com, .net y .edu ([a-m].gtld-servers.net). Los cambios son un prerrequisito para emplear extensiones de seguridad del DNS en esas tres zonas. Los dos cambios son
Nuevo comportamiento de las referencias y Eliminación del encolado como categoría oficial.

Nuevo comportamiento de las referencias 

Anteriormente, cuando se buscaba un registro A o AAAA encolado (un registro de dirección al nivel o debajo de los registro NS en un punto de delegación), los servidores de nombres oficiales para .com y .net respondían con el registro de encolado en la sección de respuestas. Sin embargo, esta respuesta no se marcaba como oficial; por ejemplo, la parte AA no estaba establecida. Aunque este comportamiento era el adecuado según los estándares del DNS, los servidores oficiales más recientes no responden así. En lugar de esto, cuando se busca un nombre a nivel o debajo del punto de delegación, los servidores oficiales responden con una referencia a la zona delegada. Este comportamiento también cumple con los estándares DNS.

Los servidores [a-m].gtld-servers.net han cambiado ahora a este último comportamiento: las búsquedas de registros encolados terminan en referencias en vez de en respuestas no oficiales.

Nótese que este cambio afecta a la resolución de ciertos dominios bajo el nombre .com y .net que dependen el uno del otro. Por ejemplo, la siguiente configuración de zonas interdependientes, "ejemplo.com" y "ejemplo.net", funcionaba bien antes:

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

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

Estos dos dominios fueron configurados en un "ciclo": todos los servidores de ejemplo.com están en el dominio ejemplo.net, y todos los servidores de ejemplo.net están en el dominio ejemplo.com. Está configuración cíclica solía funcionar porque [a-m].gtld-servers.net era oficial para ambas zonas, .com y .net, y porque estos servidores devolvían búsquedas para encolado como las respuestas no oficiales arriba descritas.

Para ilustrar exactamente porqué funcionaba esta configuración, piense en los pasos que seguiría un resolutor iterativo (la parte de un servidor de nombre recursivo que envía consultas) para resolver cualquier dato a "www.ejemplo.com":

  • El resolutor iterativo consulta un servidor oficial .com para "www.ejemplo.com" y recibe una referencia a "ejemplo.com" listando sólo servidores de nombres en "ejemplo.net".
  • Aunque la referencia incluye registros A para "ns1.ejemplo.net" y "ns2.ejemplo.net" en la sección adicional del mensaje DNS, los resolutores iterativos modernos no tienen en cuenta estos registros como defensa ante el envenenamiento de cache.
  • Habiendo descartado los registros A para "ns1.ejemplo.net" y "ns2.ejemplo.net", el motor iterativo tiene ahora los nombres, pero no las direcciones, de cualquier servidor de nombres de "ejemplo.com". Tendrá que suspender temporalmente la consulta de "www.ejemplo.com" para buscar la dirección de uno de los servidores de nombres de "ejemplo.com". Asumamos que elije resolver "ns1.ejemplo.net".
  • El resolutor iterativo termina consultando un servidor de nombres oficial .net para los registros A de "ns1.ejemplo.net". Con el comportamiento de referencia actual de [a-m].gtld-servers.net, el servidor .net devuelve una respuesta no autoritaria para el registro A para "ns1.ejemplo.net". El resolutor iterativo usa esta dirección para contactar con este servidor de nombres "ejemplo.com" y resolver "www.ejemplo.com".

Sin embargo, desde el 1 de marzo de 2010, el servidor .net no devuelve el registro A de "ns1.ejemplo.net", sino que devuelve una referencia a "ejemplo.net". Pero recuerde que todos los servidores de nombres de "ejemplo.net" están en el dominio "ejemplo.com". La única razón por la que el resultor iterativo intenta resolver ahora "ns1.ejemplo.net" es para resolver la consulta inicial de "www.ejemplo.com", también en el dominio "ejemplo.com". Así pues, con cada dominio dependiendo el uno del otro, la resolución no ya no puede tener éxito.

Verisign ha creado dos listas de dominios .com y .net que pueden verse afectadas por este cambio:

Lista 1: Dominios que participan en los ciclos

Los dominios en esta lista son mutuamente interdependientes, como se describe más arriba. Por ejemplo, dado el caso descrito anteriormente, tanto "ejemplo.com" como "ejemplo.net" estarían en la lista 1.

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

Los dominios en esta lista no son una parte activa de un ciclo como en la lista 1. Por el contrario, todos los dominios de la lista 2 son exclusivamente servidores de nombres que forman parte de un ciclo. En otras palabras, un dominio en la lista 2 tiene todos sus servidores de nombres en uno o más de los dominios de la lista 1. Continuando con el ejemplo de arriba, si el dominio "falso.com" tiene servidores de nombres en "ns1.ejemplo.com" y "ns2.ejemplo.com", entonces "falso.com" aparecería en la lista 2.

Si un dominio aparece en una de las dos listas, el cambio de 1 de marzo requiere cambiar al menos uno de los servidores de nombres para romper el ciclo (para los dominios en la lista 1) o para eliminar la dependencia de dominios en un ciclo (para los dominios en la lista 2).

Volver arriba

Eliminación del encolado como categoría oficial 

En el sistema de registro .com/.net, un dominio puede ser colocado en un estado de espera administrativa. Un dominio en espera no se publica: los registros NS que delegan al dominio se eliminan de la zona .com o .net. Por ejemplo, los registradores a veces colocan un dominio en espera si está a punto de expirar pero el registrante no ha respondido a las solicitudes para renovarlo, o si se está utilizando para una actividad maliciosa.

Antes del cambio, cuando un dominio era puesto en espera, sus registros NS se eliminaban de la zona, pero no los registros A ni AAAA de los servidores de nombres de ese dominio. Por ejemplo, habría que considerar si el dominio "ejemplo.com" existía en el registro junto con el servidor de nombres "ns.ejemplo.com". (Una nota importante: si la zona "example.com" usa o no "ns.ejemplo.com" como uno de los servidores de nombres oficiales es irrelevante para el comportamiento descrito aquí. Lo importante es que "ns.ejemplo.com" está en el dominio "example.com", p. ej., debajo del espacio de nombres DNS).

Antes solía ocurrir que si el dominio "ejemplo.com" estaba en espera, los registros NS que lo delegaban se eliminaban de la zona .com. Los registros A y AAAA para "ns.ejemplo.com" permanecían en la zona. De hecho, puesto que estos registros ya no estaban bajo un punto de delegación, se ascendían a datos oficiales.

Desde el 1 de marzo de 2010, cuando un dominio se pone en espera, los registros NS delegando al dominio se eliminan de la zona, y los registros A y AAAA para los servidores de nombres bajo el dominio ya no son ascendidos a un estatus oficial. En realidad, estos registros A y AAAA no se eliminan: aunque no se devuelven cuando se consulta por ellos directamente, aparecen en la sección adicional de las referencias que los nombran.

En el ejemplo de arriba, si "ejemplo.com" estuviera en espera, sus registros NS serían eliminados de la zona. Pero si el dominio "ejemplo.net" usa "ns.ejemplo.com" como nombre de servidor, una respuesta de referencia a "ejemplo.net" incluirá los registros A y AAAA para "ns.ejemplo.com" en la sección adicional.

Si tiene preguntas sobre estos cambios, contacte con el grupo de atención al cliente de Verisign sobre los registros.

Volver arriba


¿NECESITA MÁS INFORMACIÓN?

  • +1-703-948-3200