Source: http://geeks.ms/blogs/juansa/archive/2011/01.aspx
Timestamp: 2015-09-03 10:57:43+00:00

Document:
January 2011 - Artículos - Uno de los blogs de Juansa
13/1/2011 12:56 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: 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: Administración del servidor Expandimos los Roles, Servidor DNS, nodo DNS, Servidor DNS. Seleccionamos el nodo de Zonas de búsqueda directa. Nueva Zona (clic derecho o desde Acción) Siguiente en la página de bienvenida. Seleccionamos Zona principal y marcamos la casilla de Almacenar la Zona en AD. Siguiente. Seleccionamos Para todos los servidores DNS que se ejecutan en controladores de dominio en este bosque, siguiente. Introducimos el nombre de la Zona, GlobalNames y siguiente. Dejamos la configuración predeterminada de actualizaciones dinámicas, siguiente. Finalizar para crear la zona. Abrimos una ventana de símbolo del sistema y ejecutamos el comando: dnscmd /config /EnableGlobalNamesSupport Debe recibirse el mensaje “Propiedad del Registro EnableGlobalNamesSupport restablecida correctamente” 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.
11/1/2011 11:04 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 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. 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. 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. Publicado por
10/1/2011 11:45 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). 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: Abrimos Administración del servidor Expandimos Roles, Servidor DNS, DNS y seleccionamos el servidor. Seleccionamos Zonas de búsqueda directa. En Acción, Nueva Zona Siguiente en la pantalla del asistente, 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. Escribimos el nombre de la zona que se creará y pinchamos en siguiente. 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. 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. Finalizar Publicado por
4/1/2011 11:00 Windows Server 2008 R2: DNS&IPv6 II
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. PTR
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

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución