DNS y Microsoft Windows NT 4.

0
Por Scott B. Suhy y Glenn Wood

Versin: 1.0

Una hoja tcnica de la Business Systems Division y Microsoft Consulting Services

Resumen Este informe ofrece una introduccin al sistema de nombres de dominio (DNS) y a cmo puede ser implementado mediante Microsoft Windows NT 4.0.

Con la puesta en marcha de los servicios extendidos de directorio de Windows NT, que aparecer en una versin posterior de Windows NT, el servidor de nombres de dominio pasar a ser mucho ms importante de lo que ha sido en cualquier otra versin de Windows NT. Debido a esto, la actual instalacin y diseo de implementaciones efectivas de DNS facilitar la futura conversin a la siguiente versin de Windows NT.

Las series de hojas tcnicas de Microsoft Business Systems Division se han diseado para informar a los profesionales de las tecnologas de la informacin (IT) acerca de Windows NT y de la familia de productos de Microsoft BackOffice. Aunque a menudo se tratan las tecnologas usadas actualmente en los productos Microsoft, el verdadero objetivo de estas hojas tcnicas es ofrecer a los lectores una idea sobre cmo estn evolucionando las principales tecnologas, cmo est usando Microsoft esas tecnologas y en qu medida afecta esta informacin a los diseadores de la tecnologa. Para obtener la informacin ms reciente acerca de Windows NT Server, visite nuestro sitio World Wide Web en [Link] o el Windows NT Server Forum en Microsoft Network (GO WORD: MSNTS).

Aviso legal
La informacin contenida en este documento representa la visin actual de Microsoft Corporation sobre los temas que se describen en la fecha de la publicacin. Dado que Microsoft debe responder a las condiciones cambiantes del mercado, no debe ser interpretado como un compromiso por parte de Microsoft, y Microsoft no puede garantizar la exactitud de cualquier informacin presentada despus de la fecha de la publicacin. Este documento slo tiene validez informativa. MICROSOFT NO GARANTIZA NADA EN ESTE DOCUMENTO, EXPLCITA O IMPLCITAMENTE. 1996, Microsoft Corporation. Reservados todos los derechos. Microsoft y Windows son marcas registradas, y Windows NT y BackOffice son marcas de Microsoft Corporation. 12/96 Parte N. xxx-xxxxx

INTRODUCCIN.............................................................................................................................1

Contenido
INTRODUCCIN A DNS................................................................................................................2 ANTECEDENTES......................................................................................................................... 2 Historia de DNS..........................................................................................................................2 FUNDAMENTOS DE LA TECNOLOGA............................................................................................ 3 Introduccin................................................................................................................................3 Servidores DNS e Internet..........................................................................................................3 Dominios.....................................................................................................................................5 Zonas...........................................................................................................................................5 Servidores de nombres................................................................................................................6 Resolucin de nombres...............................................................................................................8 Almacenamiento en la cach y tiempo de vida........................................................................10 LOS ARCHIVOS DNS ............................................................................................................... 11 Introduccin..............................................................................................................................11 El archivo de base de datos......................................................................................................12 El archivo de cach..................................................................................................................16 El archivo de Bsqueda inversa...............................................................................................16 El archivo [Link] ..........................................................................................................17 El archivo de inicio BIND........................................................................................................17 IMPLEMENTACIN DE DNS MEDIANTE WINDOWS NT 4.0...........................................19 INTRODUCCIN A MICROSOFT DNS.........................................................................................19 Instalacin del servicio DNS....................................................................................................22 EL SERVIDOR .......................................................................................................................... 22 Configuracin de dominios y zonas DNS.................................................................................24 Integracin con bsquedas de WINS .......................................................................................28 WINS y la bsqueda inversa.....................................................................................................31 Otras cosas importantes...........................................................................................................33 Instalacin.................................................................................................................................36 EL RESOLVER (CLIENTE).......................................................................................................... 36 El nombre del host....................................................................................................................36 El nombre de dominio...............................................................................................................36 Los servidores DNS...................................................................................................................36 Orden de bsqueda de Sufijo de dominio ................................................................................37 Resolucin de nombres.............................................................................................................38 Nslookup....................................................................................................................................41 EL ENTORNO GENERAL............................................................................................................ 41 Puntos dbiles de la implementacin actual............................................................................42 DISEO DE SOLUCIONES..........................................................................................................43 USO DEL SERVIDOR MICROSOFT DNS PARA CONECTARSE A INTERNET......................................43 Consideraciones sobre la seguridad........................................................................................43 Diseo tpico de conectividad Internet ...................................................................................45 DISEO DE CAPACIDAD Y RENDIMIENTO ..................................................................................50 Estadsticas...............................................................................................................................50 Equilibrio de la carga DNS......................................................................................................53 La transferencia de zona...........................................................................................................53 Memoria consumida por los registros DNS.............................................................................55 DECISIONES DNS.................................................................................................................... 55 CONFIGURACIONES DE EJEMPLO............................................................................................... 59

DNS y Microsoft Windows NT 4.0

Ejemplos de confianza total......................................................................................................59 Ejemplo de mltiples maestros ................................................................................................65 EL FUTURO....................................................................................................................................72 INTRODUCCIN........................................................................................................................ 72 NUEVOS ESTNDARES ............................................................................................................. 72 DNS dinmico...........................................................................................................................72 IPv6 (IPng)................................................................................................................................74 Transferencias incrementales: duplicacin multimaestro.......................................................74 DNS protegido...........................................................................................................................75 MIGRACIN............................................................................................................................. 76 Por dnde empezamos?..........................................................................................................76 CONCLUSIN........................................................................................................................... 78 APNDICES....................................................................................................................................80 APNDICE A: EL CABLE........................................................................................................... 80 Seguimiento de consultas DNS ................................................................................................80 APNDICE B: INFORMACIN ADICIONAL...................................................................................92 Internet......................................................................................................................................92 Libros........................................................................................................................................92 Hojas tcnicas...........................................................................................................................94 Cursos........................................................................................................................................95 Varios........................................................................................................................................95 APNDICE C: REGISTRO EN EL NIC..........................................................................................96 APNDICE D: REGISTROS DNS................................................................................................97 Agradecimiento especial a las siguientes personas por su ayuda en este proyecto:............100

ii

DNS y Microsoft Windows NT 4.0

Introduccin
La utilizacin del servicio DNS en Windows NT 4.0 es opcional. El servicio DNS se suministra con Windows NT 4.0 por si necesita usarlo, aunque todava no haya nada en los Servicios de directorio de Windows NT que lo necesite. Nos gustara que empezara a usarlo en la actividad normal del tipo DNS.

Es importante indicar que DNS NO es una forma alternativa de mirar a sus Dominios de servicios de directorios (es decir, no es compatible con Examinador o Netlogon, etc.).

Si ha decidido usar DNS, este documento le ensea cmo puede disear su infraestructura de DNS hoy para prepararse para las versiones futuras de los servicios extendidos de directorio ( Enhanced Directory Services , DS) de Windows NT. Lo que estamos a punto de experimentar es un cambio de paradigma. Hasta ahora, el grupo Windows NT, dentro de una empresa, poda actuar en su propio mundo y disear los dominios, relaciones de confianza, recursos, etc. de Windows NT. Los grupos de Windows NT no tenan que preocuparse nunca del mundo de los Servicios de directorio, normalmente haba otro grupo dentro de la compaa que se preocupaba de X.500, DNS y de otros servicios similares. Con la llegada de los servicios extendidos de directorio, que estarn en la siguiente versin importante de Windows NT, esto cambiar y los dos grupos tendrn que trabajar juntos. Lo importante es que los servicios extendidos de directorio sern parecidos a X.500 y utilizarn DNS para localizar los servidores que proporcionan estos Servicios de directorio. Esta es la razn de la importancia de este documento. Permitir que los grupos de Windows NT entiendan el otro mundo de los Servicios de directorio. El documento intenta se una ayuda para que estos dos grupos entiendan las necesidades del otro, de forma que se pueda llevar a cabo una conversin progresiva a los Servicios extendidos de directorio. En este documento se define primero la tecnologa DNS (seccin fundamental para todos aquellos que no conozcan DNS). Luego se comenta el sistema de nombres de dominio especfico de Microsoft (en esta seccin se explica por qu la aplicacin DNS de Microsoft es la eleccin correcta para un entorno Microsoft o mixto), despus se tratan algunas arquitecturas (esta seccin es importante para todos aquellos que vayan a disear una solucin DNS) y, finalmente, se ocupa del futuro de Windows NT (esta es una seccin importante que todo el mundo debera leer). Esperamos que disfrute del documento y que lo encuentre de inters. Si tiene comentarios relacionados con el contenido de este documento, enve un mensaje de correo electrnico a Scott Suhy (scottsu@[Link]) o Glenn Wood (glennwo@[Link]), ambos de Microsoft Corporation.

DNS y Microsoft Windows NT 4.0 1

Antecedentes

Introduccin a DNS
Antes de examinar la implementacin que Microsoft hace de DNS, es importante que el lector sepa un poco acerca de la historia de DNS. Si ya est familiarizado con DNS y su funcionalidad, puede que desee saltarse esta seccin del documento e ir directamente a Implementacin de DNS mediante Windows NT 4.0.

Historia de DNS
El Sistema de nombres de dominio (DNS) es un conjunto de protocolos y servicios sobre una red TCP/IP que permite a los usuarios de la red utilizar nombres amigables jerrquicos cuando busque otros host (es decir, equipos) en lugar de tener que recordar y usar sus direcciones IP. En la actualidad, este sistema cada vez se usa ms en Internet y en muchas empresas privadas. Si alguna vez ha utilizado un explorador WEB, una aplicacin de Telnet, un programa de FTP o cualquier otro programa de TCP/IP parecido de Internet, entonces probablemente haya usado un servidor DNS. La funcin ms conocida de los protocolos DNS es la asignacin de nombres amigables a direcciones IP. Por ejemplo, si la direccin IP del sitio FTP de Microsoft es [Link] , la mayora de la gente llega a este equipo especificando [Link] y no la direccin IP, que es menos amigable. Adems de ser ms fcil de recordar, el nombre es ms fiable. La direccin numrica podra cambiar por muchas razones, pero el nombre siempre sirve. Antes de la implementacin de DNS, la utilizacin de nombres de equipos que fueran amigables se realizaba a travs del uso de archivos HOSTS que contenan una lista de nombres y sus direcciones IP asociadas. En Internet, este archivo se administraba de forma centralizada y cada ubicacin descargaba peridicamente una nueva copia. A medida que fue creciendo el nmero de equipos en Internet, esta solucin se complic demasiado y surgi la necesidad de algo mejor. Esta solucin mejor se convirti en DNS. Segn el Dr. Paul Mockapetris, el diseador principal de DNS, el objetivo original del diseo de DNS era reemplazar este engorroso archivo HOSTS, administrado de forma singular, por una base de datos distribuida ligera que permitiera la existencia de un espacio jerrquico de nombres, la distribucin de la administracin, tipos de datos extensibles, tamao de base de datos virtualmente ilimitado y un rendimiento razonable. DNS se asigna a la capa 7 del modelo OSI y puede usar UDP o TCP como protocolo subyacente. Los resolver envan consultas UDP primero a los servidores, para obtener un mejor rendimiento, y slo acuden a TCP si los datos devueltos estn truncados.

DNS y Microsoft Windows NT 4.0

La implementacin ms conocida del protocolo DNS BIND se program en Berkeley, originalmente, para el sistema operativo UNIX BSD 4.3. El nombre BIND significa Berkeley

Fundamentos de la tecnologa
Internet Name Domain (Dominio de nombres de Internet de Berkeley). Las especificaciones principales de DNS se definen en las Peticiones de comentarios ( Requests for Comments, RFC) 974, 1034 y 1035.

Introduccin
Un sistema de nombres de dominio (DNS) consta de una base de datos de nombres distribuida. Los nombres de la base de datos DNS establecen un estructura lgica de rbol conocida como espacio de nombres del dominio. Cada nodo o dominio del espacio de nombres del dominio tiene un nombre y puede contener subdominios. Los dominios y subdominios se agrupan en zonas para permitir la administracin distribuida del espacio de nombres (las zonas se describen ms adelante en esta seccin). El nombre del dominio identifica la posicin del dominio en la jerarqua lgica de DNS respecto de su dominio principal, al separar cada rama del rbol con un punto .. En la siguiente figura se muestran varios dominios superiores, entre los que se encuentra el dominio Microsoft y un host llamado rino dentro del dominio [Link]. Si alguien quisiera contactar con ese host, usaran el Nombre de dominio completo (FQDN) [Link].

Servidores DNS e Internet

El Centro de informacin de la red Internet ( Internet Network Information Center , [Link] administra la raz de la base de datos DNS en Internet. Los dominios
DNS y Microsoft Windows NT 4.0 3

superiores se han asignado a organizaciones y pases. Estos nombres de dominio siguen el estndar internacional 3166. Para los pases se usan abreviaturas de dos y de tres letras, y se han reservado varias abreviaturas para que las usen las organizaciones, como se muestra en los siguientes ejemplos.

DNS y Microsoft Windows NT 4.0

Nombre dominio DNS com edu gob int mil red org

Tipo de organizacin Comercial (por ejemplo, [Link] para Microsoft Corporation) Educacional (por ejemplo, [Link] para Universidad de Educacin a Distancia) Gubernamental (por ejemplo, [Link] para el palacio de la Moncloa en Madrid) Organizaciones internacionales (por ejemplo, [Link] para la OTAN) Operaciones militares (por ejemplo, [Link] para el Ejrcito) Organizaciones de redes (por ejemplo, [Link] para NSFNET) Organizaciones no comerciales (por ejemplo, [Link] para FidoNet)

Dominios
Cada nodo del rbol de una base de datos DNS, junto con todos los nodos por debajo del mismo, se llama un dominio. Los dominios pueden contener host (equipos) y otros dominios (subdominios). Por ejemplo, el dominio Microsoft, [Link], podra contener a la vez equipos, como [Link], y subdominios, como [Link], que a su vez podra contener host, como por ejemplo [Link]. Por norma general, los nombres de dominio y los nombres de host tienen restricciones, slo est permitido el uso de los caracteres `a-z', `A-Z', `0-9', y `-' (guin o signo menos). No est permitido el uso de caracteres tales como `/', ., y `_' (barra, punto y subrayado).

Zonas
Una zona es alguna parte del espacio de nombres DNS cuyos registros de la base de datos existen y se administran en un archivo determinado de zona. Puede configurarse un nico servidor DNS para administrar uno o mltiples archivos de zona. Cada zona est anclada en un determinado nodo del dominio, llamado dominio raz de la zona. Los archivos de zona no contienen necesariamente todo el rbol (es decir, todos los subdominios) bajo el dominio raz de la zona. En la figura que se muestra a continuacin, se ofrece una comparacin entre dominios y zonas. En este ejemplo, [Link] es un dominio pero el dominio completo no est controlado por un archivo de zona. Parte del dominio est realmente dividido en un archivo de zona distinto para [Link]. A veces es necesario dividir los dominios de los archivos de zonas mltiples para distribuir la administracin del dominio en grupos distintos o para realizar una duplicacin de los datos eficaz (es decir, transferencias de zonas, que se describen ms adelante).

Es muy importante que comprenda la diferencia entre una zona y un dominio. Una zona es un archivo fsico compuesto de registros del recurso que define un grupo de dominios. Un dominio es un nodo del espacio de nombres DNS y todos los subdominios que se encuentran por debajo.

DNS y Microsoft Windows NT 4.0 5

Servidores de nombres
Los servidores DNS almacenan informacin acerca del espacio de nombres del dominio y son conocidos como Servidores de nombres. Los servidores de nombres suelen ser responsables de una o ms zonas. El servidor de nombres se dice que tiene autoridad sobre esas zonas. Cuando se configura un Servidor de nombres DNS (como vamos a ver con el registro NS), se indica cules son los restantes Servidores de nombres DNS que se encuentran en el mismo dominio.

Servidores de nombres principal, secundario y maestro

Un Servidor de nombres principal es un servidor de nombres que obtiene los datos de sus zonas de archivos locales. Los cambios en una zona, como la adicin de dominios o hosts, se realizan en el Servidor de nombres principal. Un Servidor de nombres secundario obtiene los datos de sus zonas de otro servidor de nombres de la red que tiene autoridad para esa zona. El proceso de obtencin de informacin de estas zonas (es decir, el archivo de base de datos) por red se conoce como una transferencia de zona. Existen tres razones para tener servidores secundarios en una empresa:

Redundancia Se necesitan al menos dos servidores de nombres DNS que sirvan cada zona, uno principal y al menos uno secundario para redundancia. Como en el caso de cualquier sistema de tolerancia a fallos, los equipos deben ser tan independientes como sea posible (es decir, redes distintas, etc.).

DNS y Microsoft Windows NT 4.0

Ubicaciones remotas Tambin se debera tener servidores secundarios (u otros servidores principales para los subdominios) en ubicaciones remotas que tengan un alto nmero de clientes. No querr que estos clientes tengan que comunicarse a travs de vnculos lentos para la resolucin de nombres.

Reducir la carga del principal Tambin se necesitan servidores secundarios para reducir la carga del servidor principal.

Puesto que la informacin de cada zona se almacena en archivos separados, esta designacin principal o secundaria se define a nivel de zona. En otras palabras, un servidor de nombres determinado puede ser un servidor de nombres principal para ciertas zonas y un servidor de nombres secundario para otras zonas. Cuando se define una zona de un servidor de nombres como secundario, debe designar un servidor de nombres del que obtener la informacin de la zona. El origen de la informacin de la zona de un servidor de nombres secundario de una jerarqua DNS se conoce como un Servidor de nombres maestro. Un servidor de nombres maestro puede ser un servidor de nombres principal o secundario para la zona en concreto. Cuando se inicia un servidor de nombres secundario, se pone en contacto con su servidor de nombres maestro e inicia una transferencia de zona con ese servidor. Use los servidores secundarios como servidores maestros cuando el principal se encuentre sobrecargado, o cuando haya una ruta de red ms eficaz entre secundario a secundario frente a secundario a principal.

Servidores de reenvo y servidores esclavo

Cuando un servidor de nombres DNS recibe una peticin de DNS, intenta localizar la informacin solicitada dentro de sus propios archivos de zona. Si esto no funciona porque el servidor no tiene autoridad sobre el dominio solicitado, debe comunicarse con otros servidores de nombres DNS para resolver la peticin. Teniendo en cuenta que, en una red conectada globalmente, la peticin de resolucin DNS fuera de una zona local suele requerir la interaccin con servidores de nombres DNS de fuera de la empresa en Internet, puede que desee activar, de forma selectiva, determinados servidores de nombres DNS en su empresa para realizar esta comunicacin de rea extensa. Para solucionar este asunto, DNS ofrece el concepto de servidor de reenvo. Se seleccionan determinados servidores de nombres DNS para que sean servidores de reenvo y slo se permite que sean estos servidores los que lleven a cabo la comunicacin de rea amplia por Internet. Todos los dems servidores de nombres DNS de la compaa se configuran para que usen el servidor de reenvo y se configuran con la direccin IP de los servidores de nombres DNS designados como servidores de reenvo. Esta configuracin se realiza teniendo en cuenta el servidor, no la zona.

DNS y Microsoft Windows NT 4.0 7

Cuando un servidor configurado para usar un servidor de reenvo recibe una peticin DNS que no puede resolver (a travs de su propios archivos de zona), pasa la peticin al uno de los designados como servidores de reenvo. A continuacin, el servidor de reenvo realiza la comunicacin necesaria para satisfacer la peticin y devuelve los resultados al servidor que efectu la peticin, que, a su vez, devuelve la peticin al solicitante original. Si el servidor de reenvo no puede resolver la consulta, el servidor DNS intenta resolver la consulta por s mismo, de forma normal. Los esclavos son servidores DNS configurados para usar servidores de reenvo y tambin para devolver un mensaje de error si el propio servidor de reenvo no es capaz de resolver la consulta. Los esclavos no intentan ponerse en contacto con otros servidores de nombres cuando el servidor de reenvo no puede satisfacer la peticin.

Servidores de almacenamiento temporal (slo-obtener)

Aunque todos los servidores de nombres DNS almacenan en la cach las consultas que han solucionado, los Servidores de almacenamiento temporal (tambin llamados de slo-obtener) son servidores de nombres DNS cuyo nico trabajo es realizar consultas, almacenar en la cach las respuestas y devolver los resultados. Es decir, no tienen autoridad sobre ningn dominio y slo contienen la informacin que han acumulado en la cach mientras resolvan consultas. A la hora de decidir cundo usar estos servidores, tenga presente que, cuando el servidor se inicia por primera vez, no tiene informacin acumulada en la cach y tiene que ir generando dicha informacin con el tiempo, segn vaya atendiendo peticiones. Sin embargo, si disponen de un enlace lento entre los sitios, entonces se enviar mucho menos trfico por el enlace lento, porque el servidor no estar realizando transferencias de zona.

Resolucin de nombres
Un cliente puede realizar tres tipos de consultas a un servidor DNS, recursiva, iterativa e inversa. Mientras se comenta la resolucin de nombres, recuerde que un servidor DNS puede ser un cliente de otro servidor DNS.

DNS y Microsoft Windows NT 4.0

Consultas recursivas
En una consulta recursiva, se pide al servidor de nombres que responda con los datos pedidos, o con un error que indique que el nombre del dominio especificado o los datos del tipo pedido no existen. El servidor de nombres no puede simplemente mandar al solicitante a un servidor de nombres distinto. Este tipo de consulta suele realizarla un cliente DNS (un Resolver) a un servidor DNS. Adems, si un servidor DNS est configurado para usar un servidor de reenvo, la consulta de este servidor DNS a su servidor de reenvo ser una consulta recursiva.

Consultas iterativas
En una consulta iterativa, el servidor de nombres consultado devuelve al solicitante la mejor respuesta que tiene disponible. Este tipo de consulta la suele realizar un servidor DNS a otros servidores DNS despus de haber recibido una consulta recursiva de un resolver. En la siguiente figura se muestra un ejemplo de ambos tipos de consultas. La consulta 1/8 es una consulta recursiva de un resolver de clientes a su servidor DNS, mientras que 2/3, 4/5 y 6/7 son consultas iterativas del servidor DNS a otros servidores DNS.

DNS y Microsoft Windows NT 4.0 9

Obtencin del nombre del host dada la direccin IP

Qu ocurre si un resolver tiene la direccin IP y quiere saber el nombre del host de una mquina determinada? En lugar de suministrar un nombre y preguntar por una direccin IP, el cliente necesita proporcionar la direccin IP y preguntar por el nombre. Puesto que no hay una relacin directa, en el espacio de nombres DNS, entre los nombres de dominios y las direcciones IP asociadas que contienen, slo se puede garantizar una respuesta correcta si se realiza una bsqueda en profundidad de todos los dominios. Para solucionar este problema, se ha creado un dominio especial ([Link].) en el espacio de nombres DNS. Los nodos del dominio [Link] reciben su nombre segn los nmeros de la representacin en octetos punteada de las direcciones IP. Pero, puesto que las direcciones IP se vuelven ms especficas de izquierda a derecha y que los nombres de dominio se vuelven menos especficos de izquierda a derecha, al generar el rbol [Link] hay que invertir el orden de los octetos de la direccin IP. Con este arreglo, ser puede conceder la administracin de las ramas inferiores del rbol [Link] de DNS a las empresas cuando se les asigna su direccin de subred de clase A, B o C. Una vez generado el rbol del dominio en la base de datos DNS, se agrega un registro de puntero especial para asociar las direcciones IP a los nombres correspondientes de host. Es decir, para buscar un nombre de host para la direccin IP [Link], el resolver solicitar al servidor DNS un registro de puntero para [Link].[Link]. Si esta direccin estuviera fuera del dominio local, el servidor DNS empezara en la raz y resolvera, secuencialmente, los nodos del dominio hasta alcanzar [Link], que contendra el registro PTR del recurso de 2 (es decir, [Link]).

Almacenamiento en la cach y tiempo de vida

Cuando un servidor de nombres est procesando una consulta recursiva, puede que sea necesario enviar varias consultas hasta encontrar la respuesta definitiva. El servidor de nombres almacena en la cach toda la informacin que recibe en este proceso durante el periodo de tiempo especificado en los datos devueltos. Este tiempo es conocido como el tiempo de vida (Time To Live, TTL). El administrador del servidor de nombres de la zona que contiene los datos decide el TTL para los datos. Cuanto menores sean los valores de TTL se asegurar que los datos del dominio sean ms consistentes en la red si este valor cambia a menudo. Sin embargo, esto tambin aumentar la carga del servidor de nombres.

10

DNS y Microsoft Windows NT 4.0

Los archivos DNS

En cuanto se almacenan los datos en la cach de un servidor DNS, debe empezar a disminuir el TTL (es decir, a descontar) del valor original, de forma que pueda saber cundo eliminar los datos de su cach. Si llega una consulta que se puede contestar con los datos acumulados, el TTL que se devuelve con los datos es el tiempo real restante hasta que se eliminen los datos de la cach del servidor DNS. Los resolver cliente tambin disponen de cachs de datos y utilizan el valor TTL, lo que les permite saber cundo caducan los datos.

Introduccin
La mayora de los sistemas DNS tienen que configurarse editando archivos de texto. Con DNS de Microsoft, como con el resto de los productos basados en Microsoft Windows, existe una interfaz amigable. La nueva interfaz de administracin hace mucho ms fcil la configuracin de los servidores DNS de Microsoft, tanto locales como remotos. La herramienta administrativa de DNS configura los archivos de texto compatibles RFC. Aunque la interfaz grfica de usuario le ofrece la posibilidad de modificar los archivos DNS sin un editor, es importante que conozca la composicin de los archivos de configuracin del sistema DNS. En los sistemas DNS compatibles con RFC, hay varios archivos que definen la configuracin del sistema y la base de datos DNS. Entre estos archivos se incluye la base de datos, la cach, bsqueda inversa y 127 archivos de bsqueda inversa. Estos archivos tambin existen en
DNS y Microsoft Windows NT 4.0 11

el DNS de Windows NT 4.0 y tambin son compatibles con RFC. Estos archivos se explican detalladamente en esta seccin.

El archivo de base de datos

Un archivo de base de datos o archivo de zona es el archivo que contiene los registros del recurso para la parte del dominio de la que es responsable la zona. Algunos de los registros comunes del recurso se enumeran a continuacin. Para obtener una lista ms completa, remtase al apndice de este documento o consulte los RFC adecuados. Windows NT 4.0 proporciona un archivo como plantilla para trabajar con el llamado "[Link]". Es necesario modificar este archivo y cambiarle de nombre antes de usarlo en un servidor DNS de produccin. Se recomienda dar a este archivo el mismo nombre que el de la zona a la que representa. ste es el archivo que se va a duplicar entre los maestros y los secundarios.

El inicio de la autoridad
El primer registro de cualquier archivo de base de datos es el registro SOA.
IN SOA <host origen> <correo electrnico de contacto> <n ser.> <tiempo actualizacin> <tiempo reintento> <tiempo caducidad> <TTL>

host origen - El host en el que se mantiene el archivo. correo electrnico de contacto - La direccin de correo electrnico de Internet de la persona responsable del archivo de base de datos de este dominio.

En lugar de escribir el smbolo @ en el nombre de correo electrnico, como se suele hacer, el smbolo @ se sustituye por un . cuando se coloca en el archivo de zonas. Es decir, la direccin de correo electrnico glennwo@[Link] sera [Link] en el archivo de zona.

12

DNS y Microsoft Windows NT 4.0

nmero de serie - El "nmero de versin" de este archivo de base de datos. Este nmero debera aumentar cada vez que cambie el archivo de base de datos. tiempo de actualizacin - El tiempo (en segundos) que esperar un servidor secundario entre comprobaciones de su servidor maestro para ver si el archivo de base de datos ha cambiado y si hay que pedir una transferencia de zona. tiempo de reintento - El tiempo (en segundos) que esperar un servidor secundario antes de volver a intentar una transferencia de zona que haya fallado. tiempo de caducidad - El tiempo (en segundos) que un servidor secundario seguir intentando descargar una zona. Cuando haya pasado este tiempo, se rechazar la informacin antigua de la zona. tiempo de vida (TTL) - El tiempo (en segundos) que un servidor DNS tiene permitido acumular en la cach cualquier registro del recurso de este archivo de base de datos. ste es el valor que se enva con todas las respuestas de la consulta de este archivo de zona cuando el registro de recurso individual no contiene un valor que lo anule.

Para que un registro de recurso abarque una lnea en un archivo de base de datos, los saltos de lnea deben incluirse entre parntesis.

En un archivo de zona, el smbolo @ representa el dominio raz de la zona ([Link] en los siguientes ejemplos). La abreviatura IN de los siguientes registros es la clase de datos. Significa Internet. Existen otras clases, pero ninguna de ellas se utiliza demasiado en la actualidad.

Cualquier nombre de dominio del archivo de base de datos que no termine con un punto . tendr el dominio raz anexado al final.

Ejemplo: @ IN SOA [Link]. [Link]. ( 1 10800 3600 604800 86400 ) ; nmero de serie ; actualizar [3 horas] ; reintentar [1 hora] ; caducar [7 das] ; tiempo de vida [1 da]

DNS y Microsoft Windows NT 4.0 13

El establecimiento del intervalo de actualizacin de un servidor debe ser un equilibrio entre la consistencia de los datos (exactitud de los datos) y la carga de las redes.

El registro Servidor de nombres

Enumera los servidores de nombres de este dominio, permitiendo que otros servidores de nombres miren los nombres de su dominio. <dominio> Ejemplo: @ IN NS @ IN NS [Link]. [Link]. IN NS <nombreservidor host >

El registro Intercambio de correo

Este registro indica qu host procesa el correo de este dominio. Si existen mltiples registros de intercambio de correo, el resolver intentar ponerse en contacto con los servidores de correo en orden de preferencia, empezando por los valores inferiores (mayor prioridad) hasta el valor superior (menor prioridad). Al usar los siguientes registros de ejemplo, el correo enviado a scottsu@[Link] se enva primero a scottsu@[Link], si es posible, y luego a scottsu@[Link] si servidorcorreo0 no est disponible. <dominio> Ejemplo: @ @ IN MX IN MX 1 2 servidorcorreo0 servidorcorreo1 IN MX <preferencia> <servidorcorreo host >

14

DNS y Microsoft Windows NT 4.0

El registro Host
Un registro host sirve para asociar estticamente nombres de host a direcciones IP dentro de una zona. Debe contener entradas para todos los hosts que requieran asignacin esttica, incluyendo las estaciones de trabajo, los servidores de nombres, los servidores de correo, etc. stos son los registros que componen la mayor parte del archivo de base de datos cuando se usan registros estticos. <nombre host> Ejemplo: rino IN A [Link] [Link] [Link] IN A <direccin IP de host>

nombreservidor2 IN A servidorcorreo1 IN A

El registro Host Local

Un registro de host local permite consultas a "[Link]." para devolver [Link]. hostlocal IN A [Link]

El registro CNAME
Estos registros tambin reciben el nombre de "alias", aunque tcnicamente son conocidos como entradas "nombre cannico" (CNAME). Estos registros le permiten usar ms de un nombre para apuntar a un nico host. La utilizacin de nombres cannicos simplifica operaciones tales como albergar a la vez un servidor FTP y un servidor WEB en el mismo equipo. <nombre alias host > Ejemplo: Suponga que [Link] y que [Link] se encuentran en el mismo equipo. Si ste es el caso, entonces podra tener las siguientes entradas en su archivo de zona: Servidorarchivos1 ftp www IN A CNAME CNAME [Link] Servidorarchivos1 Servidorarchivos1 IN CNAME <nombre host>

Si alguna vez intentara desplazar el servicio del servidor FTP lejos del servicio WEB, lo nico que tendra que hacer es cambiar el CNAME del servidor DNS de ftp y agregar un registro de direccin para el nuevo servidor. Por ejemplo: ftp CNAME Servidorarchivos2 Servidorarchivos2 IN A [Link]

DNS y Microsoft Windows NT 4.0 15

El archivo de cach
El archivo de la cach contiene la informacin del host necesaria para resolver nombres fuera de los dominios que tienen autoridad. Contiene nombres y direcciones de servidores de nombres raz. Para los usuarios de Internet, el archivo predeterminado suministrado con el Servicio DNS de Microsoft debera ser suficiente. Para las instalaciones NO conectadas a Internet, el archivo debera sustituirse para contener los servidores de nombres que tengan autoridad sobre la raz de su red privada. Para obtener un archivo cach actual de Internet vea [Link] Ejemplo:
; DNS CACHE FILE ; ; Initial cache data for root domain servers. ; ; YOU SHOULD CHANGE: ; - Nothing if connected to the Internet. Edit this file only when ; update root name server list is released. ; OR ; - If NOT connected to the Internet, remove these records and replace ; with NS and A records for the DNS server authoritative for the ; root domain at your site. ; Internet root name server records: ; last update: Sep 1, 1995 ; related version of root zone: 1995090100 ; ; formerly [Link] . 3600000 IN NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. [Link]. 3600000 A [Link] ; formerly [Link] . 3600000 NS [Link]. ; End of File

El archivo de Bsqueda inversa

Es un archivo de base de datos que sirve para las consultas inversas en zonas DNS de IP particulares de nombres de host cuando se proporcionan los nmeros de IP. Esto permite que un resolver proporcione una direccin IP y que pida el correspondiente nombre de host. Este archivo contiene registros SOA y Servidor de nombres parecidos a otros archivos de zonas de base de datos DNS. Tambin contiene registros de punteros.

16

DNS y Microsoft Windows NT 4.0

La funcionalidad de consultas inversas de DNS es importante, pues algunas aplicaciones ofrecen la posibilidad de implementar la seguridad basada en los nombres de los hosts de conexin. Por ejemplo, si un cliente intenta vincularse a un volumen NFS (Sistema de archivos de red o Network File System) con este arreglo de seguridad, el servidor NFS entrara en contacto con el servidor DNS y realizara una consulta inversa del nombre en la direccin IP de los clientes. Si el nombre del host devuelto por el servidor DNS no se encuentra en la lista de acceso del volumen NFS, o si no se ha encontrado por DNS, entonces se denegara la peticin de montar NFS. La consulta inversa se utiliza a menudo para solucionar problemas, tal y como se explica ms adelante en este documento. A continuacin, se muestran dos zonas de ejemplo de distintas redes de clases de direccin IP. Ejemplo zona clase C: [Link] Ejemplo zona clase B: [Link]

El registro Puntero
Los registros puntero proporcionan una asignacin esttica de direcciones IP a nombres de host de una zona de bsqueda inversa. Los nmeros de IP se escriben en orden inverso y se les anexa "[Link]." al final para crear este registro puntero. Por ejemplo, la bsqueda del nombre "[Link]" requiere una consulta PTR del nombre "[Link].[Link].". <ip inversa nombre dominio> IN PTR <nombre host> Ejemplo: [Link].[Link]. IN PTR [Link].

El archivo [Link]
Es un archivo de base de datos para el dominio [Link]. Este dominio se usa para las consultas inversas de nmeros IP de la red 127, como "hostlocal". Lo nico que cambia en este archivo son los registros SOA y NS.

El archivo de inicio BIND

Aunque el archivo de inicio en realidad no se define en los RFC y no es necesario para la compatibilidad con RFC, se describe para completar la informacin de este documento. En realidad, este archivo es una parte de la implementacin especfica BIND de DNS. Microsoft DNS se puede configurar para usar un archivo de inicio si lo va a administrar mediante cambios en los archivos de texto, en lugar de usar la interfaz grfica del Administrador de DNS. Este archivo controla el comportamiento de inicio del servidor DNS. Los comandos deben estar al comienzo de una lnea y no debe haber espacios antes de ellos. Los comandos reconocidos son: "directory, cache, primary y secondary". La sintaxis de este archivo es la siguiente:

DNS y Microsoft Windows NT 4.0 17

Comando directory
Especifica el directorio en el que se encuentran los archivos a los que se hace referencia en el archivo de inicio. directory Ejemplo: directory c:\winnts\system32\dns <directorio>

Comando cache
Especifica un archivo que se ha utilizado para ayudar al servicio DNS a ponerse en contacto con los servidores de nombres para el dominio raz. Este comando, y el archivo al que hace referencia, DEBEN estar presentes. Con Windows NT 4.0 se suministra un archivo de cach adecuado para utilizarlo en Internet. cache Ejemplo: cache . cach . <nombrearchivo>

Comando primary
Especifica un dominio sobre el que este servidor de nombres tiene autoridad y un archivo de base de datos que contiene los registros de recursos para ese dominio (es decir, archivo de zona). En el archivo de inicio pueden existir mltiples registros de comandos principales. primary Ejemplo: primary primary [Link] [Link] [Link] [Link] <dominio> <nombrearchivo>

Comando secondary
Especifica un dominio sobre el que este servidor de nombres tiene autoridad y una lista de direcciones IP de servidores maestros de los que se puede intentar descargar la informacin de zona, en lugar de leerla en un archivo. Tambin define el nombre del archivo local para almacenar en la cach esta zona. En el archivo de inicio pueden existir mltiples registros de comandos secundarios. secondary Ejemplo: secondary [Link] [Link] [Link] <dominio> <lista de host> <nombrearchivo local>

18

DNS y Microsoft Windows NT 4.0

Introduccin a Microsoft DNS

Implementacin de DNS mediante Windows NT 4.0

Microsoft DNS tambin sirve para sustituir servidores DNS de UNIX por sistemas basados en Windows NT y para integrar clientes y servidores Microsoft que tengan activado WINS en un entorno basado en UNIX. Algunas personas se preguntarn qu es Microsoft DNS y por qu deben usarlo. Bien, empezaremos diciendo lo que no es. Primero, el servidor Microsoft DNS no es una adaptacin del cdigo BIND de Berkeley (que en el momento de la redaccin de este documento se encuentra en la revisin 10.4). Tomamos la decisin de no adaptar el cdigo BIND, sino escribir nuestro propio cdigo que fuera totalmente compatible con RFC y con BIND. Tomamos esta decisin porque queramos tener la posibilidad de agregar mejoras al producto. El servidor Microsoft DNS tampoco es el cdigo que se entrega en el Windows NT Resource Kit. Si ha utilizado ese programa, probablemente se haya dado cuenta de que tena problemas con la transferencia de zonas. El servicio servidor DNS de Windows NT 4.0 se ha vuelto a escribir por completo y no es simplemente una versin en la que se han corregido los problemas. Tenga por seguro que, en el DNS de Windows NT 4.0, la compatibilidad RFC ha sido comprobada en profundidad y funciona todo tal y como se describe, incluyendo la transferencia de zonas. Ahora hablemos acerca de lo que es el servidor Microsoft DNS. Antes que nada, el servidor DNS de NT 4.0 es una implementacin de DNS compatible con RFC. Esto significa que el servidor Microsoft DNS cumple todas las especificaciones documentadas en los estndares del mercado acerca de DNS en la fecha de entrega de Windows NT 4.0. Si hubiera una caracterstica obligatoria en un RFC que no se encontrara en el producto Microsoft DNS, esto se considerara un error. Puesto que Microsoft DNS es un servidor DNS compatible con RFC, crea y utiliza archivos de zona estndar de DNS y admite todos los tipos de registros de recursos estndar. Puede interactuar con otros servidores DNS e incluye el programa de diagnstico estndar de DNS, NSLOOKUP. Microsoft DNS dispone tambin de muchas caractersticas superiores y ms all de las especificadas en los RFC, tal como la actualizacin dinmica a travs de una fuerte integracin con WINS y una administracin sencilla mediante el programa de administracin grfica llamado Administrador de DNS.

Microsoft DNS admite los RFC 1033, 1034, 1035, 1101, 1123, 1183 y 1536

DNS y Microsoft Windows NT 4.0 19

Con la implementacin de DNS de Microsoft, los administradores de redes pueden desactivar los sistemas DNS heredados en favor de una implementacin de Microsoft Windows NT. Pueden eliminar todas las entradas estticas de los clientes Microsoft de los archivos de zona de los servidores DNS heredados en favor de la integracin dinmica WINS/DNS. Por ejemplo, si un cliente que no sea Microsoft desea llegar a una pgina WEB en un servidor HTTP que tenga activado DHCP/WINS, el cliente puede consultar al servidor DNS, el servidor DNS puede consultar a WINS y el nombre se puede resolver y devolver al cliente. Antes de la integracin de WINS, no haba forma de resolver el nombre con fiabilidad, debido al direccionamiento dinmico de IP. En la siguiente figura se muestra cmo un cliente distinto de Microsoft podra encontrar un equipo [Link] ejecutando Microsoft Internet Information Server (IIS) que tiene una direccin asignada dinmicamente desde DHCP que se registr con WINS.

20

DNS y Microsoft Windows NT 4.0

Adems, como ya se ha indicado, el servidor Microsoft DNS tiene un Administrador DNS como interfaz grfica de usuario que permite una administracin sencilla de cualquier otro servidor Microsoft DNS de la red, mediante RPC (funcionamiento parecido al de otros programas administrativos de Windows NT, como el Administrador del servidor o el Visor de sucesos). La interfaz grfica de administracin tambin contiene un asistente para zonas que permite que cualquier persona poco familiarizada con DNS cree zonas y archivos de bases de datos de zonas. En cualquier caso, tenga en cuenta que los servidores DNS que no sean de Microsoft no pueden administrarse con esta herramienta de administracin. Hay que resaltar que el servidor Microsoft DNS puede utilizar con facilidad los archivos de base de datos, inicio, cach, rev y otros de cualquier otra implementacin de servidor DNS (es decir, UNIX u otra implementacin DNS de Windows NT) siempre que el servidor DNS sea compatible con RFC. Lo nico que se necesita para llevar los archivos a Microsoft DNS es cambiar los nombres de archivo y las ubicaciones del archivo de Inicio.

Aunque Microsoft DNS admite un archivo de inicio en la instalacin inicial, el archivo de inicio es una implementacin especfica de BIND y no un requisito de los RFC. Esta funcin se proporciona para que resulte ms fcil la migracin desde los servidores DNS basados en BIND. Si se usa la herramienta de interfaz de usuario Administrador de DNS de Microsoft para crear y administrar los archivos de zona, la opcin de "Iniciar desde archivo de inicio" se establecer a "Iniciar desde el Registro" y Microsoft DNS utilizar y usar los datos del Registro de NT para localizar y cargar las bases de datos de archivos de zona. En el archivo BOOT se escribir un mensaje que indique que la informacin se encuentra ahora en el Registro. Para volver a iniciar desde el archivo de inicio, el valor de la clave EnableRegistryBoot del Registro de Windows NT tendr que modificarse manualmente.

El servidor Microsoft DNS tambin puede ser el principal o secundario de cualquier otro sistema operativo (o de la implementacin de Windows NT de cualquier otro fabricante). Esto facilita la conversin desde una aplicacin DNS de UNIX a la aplicacin de Microsoft. En la siguiente seccin se explica la instalacin de un servidor Microsoft DNS y los parmetros necesarios para que funcione un resolver de clientes.

DNS y Microsoft Windows NT 4.0 21

Instalacin del servicio DNS

El servidor
Comprobacin de la informacin DNS de Windows NT
Antes de instalar el servicio Microsoft DNS, es importante que la pila TCP/IP de Windows NT 4.0 Server est configurada correctamente. Ms concretamente, es necesario comprobar la seccin DNS, puesto que el servicio DNS obtiene muchos de sus valores predeterminados desde esta seccin durante la instalacin. Para comprobar la informacin, ejecute el Panel de control y vaya a Red. Haga clic en la ficha Protocolos. Elija el cuadro de dilogo de propiedades del protocolo TCP/IP y elija la ficha DNS. Compruebe que en esta pantalla figuran el Nombre host y del Dominio correctos.

Si el nombre del dominio y el nombre host se suministran en la instalacin del Panel de control de la red cuando se crea una zona, DNS agregar a la base de datos un registro SOA, A y NS. Si la informacin no est configurada, entonces slo se crear el registro SOA.

22

DNS y Microsoft Windows NT 4.0

Instalacin del servicio DNS de Microsoft

Para instalar el servicio DNS de Microsoft en Windows NT 4.0, ejecute el Panel de control y vaya a Red. Haga clic en la ficha Servicios y luego en el botn Agregar. Seleccione Servidor Microsoft DNS y elija Aceptar.

En este momento se generar una instalacin predeterminada del servicio Servidor Microsoft DNS en NT Server. De este modo se instalarn los archivos, como se indica, en el directorio \<Razdelsistema>\system32\Dns. En este momento se le pedir que reinicie el servidor.

DNS y Microsoft Windows NT 4.0 23

Configuracin de dominios y zonas DNS

Para configurar el servidor DNS, ejecute el Administrador de DNS en Herramientas administrativas. Al principio, el Administrador de DNS no tendr ningn servidor en su lista. Para agregar un servidor local, despliegue el men DNS y haga clic en Nuevo servidor. Escriba el nombre de su servidor local y haga clic en Aceptar. El servidor aparecer en la Lista de servidores. Haga doble clic en el servidor para ver las estadsticas y zonas del servidor que se han definido.

Puesto que, en principio, el servidor DNS no tiene informacin acerca de su red en particular, el servicio del servidor DNS se instala solamente como servidor de nombres de almacenamiento temporal (o slo-obtener) para Internet. Esto significa que DNS slo contiene informacin sobre servidores raz de Internet. En la mayora de las configuraciones DNS, para obtener la operacin deseada hay que suministrar informacin adicional. El primer paso para configurar el servidor DNS es determinar la jerarqua de sus dominios y zonas DNS. Las consideraciones acerca del diseo de una jerarqua DNS se describen en la siguiente seccin de este documento. Una vez determinada la informacin de los dominios y zonas, hay que introducirla en la configuracin de DNS usando el Administrador de DNS.

24

DNS y Microsoft Windows NT 4.0

Puesto que la informacin de DNS se agrupa y se controla por zonas, primero hay que crear una zona. Para ello, haga clic en el nombre del servidor con el botn secundario del mouse (ratn) y luego elija Nueva zona.

Si hace doble clic en la zona CACHE1, podr ver todos los host que el servidor DNS haya definido estticamente y almacenado dinmicamente en la cach con motivo de una consulta anterior. La CACHE mostrar tambin todas las entradas WINS que se hayan resuelto y que no hayan agotado su valor de tiempo en espera cach especfico de WINS.

A esta altura aparecer un cuadro de dilogo en el que se pregunta si la Zona que est creando es una zona principal (la informacin se almacena localmente) o una zona secundaria (la informacin se obtiene de un servidor maestro a travs de una transferencia de zona). Si es una zona principal, en esta fase no es necesaria informacin adicional. Si es una zona secundaria, tendr que introducir tambin los nombres de la zona y del servidor maestro en esta pantalla.

DNS y Microsoft Windows NT 4.0 25

El siguiente paso es rellenar la informacin de Nombre de zona y Archivo de zona del servidor local. Esto determinar cmo aparecern las zonas en el Administrador de DNS y bajo qu nombre de archivo se almacenarn. Si es una zona secundaria, el nombre de zona tiene que coincidir con el nombre de zona del servidor maestro. Si este archivo de zona ya existiera en el directorio DNS, DNS importar automticamente estos registros cuando se cree la zona.

26

DNS y Microsoft Windows NT 4.0

Si es una zona secundaria, se le pedir que escriba la direccin IP de los servidores de nombres maestros (los servidores de nombres con los que har la transferencia de zonas para esta zona).

Una vez introducida toda esta informacin, se agregar la zona a la jerarqua DNS. Si tiene zonas adicionales que desea agregar, siga el mismo procedimiento con cada una. Una vez agregadas al servidor todas las zonas, tiene que agregar todos los subdominios DNS que se encuentren bajo las zonas que pudiera contener la jerarqua. Para ello, elija la zona adecuada con el botn secundario del mouse y haga clic en Nuevo Dominio.

DNS y Microsoft Windows NT 4.0 27

Escriba el nombre del nuevo subdominio en el cuadro de dilogo y haga clic en Aceptar. Si fueran necesarios niveles mltiples de subdominios, cree cada subdominio haciendo clic en el subdominio principal inmediato con el botn secundario del mouse, haga clic en Nuevo dominio e introduzca el nombre del nuevo subdominio. Este proceso tambin puede servir para agregar nuevos hosts o registros de recursos a cualquier ubicacin del dominio de la jerarqua DNS.

Integracin con bsquedas de WINS El registro WINS

Aunque DNS puede parecer similar a WINS (Servicio de denominacin de Internet de Windows), hay un par de diferencias importantes. DNS es una base de datos esttica de direcciones IP para la asignacin de nombres a direcciones, que un administrador tiene que actualizar manualmente. Adems, DNS tiene el concepto de jerarqua, que permite dividir la administracin y duplicacin de la base de datos en zonas. WINS, por su parte, permite que los equipos registren dinmicamente sus asignaciones de nombre a direccin y, por tanto, requiere mucha menos administracin. WINS es tambin un espacio plano de nombres sin el concepto de jerarqua y necesita que cada servidor WINS mantenga una base de datos completa de entradas mediante duplicacin. El servidor Microsoft DNS funciona en estrecha colaboracin con el servidor Microsoft WINS y ambos proporcionan una amplia interoperabilidad. Para conseguir esta interoperabilidad, se defini un nuevo registro como parte del archivo de base de datos de zonas. El registro WINS es especfico para Windows NT y slo puede adjuntarse al dominio raz de la zona. La presencia de un registro WINS indica al servidor de nombres que tiene que utilizar WINS para consultar cualquier peticin de los host en la raz de la zona que no tenga direcciones estticas en la base de datos de IP. Esta funcin es especialmente til para los clientes UNIX que necesiten ponerse en contacto con clientes activados DHCP/WINS mediante IP. <dominio> Ejemplo: @ IN WINS [Link] IN WINS <Direccin IP de servidor WINS>

Activacin de bsquedas WINS

Las consultas WINS se pueden activar para una zona mediante el Administrador de DNS, en lugar de introducirlas manualmente en el registro WINS. Para ello, haga clic en la zona con el botn secundario del mouse y despus haga clic en propiedades. A continuacin haga clic en la ficha Bsqueda de WINS. Active la casilla de verificacin Usar Resolucin WINS y escriba la direccin IP del servidor WINS que desee usar y luego elija Agregar. Se pueden introducir mltiples direcciones de servidor WINS.

28

DNS y Microsoft Windows NT 4.0

Lo ms probable es que slo necesite usar la bsqueda de WINS si tiene clientes TCPIP que no sean de Microsoft que necesiten resolver nombres de host a direcciones IP. Por ejemplo, en su organizacin puede existir la necesidad de usar FTP o HTTP en sus servidores Windows NT desde clientes que no sean de Microsoft (es decir, UNIX).

Si tiene una zona configurada para realizar bsquedas WINS, todos los servidores DNS que tengan autoridad para esa zona necesitarn poder hacer bsquedas WINS o, en caso contrario, tendr un comportamiento intermitente.

Para poder agregar fcilmente la bsqueda de WINS / DNS a una arquitectura DNS heredada, cree un nuevo subdominio DNS en su empresa y active el servidor principal y los secundarios de Windows NT para realizar bsquedas de WINS en este dominio. Por ejemplo, en la siguiente figura, hay un dominio [Link] y un dominio [Link]. Todos los clientes Microsoft se registran con el servidor WINS en el dominio [Link].

DNS y Microsoft Windows NT 4.0 29

La bsqueda WINS se realiza por zonas DNS. De esta forma, una consulta a un servidor DNS de [Link] ira al servidor WINS si el DNS que tuviera el registro de bsqueda WINS tuviera autoridad para la zona [Link], aunque una consulta de [Link] no ira a ese mismo servidor WINS. Esto se muestra en la siguiente figura.

30

DNS y Microsoft Windows NT 4.0

Si est usando un registro WINS y el tiempo de vida del registro SOA no es el predeterminado tambin para WINS, el WINS TTL se configura en el cuadro de dilogo Propiedades avanzadas de la zona (bajo la ficha de bsqueda de WINS) cuando est configurando la zona. Cuando una direccin IP / Nombre host se resuelve mediante WINS, la direccin se almacena en la cach durante el tiempo que indica el Valor tiempo de espera de cach de WINS. Si esta direccin se enva alguna vez a otro DNS, lo que se enva es el valor TTL del tiempo de espera de cach de WINS.

Si los datos no cambian mucho, entonces querr establecer un valor alto en su TTL. Tenga en cuenta que tambin puede establecer el TTL en registros individuales. Si el TTL de la direccin individual de un RR es menor o mayor que el TTL del registro SOA, los TTL individuales tienen preferencia.

WINS y la bsqueda inversa El registro bsqueda inversa de WINS

Aunque WINS no se ha diseado para ofrecer la posibilidad de bsqueda inversa, esta funcionalidad puede conseguirse para los clientes activados DHCP/WINS cuando se usa el servidor DNS de Microsoft. La presencia de un registro WINS-R en la raz de la zona indica al servidor de nombres que use una bsqueda de estado de adaptador de nodo NetBIOS para cualquier peticin de bsqueda inversa de direcciones IP en la raz de la zona que no estn definidas estticamente con registros PTR. <dominio> Ejemplo: @ IN WINS-R [Link]. IN WINS-R <dominio que se va a anexar a nombres NetBIOS devueltos>

DNS y Microsoft Windows NT 4.0 31

Activacin de la bsqueda inversa WINS

La bsqueda inversa de WINS se activa para una zona mediante el Administrador de DNS, en lugar tener que introducirlo manualmente en el registro WINS-R. Para ello, haga clic en la zona [Link] adecuada con el botn secundario del mouse y despus haga clic en Propiedades. Luego haga clic en la ficha Bsqueda inversa de WINS. Active la casilla de verificacin Utilizar bsqueda inversa WINS y escriba el Dominio del host DNS que se va a anexar al nombre NetBIOS antes de devolver la respuesta al resolver.

Se puede configurar el servidor Microsoft DNS para que NO enve registros WINS a servidores secundarios. Esto es necesario si tiene una mezcla de servidores DNS Microsoft y UNIX, puesto que los servidores DNS de UNIX no tienen la capacidad de realizar bsquedas WINS.

32

DNS y Microsoft Windows NT 4.0

Otras cosas importantes El servidor Microsoft DNS admite Notify

La transaccin NOTIFY de DNS permite a los servidores maestros informar a los servidores secundarios sobre cundo ha cambiado la zona (Notify se establece en el servidor maestro zona a zona), un modelo de interrupcin en lugar de un modelo de muestreo. Esta operacin debera disminuir el retraso en la propagacin, a la vez que no aumenta innecesariamente la carga del servidor maestro. La utilizacin de esta funcin depende de la frecuencia de cambio de los datos del servidor maestro y de la lentitud del vnculo entre el secundario y el principal. Si los datos del servidor maestro cambian mucho y si es importante que los datos de los secundarios sean muy precisos y que el vnculo entre el emplazamiento que alberga al principal y al secundario no se vea impactado negativamente por la transferencia de zona, entonces sera recomendable la utilizacin de esta caracterstica. Tambin se recomienda el uso de esta funcin si los datos del servidor maestro no cambian muy a menudo. En ese caso, puede hacer que el tiempo de actualizacin del maestro sea muy grande y que se enve una notificacin a los secundarios cuando necesiten actualizar sus bases de datos de zonas.

Microsoft DNS admite la asignacin circular

La asignacin circular es una tcnica que sirve para equilibrar cargas entre servidores. Puede leer ms acerca del equilibrio de cargas en RFC 1794. A continuacin se muestra un ejemplo de su funcionamiento: En el servidor DNS podra tener 2 entradas de direccin para el mismo host, como las siguientes: [Link] A [Link] [Link] A [Link] Si genera una consulta mediante algn mecanismo del tipo PING [Link], el servidor DNS enviar de vuelta ambas direcciones IP, pero normalmente el cliente usar siempre la primera. La prxima vez que el servidor DNS reciba una consulta para este host, el orden de la lista se cambia de forma de asignacin circular (la direccin que estaba primera en la lista anterior pasar a ser la ltima en la nueva lista), por lo que, cuando el resolver del cliente elija la primera direccin IP de la lista, elegir un servidor distinto. Esto se suele usar para equilibrar cargas. A continuacin, se ofrece el seguimiento de una consulta que muestra cmo funciona la caracterstica. En el marco 1 se enva una consulta para obtener la direccin IP del host [Link]. Puesto que haba 2 entradas en la base de datos, se devolvieron las dos. El resolver del cliente, en la mayora de las implementaciones (incluyendo el resolver de MS) usa la primera entrada y desecha la otra.

DNS y Microsoft Windows NT 4.0 33

SCOTTSU-7

Xircom40417A DNS

0x1:Std Qry for [Link]

DNS: 0x1:Std Qry for [Link] of type Host Addr on class INET addr. 2 Xircom40417A SCOTTSU-7 DNS 0x1:Std Qry Resp. for [Link]

DNS: 0x1:Std Qry Resp. for [Link] of type Host Addr on class INET addr. .... DNS: Answer section: [Link] of type Host Addr on class INET addr.(2 records present) DNS: Resource Record: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link] DNS: Resource Record: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link]

La prxima vez que alguien genere una consulta para el host [Link], la primera direccin IP de la lista ser distinta.
DNS: Answer section: [Link] of type Host Addr on class INET addr.(2 records present) DNS: Resource Record: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 3600 (0xE10) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link] DNS: Resource Record: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link]

mbito NetBIOS
Lo que nunca hay que olvidar sobre el hecho de que DNS admita el mbito NetBIOS es que NO HAY QUE USARLO... a menos que su red ya utilice el mbito NetBIOS. En una configuracin de mbito, a todos los host se les asigna un identificador (Id.) de mbito y registran este Id. de mbito, junto con su nombre NetBIOS, en WINS. Si DNS est configurado para utilizar mbito, cuando consulte WINS, adems de pasar el nombre de host DNS simplemente como nombre NetBIOS, tambin pasa el dominio DNS como el Id de mbito de NetBIOS. Otro dato muy importante acerca del mbito es que, cuando se utiliza, las aplicaciones NetBIOS no pueden ver los host que se encuentren en otros mbitos. Una de estas aplicaciones NetBIOS es el servicio Netlogon de NT, responsable de las relaciones de confianza entre los dominios NT. Esto significa, por ejemplo, que si se usa el mbito, un usuario no puede iniciar sesin en un dominio cuyos controladores de dominio tienen un mbito distinto del de la estacin de los usuarios. Tambin significa que un usuario no puede tener acceso a los recursos de un servidor de red de un dominio cuyo mbito sea distinto del de las estaciones de los usuarios.

34

DNS y Microsoft Windows NT 4.0

Cundo lee y escribe Microsoft DNS en los archivos de zonas?

En el inicio del servicio DNS, se leen los archivos de zona del disco. Cuando se realizan cambios mediante el Administrador de DNS, el servicio almacena peridicamente estos cambios en el disco. Por norma general, debera utilizar siempre el programa Administrador de DNS para agregar, eliminar o modificar registros del recurso de la base de datos; sin embargo, si cree que necesita modificar los archivos con un editor, slo debera modificar esos archivos si el servicio del servidor DNS no est en uso. De forma predeterminada, los archivos se encuentran en \ %Razdelsistema%\system32\Dns. Si usa el programa de administracin de DNS, y elige el elemento de men DNS | Actualizar archivos de datos del servidor, tambin se descargarn los archivos desde la memoria al disco.

El registro de sucesos
El servidor DNS informar de los sucesos en el registro de sucesos. Esto permite que los administradores sepan cundo ha finalizado una transferencia de zona, o cundo se ha iniciado, detenido o ha ocurrido un error en el servicio DNS.

DNS y Microsoft Windows NT 4.0 35

Instalacin
El procedimiento exacto para instalar los equipos clientes individuales variar segn el sistema

El Resolver (cliente)
operativo y el software de TCP/IP que se est utilizando. Los procedimientos especficos para los clientes no se tratan en este documento, aunque se describen los parmetros de instalacin generales necesarios y su utilizacin.

El nombre del host

El nombre de host para el cliente puede ser cualquier combinacin de las letras A a la Z, los nmeros 0 al 9 y el guin (-). De forma predeterminada, en los entornos de red de Microsoft, este valor es el nombre del equipo NetBIOS, pero puede asignar un nombre de host distinto sin que esto afecte, si as lo desea, a la operacin del equipo NetBIOS. Si se usa la bsqueda de WINS con Microsoft DNS, este valor debera coincidir con el nombre de su equipo NetBIOS para mantener la coherencia. Algunos caracteres que se pueden usar para los nombres NetBIOS, especialmente el subrayado y el punto, no se pueden usar en los nombres de host DNS.

El nombre de dominio
El nombre del dominio sirve, junto con el nombre de host, para crear un nombre de dominio completo (FQDN o fully qualified domain name ) para el equipo. El FQDN es el nombre del host seguido de un punto (.) y del nombre del dominio. Por ejemplo, podra ser [Link], donde estra1 es el nombre de host y [Link] el nombre del dominio. En las consultas DNS, se usa el nombre de dominio completo.

Los servidores DNS

Muchos sistemas operativos permiten especificar varios servidores DNS en sus configuraciones. Cuando se ofrece esta posibilidad, tambin se proporciona un orden de prioridad, de tal forma que se pueda identificar un servidor preferido. Para una consulta de DNS, el sistema intenta obtener la informacin de DNS de la primera direccin IP de la lista. Si no se recibe ninguna respuesta, va al siguiente servidor de la lista, y as sucesivamente. En la mayora de los sistemas, si hay dos servidores DNS en la lista, el sistema slo comprueba el segundo servidor si no recibe respuesta del primer servidor. Si el sistema intenta comprobar un nombre de host con el primer servidor y recibe el mensaje de que no se reconoce el nombre de host, el sistema prueba con el segundo servidor DNS.

36

DNS y Microsoft Windows NT 4.0

Orden de bsqueda de Sufijo de dominio

En algunos sistemas se ofrece la opcin de orden de bsqueda de sufijo de dominio. El orden de bsqueda de sufijo de dominio especifica los sufijos de dominio DNS que se van a anexar a los nombres de host durante la resolucin de nombres. Cuando se intenta resolver un nombre de dominio completo (FQDN) de un nombre slo de host, el sistema anexar primero el nombre del dominio local. Si esto no funciona, el sistema recurrir a la lista de sufijos del dominio para crear FQDN adicionales en el orden de la lista y consultar a los servidores DNS para cada uno de ellos. A continuacin se muestra un ejemplo de una configuracin cliente de un equipo Windows NT 4.0.

DNS y Microsoft Windows NT 4.0 37

Resolucin de nombres
Los sistemas TCP/IP 3.5x de Windows NT pueden usar varios mtodos para localizar recursos NetBIOS: Cach de nombre NetBIOS Servidor de nombres NetBIOS Difusiones de subred IP Archivos LMHOSTS estticos Archivos HOSTS estticos Servidores DNS Las primeras implementaciones usaban slo cach, difusiones y archivos LMHOSTS; sin embargo, en la versin 3.5, se agreg un servidor de nombres (WINS) de NetBIOS y se realizaron modificaciones para permitir que las aplicaciones NetBIOS consultaran el espacio de nombres DNS al anexar sufijos de dominios configurables a un nombre NetBIOS. Sin embargo, la resolucin de nombres DNS se haca siempre en ltimo lugar, despus de probar con la cach NetBIOS, con el archivo LMHOSTS (si estaba activado), con WINS (si estaba activado) y con la difusin. En Windows NT 4.0, si el nombre es superior a 15 caracteres (la longitud mxima de un nombre de equipo NetBIOS en Windows NT), lo primero que se intenta es la resolucin de nombres DNS. El nombre de host se puede usar ahora en cualquiera de los programas de Windows NT (como el Explorador que se muestra a continuacin) que admitan nombres de equipo NetBIOS. En el futuro, esta funcionalidad estar tambin disponible en Windows 95.

Recuerde que el archivo \%Razdelsistema%\system32\drivers\etc\HOSTS sigue siendo til para la resolucin de nombres de host. Sin embargo, se consultar DNS antes de analizar el archivo HOSTS. Si el nombre de host DNS (superior a 16 caracteres) se pasa a un programa y hay dos transportes cargados en una estacin de trabajo (TCP y NetBEUI), slo intentar instalar la sesin el transporte TCP. Si no se usa el nombre de host y se usa el nombre NetBIOS, se probar con todos los transportes.

38

DNS y Microsoft Windows NT 4.0

En este ejemplo, tambin podra haber usado: \\[Link]\public en lugar de \\[Link]\public . Para obtener ms informacin acerca de la resolucin de nombres NetBIOS, puede consultar la hoja tcnica titulada, Microsoft Windows NT Server 3.5 - Protocolo de configuracin dinmica de host y Servicio de nombres Internet de Windows, nmero de referencia 098-56544.

En una estacin de trabajo con Windows NT, si no se encuentra un nombre de host mediante la resolucin DNS, se pasa el nombre a NetBT (NetBIOS sobre TCP/IP) para su resolucin mediante WINS, archivo LMHOSTS o difusin. Esto podra ser considerado como una caracterstica de intranets que tienen muchos servidores WEB o FTP y que desean conseguir resolucin a travs de WINS para las consultas del host. Prakash Narasimhamurthy, de Microsoft Consulting Services, ha proporcionado los grficos de flujo que se muestran en las siguientes figuras para ilustrar la resolucin de nombres para los distintos tipos de nodos.

DNS y Microsoft Windows NT 4.0 39

Nueva funcionalidad de Windows NT 4.0

40

DNS y Microsoft Windows NT 4.0

Nslookup
Probablemente, Nslookup es una de las principales herramientas de diagnstico a la hora de

El entorno general
depurar una arquitectura de sistema de nombres de dominio (DNS). Se puede usar para mostrar cualquier registro de recurso de cualquier servidor DNS, incluyendo implementaciones DNS de UNIX. NSLookup de la mayora de las otras implementaciones de DNS tambin debera funcionar en el servidor MS DNS. Es un programa de la lnea de comandos y tiene la siguiente sintaxis. nslookup [[-opcin ...] [equipo que va a buscar]] | - [servidor]

Modos
Nslookup tiene dos modos: interactivo y no interactivo. Si necesita buscar un nico dato, use el modo que no es interactivo. En el primer argumento, escriba el nombre o direccin IP del equipo en el que va a buscar. En el segundo argumento, escriba el nombre o direccin IP de un servidor de nombres DNS. Si omite el segundo argumento, se usar el servidor de nombres DNS predeterminado. Si necesita buscar ms de un dato, use el modo interactivo. Escriba un guin en el primer argumento y el nombre o direccin IP de un servidor de nombres DNS en el segundo argumento, u omita ambos argumentos y se usar el servidor de nombres DNS predeterminado.

Parmetros
-opcin ... Se puede especificar uno o ms comandos nslookup como opciones de la lnea de comandos. Para obtener una lista de los comandos, consulte Comandos de Nslookup en el archivo [Link] suministrado con Windows NT 4.0. Cada opcin consta de un guin (-) seguido inmediatamente del nombre del comando y, en algunos casos, un signo de igual (=) y luego un valor. Por ejemplo, para cambiar el tipo de consulta predeterminada a informacin del host (equipo) y el tiempo de espera inicial a 10 segundos, escribira: nslookup -querytype=hinfo -timeout=10 La longitud de la lnea de comandos no debe superar los 256 caracteres. Equipo que va a buscar Esto indica a Nslookup que busque la informacin de ese equipo mediante el servidor predeterminado actual o mediante el servidor que se especifique. Si el equipo que quiere buscar es una direccin IP y el tipo de consulta es A o PTR, se devuelve el nombre del equipo. Si el equipo que va a buscar es un nombre y no tiene un punto al final, el nombre de dominio DNS predeterminado se anexa al nombre. (Esto ltimo depende del estado de las opciones del conjunto: dominios, srchlist, defname y buscar). Para buscar un equipo que no se est en el dominio DNS actual, escriba un punto junto al nombre. Si en lugar de equipo que va buscar escribe un guin (-), la interfaz de comandos cambia al modo interactivo de nslookup. servidor

DNS y Microsoft Windows NT 4.0 41

Use este servidor como el servidor de nombres DNS. Si omite el servidor, se usar el servidor de nombres DNS predeterminado. Para obtener ms informacin acerca de Nslookup de NT, consulte el archivo [Link] que se suministra con Windows NT 4.0.

Puntos dbiles de la implementacin actual Bsqueda inversa ineficaz (NbtStat)

La integracin de DNS y de WINS no permite la bsqueda inversa eficaz de DNS. Tanto el servidor DNS como el host que se est buscando resultan involucrados cuando se solicita una bsqueda inversa para un cliente WINS, ya que el servidor DNS ejecuta una bsqueda de estado de adaptador de nodo NetBIOS para convertir esta direccin IP en un nombre. Si la actualizacin dinmica de DNS fuera una versin RFC y se utilizara en lugar de la integracin WINS, la bsqueda inversa sera ms eficaz e involucrara solamente a los servidores DNS.

Los host que no estn basados en Microsoft no se registran con WINS

Los host que no estn basados en sistemas de Microsoft no se registran en WINS y, por lo tanto, no pueden registrarse dinmicamente en DNS. Si el servidor DNS de Microsoft admitiera la actualizacin dinmica DNS verdadera, los host que no estn basados en Microsoft que admitieran DNS dinmico podran registrarse en Microsoft DNS y los host Microsoft podran registrarse dinmicamente en los DNS que no estn basados en sistemas de Microsoft que admitieran las actualizaciones dinmicas DNS estndar.

Registro WINS no es seguro

El registro WINS no es seguro y sera complicado hacer que lo fuera. El IETF est trabajando para conseguir un estndar para agregar seguridad a una actualizacin dinmica DNS. El estndar de seguridad de DNS no est programado que se incorpore al conjunto de estndares de IETF hasta 4Q96.

La integracin de DNS y de WINS no es un RFC

Aunque la actualizacin dinmica de DNS no es todava un estndar IETF, ya existen algunas implementaciones. Microsoft ha decidido esperar hasta que se estandarice con el fin de minimizar el impacto en nuestros clientes si los cambios se realizan antes de que la publicacin del estndar. Mientras que WINS se basa en estndares IETF (RFC 1001, 1002), sus races NetBIOS han tenido muy poca aceptacin por parte de IETF y de la comunidad UNIX. La integracin DNS y WINS no se basa en estndares y, por lo tanto, no se acepta.

Las API del resolver no se muestran

En la actualidad, no hay ninguna otra forma de consultar mediante programa la base de datos DNS que no sea mediante gethostbyname(). Todava no es posible hacer cosas como consultar un registro MX mediante programa al DNS.

42

DNS y Microsoft Windows NT 4.0

Uso del servidor Microsoft DNS para conectarse a Internet

Diseo de soluciones
DNS va a ser una parte importante de la arquitectura mejorada de los Servicios de directorio de la prxima revisin importante de Windows NT Server, por lo que es fundamental disear una arquitectura DNS que permita una transicin/conversin gradual.

Consideraciones sobre la seguridad

Hoy en da, hay muchas empresas que desean conectar sus redes internas a Internet para proporcionar el acceso a estos recursos externos a los empleados que lo necesiten para su trabajo. Aunque sta es una funcin muy importante, hay que disearla cuidadosamente para evitar riesgos en la proteccin de los datos al exponer la red interna a los usuarios externos a la organizacin. Una forma de proporcionar esta proteccin es mediante un servidor de seguridad ( firewall). En trminos de Internet, un servidor de seguridad (firewall) es un sistema o dispositivo que proporciona seguridad de red al permitir que solamente se realicen ciertas actividades entre las redes internas e Internet. Un sistema de servidor de seguridad puede ser muy simple o extremadamente complejo, dependiendo de los requisitos particulares de la empresa. Este documento no se ha diseado para proporcionar una descripcin exhaustiva del diseo del servidor de seguridad ( firewall) sino que slo describiremos brevemente cmo se puede usar el servidor Microsoft DNS en un entorno de servidor de seguridad. A continuacin se muestra una instalacin de conectividad Internet tpica de una empresa que usa un servidor de seguridad con dos tarjetas (es decir, proxy).

DNS y Microsoft Windows NT 4.0 43

El servidor de seguridad protege el acceso desde el exterior, al mismo tiempo que permite a los clientes de la red interna el acceso a los recursos Internet. Este diseo admite tambin servidores WWW y FTP externos. Estos servidores externos deben ser controlados de cerca y protegidos al mximo, puesto que se encuentran directamente en la red Internet sin control de acceso del tipo servidor de seguridad (firewall). El enrutador puede proporcionar algo de seguridad mediante el filtrado de paquetes, si se desea, para limitar el tipo de trfico permitido. El acceso a la red interna se controla mediante el servidor de seguridad.

44

DNS y Microsoft Windows NT 4.0

El servidor WEB interno se puede instalar exactamente igual que el servidor externo, excepto en cuanto a la seguridad, que se limita a los controles de acceso necesarios para los empleados de la empresa. Normalmente, slo aquellas personas responsables de la programacin de WEB iniciarn sesin realmente en los servidores internos para cambiar los archivos all ubicados, aunque en principio cualquiera puede tener acceso para ver las pginas Web mediante un explorador. Normalmente, los sistemas de nombres de dominio de las redes externas e internas se aslan totalmente el uno del otro. Esto impide que los clientes externos obtengan los nombres y direcciones de los recursos internos ubicados dentro del servidor de seguridad ( firewall). Lo nico que ver un usuario externo es la direccin IP de los servidores que estn proporcionando los servicios externos (es decir, ftp, www, correo, etc.).

Diseo tpico de conectividad Internet

Despus de explicar lo relativo a la seguridad, observe un diseo tpico de conectividad Internet y, ms concretamente, en la forma en la que se configuraran los servidores DNS. A continuacin se muestra un diagrama de una empresa grande prototipo que tiene varios recursos internos y externos que requieren servicios DNS.

DNS y Microsoft Windows NT 4.0 45

Hay varios elementos de este ejemplo que hay que explicar antes de comenzar la descripcin de las configuraciones de DNS. Estos elementos son: Azul dispone de un servidor DNS principal y secundario para los servicios externos que ellos mantienen (es decir, [Link] y [Link]). Tambin hay un servidor DNS secundario para su zona [Link] mantenido por su proveedor de servicios Internet por razones de redundancia (es decir, [Link]). Estos servidores de nombres tienen autoridad sobre los dominios [Link] y [Link]. Algunos servicios externos se mantienen en mltiples servidores espejo. Se utilizan mltiples servidores de correo para proporcionar conectividad de correo SMTP a [Link]. Este diseo de red utiliza el filtrado de paquetes en el enrutador, as como servidores proxy multitarjeta para implementar la seguridad. La red interna usa WINS para el registro/bsqueda de clientes y servidores Microsoft. Algunos servicios de intranet (es decir, servicios Web) se proporcionan mediante servidores Windows NT internos. Los servicios DNS de la red interna estn aislados de los servicios DNS de Internet. Por razones de claridad, la red interna se muestra como un entorno simple no enrutado. Teniendo estos detalles presentes, veamos cmo afectara esto a la arquitectura DNS. Revisaremos el proceso mental de la configuracin del servidor DNS externo y luego describiremos el servidor DNS interno.

Configuracin del servidor DNS externo

Una vez instalado el servicio DNS en los equipos con Windows NT Server (es decir, dns-servidor1 y dns-servidor2), usaremos la herramienta Administrador de DNS de Microsoft para crear una zona principal para el dominio [Link] y una zona principal de bsqueda inversa para [Link] en dns-servidor1. Esto crear un registro SOA que contenga el servidor de nombres principal [Link]. y la direccin de correo electrnico del administrador del servidor DNS Web-maestro@[Link], as como un registro NS distinto para dns-servidor1. Puesto que los restantes parmetros predeterminados de esta zona son suficientes, no los modificaremos y en el registro SOA se colocarn los valores predeterminados. En el dominio [Link] se deben crear los siguientes registros adicionales y se debe hacer con Crear registro PTR asociado activado all en donde se pueda aplicar. Hay que crear registros de servidor de nombres (NS o name server) para dns-servidor2 y [Link]. Para correo-servidor1 y correo-servidor2 hay que crear registros de correo (MX o mail exchange ). Estableceremos la preferencia de estos dos en 10 para equilibrar la carga. Adems, hay que crear registros de direccin (A) para cada uno de los equipos que se conectan directamente a la red expuesta a Internet.

46

DNS y Microsoft Windows NT 4.0

El nombre real del servidor gopher de nuestro ejemplo es [Link]. El estndar de facto para suministrar servicios en Internet es servirlos en equipos con nombres de host que se correspondan con el servicio suministrado. Para permitir que los usuarios localicen fcilmente nuestro servicio gopher al conectarse al [Link] estndar, usaremos un nombre cannico (es decir, alias) para este servidor. Para hacerlo, creamos un registro de nombre cannico (CNAME) para gopher y lo asociamos a gopher-servidor1. Puesto que hay mltiples servidores Web en espejo y servidores ftp que proporcionan servicios a los usuarios externos, es necesario tener una forma de agruparlos para que se produzca el equilibrio de carga de los servidores. Hay varias formas de hacer esto con tcnicas de 'asignacin circular'. El mtodo que usaremos aqu es la asociacin de cada servidor espejo al mismo nombre de alias. Usaremos los nombres ms conocidos de los servicios como los alias (es decir, www, ftp, etc.), lo que permitir a los usuarios localizar ms fcilmente los servicios. Para ello, creamos un registro de nombre cannico (CNAME) por cada servidor espejo con el nombre del servicio como alias y el nombre del servidor para el host. En consecuencia, cada vez que se consulte un servidor DNS determinado acerca de un nombre de servidor en particular usando su alias (es decir, [Link]), se devolver la lista de servidores usando una 'asignacin circular' con un servidor distinto cada vez el primero de la lista. Puesto que la mayora de los resolver prueban primero con la primera entrada devuelta, como ya se ha explicado en este documento, esto proporcionar equilibrio de carga entre los servidores. Una vez instalada esta zona en el servidor DNS principal, se deberan crear las zonas [Link] y [Link] en los servidores DNS secundarios. Estas zonas secundarias deberan de apuntar de nuevo al servidor DNS principal como el maestro para la transferencia de zonas.

DNS y Microsoft Windows NT 4.0 47

ste es el archivo de zona resultante para los servidores DNS externos:

;----------------------------------------------------------------------------------; ; Database file [Link] for [Link]. zone. (External DNS Server) ; Zone version: 10 ; @ IN SOA 10 3600 600 86400 3600 ) Zone NS records IN IN IN Zone records NS NS NS dns-servidor1 dns-servidor2 [Link]. ; ; ; ; ; [Link]. serial number refresh retry expire minimum TTL [Link]. (

; ; ; @ @ @ ; ; ;

@ IN MX 10 correo-servidor1 @ IN MX 10 correo-servidor2 dns-servidor1 IN A [Link] dns-servidor2 IN A [Link] ftp-servidor1 IN A [Link] ftp-servidor2 IN A [Link] gopher-servidor1 IN A [Link] correo-servidor1 IN A [Link] correo -servidor2 IN A [Link] proxy-servidor1 IN A [Link] proxy-servidor2 IN A [Link] proxy-servidor3 IN A [Link] ; www-servidor1 IN A [Link] www-servidor2 IN A [Link] www-servidor3 IN A [Link] www-servidor4 IN A [Link] ; ftp IN CNAME ftp-servidor1 ftp IN CNAME ftp-servidor2 ; gopher IN CNAME gopher-servidor1 ; www IN CNAME www-servidor1 www IN CNAME www-servidor2 www IN CNAME www-servidor3 www IN CNAME www-servidor4 ; ;-----------------------------------------------------------------------------------

48

DNS y Microsoft Windows NT 4.0

Configuracin de servidor DNS interno

Una vez instalado el servicio DNS en los equipos con Windows NT Server (es decir, dns-interno1 y dns-interno2), usamos la herramienta Administrador DNS de Microsoft para crear una zona principal para el dominio interno [Link] y una zona principal de bsqueda inversa para [Link] en dns-interno1. Esto crear un registro SOA que contiene al servidor de nombres principal [Link]. y la direccin electrnica para el administrador del servidor DNS Web-master@[Link], as como un registro NS aparte para dns-interno1. Puesto que los restantes parmetros predeterminados para la zona son suficientes, no los modificaremos y se colocarn los valores predeterminados en el registro SOA. Una vez creadas estas zonas, activaremos la bsqueda WINS en la zona [Link] e introduciremos las direcciones IP de los dos servidores WINS internos. Esto crear un registro WINS (WINS) en este archivo de zona. Tambin activaremos la bsqueda inversa WINS en la zona [Link] e introduciremos el dominio del host DNS como [Link].. Esto crear un registro de bsqueda inversa WINS (WINS-R) en este archivo de zona. En el dominio [Link] interno hay que crear los siguientes registros adicionales, y debe hacerse teniendo activado Crear registro PTR asociado all donde se pueda aplicar. Hay que crear un registro de servidor de nombres (NS) para dns-interno2. Hay que crear los registros de direccin (A) para cada uno de los equipos que se conectan directamente a la red corporativa aislada que no son clientes WINS. Puede resultar que todos los servidores de la Red corporativa reconozcan WINS y por tanto no sean necesarias entradas estticas aunque, simplemente para mostrarle cmo puede mezclar entradas estticas con WINS, definiremos estticamente los servidores proxy y los servidores DNS en el archivo de zona DNS. Tambin crearemos un registro de direccin hostlocal para la direccin local [Link]. Puesto que hay mltiples servidores espejo de Web que proporcionan servicios a los usuarios internos, usaremos la tcnica de asignacin circular mediante nombres cannicos, tal y como lo hicimos en la red externa y asociaremos estos servidores espejo a [Link]. La diferencia aqu es que no hay registros de direccin (A) asociados para los servidores Web internos (es decir, www-interno1, www-interno2, www-interno3) puesto que estos son clientes WINS y el servidor DNS consultar estas direcciones cuando lo necesite al servidor WINS.

DNS y Microsoft Windows NT 4.0 49

Una vez instalada esta zona en el servidor DNS principal, hay que crear las zonas [Link] y [Link] en el servidor DNS secundario. Estas zonas secundarias deberan apuntar

Diseo de capacidad y rendimiento

de nuevo al servidor DNS principal como el maestro para la transferencia de zonas. ste es el archivo de zona resultante para los servidores DNS internos:
;----------------------------------------------------------------------------------; ; Database file [Link] for [Link]. zone. (Internal DNS Server) ; Zone version: 12 ; @ IN SOA 12 3600 600 86400 3600 ) Zone NS records IN IN WINS lookup record IN Zone records WINS [Link] [Link] NS NS dns-interno1 dns-interno2 ; ; ; ; ; [Link]. serial number refresh retry expire minimum TTL [Link].(

; ; ; @ @ ; ; ; @ ; ; ;

dns-servidor1 IN A [Link] dns-servidor2 IN A [Link] proxy-servidor1 IN A [Link] proxy-servidor2 IN A [Link] proxy-servidor3 IN A [Link] hostlocal IN A [Link] ; corpweb IN CNAME www-interno1 corpweb IN CNAME www-interno2 corpweb IN CNAME www-interno3 ; ;-----------------------------------------------------------------------------------

Estadsticas
Microsoft DNS realiza el seguimiento de un nmero determinado de estadsticas de consulta. Estas estadsticas pueden verse mediante el Administrador de DNS. Estas estadsticas son acumulativas desde la ltima vez que se inici el servicio DNS. Resultan de utilidad al comparar cargas relativas entre dos servidores DNS para determinar cuntas peticiones est atendiendo cada uno. Si un servidor est ms ocupado que el otro, puede que deba tener en cuenta el cambiar la arquitectura DNS actual o volver a configurar algunos de los resolver. En la siguiente figura se muestran las estadsticas del servidor \\B20TCP:

50

DNS y Microsoft Windows NT 4.0

Por motivos de diseo de capacidad, en un servidor DNS dedicado, es importante iniciar las estadsticas peridicamente y observar el crecimiento de las consultas con respecto a la memoria, el disco, la red y el rendimiento de la CPU del servidor. Puesto que las estadsticas se guardan desde el reinicio del servicio DNS, probablemente querr anotar la fecha y hora en la que se inici el servicio DNS (esta informacin se puede obtener del Registro de sucesos). Ahora que ya sabe cuntas consultas por segundo est contestando el servidor DNS, Cuntas consultas son demasiadas? La respuesta depende de: En qu hardware se est ejecutando el servidor? El equipo est dedicado a DNS o se est usando para otros cometidos? Cul es el ancho de banda actual de la red?

DNS y Microsoft Windows NT 4.0 51

Si cree que su servidor DNS no est respondiendo tan rpido como debera, entonces debera mirar primero los siguientes contadores de control de rendimiento del servidor. Si se alcanza alguno de los lmites, entonces el sistema tiene un problema de rendimiento y tendr que realizar una investigacin ms profunda: Objeto procesador memoria disco fsico Contador % tiempo procesador bytes disponibles % tiempo de disco Lmite > 80% < 1MByte > 67% slo est disponible si inicia los contadores desde la lnea de comandos con diskperf -y y reinicia el sistema slo disponible si est instalado el Agente de Monitor de red Notas

segmento de red

% utilizacin de red

> 40%

Si la memoria es un problema, entonces debera comprobar el objeto proceso, instancia DNS, contador Bytes privados. Si este contador es muy alto, entonces el servicio DNS es lo que est haciendo que contador de bytes de memoria disponible sea bajo. Si es as, debera agregar ms memoria, o investigar qu registros estn activos actualmente en la cach de DNS y encontrar el TTL asociado a cada uno. Si lo que supone un problema es el procesador, entonces debera comprobar el objeto procesador, la instancia DNS, el contador %tiempo de procesador. Si ste es > 80 % entonces quizs debera considerar la ejecucin del servidor DNS en un servidor ms potente. Si ste no es alto, y el %tiempo de procesador sigue siendo alto, mire los dems procesos y determine cul est requiriendo gran cantidad del tiempo de la CPU. En un servidor DNS, el %tiempo de disco del disco fsico no debera suponer ningn problema, a menos que el sistema haya iniciado la paginacin por falta de memoria. Si es as, necesitara tratar esto como un problema de memoria. Si la utilizacin de la red supone un problema, tiene que averiguar si es el servidor DNS el que est provocando todo el trfico o si es cualquier otro servidor del mismo segmento. Para ello, use el poderoso programa Monitor de red que se suministra con SMS (esto le permite capturar todo el trfico hacia cualquier direccin especfica de red y desde dicha direccin) o el programa de conjunto de caractersticas menos potentes que se suministra con Windows NT 4.0 (sta solo le permite el seguimiento del trfico hacia el servidor local y a partir de ste).

52

DNS y Microsoft Windows NT 4.0

Equilibrio de la carga DNS

Si tiene mltiples servidores DNS, como por ejemplo un principal y dos secundarios, entonces probablemente querr configurar algunos de los clientes para que apunten a un DNS secundario y a otros clientes para que apunten a otro DNS secundario.

La transferencia de zona
Una transferencia de zona no es ms que una copia de un archivo. El contenido completo de la base de datos se copia desde el principal (o maestro) al secundario cada vez que el principal (o maestro) le notifica que ha habido un cambio. Cuando se inicia un servicio DNS de un secundario o ha terminado el intervalo de actualizacin de su registro SOA (de forma predeterminada, ste est establecido a 3 horas), consultar a su principal para determinar el nmero de serie del registro SOA. Si es distinto del de su base de datos local, pedir una transferencia de zona. La primera trama es la peticin del registro SOA del principal.
secondary primary DNS 0x4000:Std Qry for [Link] of type SOA on class INET

+ FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x7701; Proto = UDP; Len: 57 + UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 37 (0x25) DNS: 0x4000:Std Qry for [Link] of type SOA on class INET addr. DNS: Query Identifier = 16384 (0x4000) + DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type SOA on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Start of zone of authority DNS: Question Class = Internet address class

La siguiente trama es el registro SOA que se devuelve.

primary secondary DNS 0x4000:Std Qry Resp. for [Link] of type SOA on class INET

+ FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x3617; Proto = UDP; Len: 149 + UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 129 (0x81) DNS: 0x4000:Std Qry Resp. for [Link] of type SOA on class INET addr. DNS: Query Identifier = 16384 (0x4000) + DNS: DNS Flags = Response, OpCode - Std Qry, AA RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type SOA on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Start of zone of authority DNS: Question Class = Internet address class DNS: Answer section: [Link] of type SOA on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Start of zone of authority DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 80 (0x50) DNS: Primary Name Server: [Link] DNS: Responsible Authorative Mailbox: [Link] DNS: Version number = 19 (0x13) DNS: Update Interval = 3600 (0xE10) DNS: Retry interval = 600 (0x258) DNS: Expiration Limit = 86400 (0x15180) DNS: Minimum TTL = 3600 (0xE10)

DNS y Microsoft Windows NT 4.0 53

La siguiente trama es la peticin de transferencia de zona.

secondary primary DNS 0x0:Std Qry for [Link] of type Req. for zn Xfer

+ FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x7A01; Proto = TCP; Len: 71 + TCP: .AP..., len: 31, seq: 365696, ack: 35871892, win: 8760, src: 1072 dst: 53 DNS: 0x0:Std Qry for [Link] of type Req. for zn Xfer on class INET addr. DNS: TCP Length = 29 (0x1D) DNS: Query Identifier = 0 (0x0) + DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Req. for zn Xfer on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Request for zone transfer DNS: Question Class = Internet address class

La siguiente trama contiene la base de datos que devuelve el maestro.

primary secondary DNS 0x0:Std Qry Resp. for [Link] of type SOA

+ FRAME: Base frame properties + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol + IP: ID = 0x3817; Proto = TCP; Len: 163 + TCP: .AP..., len: 123, seq: 35871892, ack: 365727, win: 8729, src: 53 dst: 1072 DNS: 0x0:Std Qry Resp. for [Link] of type SOA on class INET addr. DNS: TCP Length = 121 (0x79) DNS: Query Identifier = 0 (0x0) + DNS: DNS Flags = Response, OpCode - Std Qry, RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Req. for zn Xfer on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Request for zone transfer DNS: Question Class = Internet address class DNS: Answer section: of type SOA on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Start of zone of authority DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 80 (0x50) DNS: Primary Name Server: [Link] DNS: Responsible Authorative Mailbox: [Link] DNS: Version number = 19 (0x13) DNS: Update Interval = 3600 (0xE10) DNS: Retry interval = 600 (0x258) DNS: Expiration Limit = 86400 (0x15180) DNS: Minimum TTL = 3600 (0xE10)

54

DNS y Microsoft Windows NT 4.0

00000000 00000010 00000020 00000030 00000040

00 02 64 22 00

A0 AB CC 19 00

24 39 00 58 00

63 17 35 A8 00

AB 40 04 00 07

22 00 30 00 73

00 80 02 00 63

80 06 23 3D 6F

C7 B9 5D 00 74

A9 C6 0F 00 74

EC 9D 00 80 73

0F 37 05 80 75

08 66 94 00 03

00 34 9F 01 63

45 9D 50 00 6F

00 37 18 01 6D

..$c."........E. ..9.@......7f4.7 d..5.0.#].....P. ".X....=........ .....[Link]

Decisiones DNS
00000050 00000060 00000070 00000080 00000090 000000A0 000000B0 000000C0 000000D0 000000E0 000000F0 00000100 00000110 00000120 00000130 00000140 00000150 00000160 00000170 00000180 00000190 000001A0 000001B0 000001C0 000001D0 000001E0 000001F0 00000200 00000210 00000220 00000230 00000240 00000250 00000260 00000270 00000280 00000290 000002A0 000002B0 00 14 00 00 00 09 73 01 6D 00 73 80 73 6E 63 77 40 6F 6F 6F C1 73 08 00 01 63 2D 66 07 01 00 00 74 06 75 0D 63 03 58 00 00 9D 00 FC 73 75 00 00 1A 63 80 75 77 6F 6F 00 74 70 C0 00 63 67 00 00 6F 37 34 73 0C 01 00 74 00 2D 41 6F 63 00 FC 00 37 00 00 63 03 00 00 0C 6F 00 03 6F 70 07 00 74 70 0C 36 6F 6F 00 01 6D C0 00 63 73 00 80 73 01 37 64 74 6F 01 00 00 66 07 01 6F 63 00 FC 73 74 01 63 C0 70 73 80 73 65 00 00 74 6F 00 00 00 0C 3A 6F 63 01 80 75 00 07 6D 74 6D 51 01 00 34 73 C0 74 6F 00 00 63 74 00 6F 0C 65 63 80 75 72 01 00 74 6F 04 00 00 00 00 74 6F 00 00 03 00 73 69 73 00 80 C0 05 00 63 0C 74 6D 07 01 6F 73 01 6D 00 72 6F 00 03 68 00 80 73 6F 9D 00 FC 01 00 74 74 00 01 63 00 63 6E 75 00 00 0C 00 40 6F 00 73 00 73 C0 74 75 00 00 02 68 74 01 63 65 01 80 75 6F 37 00 00 00 80 73 74 0E 00 6F 00 6F 69 2D 00 00 FF 00 00 74 02 75 00 63 0C 74 03 00 00 00 65 74 00 6F 61 00 00 03 6F 64 07 01 01 80 75 73 10 01 6D 00 74 73 37 00 0E 01 00 00 74 00 2D 43 6F 00 73 63 00 FC 01 61 73 01 6D 64 00 01 63 64 64 73 09 00 00 03 75 00 00 00 50 74 74 07 13 10 00 58 80 73 01 37 00 74 02 75 6F 00 00 00 64 75 00 00 07 0E 00 6F C0 00 63 73 00 01 63 5F 04 00 00 09 73 72 73 00 01 02 80 75 00 07 00 74 00 5F 6D 07 01 00 07 03 00 00 67 10 01 6D 0C 37 6F 63 0E 00 6F 6E 9D 00 FC 73 75 61 63 00 00 00 00 03 00 73 80 73 01 6E 00 73 07 0E 67 63 00 FC 6C 00 00 00 00 00 74 6F 10 01 6D 74 37 00 00 63 03 74 6F 0E 00 00 01 63 0E 63 80 75 00 74 00 63 67 10 6C 6F 00 00 65 04 00 00 01 00 74 74 00 00 00 34 64 07 01 6F 63 6F 74 10 0E 01 00 6F 10 6F 00 03 00 34 51 6F 6C 00 65 6D 07 01 6E 9D 00 FC 00 80 73 74 04 00 00 30 CC 73 C0 74 6F 72 74 00 10 00 01 6D 00 74 01 63 0E 30 00 74 65 20 6E 00 73 0A 6E 37 00 00 01 80 75 73 9D 00 FC C0 00 63 0C 74 6D 09 73 00 00 00 00 00 17 74 00 6F 10 07 00 74 6E 0A 6E 00 63 63 77 6A 07 01 00 00 03 75 37 00 00 0C 79 6F 00 73 00 73 75 02 ................ .........X...... ..7f4.@......... ....[Link]. ................ .[Link] [Link]..C....... ......[Link] m............... ...scottsu_nt40. [Link]..Q.. ...........scott [Link]......glen nwo............. [Link] [Link].. @.............sc [Link]......c [Link] o.............7j ..6............. [Link]..... .gooooood....... ......7dd.7..... ........scottsu. com......scottsu -7.............7 f4.:............ .[Link].... ..scottsu_nt40.. ...........7d..y .............sco [Link]........ ........[Link] [Link]. .Administrator.s [Link] .com............ X..Q.....

Memoria consumida por los registros DNS

Los registros RR de DNS son muy pequeos, de 16 bytes aproximadamente. Los registros del dominio son muy pequeos, tienen alrededor de 56 bytes. Si carga una gran cantidad de registros en el servidor puede que no aprecie ningn movimiento en el contador Bytes privados del proceso DNS porque el servidor DNS asigna la memoria en bloques. La forma en la que DNS usa la cach es otro asunto. La memoria virtual (paginable) se asigna a las entradas de la cach segn se necesitan (recuerde, al mismo tiempo que un servidor DNS lleva a cabo una resolucin, almacena en la cach una copia de los datos para el TTL de esos datos). Si el servidor necesita ms memoria, esta memoria proceder del archivo de paginacin (que normalmente es muy lento).

Cuando disee una arquitectura DNS, es importante que se plantee unas cuantas preguntas acerca de las infraestructuras presentes y futuras. Es posible que las siguientes preguntas le ayudarn a desarrollar un esqueleto de DNS adecuado para su empresa.

DNS y Microsoft Windows NT 4.0 55

Cuntos dominios necesito?

Esta es sin duda la pregunta ms importante que tendr que contestar! Cuando se disea una arquitectura DNS para la red de una empresa, hay que tener en cuenta dos vas diferentes. La primera opcin es la ms fcil: cree un dominio DNS para toda la empresa (por ejemplo [Link]). Esto significa que tendra un servidor DNS principal y uno o ms servidores DNS secundarios. Esta opcin tiene tambin algunas desventajas. La primera es que el DNS principal puede tener problemas a la hora de mantener el ritmo de consulta de todos los secundarios. Para solucionar este problema puede, por ejemplo, aumentar el intervalo de actualizacin del secundario, hacer que algunos de los secundarios se carguen a partir de otros secundarios (es decir, mltiples maestros DNS) o crear algunos servidores de almacenamiento temporal (lo que le evita el tiempo adicional de una transferencia de zona. Advertencia: slo son tiles cuando han generado su cach). Si elige este enfoque y ms adelante decide volver a disearlo, siempre se puede dividir. La segunda opcin es la ms adecuada para las grandes instalaciones de red que abarcan mltiples sitios (sta es la opcin que examinaremos ms detalladamente en el resto del documento). En este diseo, tendra ms de un dominio DNS. La arquitectura constara de un dominio raz (con un servidor DNS principal y uno o ms servidores DNS secundarios) y con uno o ms subdominios (cada uno con un servidor DNS principal y un servidor DNS secundario como mnimo). Un ejemplo de los subdominios podra ser [Link] y [Link]. La razn para tal diseo es bastante evidente. Una arquitectura de red suele dividir un dominio DNS corporativo en mltiples dominios DNS para distribuir la administracin de las partes del dominio en varias entidades dentro de la organizacin o para activar mltiples archivos de zonas puesto que slo se pueden crear archivos de zona a nivel de dominio. Otra razn menos evidente puede ser que permite la afiliacin organizativa de sus sistemas. Si elige esta va, entonces la estructura de su dominio debera ser un reflejo de la estructura de su organizacin, especialmente de la estructura de soporte de sus empresas. En cualquier caso, tiene que determinar cuntos dominios necesita su empresa.

56

DNS y Microsoft Windows NT 4.0

Este es un ejemplo de una configuracin de ese tipo, en el que se muestran los servidores DNS y los archivos de base de datos de zona de cada uno:

Desde el punto de vista de una futura migracin, es recomendable la creacin de un dominio DNS por cada dominio Windows NT que tenga en la actualidad en su empresa.

Puede que ahora no le parezca muy til, pero pensando en una migracin ligera a la siguiente revisin importante de Windows NT este hecho podra ser importante. La siguiente revisin importante de Windows NT estar firmemente ligada a la estructura DNS. Consulte la seccin Futuro de este documento para obtener ms informacin.

DNS y Microsoft Windows NT 4.0 57

En la siguiente figura se intenta mostrar la apariencia futura de un nombre, aunque tenga en cuenta que podr seguir usando nombres amigables, como por ejemplo Scottsu@[Link].

Para obtener una visin general sobre cmo podra coincidir un dominio Windows NT con un dominio DNS, consulte la siguiente figura. Tiene un dominio de mltiples maestros con 2 maestros en Granada y Toledo, y 6 recursos, U100 a U202.

58

DNS y Microsoft Windows NT 4.0

Configuraciones de ejemplo

Para el diseo del dominio anterior podra tener 9 dominios DNS, [Link], [Link], [Link], [Link], [Link], [Link], [Link], [Link] y [Link].

La mayora de los diseos de dominios de empresas se puede identificar con uno de los siguientes modelos: el modelo de dominio simple, el modelo de dominio maestro, el modelo de mltiples dominios maestros o el modelo de dominio de confianza total. Para obtener ms informacin acerca de estos modelos, consulte el manual de administracin de Windows NT. En esta seccin se describen dos de estos modelos, el modelo de confianza total y el modelo de mltiples dominios maestros. Nos fijaremos en los modelos antes y despus de DNS. Esperamos que esto le permita entender cmo implementar DNS en su propio entorno.

Ejemplos de confianza total Antes de DNS

Empecemos con el siguiente diseo de dominio (sin DNS) y determinemos el mejor enfoque para una arquitectura de diseo DNS. A continuacin se ofrece un ejemplo de un modelo de dominio de confianza total. Hay 2 dominios Granada y Toledo. Supongamos lo siguiente:
DNS y Microsoft Windows NT 4.0 59

Hay un centro de datos en Toledo y Granada con un vnculo de alta velocidad entre ambos centros. Cada centro de datos tiene un gran nmero sitios remotos (500 cada uno con 20 usuarios) que soporta a travs de vnculos directos de 38KB conectados al centro de datos adecuado (en el diagrama slo se muestran 2). Cada centro de datos tiene el controlador principal de dominio (PDC) y servidor WINS que dan soporte a las ubicaciones remotas. Cada ubicacin remota tiene, como mnimo, un controlador de dominio de reserva (BDC) de Windows NT que obtiene su base de datos de administracin de cuentas de seguridad (SAM) de su PDC respectivo del centro de datos. Esto significa que la duplicacin de cuentas de usuario se produce sobre el vnculo lento (38K), por lo que en la base de datos hay pocas cuentas de usuarios y la caducidad de la contrasea est desactivada. En este diseo se ha utilizado un modelo de Confianza total porque slo hay un servidor por ubicacin remota y haba 20 usuarios por ubicacin. Si existiera un diseo de dominio maestro o de mltiples maestros, se requeriran 2 servidores. Si se ha utilizado un dominio, la base de datos de cuentas de usuarios hubiera sido demasiado grande. No se ha considerado la posibilidad de crear un dominio en cada ubicacin porque el total de la red corporativa de esta empresa consta de 1000 sitios remotos.

60

DNS y Microsoft Windows NT 4.0

Los BDC remotos contienen una entrada #PRE (cargas previas de entradas permanentes en la cach NetBIOS; si desea ver la cach escriba nbtstat -c) para todos los controladores principales de dominio de su archivo LMHOSTS (ej. [Link] TOLEDO_PDC #PRE #DOM:TOLEDO). Esto es importante porque cada BDC remoto necesita una instalacin de sesin segura entre su PDC respectivo y un PDC o BDC de todos los dominios en los que se confa. Teniendo en cuenta el enlace lento a cada una de las ubicaciones remotas y el enlace rpido entre los centros de datos, parece que tiene ms sentido tener la instalacin de sesin segura entre los BDC locales y el PDC de los dems dominios en los que se confa. Cada sitio remoto cuenta con un nmero de estaciones de trabajo clientes TCP/IP (en nuestro diagrama slo mostramos 2) Mnode (primero difunde y luego comprueba el servidor WINS) en la misma LAN que el servidor(es) con Windows NT Hnode local (comprueba la resolucin de nombres en el servidor WINS antes de la difusin).

DNS y Microsoft Windows NT 4.0 61

A la hora de disear una solucin, es importante considerar el flujo de trfico de establecer sesin y de validacin de inicio de sesin. No querr disear una solucin que impida que un cliente pueda entrar en contacto con su servidor local si el vnculo entre la ubicacin remota y su centro de datos se hubiera perdido.

En nuestro ejemplo, la validacin de inicio de sesin se produce a nivel local entre los clientes y los servidores locales. El establecimiento de sesin y la resolucin de nombres en servidores locales se producir tambin a nivel local porque los clientes se establecen como clientes TCPIP Mnode. El establecimiento de sesin y la resolucin de nombres entre un cliente de una ubicacin y un servidor de otra ubicacin remota tomar una ruta muy distinta e incluir tanto al servidor WINS del centro de datos como a los PDC de dominio de clientes. En el ejemplo (observe que en el ejemplo se han eliminado algunos dispositivos para simplificar la visin del diagrama), el equipo NT Workstation de la ubicacin 200 del dominio Toledo se conecta al servidor \\BDC100 de la ubicacin 100 del dominio Granada. El cliente se pone en contacto primero con el servidor WINS de su centro de datos para obtener la direccin IP del servidor \\BDC100 (1 y 2). Luego intenta establecer una sesin en el servidor \\BDC100 (3). El servidor \\BDC100, a su vez, usa su sesin segura en los PDC clientes por motivos de autentificacin de paso a travs (4 y 5). Si se comprueba la seguridad, se permitir que el cliente establezca la sesin y contine (6). En este ejemplo, hay 3 puntos fsicos de fallo, el vnculo entre la ubicacin 200 y el centro de datos de Toledo, el vnculo entre el centro de Toledo y el centro de datos de Granada, y el vnculo entre la ubicacin 100 y el centro de datos de Granada.

62

DNS y Microsoft Windows NT 4.0

Despus de DNS
Ahora que ya entiende la arquitectura actual, Cmo diseara una implementacin DNS de Windows NT 4.0? sta es una de las soluciones posibles. En el siguiente diseo hay 4 zonas, 4 dominios ( com, [Link], [Link] y [Link]) y un servidor DNS en cada ubicacin remota.

A continuacin se ofrecen ms detalles acerca del diseo: Los servidores DNS que contienen los archivos de zona [Link] y [Link] estn ubicados en sus respectivos centros de datos y el servidor DNS que contiene el archivo de zona [Link] est ubicado en uno u de los dos centros de datos, dependiendo del que tenga el mayor trfico de establecimiento de sesin de ubicacin remota del lado cliente. Cada zona DNS debera tener tambin un registro WINS que apunte a su respectivo servidor WINS. Tambin hay un servidor DNS slo cach en cada una de las ubicaciones remotas de la misma zona. Puesto que haba un servidor ubicado en el emplazamiento remoto, all se puso tambin un servidor DNS. Debido a la lentitud del vnculo, lo ms lgico sera que este servidor fuera de slo cach. Si no hubiera servidores en la ubicacin remota no sera realmente necesario un DNS; sin embargo, cada caso es distinto y la resolucin rpida de nombre a direccin IP es una decisin comercial que tiene que ver con el coste de agregar otro servidor, frente al coste de una resolucin de nombres lenta. En este caso, [Link] y [Link] van a ser dominios en el servidor raz de los centros de datos. Uno de los servidores raz, probablemente el de Toledo, albergar tambin los dominios com y azul. Cada uno de los servidores de almacenamiento temporal de las ubicaciones remotas tendrn estos servidores enumerados en su archivo de cach. Debera configurarse la bsqueda WINS DNS en los servidores DNS de cada centro de datos. Puede que quiera tener en consideracin la adicin de un secundario para cada principal ubicado en el centro de datos para funciones de tolerancia a fallos. Puesto que en las ubicaciones remotas no hay servidores secundarios, no hay razn para agregarlos a la lista de notificacin. Sin embargo, los servidores secundarios de los centros de datos deberan encontrarse en la lista de notificacin.
DNS y Microsoft Windows NT 4.0 63

Con este diseo, un cliente de una ubicacin remota puede ahora establecer una sesin mediante el nombre de HOST en lugar del nombre de NetBIOS. Por ejemplo, en lugar de escribir Net use * \\BDC100\pblico puede escribir Net use * \\[Link]\pblico Sigamos la ruta del trfico si el cliente decide conectarse a travs del mecanismo de nombre de HOST:

El cliente se pone en contacto con su servidor DNS local con una consulta recursiva (1). El servidor DNS de almacenamiento temporal [Link] comprueba la cach de su memoria local; si la direccin IP de [Link] no se encuentra en la cach, el servidor DNS [Link] comprueba su archivo CACHE y enva una consulta iterativa a su servidor de dominio RAZ (es decir, [Link]) (2). El servidor [Link] responde (3) e indica a [Link] que se ponga en contacto con [Link] (4). Cuando [Link] se pone en contacto con [Link], el servidor DNS [Link] comprobar el servidor WINS (5) definido en su registro WINS (6) y el servidor [Link] responde con la direccin IP (7) y la consulta de nombre dirigida y el establecimiento de la sesin pueden continuar (8,9,10,11 y 12). Si las direcciones IP no estuvieran almacenadas en la cach, se necesitaran 8 tramas para la resolucin de nombres de la direccin IP (en comparacin con las 2 tramas del diseo WINS).

64

DNS y Microsoft Windows NT 4.0

Si el servidor DNS [Link] estuviera configurado como de reenvo la peticin a [Link] habra sido tambin iterativa. Sin embargo, si el servidor DNS [Link] hubiera sido configurado como un servidor esclavo, la peticin a [Link] hubiera sido recursiva.

En cuanto se hayan implementado el DNS dinmico y los Servicios de directorio mejorados, se podrn eliminar los servidores WINS de esta empresa y se podr desactivar NetBIOS. A partir de este punto, DNS se utilizar como ndice del directorio para buscar objetos de equipos, como, por ejemplo, controladores de equipos y de dominios.

Ejemplo de mltiples maestros

En la siguiente seccin se explica un modelo de mltiples dominios maestros de Windows NT 4.0 muy simple y bien construido y se muestra cmo implementar DNS dentro de ese entorno en pro de una conversin segura a las futuras versiones de Windows NT.

Antes de DNS
ste es el diseo tpico de mltiples maestros con dos dominios maestros y 6 dominios de recursos:

Vamos a usar la estructura de dominio Granada y Toledo y a suponer lo siguiente: Hay un centro de datos en Toledo y en Granada con un vnculo de alta velocidad entre ambos centros de datos (algo parecido a T1). Cada centro de datos tiene un nmero determinado de sitios remotos a los que dan servicio mediante vnculos de 512KB (en el diagrama slo se muestran 2, uno para la ubicacin 100 y otro para la ubicacin 200). Cada centro de datos tiene el controlador principal de dominio (PDC) de los dominios maestros del centro de datos, un servidor WINS y un controlador de dominio de reserva (BDC) para el otro dominio maestro. Cada sitio remoto tiene un controlador de dominio de reserva (BDC) con Windows NT para cada dominio maestro (dominio de cuentas) y un PDC (y un nmero indeterminado de BDC) para el dominio de recursos (sin cuentas de usuarios definidas).

DNS y Microsoft Windows NT 4.0 65

Hay un servidor WINS, que es un compaero de insercin-extraccin del servidor WINS del centro de datos respectivo, en cada ubicacin remota. Asimismo, los servidores WINS de los centros de datos son compaeros de insercin-extraccin los unos con los otros. Todos los clientes y servidores son Hnode debido al servidor WINS local. Todas las estaciones de trabajo con Windows NT de los dominios de recursos tienen sus cuentas de equipo en sus respectivos dominios de recursos, sin embargo, los usuarios inician sesin en los dominios maestros. Un enrutador separa todos los clientes de los servidores en las ubicaciones remotas. La siguiente figura muestra el diseo actual:

Fijmonos en el flujo de trfico para la validacin de inicio de sesin y la resolucin de nombres del establecimiento de sesin. En la mayora de las situaciones de dominios de mltiples maestros, la cuenta del equipo cliente Windows NT existe en el dominio de recursos y el usuario inicia sesin en el dominio maestro. Toda la validacin de inicio de sesin se har localmente dentro del sitio. Un cliente Windows NT Workstation consulta al servidor WINS local, una vez iniciada la sesin, acerca de la lista de BDC (mediante consulta de nombres para DOMINIO <1C>). El servidor WINS responder con una lista de hasta 25 BDC (la lista contiene el PDC y todos los BDC del dominio maestro registrados con el mismo, as como otros que se duplicaron para l). El cliente enva entonces una peticin a cada servidor de la lista y utiliza el primer servidor que le responde (que generalmente ser el BDC del dominio maestro local) como su servidor con el que establece un canal seguro y que usa para realizar la validacin de inicio de sesin.

66

DNS y Microsoft Windows NT 4.0

El establecimiento de sesin remota desde un cliente Windows NT en un dominio de recursos a un servidor de otro dominio de recursos se realiza como se indica en el siguiente diagrama.

El cliente NT Workstation consultar en el servidor WINS la direccin del servidor en el dominio con el que desea ponerse en contacto (1). El servidor WINS contestar con la direccin (2) porque previamente se haba duplicado para l. La estacin de trabajo Windows NT se pondr en contacto directamente con el servidor (3). Ese servidor ver que la peticin de establecimiento de sesin procede de un usuario de un dominio maestro en el que se confa y usar su canal protegido a un BDC o PDC de dominio en el que se confa para comprobar las credenciales (5) y, finalmente, el servidor permitir que el cliente se conecte o rechazar la peticin (6).

Despus de DNS
Ahora que ya entiende la arquitectura actual: cmo diseara una implementacin DNS de Windows NT 4.0? La primera cosa que hay que decidir es la estructura de los dominios DNS. Sabemos que, pensando en futuras migraciones, los dominios DNS deberan ser iguales a los dominios de Windows NT 4.0. La primera y ms importante pregunta ya est contestada, es decir, cuntos dominios necesitamos?. La respuesta es uno por cada dominio de Windows NT: diez. La segunda pregunta es: cmo deben asignarse los nombres de dominio?. Por ejemplo, deberamos tener [Link] o [Link]? Todo diseo tiene que ser simple! Esto, en nuestro caso, significa mantener el nombre lo ms corto posible. Esta segunda pregunta tiene una segunda parte: de qu dominio DNS deberan formar parte los clientes y los servidores?. En la situacin de Mltiples maestros, lo ms lgico es poner todas las estaciones de trabajo dentro de un dominio DNS llamado [Link] y [Link] etc., y luego poner todos los servidores dentro de un dominio llamado [Link] y [Link]. (Esto puede que requiera cambios en la configuracin TCP/IP de cada cliente). As se permitir una conversin fcil a DNS dinmico y a los Servicios extendidos de directorio. La tercera pregunta es: cuntos servidores sern necesarios para mantener esto?. Habr 10 dominios DNS (los 8 previstos + [Link] y com) y 8 servidores DNS, de la misma forma que hay 8 dominios Windows NT y controladores de dominio (los PDC y BDC). Esto requiere que el servicio del servidor DNS se encuentre en ejecucin en cada una de las ubicaciones. El servicio puede ejecutarse en el PDC o BDC existente dentro de la ubicacin remota, suponiendo que haya suficiente capacidad para ello. Los servidores DNS de los emplazamientos que albergan los dominios de recurso sern principales para sus dominios de nombres de recursos de Windows NT, como, por ejemplo, L100. [Link], y secundarios para sus respectivos dominios maestros Windows NT, como, por ejemplo, [Link].

DNS y Microsoft Windows NT 4.0 67

Despus de todo lo expuesto anteriormente, la jerarqua de dominios DNS podra parecerse a lo siguiente:

Con este diseo, un cliente de una ubicacin remota puede establecer ahora una sesin mediante nombre de HOST, en lugar de usar el nombre NetBIOS. Por ejemplo, en lugar de escribir Net use * \\WKS100\pblico podra escribir Net use * \\[Link]\ pblico Si el cliente decide conectarse a travs del mecanismo de nombre de HOST, si sigue la ruta del trfico y la compara con la ruta a travs de WINS (observe que en el ejemplo se han eliminado algunos de los dispositivos para hacer que el diagrama sea ms fcil de ver).

68

DNS y Microsoft Windows NT 4.0

El cliente se pone en contacto con su servidor local DNS con una consulta recursiva (1) para [Link]. El servidor local DNS comprueba la cach de su memoria local y, si la direccin IP de [Link] no se encuentra en la cach, comprueba su archivo CACH y enva una consulta iterativa a su servidor RAZ de dominio (es decir, [Link]) (2). El servidor [Link] responder (3) indicando al servidor local DNS que se ponga en contacto con [Link] (4). [Link] comprobar el servidor WINS (5 y 6) (el servidor DNS se pregunta a s mismo, Yo debera tener la direccin IP del host [Link] porque tengo autoridad sobre el dominio [Link], pero no la tengo, con lo cual, compruebe WINS) definido en su registro WINS y responder con la direccin IP (8), con lo que la consulta dirigida de nombre y el establecimiento de sesin pueden continuar (9,10,11,12). Si las direcciones IP no estuvieran en la cach, seran necesarias 8 tramas para la resolucin de nombres de la direccin IP (en comparacin con las 2 tramas del diseo WINS).

Ambas zonas del servidor DNS de la ubicacin remota deberan apuntar al mismo servidor local WINS.

El servidor local DNS que tiene autoridad sobre [Link] no se puso en contacto con su servidor local WINS porque el nombre DNS que se peda no era un nombre secundario directo de su dominio DNS [Link]. Slo era un nombre secundario directo de un servidor DNS que tena autoridad sobre [Link] .

DNS y Microsoft Windows NT 4.0 69

Un cliente de una ubicacin remota tambin puede establecer una sesin con un servidor remoto a travs del nombre de HOST, en lugar de hacerlo con el nombre NetBIOS. Por ejemplo, en vez de escribir Net use * \\PDC100\pblico podra escribir Net use * \\[Link]\pblico Si el cliente decide conectarse a travs del mecanismo de nombre de HOST, sigamos la ruta del trfico y comparmosla con la ruta a travs de WINS (observe que, en el ejemplo, se han eliminado algunos de los dispositivos para hacer que el diagrama sea ms claro).

70

DNS y Microsoft Windows NT 4.0

El cliente se pone en contacto con su servidor local DNS con una consulta recursiva (1) para [Link]. El servidor local DNS comprueba la cach de su memoria local y, si la direccin IP de [Link] no est en la cach, el servidor local DNS comprueba su archivo CACH y enva una consulta iterativa al servidor RAZ de su domino (es decir, [Link]) (2). El servidor [Link] responder (3) e indicar al servidor local DNS que se ponga en contacto con [Link] (4). Cuando el servidor DNS local se ponga en contacto con [Link], el DNS [Link] comprobar el servidor WINS (5 y 6) (el servidor DNS se preguntar, Debera tener la direccin IP de [Link] porque tengo autoridad sobre el dominio [Link], pero no la tengo, con lo cual, compruebe WINS) definido en su registro WINS y responde con la direccin IP (7). A continuacin, el DNS local devuelve esa direccin al cliente (8), con lo que la consulta de nombre dirigida y el establecimiento de sesin pueden continuar (9,10,11,12). Si las direcciones IP no estuvieran en la cach, seran necesarias 8 tramas para la resolucin de nombres de la direccin IP (en comparacin con las 2 tramas en el diseo WINS).

El servidor local DNS no se puso en contacto con su servidor local WINS porque el nombre DNS que se peda no era un nombre secundario directo de un dominio DNS [Link] o [Link], sino que slo fue un nombre secundario directo de un servidor DNS que tena autoridad sobre [Link] . En cuanto el DNS dinmico y los Servicios extendidos de directorio se hagan realidad, se pueden eliminar los servidores WINS de esta empresa y se puede apagar NetBIOS. A partir de este punto, DNS servir de ndice del directorio para buscar objetos de equipos, como, por ejemplo, controladores de equipos y de dominio. Puede parecer que hay ms puntos de error en la resolucin de nombres (8 tramas mediante DNS frente a 2 tramas mediante WINS), sin embargo, con esta arquitectura habr un duplicacin de DNS dinmica menor que la duplicacin de WINS de hoy en da, y el espacio plano de nombres de 16 caracteres NetBIOS ya habr pasado a la Historia.

DNS y Microsoft Windows NT 4.0 71

Nuevos estndares Introduccin

El futuro
DNS dinmico , IPv6, transferencia incremental, DNS seguro, uso limitado (o ningn uso, usted decide) de NetBIOS...

La prxima generacin de Windows NT contendr una implementacin de los Servicios de directorio extendidos. Habr cambiado la forma de pensar sobre dominios, usuarios, grupos y relaciones de confianza. Los dominios de DS extendido se asignarn directamente a los dominios DNS y la administracin de los usuarios y grupos se podr delegar en unidades organizativas (OU, Organizational Units) del directorio. Los nuevos dominios DS extendidos sern mucho ms funcionales que los actuales dominios de Windows NT Server. La idea fundamental, desde el punto de vista de la implementacin de DNS, es que DNS se convertir en el servicio localizador principal en la red de los Servicios de directorio extendidos. Los clientes de DS extendido usarn DNS, de forma parecida a como los clientes de Windows NT 4.0 usan hoy WINS, para buscar otros servidores que ejecutan el servicio DS y a otros host de la red. En esta seccin se comentan algunos de los nuevos conceptos de los Servicios de directorio extendidos, as como algunos de los nuevos estndares que afectarn a DNS en el futuro. A continuacin, se prev cmo puede ser un buen diseo de DNS / DS en el futuro, con la intencin de darle una pista sobre cmo podra disear su red hoy para que est preparada para esta conversin futura.

DNS dinmico
Windows NT 4.0 incluye servicios de asignacin de nombre a direcciones IP: WINS y DNS. Una diferencia fundamental entre los dos es que, donde WINS acomoda el registro dinmico de nombres NetBIOS (y de las direcciones IP asociadas), los nombres DNS (y las direcciones IP asociadas) deben introducirse estticamente en la base de datos del servicio DNS. En el entorno Windows NT / Win95, no se recomienda el registro esttico de la informacin de nombre a direccin IP. Esto se debe a que, salvo en las instalaciones muy pequeas de redes Microsoft, los equipos no tienen asignaciones estticas de direcciones IP. Los equipos usan el protocolo DHCP (Protocolo de configuracin dinmica de host) para obtener una asignacin de direccin IP cada vez que se inicializan. La IETF (Internet Engineering Task Force) est considerando una propuesta de registro dinmico de la informacin DNS. Puede descargar la especificacin desde [Link]

72

DNS y Microsoft Windows NT 4.0

drafts/[Link]. Con la actualizacin dinmica de DNS, un equipo cliente, despus de obtener su direccin IP de DHCP, puede usar un protocolo estndar para registrar dinmicamente su nombre DNS y direccin IP en la base de datos de DNS. En la franja horaria de NT 4.0, se determin que no debera implementarse la actualizacin dinmica debido al estado actual de la especificacin, y a las preocupaciones con respecto a la escalabilidad. La actual propuesta de DNS dinmico se fundamenta en un modelo de duplicacin extraer de un nico maestro y consecuentemente, si el maestro nico est cado o no se puede alcanzar, no se pueden llevar a cabo las actualizaciones dinmicas. Microsoft est a favor de un acuerdo de mltiples maestros similar a WINS que permite que continen los registros aunque haya cado un nico punto de error. A largo plazo, se recomienda la utilizacin de actualizacin dinmica DNS frente a la integracin DNS-WINS de Windows NT 4.0 por las siguientes razones: La integracin DNS-WINS no permite una bsqueda inversa DNS eficaz (resolucin de direccin IP desde nombre DNS). Los servicios WWW (World Wide Web) y Servidor de seguridad (firewall) de Internet utilizan bsqueda inversa por motivos de seguridad. Debido a la reciente proliferacin de tales servicios, est aumentando la necesidad de una bsqueda inversa DNS eficaz. Si se usara la actualizacin dinmica DNS en lugar de la integracin WINS, este problema no existira. La integracin DNS-WINS no permite una relacin principal-reserva correcta entre los servidores de nombres DNS de Microsoft y los que no trabajan con sistemas Microsoft. Esto se debe al hecho de que los servidores de nombres DNS que no son de Microsoft carecen de la capacidad de bsqueda WINS. Por razones de conversin, los clientes desean instalar servidores DNS de MS como reserva de los servidores principales DNS que no son de Microsoft. Si se usara la actualizacin dinmica DNS en lugar de la integracin WINS, este problema no existira. Los host que no trabajan con sistemas de MS no se registran en WINS y, por lo tanto, no pueden registrarse dinmicamente en DNS. La actualizacin dinmica de DNS es un estndar IETF. Si fuera implementado (por MS), los host que no son de MS [que admiten el estndar de actualizacin dinmica de DNS] podran registrarse dinmicamente en el DNS de MS, y los host MS podran registrarse dinmicamente en un DNS que no fuera de MS [que admita el estndar de actualizacin dinmica de DNS].

DNS y Microsoft Windows NT 4.0 73

El registro WINS no est protegido, y no tiene visos de estarlo. La IETF est trabajando en la creacin de un estndar para agregar seguridad a la actualizacin dinmica de DNS. El estndar de seguridad de DNS no est programado para entrar en la lnea de los estndares de IETF hasta 4Q96. Algunas empresas ya han decidido renunciar a un estndar y desarrollar su propia implementacin de seguridad. Los clientes Microsoft no pueden registrarse con ninguna de las versiones actuales de DNS dinmico, y los servidores DNS dinmico no pueden duplicar sus datos dinmicos para otros servidores que NO sean servidores dinmicos DNS. En las implementaciones actuales de DNS dinmico, el principal es un nico punto de error. Todos los clientes deben registrar sus nombres y direcciones IP con este equipo. Si este equipo se ha cado, no se puede actualizar la base de datos de DNS.

IPv6 (IPng)
IPv6 se define en RFC 1883 ([Link] ). A veces se hace referencia a este protocolo como la Prxima generacin IP o IPng. La versin 6 de IP (IPv6) es una nueva versin del protocolo Internet, diseado como sucesor de la versin 4 de IP (IPv4) [RFC-791]. Los cambios de IPv4 a IPv6 se encuadran en las siguientes categoras: Capacidad de direccionamiento extendida Simplificacin del formato de cabecera Mayor cobertura de extensiones y opciones Capacidad de etiquetado de flujo Capacidad de autentificacin y de privacidad Con la llegada de este nuevo estndar, ser necesario modificar el protocolo DNS. El RFC 1886 ([Link] ) define estos cambios. Entre los cambios se incluye un nuevo tipo de registro de recurso para almacenar una direccin IPv6, un nuevo dominio que admita las bsquedas basadas en una direccin IPv6 y definiciones actualizadas de tipos de consultas ya existentes que devuelven direcciones Internet como parte del proceso de secciones adicionales. Las extensiones estn diseadas para ser compatibles con las aplicaciones existentes y, en particular, con las propias implementaciones de DNS. La compatibilidad actual del almacenamiento de direcciones Internet en el Sistema de nombres de dominio (DNS) no puede ampliarse fcilmente para admitir direcciones IPv6, puesto que las aplicaciones suponen que las consultas de direcciones devuelven direcciones Ipv4 de 32 bits.

Transferencias incrementales: duplicacin multimaestro

La transferencia incremental se utiliza para difundir rpidamente los cambios en una base de datos DNS. Windows NT 4.0 no admite el protocolo de transferencia incremental, aunque se admitir en el futuro. El protocolo de transferencia incremental est diseado para reducir el tiempo de latencia y reducir la cantidad de datos enviados durante una transferencia de zona. Esto se realiza mediante dos mecanismos.

74

DNS y Microsoft Windows NT 4.0

La notificacin se utiliza para notificar activamente a los servidores un cambio en un archivo de zona. La notificacin se lleva a cabo mediante la extensin NOTIFY de DNS (MS DNS admite Notify en Windows NT 4.0). Para obtener informacin adicional acerca de la especificacin de notificacin consulte el esquema de Internet en [Link] La propagacin de zona se ha mejorado enviando simplemente la informacin modificada. Es un mtodo mucho mejor que el actual mecanismo de transferencia de zona completa, puesto que el mtodo actual siempre transfiere todo el archivo de zona. Para obtener informacin adicional acerca del protocolo Transferencia incremental, consulte el esquema de Internet en [Link] La duplicacin de datos dinmicos funcionar muy parecido a cmo funciona WINS hoy en da, aunque los datos permanecen dentro de la zona en lugar de duplicar los datos innecesarios para cada uno de los restantes servidores (como WINS). En la siguiente figura se muestra el registro del resolver y cmo funciona la duplicacin:

La base de datos dinmica de [Link] slo duplica entre el servidor DNS 2 y el servidor DNS 3. La base de datos dinmica de [Link] slo duplica entre el servidor DNS 1 y el servidor DNS 2.

DNS protegido
A medida que DNS se vaya convirtiendo en una parte operacional fundamental de la infraestructura de Internet, ser necesario establecer un mtodo de seguridad para asegurar la integracin y autentificacin de los datos. Las extensiones del DNS se describen en el documento DNS Protocol Security Extensions--30 January 1996 (Extensiones de seguridad del protocolo DNS de 30 Enero de 1996) de IETF-DRAFT que proporciona estos servicios a los resolver o aplicaciones preocupados por la seguridad a travs del uso de firmas digitales codificadas. Estas firmas digitales se incluyen en zonas protegidas como registros del recurso. En muchos casos, la seguridad se puede proporcionar incluso a travs de servidores DNS no preocupados por la seguridad.

DNS y Microsoft Windows NT 4.0 75

Las extensiones tambin proporcionan claves pblicas autentificadas para su almacenamiento en el DNS. Este almacenamiento de claves admite el servicio general pblico de distribucin de

Migracin
claves, as como la seguridad DNS. Las claves almacenadas permiten que los resolver conscientes de la seguridad aprendan la clave de autentificacin de las zonas, adems de aqullas para las que han sido configuradas inicialmente. Se puede conseguir que las claves asociadas con nombres DNS admitan otros protocolos. Se proporciona soporte para una amplia variedad de tipos de clave y de algoritmos. Adems, las extensiones de seguridad proporcionan la autentificacin opcional de transacciones del protocolo DNS. Para obtener ms informacin, vea [Link] . En las implementaciones actuales de DNS dinmico, los fabricantes tenan que desarrollar su propio protocolo de seguridad debido a la falta de un estndar definido. Tenga cuidado cuando desarrolle uno de estos productos, porque puede resultar incompatible con los productos futuros cuando se defina una especificacin.

Por dnde empezamos?

Vamos a examinar el proceso de conversin a los Servicios de directorio extendidos. Los nuevos dominios DS extendidos podrn interoperar totalmente con los dominios de Windows NT Server. (Es decir, los dominios ya existentes de Windows NT Server podrn confiar en los dominios DS extendidos, al igual que ahora confan en otros dominios de Windows NT Server). Los servidores DS extendidos podrn funcionar como controladores de dominio de reserva de los dominios de Windows NT Server. Esta interoperabilidad permitir la actualizacin a Servidor DS extendido de una forma ordenada, al mismo tiempo que permite que los servidores Windows NT existentes funcionen sin ninguna modificacin. Los administradores no se vern forzados a usar el modelo de administracin de DS extendido hasta que estn preparados para hacerlo. Incluso cuando los servidores DS extendidos se encuentren en la red, por ejemplo, los administradores podrn mantener toda la informacin de la cuenta en el dominio de Windows NT Server, usando las herramientas administrativas actuales de Windows NT Server. Por lo consiguiente, los administradores podrn distribuir servidores DS extendidos sin interrumpir la administracin de la red. Mientras se implantan los servidores DS extendidos, los administradores pueden empezar a almacenar la informacin de las cuentas de usuario en los servidores DS extendidos, a la vez que continan almacenando y administrando esas cuentas en el dominio de Windows NT Server y a partir de dicho dominio. Esto permitir que las organizaciones puedan migrar cada vez ms informacin de las cuentas a un servidor DS extendido, a medida que vaya aumentando su confianza en la estabilidad y capacidad del DS extendido. En cuanto estn bien establecidos los servidores DS extendido, los administradores podrn mantener toda la informacin de la cuenta en servidores DS extendido, usando las herramientas de stos. Sin embargo, para los clientes que no sean de DS extendido, estos servidores continuarn pareciendo y actuando exactamente como servidores Windows NT Server 4.x.

76

DNS y Microsoft Windows NT 4.0

En cuanto se hayan terminado todas las transiciones de clientes y de servidores, el entorno DS extendido ser el entorno de uso diario, tanto para los usuarios finales como para los administradores del sistema. Y la transicin, activada por la interoperabilidad entre la integracin de Windows NT Server y DS extendido, permitir que las organizaciones realicen una transicin fcil al espacio de nombres global y unificado proporcionado por DS extendido, sin interrumpir las operaciones diarias de la red.

Puesto que DNS est basado en estndares TCPIP y que la siguiente generacin de Windows NT descansa en DNS como su espina dorsal, qu ocurre con IPX y Netbeui?
Se continuar ofreciendo compatibilidad con Netbeui y con IPX, sin embargo, no hay que perder de vista que la direccin indicada de Microsoft es TCPIP, como lo es de la mayora de los otros fabricantes de redes. Si decide usar IPX y Netbeui en la siguiente revisin de Windows NT, tendr que usar NetBIOS. Sin embargo, si elige la utilizacin del protocolo TCPIP, no necesitar NetBIOS como parte de su arquitectura.

DNS y Microsoft Windows NT 4.0 77

Qu pasa con las aplicaciones heredadas que dependen de nombres NetBIOS, como

Conclusin
SMS?
Mientras tenga aplicaciones que requieran nombres NetBIOS, tendr que usar la resolucin de nombres NetBIOS en su red. Cuando decida empezar la migracin a DS extendido necesitar encontrar todas las aplicaciones (servicios, etc.) que requieran NetBIOS y desarrollar un plan de conversin de nombres de host para cada una de ellas.

Buscar DC en un entorno de Servicio extendido de directorios

En la ruta de acceso a un verdadero entorno de Servicios de directorio extendidos de Windows NT (sin NetBIOS) habr una ruta de conversin necesaria que incluya la utilizacin de los tres estndares para facilitar la compatibilidad con los anteriores sistemas NetBIOS heredados. Segn se inicien los equipos de los Servicios de directorio extendidos de Windows NT, usarn el protocolo WINS existente para registrar los nombres NetBIOS con sus servidores WINS configurados, y registrar sus registros A con sus servidores DNS. Por lo tanto, las asignaciones de nombres NetBIOS y DNS a direcciones IP de Windows NT estarn disponibles para todos los equipos Windows NT de DS extendido y las de nivel inferior a stas (Windows 95, Windows para Trabajo en grupo, etc.). Cuando se inicien los servidores DS extendidos de Windows NT, que contengan la base de datos de servicios de directorio, no slo registrarn un nombre NetBIOS en el servidor WINS, y un registro A en el servidor DNS, sino que tambin guardarn otro registro en el servidor DNS que defina la ubicacin, los protocolos admitidos de acceso a DS, los protocolos de transporte, etc. Un equipo puede tener mltiples registros A registrados. Por ejemplo, un Servicio extendido de directorios DC podra registrar: [Link] [Link] A A [Link] [Link]

Esto permitir que otras estaciones de trabajo de Servicios de directorio extendidos encuentren DC para validar sus credenciales de seguridad.

Cosas con las que puede contar en el futuro

Microsoft adoptar una solucin de DNS dinmico protegida y nuestros clientes se registrarn de forma automtica en el DNS. Tambin habr un proceso para usar DNS para localizar el DC de Servicios de directorio ms prximo. La siguiente revisin de los Servicios de directorio dar por supuesto que los dominios DNS coinciden con los dominios DS.

Reglas para crear una buena solucin DNS para el futuro

Si hay servidores en un sitio, es necesario que haya un servidor DNS en ese sitio. Cree un dominio DNS por cada dominio de NT 4.0.

78

DNS y Microsoft Windows NT 4.0

Cada servidor DNS del sitio debera ser un principal para el dominio DNS especfico del sitio y un secundario para el dominio DNS principal. Los clientes Windows deben registrarse en un dominio DNS especfico del sitio. Los equipos Windows NT Server deben registrarse en un dominio maestro DNS.

DNS y Microsoft Windows NT 4.0 79

Apndice A: El cable

Apndices

Seguimiento de consultas DNS Preguntar al DNS la direccin IP de un HOST

El ejemplo consta de la siguiente instalacin, con 4 host, 2 de los cuales son servidores DNS principales.

El cliente Windows NT 4.0 ejecuta el siguiente PING. Las flechas representan un paquete y los nmeros asocian el nmero de trama con el seguimiento que se muestra a continuacin.

80

DNS y Microsoft Windows NT 4.0

DNS y Microsoft Windows NT 4.0 81

Se realiza el seguimiento de la siguiente consulta: Ping [Link] es decir, el Host es serpiente y el dominio es [Link]

En primer lugar, el cliente tiene que consultar los nombres en su servidor DNS. Observe que la consulta es recursiva.
1 SCOTTSU-7 SCOTTSU_NT40 DNS 0x1:Std Qry for [Link] IP: ID = 0x9608; Proto = UDP; Len: 77 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Total Length = 77 (0x4D) IP: Identification = 38408 (0x9608) IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9F28 IP: Source Address = [Link] IP: Destination Address = [Link] IP: Data: Number of data bytes remaining = 57 (0x0039) UDP: Src Port: Unknown, (1066); Dst Port: DNS (53); Length = 57 (0x39) UDP: Source Port = 0x042A UDP: Destination Port = DNS UDP: Total length = 57 (0x39) bytes UDP: CheckSum = 0xB2D7 UDP: Data: Number of data bytes remaining = 49 (0x0031) DNS: 0x1:Std Qry for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........0....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class

scottsu_40NT.[Link] no tiene autoridad sobre el dominio [Link], por lo que el host scottsu_40NT.[Link] enva la peticin al servidor DNS del subdominio [Link]. Observe que la consulta es iterativa.
2 SCOTTSU_NT40 COPPERHEAD DNS 0x5:Std Qry for [Link] IP: ID = 0x9C1C; Proto = UDP; Len: 77 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Total Length = 77 (0x4D) IP: Identification = 39964 (0x9C1C) IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9487 IP: Source Address = [Link] IP: Destination Address = [Link] IP: Data: Number of data bytes remaining = 57 (0x0039) UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 57 (0x39) UDP: Source Port = DNS

82

DNS y Microsoft Windows NT 4.0

UDP: Destination Port = DNS UDP: Total length = 57 (0x39) bytes UDP: CheckSum = 0xB33B UDP: Data: Number of data bytes remaining = 49 (0x0031) DNS: 0x5:Std Qry for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 5 (0x5) DNS: DNS Flags = Query, OpCode - Std Qry, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......0........ = Iterative query desired DNS: ........0....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class

El host [Link] contesta con los datos al servidor DNS Scottsu_40NT.

3 COPPERHEAD SCOTTSU_NT40 DNS 0x5:Std Qry Resp. for [Link] IP: ID = 0x5F04; Proto = UDP; Len: 93 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Total Length = 93 (0x5D) IP: Identification = 24324 (0x5F04) IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0xD18F IP: Source Address = [Link] IP: Destination Address = [Link] IP: Data: Number of data bytes remaining = 73 (0x0049) UDP: Src Port: DNS, (53); Dst Port: DNS (53); Length = 73 (0x49) UDP: Source Port = DNS UDP: Destination Port = DNS UDP: Total length = 73 (0x49) bytes UDP: CheckSum = 0x8BD1 UDP: Data: Number of data bytes remaining = 65 (0x0041) DNS: 0x5:Std Qry Resp. for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 5 (0x5) DNS: DNS Flags = Response, OpCode - Std Qry, AA RA Bits Set, RCode - No error DNS: 1............... = Response DNS: .0000........... = Standard Query DNS: .....1.......... = Server authority for domain DNS: ......0......... = Message complete DNS: .......0........ = Iterative query desired DNS: ........1....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link]

Los datos se devuelven al cliente.

4 SCOTTSU_NT40 SCOTTSU-7 DNS 0x1:Std Qry Resp. for [Link] IP: ID = 0x9D1C; Proto = UDP; Len: 93 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Service Type = 0 (0x0) IP: Total Length = 93 (0x5D) IP: Identification = 40220 (0x9D1C)

DNS y Microsoft Windows NT 4.0 83

IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = UDP - User Datagram IP: CheckSum = 0x9804 IP: Source Address = [Link] IP: Destination Address = [Link] IP: Data: Number of data bytes remaining = 73 (0x0049) UDP: Src Port: DNS, (53); Dst Port: Unknown (1066); Length = 73 (0x49) UDP: Source Port = DNS UDP: Destination Port = 0x042A UDP: Total length = 73 (0x49) bytes UDP: CheckSum = 0x8F6D UDP: Data: Number of data bytes remaining = 65 (0x0041) DNS: 0x1:Std Qry Resp. for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Response, OpCode - Std Qry, RD RA Bits Set, RCode - No error DNS: 1............... = Response DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........1....... = No recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link]

El cliente ya puede hacer PING al servidor.

5 6 SCOTTSU-7 SERPIENTE ICMP ICMP Echo, From [Link] To [Link] SERPIENTE SCOTTSU-7 Echo Reply, To [Link] From [Link]

El uso de la red
A continuacin se muestra un seguimiento del nuevo comportamiento de Windows NT 4.0 que permite que un cliente se conecte a un servidor Windows NT a travs del nombre de HOST, en lugar del nombre del equipo NetBIOS. Esto es un seguimiento del siguiente comando: Net Use * \\[Link]\c$ Consulte el Nombre de host [Link] al DNS
1 4.248 SCOTTSU-7 SCOTTSU_NT40 DNS 0x6:Std Qry for [Link] IP: Source Address = [Link] IP: Destination Address = [Link] UDP: Src Port: Unknown, (1057); Dst Port: DNS (53); Length = 48 (0x30) UDP: Source Port = 0x0421 UDP: Destination Port = DNS UDP: Total length = 48 (0x30) bytes UDP: CheckSum = 0x8FEA UDP: Data: Number of data bytes remaining = 40 (0x0028) DNS: 0x6:Std Qry for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 6 (0x6) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: 0............... = Query DNS: .0000........... = Standard Query DNS: .....0.......... = Server not authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........0....... = Recursive queries supported by server DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0)

84

DNS y Microsoft Windows NT 4.0

DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class

sta es la respuesta del servidor DNS. La direccin IP de [Link] se encuentra al final de la trama
2 4.255 SCOTTSU_NT40 SCOTTSU-7 DNS 0x6:Std Qry Resp. for [Link] IP: Source Address = [Link] IP: Destination Address = [Link] UDP: Src Port: DNS, (53); Dst Port: Unknown (1057); Length = 64 (0x40) UDP: Source Port = DNS UDP: Destination Port = 0x0421 UDP: Total length = 64 (0x40) bytes UDP: CheckSum = 0x4932 UDP: Data: Number of data bytes remaining = 56 (0x0038) DNS: 0x6:Std Qry Resp. for [Link] of type Host Addr on class INET addr. DNS: Query Identifier = 6 (0x6) DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: 1............... = Response DNS: .0000........... = Standard Query DNS: .....1.......... = Server authority for domain DNS: ......0......... = Message complete DNS: .......1........ = Recursive query desired DNS: ........1....... = Non-recursive queries DNS: .........000.... = Reserved DNS: ............0000 = No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link] of type Host Addr on class INET addr. DNS: Question Name: [Link] DNS: Question Type = Host Address DNS: Question Class = Internet address class DNS: Answer section: [Link] of type Host Addr on class INET addr. DNS: Resource Name: [Link] DNS: Resource Type = Host Address DNS: Resource Class = Internet address class DNS: Time To Live = 0 (0x0) DNS: Resource Data Length = 4 (0x4) DNS: IP address = [Link]

A continuacin el cliente realiza un Estado del adaptador en la direccin IP para averiguar qu nombres ha registrado el equipo
3 4.254 SCOTTSU-7 SCOTTSU_NT40 NBT NS: Query req. for *<00...(15)> IP: Source Address = [Link] IP: Destination Address = [Link] UDP: Src Port: NETBIOS Name Service, (137); Dst Port: NETBIOS Name Service (137); Length = 58 (0x3A) UDP: Source Port = NETBIOS Name Service UDP: Destination Port = NETBIOS Name Service UDP: Total length = 58 (0x3A) bytes UDP: CheckSum = 0x3A63 UDP: Data: Number of data bytes remaining = 50 (0x0032) NBT: NS: Query req. for *<00...(15)> NBT: Transaction ID = 32860 (0x805C) NBT: Flags Summary = 0x0000 - Req.; Query; Success NBT: 0............... = Request NBT: .0000........... = Query NBT: .....0.......... = Non-authoritative Answer NBT: ......0......... = Datagram not truncated NBT: .......0........ = Recursion not desired NBT: ........0....... = Recursion not available NBT: .........0...... = Reserved NBT: ..........0..... = Reserved NBT: ...........0.... = Not a broadcast packet NBT: ............0000 = Success NBT: Question Count = 1 (0x1) NBT: Answer Count = 0 (0x0) NBT: Name Service Count = 0 (0x0) NBT: Additional Record Count = 0 (0x0) NBT: Question Name = *<00...(15)> NBT: Question Type = Node Status Request NBT: Question Class = Internet Class

DNS y Microsoft Windows NT 4.0 85

sta es la respuesta al estado del adaptador. El equipo tiene varios nombres NetBIOS registrados.
4 4.255 SCOTTSU_NT40 SCOTTSU-7 NBT NS: Query (Node Status) resp. for *<00...(15)>, Success IP: Source Address = [Link] IP: Destination Address = [Link] UDP: Src Port: NETBIOS Name Service, (137); Dst Port: NETBIOS Name Service (137); Length = 345 (0x159) UDP: Source Port = NETBIOS Name Service UDP: Destination Port = NETBIOS Name Service UDP: Total length = 345 (0x159) bytes UDP: CheckSum = 0xC551 UDP: Data: Number of data bytes remaining = 337 (0x0151) NBT: NS: Query (Node Status) resp. for *<00...(15)>, Success NBT: Transaction ID = 32860 (0x805C) NBT: Flags Summary = 0x8400 - Resp.; Query; Success NBT: 1............... = Response NBT: .0000........... = Query NBT: .....1.......... = Authoritative Answer NBT: ......0......... = Datagram not truncated NBT: .......0........ = Recursion not desired NBT: ........0....... = Recursion not available NBT: .........0...... = Reserved NBT: ..........0..... = Reserved NBT: ...........0.... = Not a broadcast packet NBT: ............0000 = Success NBT: Question Count = 0 (0x0) NBT: Answer Count = 1 (0x1) NBT: Name Service Count = 0 (0x0) NBT: Additional Record Count = 0 (0x0) NBT: Resource Record Name = *<00...(15)> NBT: Resource Record Type = Node Status Request NBT: Resource Record Class = Internet Class NBT: Time To Live = 0 (0x0) NBT: RDATA Length = 263 (0x107) NBT: Number of Names = 12 (0xC) NBT: ASCII Name = SCOTTSU_NT40 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40 00 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D 00 NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1C> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1B> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1E> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name

86

DNS y Microsoft Windows NT 4.0

