Citrix ADC

Cómo admite el sistema de nombres de dominio GSLB

El sistema de nombres de dominio (DNS) se considera una base de datos distribuida, que utiliza la arquitectura cliente/servidor. Los servidores de nombres son los servidores de la arquitectura y los solucionadores son los clientes que son rutinas de biblioteca instaladas en un sistema operativo que crean y envían consultas a través de la red.

La jerarquía lógica del DNS se muestra en el siguiente diagrama:

Jerarquía DNS lógica

Nota:

Los servidores raíz de segundo nivel son responsables de mantener las asignaciones de servidor de nombres a direcciones para delegaciones de servidores de nombres dentro de los dominios .com, .net, .org, .gov, etc. Cada dominio de los dominios de segundo nivel es responsable de mantener las asignaciones de servidor de nombres a direcciones para los dominios organizativos de nivel inferior. A nivel de la organización, las direcciones de host individuales se resuelven para www, FTP y otros hosts que proporcionan servicios.

Delegación

El objetivo principal de la topología DNS actual es aliviar la carga de mantener todos los registros de direcciones en una sola autoridad. Esto permite la delegación de un espacio de nombres de organización a esa organización en particular. La organización puede delegar aún más su espacio en subdominios de la organización. Por ejemplo, en citrix.com puede crear subdominios llamados sales.citrix.comeducation.citrix.com, y support.citrix.com. Los departamentos correspondientes pueden mantener su propio conjunto de servidores de nombres autorizados para su subdominio y, a continuación, mantener su propio conjunto de asignaciones de nombres de host a direcciones. Ningún departamento es responsable de mantener todos los registros de direcciones de Citrix. Cada departamento puede cambiar direcciones y modificar topologías, y no imponer más trabajo en el dominio u organización de nivel superior.

Beneficios de la topología jerárquica

Algunas de las ventajas de la topología jerárquica incluyen:

  • Escalabilidad
  • Agregar funcionalidad de almacenamiento en caché a los servidores de nombres de cada nivel, donde un host atiende una solicitud DNS que no tiene autoridad para un dominio determinado pero puede contribuir a la respuesta a la consulta y reducir la congestión y el tiempo de respuesta.
  • El almacenamiento en caché también crea redundancia y resiliencia ante fallos del servidor. Si falla un servidor de nombres, es posible que los registros se puedan entregar desde otros servidores que tienen copias recientes en caché de los mismos registros.

Resolvers

Los solucionadores son el componente cliente del sistema DNS. Los programas que se ejecutan en un host que necesitan información del espacio de nombres de dominio utilizan el solucionador. El solucionador se ocupa de:

  • Consulta de un servidor de nombres.
  • Interpretación de respuestas (que pueden ser registros de recursos o un error).
  • Devolver la información a los programas que la solicitaron.

El solucionador es un conjunto de rutinas de biblioteca que se compilan en programas como telnet, FTP y ping. No son procesos separados. Los solucionadores pueden crear una consulta, enviarla y esperar una respuesta. Y envíelo de nuevo (posiblemente a un servidor de nombres secundario) si no se responde dentro de un tiempo determinado. Este tipo de solucionadores se conocen como solucionadores de código auxiliar. Algunos solucionadores tienen la funcionalidad agregada a los registros en caché y respetan el tiempo de vida (TTL). En Windows, esta funcionalidad está disponible a través del servicio cliente DNS; se puede ver a través de la consola “services.msc”.

Servidores de nombres

En general, los servidores de nombres almacenan información completa sobre una parte determinada de un espacio de nombres de dominio (denominado zona). A continuación, se dice que el servidor de nombres tiene autoridad para esa zona. También pueden ser autorizados para varias zonas.

La diferencia entre un dominio y una zona es sutil. Un dominio es el conjunto completo de entidades, incluidos sus subdominios, mientras que una zona es solo la información de un dominio que no se delega en otro servidor de nombres. Un ejemplo de zona es citrix.com, mientras que sales.citrix.com es una zona separada si esa zona se delega en otro servidor de nombres dentro del subdominio. En este caso, la zona Citrix principal puede incluir citrix.comit.citrix.com, y support.citrix.com. Dado que sales.citrix.com está delegado, no forma parte de la zona sobre la que el servidor de nombres citrix.com tiene autoridad. En el siguiente diagrama se muestran las dos zonas.

Zonas DNS

Para delegar correctamente un subdominio, debe asignar autoridad para el subdominio a distintos servidores de nombres. En el ejemplo anterior, ns1.citrix.com no contiene información sobre el subdominio sales.citrix.com. En su lugar, contiene punteros a los servidores de nombres autorizados para el subdominio ns1.sales.citrix.com.

Servidores de nombres raíz y resolución de consultas

Los servidores de nombres raíz conocen las direcciones IP de todos los servidores de nombres autorizados para los dominios de segundo nivel. Si un servidor de nombres no tiene información sobre un dominio determinado en sus propios archivos de datos, solo necesita ponerse en contacto con un servidor raíz para comenzar a atravesar la rama adecuada de la estructura de árbol DNS para llegar finalmente al dominio dado. Esto implica una serie de solicitudes a varios servidores de nombres para ayudar con el recorrido del árbol y encontrar el siguiente servidor de nombres autorizado, con el que debe contactarse para obtener más resolución.

En el siguiente diagrama se muestra una solicitud DNS típica, suponiendo que no haya ningún registro almacenado en caché para el nombre solicitado durante la transversal. En el siguiente ejemplo se utiliza una simulación del dominio Citrix.

Zonas DNS

Consultas recursivas y no recursivas

En el ejemplo anterior se muestran los dos tipos de consultas que pueden producirse.

  • Consulta recursiva: La consulta entre el solucionador y el servidor de nombres configurado localmente es recursiva. Esto significa que el servidor de nombres recibe la consulta y no responde al solucionador hasta que se responde completamente a la consulta o se devuelve un error. Si el servidor de nombres recibe una referencia a la consulta, el servidor de nombres sigue la referencia hasta que el servidor de nombres finalmente recibe la respuesta (dirección IP) devuelta.

  • Consulta no recursiva: La consulta que el servidor de nombres configurado localmente realiza en el servidor de nombres de nivel de dominio autorizado posterior no es recursiva (o iterativa). Cada solicitud se responde inmediatamente con una referencia a un servidor autorizado de nivel inferior o la respuesta a la consulta, si el servidor de nombres consultado contiene la respuesta en sus archivos de datos o en su caché.

Almacenamiento en caché

Aunque el proceso de resolución está involucrado y podría requerir pequeñas solicitudes a varios hosts, es rápido. Uno de los factores que aumenta la velocidad de la resolución DNS es el almacenamiento en caché. Cada vez que un servidor de nombres recibe una consulta recursiva, es posible que tenga que comunicarse con otros servidores para llegar al servidor autorizado adecuado para la solicitud específica. Almacena toda la información que recibe para referencia futura. Cuando el siguiente cliente realiza una solicitud similar, como un host diferente pero en el mismo dominio, ya conoce el servidor de nombres autorizado para ese dominio y puede enviar una solicitud directamente allí en lugar de iniciarse en el servidor de nombres raíz.

También se puede almacenar en caché para respuestas negativas, como las consultas de hosts que no existen. En este caso, el servidor no debe consultar al servidor de nombres autorizado del dominio solicitado para averiguar que el host no existe. Para ahorrar tiempo, el servidor de nombres simplemente comprueba la memoria caché y responde con el registro negativo.

Los servidores de nombres no almacenan en caché los registros indefinidamente o, de lo contrario, nunca podrá actualizar las direcciones IP. Para evitar problemas de sincronización, las respuestas DNS contienen un tiempo de vida (TTL). Este campo describe el intervalo de tiempo para el que la caché puede almacenar un registro antes de descartarlo y comprobar con el servidor de nombres autorizado los registros actualizados. Si los registros no han cambiado, el uso de TTL también permite respuestas dinámicas rápidas desde dispositivos que realizan GSLB.

Tipos de registros de recursos

Varios RFC proporcionan una lista completa de los tipos de registros de recursos DNS y su descripción. En la tabla siguiente se enumeran los tipos de registros de recursos comunes.

Tipo de registro de recursos Descripción RFC
A Dirección de host RFC 1035
N Un servidor de nombres autoritativo RFC 1035
MD Un destino de correo (Obsoleto - usar MX) RFC 1035
MF Un reenviador de correo (Obsoleto - usar MX) RFC 1035
CNAME El nombre canónico de un alias RFC 1035
JABONERA Marca el inicio de una zona de autoridad RFC 1035
SEMANAS Descripción de un servicio bien conocida RFC 1035
PTR Un puntero de nombre de dominio RFC 1035
HINFO Información del host RFC 1035
MINFO Información sobre buzones de correo o listas de correo RFC 1035
MX Intercambio de correo RFC 1035
TXT Cadenas de texto RFC 1035
AAAA Dirección IP6 RFC 3596
SRV Selección de servidores RFC 2782]

Cómo admite GSLB DNS

GSLB utiliza algoritmos y protocolos que deciden qué dirección IP debe enviarse para una consulta DNS. Los sitios GSLB se distribuyen geográficamente y hay un servidor de nombres autorizado de DNS en cada sitio que se ejecuta como servicio en el dispositivo Citrix ADC. Todos los servidores de nombres de los distintos sitios implicados tienen autoridad para el mismo dominio. Cada uno de los dominios GSLB es un subdominio para el que se configura una delegación. Por lo tanto, los servidores de nombres GSLB son autorizados y pueden utilizar uno de los diversos algoritmos de equilibrio de carga para decidir qué dirección IP devolver.

Se crea una delegación agregando un registro del servidor de nombres para el dominio GSLB en los archivos de base de datos de dominio principal y un registro de direcciones posterior para los servidores de nombres que se utilizan para la delegación. Por ejemplo, si quiere utilizar GSLB para www.citrix.com, se puede utilizar el siguiente archivo SOA de enlace para delegar solicitudes en servidores de nombres: Netscaler1 y Netscaler2. www.citrix.com

###########################################################################
@ IN SOA citrix.com. hostmaster.citrix.com. (
1 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; negative caching TTL
IN NS ns1
IN NS ns2
IN MX 10 mail

ns1   IN A 10.10.10.10
ns2   IN A 10.10.10.20
mail  IN A 10.20.20.50

### Old Configuration if www was not delegated to a GSLB name server
www IN A 10.20.20.50

### Updated Configuration
Netscaler1 IN A xxx.xxx.xxx.xxx
Netscaler2 IN A yyy.yyy.yyy.yyy
www IN NS Netscaler1.citrix.com.
www IN NS Netscaler2.citrix.com.
###
IN MX 20 mail2
mail2 IN A 10.50.50.20
###########################################################################

<!--NeedCopy-->

Entender BIND no es un requisito para configurar DNS. Todas las implementaciones de servidores DNS compatibles tienen un método para crear la delegación equivalente. Los servidores DNS de Microsoft se pueden configurar para la delegación siguiendo las instrucciones de Crear una delegación de zona).

Lo que diferencia a GSLB en el dispositivo Citrix ADC del uso del servicio DNS estándar para distribuir el tráfico es que los sitios GSLB de Citrix ADC intercambian datos mediante un protocolo propietario denominado Metric Exchange Protocol (MEP). Con MEP, los sitios de la GSLB pueden mantener información sobre todos los demás sitios. Cuando se recibe una solicitud DNS, el MEP considera las métricas de GSLB para determinar información como la siguiente:

  • Sitio con el menor número de conexiones actuales
  • Sitio más cercano al servidor LDNS, que envió la solicitud en función de los tiempos de ida y vuelta (RTT).

Hay varios algoritmos de equilibrio de carga que se pueden utilizar, pero GSLB es un DNS con el cerebro debajo que indica al servidor de nombres (alojado en el dispositivo Citrix ADC) qué dirección debe enviarse según las métricas de los sitios participantes.

Otros beneficios que ofrece GSLB son la capacidad de mantener la persistencia (o afinidad del sitio). Las respuestas a las consultas DNS entrantes se pueden comparar con la dirección IP de origen para determinar si esa dirección se dirigió a un sitio concreto en el pasado reciente. Si es así, se envía la misma dirección en la respuesta DNS para garantizar que se mantenga la sesión del cliente.

Otra forma de persistencia se obtiene a nivel de sitio mediante redireccionamientos HTTP o proxying HTTP. Estas formas de persistencia ocurren después de que se produce la respuesta DNS. Por lo tanto, si recibe una solicitud HTTP en un sitio que contiene una cookie para dirigir la solicitud a otro sitio participante, puede responder con una redirección o enviar la solicitud al sitio correspondiente.

Protocolo de intercambio de métricas

Metric Exchange Protocol (MEP) se utiliza para compartir los datos utilizados en los cálculos de GSLB entre sitios. Mediante conexiones MEP, se intercambian tres tipos de datos. Estas conexiones no tienen por qué estar seguras a través del puerto TCP 3011 o pueden ser seguras mediante SSL a través del puerto TCP 3009.

Se intercambian los tres tipos de datos siguientes y tienen sus propios intervalos y métodos de intercambio.

  • Intercambio de métricas del sitio: Este es un modelo de intercambio de encuestas. Por ejemplo, si site1 tiene una configuración para los servicios site2, cada segundo sitio1 solicita al sitio2 el estado de los servicios GSLB. Site2 responde con el estado y otros detalles de carga.

  • Intercambio de métricas de red: Este es el intercambio de información RTT de LDNS, que se utiliza en el algoritmo de equilibrio de carga dinámico de proximidad. Este es un modelo de intercambio push. Cada cinco segundos, cada sitio envía sus datos a otros sitios participantes.

  • Intercambio de persistencia: es para el intercambio de persistencia SOURCEIP. Este es también un modelo de intercambio push. Cada cinco segundos, cada sitio envía sus datos a otros sitios participantes.

De forma predeterminada, los servicios del sitio se supervisan a través de MEP basándose únicamente en la información de las encuestas. Si vincula monitores en función del intervalo de monitor, el estado se actualiza y puede controlar la frecuencia de las actualizaciones estableciendo el intervalo de supervisión en consecuencia.