January 2011 - Artículos

Windows Server 2008 R2: DNS&IPv6 V

Las mejoras de Windows Server 2008 R2 sobre la versión básica de BIND-DNS ayuda a ser al DNS más confiable y a tener una estrategia de resolución más robusta tanto para entornos Microsoft como No-Microsoft.

Quizás la más significativa de las características en la implementación de DNS en R2 sea que las zonas integradas de AD se almacenen en la partición de aplicación de AD. Para cada dominio en un bosque, una partición de aplicación separada se crea y se usa para almacenar los registros que existen en cada zona integrada de AD. Ya que esta partición no se incluye como parte del Catálogo global, las entradas del DNS no se incluyen como parte de la replicación de éste.

Con el concepto de partición de aplicación, la carga de replicación se ve reducida ahora mientras la información importante de la zona se delega a áreas de la red donde sea necesaria.

La configuración del DNS usando el asistente permite la creación automática de una zona DNS paso a paso. Esta característica es de agradecer, ya que facilita la creación de zonas, especialmente para AD.

En anteriores versiones del DNS de Microsoft existía cierta cuestión conocida y documentada, ‘la isla’, que se manifestaba por un DNS que se apuntaba a sí mismo como servidor DNS. Si la IP cambiaba el DNS actualizaba su propia entrada pero el resto de DNS del dominio eran incapaces de recuperar actualizaciones desde el servidor original ya que lo solicitaban a la IP anterior. Esto convertía al servidor en una isla. Microsoft lo arregló en Windows Server 2003 y posteriores. R2 primero cambia sus registros Host en un número suficiente de servidores DNS autoritativos dentro del DNS haciendo que la IP cambiada se replicase con éxito, eliminando el problema de ‘isla’. El resultado es que ya no se necesita apuntar un DNS raíz sobre otro para las actualizaciones, como se aconsejaba anteriormente.

En AD, todos los inicios de sesión y búsquedas de los clientes se redirigen a los servidores DC y Catálogos Global mediante referencias a los registros SRV del DNS. Estos registros se almacenaron en un subdominio del dominio AD que se conoce como _msdcs subdominio.

En R2, _msdcs es una zona separada en el DNS, como vemos en la imagen:

msdcs_zone

Esta zona, almacenada en la partición de aplicación, se replica a todos los DC que sean servidores DNS. Esta lista de registros SRV se movió principalmente para cumplir con las necesidades de sitios remotos. En Windows 2000, estos sitios remotos tenía que replicar el DNS completo para acceder a los registros de _msdcs, qué producía un mayor tiempo de replicación y una capacidad de respuesta reducida. Si delegamos los registros SRV a su propia zona, sólo ésta puede designarse para la replicación de DNS remotos, ganando tiempo en la replicación y obteniendo mayor capacidad de respuesta.

DNS y un entorno AD DS

DNS es inseparable de AD. De hecho ambos se confunden uno por otro con frecuencia, debido quizás a su estructura similar.

AD utiliza una estructura jerárquica basada en X.500 que se diseñó para mapearla dentro de la jerarquía DNS, de ahí las similitudes. Además, AD usa el DNS para todas las búsquedas internas, desde los inicios de sesión a las búsquedas en el catálogo global.

Problemas con DNS pueden suponer un desastre para un entorno de AD.Ya que todos, servidores y clientes, están constantemente realizando búsquedas de unos a otros, y un corte en la resolución de nombres afecta seriamente a la funcionalidad de AD. Por estas y otras razones, DNS redundante en AD es muy recomendable, aun en pequeños entornos de AD.

Las consideraciones de seguridad para la BD de DNS no deben darse por sentadas. Actualizaciones seguras para las zonas integradas-AD son altamente recomendadas, y mantener los servidores DHCP fuera de los DC también ayudan a mantener seguro el DNS. Además, limitar el acceso administrativo al DNS ayudará a reducir problemas de ‘monerías’ no autorizadas en el DNS.

AD DS se escribió especifícamente para ser capaz de coexistir y, de hecho, utilizar implementaciones DNS que no son de Microsoft siempre que sean compatibles con actualizaciones dinámicas y registros SRV. Por ejemplo, AD funcionará en versiones UNIX BIND 8.1.2 y superiores. Con esta idea en mente sin embargo, no deja de ser recomendable que una empresa con una inversión significativa en tecnologías de Microsoft considere tener el DNS para AD en un R2, ya que las mejoras en funcionalidad y seguridad es la mejor opción en estas situaciones.

En entornos que usen versiones antiguas de DNS no no pueden alojar a clientes AD en sus BD, AD DNS puede simplemente ser delegado a una zona separada en la que puede ser autoritativo. Los R2 pueden funcionar como simples reenvíadores en implementaciones foráneas de DNS para proporcionar resolución de recursos en la zona original.

Ciertas situaciones en AD requieren el uso de zonas secundarias para manejar resolución específica. En ciertos modelos de dominio donde árboles separados forman distintos espacios de nombres dentro de un mismo bosque, se necesitan zonas secundarias de cada raíz DNS en Windows 2000 para mantener una sincronización correcta del bosque. Ya que cada árbol en este modelo se compone de dominios independientes que pueden no tener privilegios de seguridad en los otros dominios, se necesitará un mecanismo en el lugar para permitir las búsquedas entre los dos árboles. La creación de zonas secundarias en cada entorno de DNS proporcionarán una solución. R2 dispone de la opción de replicar estos árboles separados a todos los DNS en el bosque, reduciendo la necesidad de las zonas secundarias. La replicación de zonas secundarias fuera del bosque es aun, algunas veces, necesarios sin embargo. El reenvío condicional y las zonas de rutas internas pueden también utilizarse en ciertos casos para obtener un resultado similar sin necesidad de replicación de los datos.

SRV y resolución de Sites

Todos los clientes de AD DS usan DNS para cualquier tipo de búsqueda basada en dominio. Inicios de sesión, por ejemplo, necesitan de una búsqueda dentro de AD para un SRV específico que indica la ubicación de los DC y Global Catalog. R2, como se ha dicho, divide la ubicación de los SRV dentro de zonas separadas, que se replican al resto de DCs que tienen DNS instalado.

Se crean subdominios para cada Site en esta zona; Indican que recursos están disponibles en quéllos Sites específicos. En dos palabras, si un SRV en un subdominio de un Site específico es incorrecto, u otro servidor de un Site distinto está en la lista, todos los clientes de ese Site están obligados a autentificarse en otros Sites. Esto es importante ya que un problema común es qué cuando los Sites se creaban antes se llenaban de servidores, un SRV desde la ubicación central se añade para este subdominio del Site en el DNS. Cuando se añade un nuevo servidor a estos Sites, sus SRV se unen a los otros SRV que se colocaron cuando se creó el Site. Estos registros no se eliminan automáticamente y ellos consecuentemente dirigen a los clientes a servidores a través de lentos enlaces WAN, y con ello hacen que los inicios de sesión sean lentos.

Además de los contenedores Site, la raíz de dichos contenedores contienen una lista de todos los DC en un dominio específico. Estas listas se usan para resolución cuando un servidor de Site no responde. Sí un DC de Site está caído, los clientes de forma aleatoria eligen un DC en este Site.

Zona GlobalNames

En algunos casos, no es conveniente el uso de nombre de dominio cualificado FQDN por los usuarios finales. Esto es especialmente cierto para los novatos o en el caso de nombres de dominio largos. Un usuario escribe una URL, http://intranet.r2.local y a veces es fácil equivocarse. WINS proporciona facilidad en esto, en que puede utilizarse etiquetas simples en su lugar. Esto permite que el usuario escriba sólo http://intranet para acceder al recurso.

Sin embargo, con la llegada de IPv6, WINS no será compatible con el nuevo direccionamiento. Hay otras ventajas de DNS sobre WINS, menor carga administrativa, repositorio único de resolución de nombres, seguridad y estándares abiertos.

R2 proporciona una característica que se introdujo en 2008 para tratar esto, la zona GlobalNames (GNZ). Esta zona proporciona una resolución de etiqueta simple via zona DNS, parecido a WINS. La zona es una zona de búsqueda directa normal, si bien es cierto que con un nombre especial (GlobalNames), y que se usa por el DNS de una manera especial. Si el DNS es incapaz de resolver una dirección en sus zonas locales, intentará resolver la etiqueta simple contra la zona GlobalNames.

GNZ ofrece la promesa, finalmente, de terminar con la resolución WINS y NetBIOS.

Si queremos configurar una zona GlobalNames:

  1. Administración del servidor
  2. Expandimos los Roles, Servidor DNS, nodo DNS, Servidor DNS.
  3. Seleccionamos el nodo de Zonas de búsqueda directa.
  4. Nueva Zona (clic derecho o desde Acción)
    globalNames01
  5. Siguiente en la página de bienvenida.
  6. Seleccionamos Zona principal y marcamos la casilla de Almacenar la Zona en AD. Siguiente.
  7. Seleccionamos Para todos los servidores DNS que se ejecutan en controladores de dominio en este bosque, siguiente.
  8. Introducimos el nombre de la Zona, GlobalNames y siguiente.
  9. Dejamos la configuración predeterminada de actualizaciones dinámicas, siguiente.
  10. Finalizar para crear la zona.
    globalNames02
  11. Abrimos una ventana de símbolo del sistema y ejecutamos el comando:
    1. dnscmd /config /EnableGlobalNamesSupport
    2. Debe recibirse el mensaje “Propiedad del Registro EnableGlobalNamesSupport restablecida correctamente”

    globalNames03
    globalNames04

El comando debe ejecutarse en cada DNS del que se espere que resuelva GlobalNames, a menos de que la zona se les replique ya.

Ahora la Zona GlobalNames está lista para responder consultas. Para cualquier servidor que necesite responder a una etiqueta simple, introducimos un registro CNAME en esta zona con el apropiado FQDN del recurso.

Publicado por Juansa con no comments

Windows Server 2008 R2: DNS&IPv6 IV

Apuntes

Sugerencias de raíz:

Se usan si no se configuran reenvíadores o sí estos no responden.  De forma predeterminada una instalación de DNS incluye un listado de nombres de servidores en internet para utilizarse en la resolución de nombres .com, .net, .es, y resto de dominios de internet. Cuando un servidor DNS no puede resolver un nombre en sus zonas o su caché, realizará la consulta en la lista de sugerencias de raíz, que indicará que servidores hay que consultar.

El archivo de sugerencias debe actualizarse regularmente para estar seguros que los servidores listados siguen estando disponibles. El archivo se encuentra en ruta_del_sistema\system32\DNS\cache.dns y puede actualizarse por internet, en ftp://ftp.rs.internic.net/domain/named.cache

roothints

Podemos ver las sugerencias de raíz de nuestro 2008 R2 abriendo el Administrador del servidor, seleccionamos el servidor DNS, clic derecho, propiedades, pestaña Sugerencias de raíz.

sugerenciasraiz

Reenvíadores:

Los reenvíadores son servidores de nombres que manejan todas las consultas iterativas para un DNS, Es decir, si un servidor no puede responder una consulta de un cliente, los servidores que tienen reenvíadores simplemente reenvían la consulta a uno de los configurados que procesará la consulta a los DNS raíz en Internet. Se utilizan con frecuencia en entornos en los que las empresas usan DNS de sus proveedores de internet para el manejo de todo el tráfico DNS, o, si el DNS maneja la resolución interna de nombres de AD y al tiempo reenvía las solicitudes externas a otros DNS.

En el reenvío condicional, las consultas realizadas sobre un dominio específico o conjunto de dominios se envían a un reenviador específico. Esto normalmente se usa para definir rutas que el tráfico interno seguirá.

Los servidores de sólo reenvío no están destinados a realizar consultas iterativas, sino a transmitir todas las solicitudes que no pueden responder localmente a un reenvíador o conjunto de reenvíadores. Si estos no responden se produce un mensaje de error.

Los reenvíadores se configuran en la pestaña de Reenvíadores de las propiedades del Servidor DNS.

reenviadores01reenviadores02

Wins:

En entornos en los que aún es necesario, la bd de WINS se utiliza junto a DNS para la resolución de nombres. Si un DNS ha finalizado todos los métodos para resolver, un WINS puede ser consultado para proporcionar dicha resolución.

Para habilitar WINS, Pestaña WINS de las propiedades de la zona de búsqueda directa de nuestro servidor DNS, marcaremos la casilla de Usar búsqueda directa WINS e indicaremos la IP del servidor, luego pulsamos en el botón agregar y Aceptar para guardar los cambios.

wins

Publicado por Juansa con no comments

Windows Server 2008 R2: DNS&IPv6 III

Zonas DNS

Una zona DNS es una parte de un espacio de nombres DNS que se controla por un grupo de servidores o un Servidor DNS particular. La zona es el primer mecanismo de delegación en DNS y se usa para establecer límites sobre cual servidor puede resolver las consultas. Cualquier servidor que aloja una zona concreta se dice que es autoritativo para dicha zona, con la excepción de las zonas de código auxiliar (stub zones).