NBT: ASCII Name = SCOTTSU_NT40 <03> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40D <1D> NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = <01><02>__MSBROWSE__<02><01> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = INet~Services <1C> NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: ASCII Name = IS~SCOTTSU_NT4000 NBT: Resource Record Flags = 17408 (0x4400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 0............... = Unique NetBIOS Name NBT: ASCII Name = SCOTTSU_NT40 NBT: Resource Record Flags = 50176 (0xC400) NBT: ......0......... = Non-Permanent NBT: .....1.......... = Active Name NBT: ....0........... = Name is not in Conflict NBT: ...0............ = Not Deregistering NBT: .10............. = M Node NBT: 1............... = Group NetBIOS Name NBT: Adapter Address = 00A02463AB22 NBT: Version Major = 0 (0x0) NBT: Version Minor = 0 (0x0) NBT: Duration = 0 (0x0) NBT: FRMRs Received = 0 (0x0) NBT: FRMRs Transmitted = 0 (0x0) NBT: IFrame Receive Errors = 0 (0x0) NBT: Transmit Aborts = 0 (0x0) NBT: Tranmitted = 0 (0x0) NBT: Received = 0 (0x0) NBT: IFrame Transmit Errors = 0 (0x0) NBT: No Receive Buffers = 0 (0x0) NBT: T1 Timeouts = 0 (0x0) NBT: Ti Timeouts = 0 (0x0) NBT: Free NCBS = 0 (0x0) NBT: NCBS = 0 (0x0) NBT: Max NCBS = 0 (0x0) NBT: No Transmit Buffers = 255 (0xFF) NBT: Max Datagram = 799 (0x31F) NBT: Pending Sessions = 32 (0x20) NBT: Max Sessions = 33008 (0x80F0) NBT: Packet Size = 20976 (0x51F0)

Ahora el cliente va a hacer el protocolo de 3 vas de TCP...

5 4.257 SCOTTSU-7 SCOTTSU_NT40 TCP ....S., len: 4, seq: 2817881, ack: 0, win: 8192 IP: Source Address = [Link] IP: Destination Address = [Link] TCP: ....S., len: 4, seq: 2817881, ack: 0, win: 8192, src: 1056 dst: 139 (NBT Session) 6 4.257 SCOTTSU_NT40 SCOTTSU-7 TCP .A..S., len: 4, seq: 5416017, ack: 2817882, win: 8760, src SCOTTSU_NT40 SCOTTSU-7 IP

IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .A..S., len: 4, seq: 5416017, ack: 2817882, win: 8760, src: 139 (NBT Session) dst: 1056

DNS y Microsoft Windows NT 4.0 87

4.258 SCOTTSU-7

SCOTTSU_NT40 TCP

.A...., len: 0, seq: 2817882, ack: 5416018, win: 8760

IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .A...., len: 0, seq: 2817882, ack: 5416018, win: 8760, src: 1056 dst: 139 (NBT Session)

A continuacin el cliente enviar una peticin de sesin NetBT al nombre del servidor NetBIOS (no al nombre de HOST).
8 4.259 SCOTTSU-7 SCOTTSU_NT40 NBT SS: Session Request, Dest: SCOTTSU_NT40 IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .AP..., len: 72, seq: 2817882, ack: 5416018, win: 8760, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 2817882 (0x2AFF5A) TCP: Acknowledgement Number = 5416018 (0x52A452) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8760 (0x2238) TCP: CheckSum = 0x722C TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 72 (0x0048) NBT: SS: Session Request, Dest: SCOTTSU_NT40 , Source: SCOTTSU-7 <00>, Len: 68 NBT: Packet Type = Session Request NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 68 (0x44) NBT: Called Name = SCOTTSU_NT40 NBT: Calling Name = SCOTTSU-7 <00>

Esto es una respuesta afirmativa de sesin del servidor.

9 4.259 SCOTTSU_NT40 SCOTTSU-7 NBT SS: Positive Session Response, Len: 0 IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .AP..., len: 4, seq: 5416018, ack: 2817954, win: 8688, src: 139 (NBT Session) dst: 1056 TCP: Source Port = NETBIOS Session Service TCP: Destination Port = 0x0420 TCP: Sequence Number = 5416018 (0x52A452) TCP: Acknowledgement Number = 2817954 (0x2AFFA2) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8688 (0x21F0) TCP: CheckSum = 0x5D4C TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 4 (0x0004) NBT: SS: Positive Session Response, Len: 0 NBT: Packet Type = Positive Session Response NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 0 (0x0)

Ahora se comenzar a establecer una sesin entre el redirector y el servidor (nivel de aplicacin). Comienza con una trama de negociacin.
10 11 4.262 SCOTTSU-7 SCOTTSU_NT40 SMB SMB C negotiate, Dialect = NT LM 0.12 R negotiate, Dialect # = 7

4.276 SCOTTSU_NT40 SCOTTSU-7

88

DNS y Microsoft Windows NT 4.0

Ahora se establece la sesin entre el redirector y el servidor. Esta trama tambin tiene adjuntada un Conectar a rbol. Observe que el nombre del servidor en Conectar a rbol es el Nombre de HOST. En realidad, el redirector no utiliza este nombre. Slo conoce el nombre del equipo NetBIOS.
12 4.275 SCOTTSU-7 SCOTTSU_NT40 SMB C session setup & X, and C tree connect IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .AP..., len: 314, seq: 2818128, ack: 5416131, win: 8647, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 2818128 (0x2B0050) TCP: Acknowledgement Number = 5416131 (0x52A4C3) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8647 (0x21C7) TCP: CheckSum = 0x5638 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 314 (0x013A) NBT: SS: Session Message, Len: 310 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 310 (0x136) NBT: SS Data: Number of data bytes remaining = 310 (0x0136) SMB: C session setup & X, Username = Administrator, and C tree connect & X, Share = \\[Link]\IPC$ SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0xCAFE TID = 0x0000 MID = 0x0000 UID = 0x0000 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 51966 (0xCAFE) SMB: User ID (UID) = 0 (0x0) SMB: Multiplex ID (MID) = 0 (0x0) SMB: Flags Summary = 24 (0x18) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...1.... = Canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 32771 (0x8003) SMB: ...............1 = Understands long nombrearchivos SMB: ..............1. = Understands extended attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 1............... = Using UNICODE strings SMB: Command = C session setup & X SMB: Word count = 13 SMB: Word parameters SMB: Next offset = 0x00E8 SMB: Max Buffer Size = 4356 SMB: Max MPX requests = 50 SMB: VC number = 0 SMB: Session Key = 0 SMB: Password length = 24 (0x18) SMB: Unicode Password length = 24 (0x18) SMB: Capabilities = 212 (0xD4) SMB: ...............................0 = No Raw Reads and Writes. SMB: ..............................0. = No support for multiplexed commands. SMB: .............................1.. = Supports UNICODE strings. SMB: ............................0... = Does not support large files. SMB: ...........................1.... = Supports the NT SMB extensions. SMB: ..........................0..... = RPC remote API's not supported. SMB: .........................1...... = Recognizes NT Status codes. SMB: ........................1....... = Supports level II oplocks. SMB: .......................0........ = Does not support Lock and Read. SMB: Byte count = 171 SMB: Byte parameters SMB: Account name = Administrator SMB: Domain name = SCOTTSU_NT40D SMB: Native OS = Windows NT 1307 SMB: Native Lanman = Windows NT 4.0

DNS y Microsoft Windows NT 4.0 89

SMB: Command = C tree connect & X SMB: Word count = 4 SMB: Word parameters SMB: Next offset = 0x0000 SMB: Disconnect flag = 0x0000 SMB: Password length = 1 (0x1) SMB: Byte count = 67 SMB: Byte parameters SMB: Password = SMB: Path name = \\[Link]\IPC$ 13 14 15 16 17 4.289 SCOTTSU_NT40 SCOTTSU-7 4.289 SCOTTSU_NT40 SCOTTSU-7 4.297 SCOTTSU_NT40 SCOTTSU-7 4.479 SCOTTSU-7 4.637 SCOTTSU-7 TCP TCP SMB ...R.., len: 0, seq: 4933305, ack: 2818128, win: 0 ...R.., len: 0, seq: 3578897, ack: 2818128, win: 0 R session setup & X, and R tree connect & X, Type = IPC .A...., len: 0, seq: 2818442, ack: 5416289, win: 8489 C tree connect & X, Share = \\[Link]\C$

SCOTTSU_NT40 TCP SCOTTSU_NT40 SMB

IP: Source Address = [Link] IP: Destination Address = [Link] TCP: .AP..., len: 107, seq: 2818442, ack: 5416289, win: 8489, src: 1056 dst: 139 (NBT Session) TCP: Source Port = 0x0420 TCP: Destination Port = NETBIOS Session Service TCP: Sequence Number = 2818442 (0x2B018A) TCP: Acknowledgement Number = 5416289 (0x52A561) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP... TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 8489 (0x2129) TCP: CheckSum = 0x99CE TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 107 (0x006B) NBT: SS: Session Message, Len: 103 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 103 (0x67) NBT: SS Data: Number of data bytes remaining = 103 (0x0067) SMB: C tree connect & X, Share = \\[Link]\C$ SMB: SMB Status = Error Success SMB: Error class = No Error SMB: Error code = No Error SMB: Header: PID = 0xCAFE TID = 0x0000 MID = 0x0040 UID = 0x0801 SMB: Tree ID (TID) = 0 (0x0) SMB: Process ID (PID) = 51966 (0xCAFE) SMB: User ID (UID) = 2049 (0x801) SMB: Multiplex ID (MID) = 64 (0x40) SMB: Flags Summary = 24 (0x18) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...1.... = Canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 0....... = Client command SMB: flags2 Summary = 32771 (0x8003) SMB: ...............1 = Understands long filenames SMB: ..............1. = Understands extended attributes SMB: ..0............. = No paging of IO SMB: .0.............. = Using SMB status codes SMB: 1............... = Using UNICODE strings SMB: Command = C tree connect & X SMB: Word count = 4 SMB: Word parameters SMB: Next offset = 0x0000 SMB: Disconnect flag = 0x0000 SMB: Password length = 1 (0x1) SMB: Byte count = 60 SMB: Byte parameters SMB: Password = SMB: Path name = \\[Link]\C$ 18 4.654 SCOTTSU_NT40 SCOTTSU-7 SMB R tree connect & X, Type = A:

90

DNS y Microsoft Windows NT 4.0

Bsqueda inversa de nombres

A continuacin se muestra el seguimiento de una bsqueda de nombres inversa mediante el comando PING -a direccin IP. Este comando enva la direccin IP al servidor DNS y pregunta el nombre de HOST asociado con el nombre NetBIOS. Recuerde que si el servidor DNS no tuviera este nombre en su tabla, el servidor DNS ejecutara un estado de adaptador en la direccin IP, en lugar de ir a WINS. Sin embargo, eso slo se producir si est activada la siguiente casilla de verificacin en las propiedades de la zona *[Link]:

Ping -a [Link]
DNS: 0x1:Std Qry for [Link].[Link] of type Dom. name ptr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Query, OpCode - Std Qry, RD Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 0 (0x0) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link].[Link] of type Dom. name ptr on class INET addr. DNS: Question Name: [Link].[Link] DNS: Question Type = Domain name pointer DNS: Question Class = Internet address class

DNS y Microsoft Windows NT 4.0 91

Observe que el nombre de la pregunta es la direccin IP al revs [Link].[Link] del tipo PTR.
*****************************************************************************************************************************

Apndice B: Informacin adicional

DNS: 0x1:Std Qry Resp. for [Link].[Link] of type Dom. name ptr on class INET addr. DNS: Query Identifier = 1 (0x1) DNS: DNS Flags = Response, OpCode - Std Qry, AA RD RA Bits Set, RCode - No error DNS: Question Entry Count = 1 (0x1) DNS: Answer Entry Count = 1 (0x1) DNS: Name Server Count = 0 (0x0) DNS: Additional Records Count = 0 (0x0) DNS: Question Section: [Link].[Link] of type Dom. name ptr on class INET addr. DNS: Question Name: [Link].[Link] DNS: Question Type = Domain name pointer DNS: Question Class = Internet address class DNS: Answer section: [Link].[Link] of type Dom. name ptr on class INET addr. DNS: Resource Name: [Link].[Link] DNS: Resource Type = Domain name pointer DNS: Resource Class = Internet address class DNS: Time To Live = 86400 (0x15180) DNS: Resource Data Length = 23 (0x17) DNS: Pointer: [Link]

Internet
Todos los esquemas de IETF: [Link] Todos los RFC: [Link] UseNet: [Link] Buenos sitios DNS en la red: [Link] Listas de correo: namedroppers Es el foro de discusin del grupo de trabajo de DNS del Internet Engineering Task Force, y lo utiliza tambin el grupo de trabajo dnsind. La misin de dnsind es trabajar en la extensin de los protocolos relacionados con DNS para incorporar la transferencia incremental de zonas, la notificacin de cambios y las actualizaciones dinmicas. Las peticiones de subscripcin deben enviarse a majordomo@[Link]. Las preguntas generales acerca de DNS no son apropiadas para este foro. Hay archivos actualizados disponibles. dns-security Es el foro de discusin del grupo de trabajo dnssec de la IETF. Las peticiones de subscripcin deben enviarse a dns-security-request@[Link].

Libros
DNS and BIND Un manual de referencia y de usuario de DNS, todo en uno, para los usuarios de BIND. Excelente para los administradores DNS principiantes a intermedios; no trata temas ms avanzados.

92

DNS y Microsoft Windows NT 4.0

Fecha publicacin: Octubre 1992, reeditado marzo 1993 con pocas correcciones. Autores: Paul Albitz y Cricket Liu Editorial: O'Reilly & Associates ISBN: 1-56592-010-4 TCP/IP Network Administration Contiene una visin general completa de DNS como uno de los servicios de red estndar de un entorno TCP/IP. Fecha publicacin: Agosto 1992, reeditado enero 1994 con pocas correcciones. Autor: Craig Hunt Editorial: O'Reilly & Associates ISBN: 0-937175-82-X

DNS y Microsoft Windows NT 4.0 93

UNIX System Administration Handbook, Second Edition La actualizacin del clsico de Nemeth y Snyder, incluye ahora el captulo 16 dedicado a DNS. Particularmente indicado para la comparacin de las caractersticas que aportan los distintos fabricantes. Fecha publicacin: 1995 Autores: Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein Editorial: Prentice Hall ISBN: 0-13-151051-7 TCP/IP Illustrated, Volume 1 Para los temas relacionados con redes y protocolos, consulte el tema 14. Fecha publicacin: 1994 Autor: W. Richard Stevens Editorial: Addison-Wesley Publishing Company ISBN: 0-201-63346-9 Firewalls and Internet Security: Repelling the Wily Hacker Incluye consejos sobre DNS en un entorno de servidor de seguridad ( firewall). Fecha publicacin: 1994 Autores: William R. Cheswick y Steven M. Bellovin Editorial: Addison-Wesley Publishing Company ISBN: 0-201-63357-4 Building Internet Firewalls Buen libro general sobre seguridad con un enfoque prctico. El captulo 8 incluye una seccin detallada sobre DNS en un entorno de servidor de seguridad. Fecha publicacin: Septiembre 1995 Autores: D. Brent Chapman y Elizabeth D. Zwicky Editorial: O'Reilly & Associates ISBN: 1-56592-124-0

Hojas tcnicas
Microsoft Windows NT 3.5/3.51: Detalles sobre la implementacin de TCP/IP ( Parte N
62170) 098-

[Link] (Parte N 098-56544)

94

DNS y Microsoft Windows NT 4.0

Cursos
The Domain Name System (DNS) & Internet Naming and Directory Services - por Dr. Paul Mockapetris

Varios
[Link]

DNS y Microsoft Windows NT 4.0 95

Apndice C: Registro en el NIC

Domain-request@[Link] (703) 876-5050 CIC@[Link] (617) 873-2777 domains%[Link]@[Link] Enve un mensaje por correo electrnico a listserv%[Link]@[Link] con el texto SEND DOMAIN GUIDE Este archivo contiene ejemplos y una plantilla, adems de las explicaciones. Formulario de registro de dominio [Link] Tarifa $100 (esto incluye la tarifa de mantenimiento de $50 por dos aos). Transcurridos los dos aos, se mandar una factura anual.

96

DNS y Microsoft Windows NT 4.0

Apndice D: Registros DNS

A - El registro de recurso A (Address) asigna un nombre de host (equipo o cualquier otro dispositivo de red) a una direccin IP de una zona DNS. Su homlogo, el registro de recurso PTR, sirve para asignar una direccin IP a un nombre de host (equipo o cualquier otro dispositivo de red) de una zona inversa DNS (los del dominio DNS [Link]). AFSDB - El registro de recurso AFSDB da la ubicacin de un servidor de base de datos de celdas AFS (Andrew File System), o el servidor de nombres autentificado de celdas DCE (Distributed Computing Environment). AFS de Transarc es un sistema de archivos de red, parecido a NFS, pero diseado ms para las redes de rea extensa (WAN). El sistema AFS usa DNS para asignar un nombre de dominio DNS al nombre de un servidor de base de datos de celda AFS. El servicio Nombres DCE de la Open Software Foundation usa DNS para una funcin similar: asignar el nombre de dominio DNS de una celda DCE a los servidores de nombres autentificados para esa celda. CNAME - El registro de recurso CNAME (nombre cannico) crea un alias (nombre sinnimo) para el nombre de host especificado (equipo u otro dispositivo de red). Puede usar los registros CNAME para ocultar los detalles de implementacin de su red a los clientes que se conectan a ella. Por ejemplo, [Link] es un alias (CNAME) del nombre real del equipo que ejecuta el servidor FTP para Microsoft. Los clientes se conectan a [Link] sin saber el nombre real del equipo. Esto tambin permite el desplazamiento del servidor FTP a un equipo distinto; slo ser necesario cambiar el registro CNAME. HINFO - El registro de recurso HINFO (host information ) identifica el tipo de hardware y el sistema operativo del host (equipo o cualquier otro dispositivo de red). Los identificadores del Tipo de CPU y del Sistema operativo deben proceder de MACHINE NAMES y SYSTEM NAMES que se enumeran en RFC 1700 (Nmeros asignados). ISDN - El registro de recurso ISDN (Integrated Services Digital Network) es una variacin del registro del recurso A (address). En lugar de asignar un nombre de host (equipo o cualquier otro dispositivo de red) a una direccin IP, el registro ISDN asigna el nombre a una direccin ISDN. Una direccin ISDN es un nmero de telfono que consta de un cdigo de pas, un prefijo de rea o de regin, un nmero de telfono local, y, en algunos casos, una subdireccin. El registro de recurso ISDN est diseado para utilizarse junto con el registro de recurso RT (route through). MB - El registro de recurso MB (mailbox ) es un registro experimental que especifica un host DNS (equipo o cualquier otro dispositivo de red) con el buzn de correos especificado. Otros registros experimentales relacionados son el registro de recurso MG ( mail group), el registro de recurso MR (mailbox rename ) y el registro de recurso MINFO (mailbox information). MG - El registro de recurso MG (mail group) es un registro experimental que especifica un buzn miembro del grupo de correos (lista de correos) especificado por nombre de dominio DNS. Otros registros experimentales relacionados son el registro de recurso MB (mailbox), el registro de recurso MR (mailbox rename) y el registro de recurso MINFO (mailbox information).

DNS y Microsoft Windows NT 4.0 97

MINFO - El registro de recurso MINFO (mailbox information ) es un registro experimental que especifica un buzn de correos que es responsable de la lista de correos o buzn que se especifique. Otros registros experimentales relacionados son el registro de recurso MB (mailbox), el registro de recurso MG (mail group) y el registro de recurso MR (mailbox rename). MR - El registro de recurso MR (mailbox rename) es un registro experimental que especifica un buzn que es el cambio de nombre correcto del otro buzn especificado. Otros registros experimentales relacionados son el registro de recurso MB ( mailbox ), el registro de recurso MG (mail group) y el registro de recurso MINFO (mailbox information ). MX - El registro de recurso MX (mail exchanger) especifica un servidor de intercambio de correos para un nombre de dominio DNS. Un servidor de correos es un host (equipo o cualquier otro dispositivo de red) que procesa o enva correo del nombre de dominio DNS. Procesar el correo significa entregarlo al destinatario o pasarlo a un tipo distinto de transporte de correo. Reenviar el correo significa enviarlo a su servidor de destino final, enviarlo a otro servidor de correos que est ms cerca del destino final usando el protocolo SMTP (Simple Message Transfer Protocol ), o dejarlo en la cola durante un tiempo determinado. NS - El registro de recurso NS (name server) identifica al servidor (o servidores) de nombres DNS para el dominio DNS. Los registros de recurso NS aparecen en todas las zonas y zonas inversas DNS (las del dominio DNS [Link]). PTR - El registro de recurso PTR (pointer) asigna una direccin IP a un nombre de host (equipo o cualquier otro dispositivo de red) de una zona inversa DNS (las del dominio DNS [Link]). Su homlogo, el registro de recurso A ( address), se usa para asignar un nombre de host (equipo o cualquier otro dispositivo de red) a una direccin IP de una zona DNS. RP - El registro de recurso RP (responsible person) indica quin es responsable del dominio DNS o host (equipo o cualquier otro dispositivo de red). Puede especificar mltiples registros RP para un dominio o host DNS dado. El registro tiene dos partes: una direccin de correo electrnico (en el mismo formato DNS que el del registro de recurso SOA) y un nombre de dominio DNS que apunta a informacin adicional acerca del contacto. RT - El registro de recurso RT (route through) especifica un host (equipo o cualquier otro dispositivo de red) intermedio que enruta los paquetes a un host de destino. El registro RT se usa junto con los registros de recurso ISDN y X25. Sintctica y semnticamente es parecido al tipo de registro MX y se usa de forma muy similar. SOA - El registro de recurso SOA (start of authority ) indica que este servidor de nombres DNS es la mejor fuente de informacin para los datos de este dominio DNS. Es el primer registro de cada uno de los archivos de la base de datos DNS. El Administrador de DNS, cuando se crea una nueva zona de DNS, crea automticamente el registro de recurso SOA. TXT - El registro de recurso TXT (text ) asocia la informacin de texto general con un elemento de la base de datos DNS. Se suele utilizar para identificar la ubicacin (por ejemplo, Ubicacin: Edificio 26S, Habitacin 2499) de un host (equipo o cualquier otro

98

DNS y Microsoft Windows NT 4.0

dispositivo de red). La cadena de texto debe ser de menos de 256 caracteres, pero se permiten mltiples registros del recurso TXT.

DNS y Microsoft Windows NT 4.0 99

WKS - El registro de recurso WKS (well-known service ) describe los servicios proporcionados por un protocolo en particular en una interfaz en particular. Normalmente, el protocolo es UDP o TCP, pero puede ser cualquiera de las entradas enumeradas en el archivo PROTOCOLS (\%Razdelsistema %\system32\drivers\etc\protocol). Los servicios son los servicios bajo el nmero de puerto 256 del archivo SERVICES (\%Razdelsistema%\system32\drivers\etc\services). X25 - El registro de recurso X25 (X.25) es una variacin del registro de recurso A (address). En lugar de asignar un nombre de host (equipo o cualquier otro dispositivo de red) a una direccin IP, el registro X25 asigna el nombre a una direccin X.121. X.121 es el estndar ISO (International Standards Organization ) que especifica el formato de las direcciones usadas en las redes X.25. El registro de recurso X25 est diseado para ser usado junto con el registro del recurso RT (route through). Registro genrico - El registro de recurso genrico se usa para agregar un registro de recurso no estndar a la base de datos DNS. El registro de recurso genrico es una funcin del Administrador DNS de Microsoft.

Agradecimiento especial a las siguientes personas por su ayuda en este proyecto:

Azfar Moazzam; James Gilroy; Dan Perry; Jim Harrison; Dave Macdonald; Steven Judd; Prakash Narasimhamurthy; Margaret Johnson; Rodger Seabourne

10 0

DNS y Microsoft Windows NT 4.0