ZONAdns

Hay que entender que cualquier sección o subsección de DNS puede existir dentro de una sola zona. Una empresa puede decidir emplazar  un espacio de nombres de un dominio, subdominios y sub-subdominios en una sola zona. O secciones específicas de este espacio de nombres puede ser dividido en zonas separadas. De hecho, el espacio de nombres de internet puede ser visto como un solo espacio de nombres con el punto . como raíz, que se divide en multitud de zonas distintas.

Zonas de búsqueda directa

Una zona de búsqueda directa, como el nombre sugiere, realiza búsquedas directas en la base de datos de DNS, es decir, este tipo de zona resuelve nombres a direcciones IP e información de recursos. Por ejemplo, si un usuario realiza una consulta sobre el nombre R2.local se devolverá la IP 192.168.1.77, que es la que consta en la base de datos.

Zonas de búsqueda inversa

Una zona de búsqueda inversa lleva a cabo exactamente lo contrario que una zona de búsqueda directa. Las direcciones IP se emparejan con nombres comunes. Es parecido a conocer un número de telefóno pero no el nombre al que pertenece. Estas zonas de búsqueda inversa son normalmente creadas de forma manual y no existen en todas las implementaciones. Los registros presentes son los PTR.

Zonas primarias

En un DNS tradicional (no integrado en AD DS), un único servidor sirve como maestro para una zona, y todos los cambios que se hacen en una zona en particular quedan hechos en el mismo servidor. Un servidor único puede alojar múltiples zonas, puede ser primario para una zona y ser secundario para otra. Si una zona es primaria, sin embargo, todos los cambios hechos para ella se deben hacer en el servidor que mantiene la copia maestra de la zona.

Zonas secundarias

Una zona secundaria se añade para proporcionar redundancia y balanceo de carga para la zona primaria. Cada copia de la BD en DNS es de sólo lectura, es decir no admite cambios desde la zona secundaria, estos deben realizarse en el servidor que mantenga la copia primaria. Un único servidor puede contener varias zonas primarias y varias zonas secundarias. El proceso de creación de una zona secundaria es similar al de una zona primaria, con la diferencia de que los datos se tranferirán desde el servidor que aloje la zona primaria.

Zonas de rutas internas

El concepto de zona de rutas internas es único para el DNS de Microsoft. Esta zona esencialmente no contiene información sobre los miembros de un dominio sino que sirve simplemente las consultas directas hacia una lista designada de nombres de servidor para distintos dominios. Por tanto una zona de rutas internas sólo contiene registros NS y SOA y de adherencia de host. Los registros de adherencia son esencialmente registros A que trabajan conjuntamente con un NS concreto para resolver la dirección IP de un nombre de servidor particular.

Este tipo de zona puede crearse una vez tenemos claro las necesidades para este tipo de recurso. Los pasos serían:

  1. Abrimos Administración del servidor
    Stub_zone01
  2. Expandimos Roles, Servidor DNS, DNS y seleccionamos el servidor.
    Stub_zone02
  3. Seleccionamos Zonas de búsqueda directa.
    Stub_zone03
  4. En Acción, Nueva Zona
    Stub_zone04
  5. Siguiente en la pantalla del asistente,
    Stub_zone05
  6. Seleccionamos zona de rutas internas, ya que esta zona no será integrada en AD desmarcamos la casilla de Almacenar la zona en AD, y pinchamos en siguiente.
    Stub_zone06
  7. Escribimos el nombre de la zona que se creará y pinchamos en siguiente.
    Stub_zone07
  8. Después seleccionamos Crear un archivo nuevo con este nombre de archivo: dejamos el valor predeterminado a no ser que estemos migrando un archivo de zona ya existente. Siguiente.
    Stub_zone08
  9. Escribimos la dirección IP del servidor o servidores desde donde se copiarán los registros de zona. Enter para validar cada servidor, al acabar siguiente.
    Stub_zone10
  10. Finalizar
    Stub_zone11

 

Publicado por Juansa con no comments

Windows Server 2008 R2: DNS&IPv6 II

 

Registros de recursos

En la jerarquía de DNS los objetos se identifican mediante el uso de registros de recursos RR. Estos registros se usan para búsquedas básicas de usuarios y recursos dentro del dominio especificado y son únicos para el dominio en que se ubican. DNS no es un espacio de nombres plano sin embargo, múltiples RR idénticos pueden coexistir a diferentes niveles de la jerarquía DNS, puesto que la naturaleza distributiva de dicha jerarquía permite esos niveles.

Muchos registros de recursos claves existen en las implementaciones de DNS, especialmente a aquéllos referidos con Windows server 2008 R2 AD DS. Para una comprensión mejor de DNS veamos familiarmente estos tipos específicos de RR.

SOA (Start of Authority)

El registro SOA indica qué servidor es el autoritativo para una zona en particular. El servidor al que hace referencia los registros SOA es posteriormente el servidor que se supone es la fuente autorizada de información sobre una zona en particular y es el encargado de procesar las actualizaciones de zona. El registro SOA contiene información como el intervalo de TTL (tiempo de vida), la persona contacto y responsable del DNS, como puede verse en la imagen.

SOA_record

Un Registro SOA se crea automáticamente cuando se instala DNS con AD DS de Windows Server 2008 R2 y se rellena con el TTL predeterminado, servidor primario y otras informaciones pertinentes para la zona. Después de la instalación, podemos cambiar dichos valores para alcanzar las necesidades de la organización.

Host (A)

El tipo más común de RR sin duda es el Registro de Host o Registro A. Este tipo sólo contiene el nombre del equipo y su correspondiente dirección IP. Además de ser el registro que más entradas tiene en el DNS ya que se usan para identificar las direcciones IP de la mayoría de recursos dentro de un dominio.

hostA

 

NS (Name Server)

Los registros NS identifican que equipos de una base de datos DNS son los servidores de nombres, esencialmente los servidores DNS para una zona en particular. Aunque puede existir sólo un SOA por zona, pueden existir múltiples NS para la zona, que indica a los clientes que equipos están disponibles para responder solicitudes DNS contra esa zona.

NS01

* Los NS no contienen la ip de un recurso en particular. De hecho, en la mayoría de casos sólo los Host (A) contienen esta información. Tanto los NS como otros similares simplemente apuntan al registro A de un servidor.

NS02

SRV (Servicio)

Los registros SRV son RRs que indican que recursos llevan a cabo un servicio en particular. Los Controladores de Dominio (DC) en AD DS son referenciados por registros SRV que definen servicios específicos, como Catálogo Global (GC), LDAP y Kerberos. Estos registros son, relativamente, nuevos en DNS y no existían en la implementación original del estándar. Cada SRV contienen información sobre una funcionalidad particular que proporciona un recurso.

NS03NS04

 

MX (Mail Exchanger)

Un MX indica qué recursos están disponibles para la recepción de correo SMTP. Estos registros se pueden establecer en un dominio base y todo el correo dirigido a un dominio en particular será reenvíado al servidor o servidores indicados por el registro MX. Por ejemplo, sin el MX se establece para el dominio R2.local, todo el correo enviado a "usuario@R2.local" será automáticamente dirigido al servidor indicado en el registro MX, en la imagen a correo.R2.local.

NS05

NS06

PTR

Las consultas de búsqueda inversa se realizan mediante el uso de registro de puntero PTR. Es decir, si un usuario quiere buscar el nombre de un recurso que está asociado con una dirección IP específica, debería hacer una consulta inversa usando esa dirección IP. Un servidor DNS respondería utilizando un registro PTR que indicaría el nombre asociado con esa IP. Los PTR se hallan en la zona de búsqueda inversa.

NS07NS08

CNAME

Un registro de Nombre Canónico (CNAME) representa un alias de servidor, y permite que un servidor sea referenciado por múltiples nombres en el DNS. El registro redirige las solicitudes hacia un registro A de un equipo en particular. Son útiles cuando se migran servidores y en situaciones en que un nombre amigable como correo.r2.local, es mucho mejor que un nombre complejo de convención de nombres de servidor, como SRVEXCHANG01.R2.local.

NS09

NS10

Otros registros

  • AAAA –Mapea una dirección IP estándar hacia una dirección IPv6 de 128 bits.
  • ISDN – Mapea un nombre DNS específico hacia un número de telefóno ISDN.
  • KEY – Almacena una clave pública utilizada para cifrado de un dominio en particular.
  • RP – Especifica la persona responsable de un dominio.
  • WKS – Designa un particualr servicio conocido.
  • MB –Indica que equipo contiene un buzón de correo específico.

 

Publicado por Juansa con no comments