Configuración DHCP Windows 2000

ndice Servicios de Red en Windows 2000 Server
Servicios de Red en Windows 2003
1. Servicio del Protocolo de configuracin dinmica de host (DHCP) 2. Funcionamiento del servicio de nombres de dominio (DNS) 3. Instalacin y configuracin del DNS 4. Servicio de nombres de Internet de Windows (WINS)
Tema 1.- Servicio del Protocolo DHCP

q
Descripcin de DHCP r Clientes y servidores de DHCP r mbitos y opciones de DHCP r Clases de opciones r Agentes rel de DHCP r Deteccin de servidor de DHCP no autorizado r Direccionamiento de IP privada automtica (APIPA) r Integracin de DNS r Integracin del Servicio Enrutamiento y acceso remoto r mbitos de multidifusin r Soporte BOOTP Instalacin y configuracin de un Servidor DHCP r Creacin de un nuevo mbito r Autorizacin del servidor DHCP y activacin de los mbitos r Agregacin de reservas de direcciones r Activacin de las actualizaciones dinmicas de un servidor DNS r Liberar, renovar o verificar una concesin con Ipconfig r Descripcin general de DHCP en Windows 2000 Funcionamiento de DHCP r Obtencin de una concesin inicial r Renovacin de una concesin r Cambios en subredes y servidores r Uso del agente rel de DHCP r Deteccin de servidores de DHCP no autorizados r Actualizacin de las entradas de DNS r Mensajes de DHCP Mensajes de DHCP r Formato general de los mensajes Opciones de DHCP r Formatos de las opciones r Opciones que admite Windows 2000
Ir a la pgina Principal
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/indice_m.htm06/01/2006 5:06:10
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-ind.htm
Tema 1.- Servicio del Protocolo DHCP

q
Descripcin de DHCP r Clientes y servidores de DHCP r mbitos y opciones de DHCP r Clases de opciones r Agentes rel de DHCP r Deteccin de servidor de DHCP no autorizado r Direccionamiento de IP privada automtica (APIPA) r Integracin de DNS r Integracin del Servicio Enrutamiento y acceso remoto r mbitos de multidifusin r Soporte BOOTP Instalacin y configuracin de un Servidor DHCP r Creacin de un nuevo mbito r Autorizacin del servidor DHCP y activacin de los mbitos r Agregacin de reservas de direcciones r Activacin de las actualizaciones dinmicas de un servidor DNS r Liberar, renovar o verificar una concesin con Ipconfig r Descripcin general de DHCP en Windows 2000 Funcionamiento de DHCP r Obtencin de una concesin inicial r Renovacin de una concesin r Cambios en subredes y servidores r Uso del agente rel de DHCP r Deteccin de servidores de DHCP no autorizados r Actualizacin de las entradas de DNS r Mensajes de DHCP Mensajes de DHCP r Formato general de los mensajes Opciones de DHCP r Formatos de las opciones r Opciones que admite Windows 2000
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-ind.htm06/01/2006 5:06:12
Servicio de Protocolo DHCP de Windows 2000
Servicio del Protocolo DHCP

q Descripcin de DHCP - Clientes y servidores de DHCP - mbitos y opciones de DHCP - Clases de opciones - Mensajes de DHCP - Concesiones y reservas de DHCP - Agentes rel de DHCP - Deteccin de servidor de DHCP no autorizado - Direccionamiento de IP privada automtica (APIPA) - Integracin de DNS - Integracin del Servicio Enrutamiento y acceso remoto - mbitos de multidifusin - Soporte BOOTP q Instalacin y configuracin de un Servidor DHCP - Creacin de un nuevo mbito - Autorizacin del servidor DHCP y activacin de los mbitos - Agregacin de reservas de direcciones - Activacin de las actualizaciones dinmicas de un servidor DNS - Liberar, renovar o verificar una concesin con Ipconfig - Descripcin general de DHCP en Windows 2000 q Funcionamiento de DHCP - Obtencin de una concesin inicial - Renovacin de una concesin - Cambios en subredes y servidores - Uso del agente rel de DHCP - Deteccin de servidores de DHCP no autorizados - Actualizacin de las entradas de DNS q Mensajes de DHCP - Formato general de los mensajes q Opciones de DHCP - Qu son las opciones de DHCP? - Formatos de las opciones - Opciones que admite Windows 2000
Para que un host con TCP/IP se comunique correctamente con otro, ambos deben estar configurados apropiadamente. Requieren una direccin de IP vlida y nica, una mscara de subred y una direccin de pasarela predeterminada, aunque se puede omitir si el host slo se va a comunicar en la subred local. Para redes mayores se necesita configurar otros elementos, como la direccin de IP de un servidor de DNS, la direccin de IP de un servidor WINS y los tipos de nodo NetBIOS. En grandes redes, asegurar que todos los hosts se han configurado correctamente puede ser una tarea de administracin y gestin importante, especialmente en redes dinmicas con usuarios mviles con ordenadores porttiles. La configuracin manual o la reconfiguracin de un gran nmero de equipos es una tarea que lleva mucho tiempo y un error en la configuracin de un host puede hacer que sea imposible que se comunique con el resto de la red. DHCP es un protocolo cliente-servidor que simplifica la administracin de la configuracin de los clientes de IP y la asignacin de los datos de configuracin de IP. Mediante DHCP, el administrador define todos los parmetros de configuracin necesarios en un servidor central, quien proporciona a los hosts toda la informacin de configuracin de IP. DHCP proporciona tres ventajas clave en la planificacin, diseo y mantenimiento de una red de IP:
q
Administracin centralizada de las configuraciones de IP. El administrador de DHCP puede administrar de manera centralizada toda la informacin de configuracin de IP. De esta forma se elimina la necesidad de configurar manualmente los hosts individualmente cuando se implanta por primera vez TCP/IP o cuando se necesitan cambios en la infraestructura de IP. Sencillez en la configuracin de IP de host. Mediante DHCP se asegura que los clientes de DHCP obtienen parmetros de configuracin de IP precisos y en tiempo, sin intervencin del usuario. Como la configuracin es automtica se elimina gran parte de los problemas. Flexibilidad. Utilizando DHCP, el administrador aumenta su flexibilidad para el cambio de la informacin de configuracin de IP, lo que permite que el administrador cambie la configuracin de IP de manera sencilla cuando se necesitan los cambios.
Descripcin general de DHCP en Windows 2000

DHCP es un protocolo cliente-servidor que proporciona automticamente a un host de IP su direccin IP y otra informacin de configuracin relacionada como la mscara de subred y la pasarela predeterminada. En las RFC 2131 y 2132 se define DHCP como un estndar del Internet Engineering Task Force (IETF) basado en el Protocolo de arranque, BOOTP (Bootstrap Protocol), con el que comparte muchos detalles de implementacin. DHCP permite que todos los hosts obtengan toda la informacin de configuracin necesaria desde un servidor de DHCP. Todos los Windows 2000 Server (incluyendo Server, Advanced Server y Data Center Server) incluyen el servicio Servidor de DHCP, que se instala como opcional. Todos los clientes de Microsoft Windows instalan automticamente el servicio cliente de DHCP como parte de TCP/IP, incluidos Windows 2000, Windows NT 4.0, Windows 98 y Windows 95.
Clientes y servidores de DHCP

Un equipo que obtiene su informacin de configuracin mediante DHCP se le conoce como un cliente de DHCP. Los clientes de DHCP se comunican con un servidor de DHCP para obtener su direccin de IP e informacin de configuracin de TCP/IP relacionada. Los servidores de DHCP mantienen la informacin sobre las direcciones de IP disponibles e informacin relacionada que haya definido el administrador de DHCP.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (1 of 23)06/01/2006 5:06:15
mbitos y opciones de DHCP

Se puede proporcionar a un cliente de DHCP un conjunto de direcciones de IP y la informacin de configuracin asociada, lo que se conoce como un mbito (scope). Un mbito es un conjunto de direcciones de IP que el servidor puede enviar a los clientes de DHCP, junto con una o ms opciones. Una opcin es un elemento concreto de configuracin como una mscara de subred o una direccin de IP de pasarela predeterminada, que el administrador de DHCP quiere que el servidor de DHCP proporcione a los clientes de DHCP. Un administrador de DHCP puede crear uno o ms mbitos en uno o ms servidores Windows 2000 ejecutando el servicio DHCP. Sin embargo, como los servidores de DHCP no se comunican informacin de mbito unos con otros, el administrador debe ser cuidadoso para asegurarse de que los mbitos estn definidos de forma que varios servidores de DHCP no manejen las mismas direcciones de IP para diferentes clientes, o manejen direcciones que se han asignado a hosts de IP configurados manualmente. Las direcciones de IP definidas en un mbito de DHCP son contiguas y asociadas con una mscara de subred. Para permitir que algunas de las direcciones de IP del mbito ya estn asociadas y en uso, el administrador de DHCP puede especificar una exclusin -una o ms direcciones de IP en el mbito que no se pueden enviar a los clientes de DHCP. En redes con mltiples subredes y mltiples redes es til tener estndares para separar las direcciones dinmicas de IP que ofrece DHCP de las direcciones que se usan para configurar manualmente los hosts. En el paquete del protocolo de DHCP, cada opcin comienza con un nico byte de marca que define la opcin. Una opcin puede ser de tamao fijo, como el Tipo de nodo de NetBIOS (Opcin 46); de tamao variable, como el Nombre de dominio del Servidor de nombres de dominio (DNS) (Opcin 15); o un array de elementos como la lista de Servidores de DNS (Opcin 6). Con el servicio DHCP de Windows 2000, el administrador de DHCP puede administrar las opciones en los siguientes cinco niveles:
q
Opciones predefinidas. Permite al administrador de DHCP especificar los valores de las opciones predeterminadas para todas las opciones que admite el servidor de DHCP y crear nuevos tipos de opcin para su uso en este servidor. Opciones de servidor. Valores asignados a todos los clientes y mbitos definidos en el servidor DHCP, a no ser que prevalezcan las opciones de mbito, clase o cliente. Opciones de mbito. Valores que se aplican slo a clientes de un mbito concreto, a no ser que prevalezcan las opciones de clase y de cliente. Opciones de clase. Permite que el administrador establezca opciones de clase por usuario o fabricante, proporcionando datos de opcin a una clase concreta de clientes DHCP, es decir, a todos los clientes de Windows 2000. Ante el conjunto de opciones de este nivel slo prevalecen las opciones asignadas en el nivel de cliente. Opciones reservadas por clientes. Se establecen para un cliente de DHCP individual. Slo prevalecen, a las opciones de este nivel, las opciones asignadas manualmente en el equipo cliente.
Clases de opciones
Una clase de opcin de DHCP es un conjunto adicional de opciones que se pueden proporcionar a un cliente de DHCP si el equipo forma parte de una clase de equipos. El administrador puede usarlo para administrar los valores de opcin que proporciona a los clientes de DHCP. Existen dos tipos de clases de opciones en un servidor de DHCP de Windows 2000: clases del fabricante y clases del usuario. Cuando el administrador configure las clases de opciones en un servidor de DHCP, un cliente que pertenezca a dicha clase, por ejemplo todos los equipos con Windows 2000, se les puede dar tipos de opciones concretas para esta clase para su configuracin. Para poder usar clientes anteriores de DHCP que no puedan enviar el ID de clase, el administrador puede configurar clases por defecto para los valores de opcin. De esta forma, los administradores pueden aprovechar opciones
concretas para clases particulares de clientes a la vez que le proporciona todas las opciones necesarias para otros clientes. Un cliente de DHCP puede indicar en los mensajes del protocolo DHCP que enva a un servidor que el cliente es miembro de una clase de usuario o fabricante en particular. El administrador puede usar DHCP para definir los valores de opcin que se devuelven para esta clase de cliente. Por ejemplo, el administrador puede configurar opciones especficas para equipos con Windows 2000, que se envan como valores de opcin (por ejemplo, si se enva un abandono de DHCP cuando se apaga el equipo). Otros clientes, como Windows 95, que no disponen de esta funcin, no deberan recibir estos valores. Para que un cliente de DHCP reciba valores de opcin de estas opciones extendidas, el cliente debe especificar una cadena opcin de clase de usuario que contenga una cadena con la identificacin del tipo de cliente. El servidor de DHCP puede usar esta identidad para enviar opciones extra al cliente. La opcin clase de usuario se establece con el comando IPCONFIG.
Agentes rel de DHCP

Cuando se arranca inicialmente un cliente de DHCP de Windows 2000, difunde mensajes de DHCP para obtener o renovar una concesin de un servidor de DHCP. El administrador de DHCP usa un Agente Rel de DHCP para centralizar los servidores de DHCP y evitar la necesidad de un servidor de DHCP en cada una de las subredes. Tambin conocido como agente rel de BOOTP, un agente rel de DHCP es un host o un enrutador de IP que escucha los mensajes de clientes de DHCP que se difunden en la subred y transfiere los mensajes a un servidor configurado con DHCP. El servidor DHCP enva mensajes de DHCP al agente rel que vuelve a difundirlos en la subred para el cliente de DHCP. El servicio Enrutamiento y acceso remoto de Windows 2000 Server incluye un agente rel de DHCP. El administrador de DHCP tiene que activar el Servicio Enrutamiento y acceso remoto, aadir el agente rel de DHCP y configurar las direcciones de IP del servidor de DHCP. Adems, la mayora de los enrutadores modernos se pueden configurar para proporcionar funciones rel. En muchos enrutadores se refiere a ello como Reenvo de BOOTP (BOOTP Forwarding).
Deteccin de servidor de DHCP no autorizado

Los servidores de DHCP configurados apropiadamente proporcionan informacin de configuracin de IP a las redes de IP. Sin embargo, cuando se introduce en una red un servidor de DHCP configurado de forma incorrecta, o se introduce un servidor de DHCP en una red equivocada, puede haber problemas. Por ejemplo, si un cliente consigue una concesin de un servidor configurado incorrectamente, el cliente puede recibir una direccin de IP no vlida, lo que impide que se pueda comunicar con el resto de la red. Ello impide que los usuarios se conecten. Con Windows 2000, un servidor de DHCP no autorizado es simplemente un servidor de DHCP que no ha sido autorizado explcitamente. A los servidores de DHCP no autorizados tambin se les denomina servidores rogue. En un entorno de dominios de Windows 2000, el servicio de DHCP de un servidor no autorizado fallar al inicializarse. El administrador debe autorizar explcitamente a todos los servidores de DHCP de Windows 2000 que funcionan en el entorno de un dominio de Active Directory. Durante la inicializacin, el servicio de DHCP de Windows 2000 comprobar su autorizacin y no arrancar si el servidor detecta que est en el entorno de un dominio y el servidor no tiene autorizacin explcita.
Direccionamiento de IP privada automtica (APIPA)

Los clientes de DHCP necesitan encontrar un servidor de DHCP para conseguir una concesin inicial. En la mayora de los casos, el cliente de DHCP encontrar un servidor en la subred local o a travs de un agente rel. Para permitir la posibilidad de que el servidor de DHCP no est disponible, Windows 2000 y Windows 98 proporcionan APIPA (Automatic Private IP Addressing). APIPA es una facilidad de la implementacin de TCP/IP de Windows 2000 para que un equipo obtenga informacin de configuracin de IP sin un servidor de DHCP ni configuracin manual.
Con APIPA se evita el problema de los hosts de IP que les es imposible comunicarse si, por alguna razn, el servidor de DHCP no est disponible. APIPA tambin es til en pequeos grupos de trabajo donde no existe un servidor de DHCP. Como la autoconfiguracin no dispone de pasarela predeterminada, slo funciona en una nica subred y no es apropiado para grandes redes. Si el cliente de DHCP no es capaz de localizar un DHCP, el equipo se autoconfigura con una direccin de IP aleatoria elegida de la red de clase B 169.254.0.0 de las reservadas para la IANA, con la mscara de red 255.255.0.0. El equipo as autoconfigurado comprueba si la direccin de IP elegida ya est en uso mediante una difusin de ARP gratuita. Si la direccin de IP elegida ya est en uso, el equipo elige aleatoriamente otra direccin. El equipo realiza diez intentos de encontrar una direccin de IP disponible. Una vez se ha verificado que la direccin seleccionada est libre, el cliente se configurar con esa direccin. El cliente de DHCP continuar comprobando si existe un servidor de DHCP cada 5 minutos, y si se encuentra, se usar la configuracin que indique el servidor de DHCP.
Integracin de DNS
Los clientes de Windows 2000 admiten la actualizacin dinmica de DNS, lo que permite que los clientes de DHCP actualicen su servidor de DNS configurado con la informacin de reenvo y bsqueda inversa.
Integracin del Servicio Enrutamiento y acceso remoto

El Servicio Enrutamiento y acceso remoto de Windows 2000 incluye una funcionalidad del servidor del Servicio de acceso remoto que permite que clientes de la Conexin telefnica o Redes privadas virtuales (VPN) accedan al servidor del Servicio Enrutamiento y acceso remoto unindose a la red local. Para el resto de equipos de la red local, estos clientes aparecen como iguales. En este caso el servidor de acceso remoto se comporta como una pasarela entre el cliente remoto y la red local. Los clientes del servicio de acceso remoto necesitarn una direccin de IP para la red local antes de empezar a funcionar. Aunque se puede configurar manualmente el cliente del Servicio de acceso remoto con una direccin de IP apropiada, es una sobrecarga de trabajo de administracin. Otra alternativa es que el Servicio Enrutamiento y acceso remoto de Windows 2000 est configurado para obtener cualquier direccin de IP necesaria de un servidor de DHCP. Cuando un servidor de acceso remoto de Windows 2000 se configura para que utilice DHCP para obtener las direcciones de IP, el servidor de acceso remoto obtiene 10 direcciones de IP de un servidor de DHCP. El servidor de acceso remoto usa la primera direccin conseguida para s mismo y asigna la otras direcciones a los clientes de acceso remoto con TCP/IP segn se conectan. Las direcciones de IP que se liberan cuando un cliente se desconecta se reutilizan. Cuando se estn utilizando las 10 direcciones de IP, el servidor de acceso remoto consigue otras diez ms. Cuando el Servicio Enrutamiento y acceso remoto se detiene, todas las direcciones conseguidas mediante DHCP se liberan. Si cuando se arranca el Servicio Enrutamiento y acceso remoto no hay disponible ningn servidor de DHCP, se usan las direcciones APIPA en el intervalo 169.254.0.1 a 169.254.255.254.
mbitos de multidifusin
Adems de dar concesiones de direcciones de IP, el servicio DHCP de Windows 2000 admite mbitos de multidifusin. Un mbito de multidifusin es un conjunto de direcciones de clase D para su uso en aplicaciones de multidifusin. Esta caracterstica permite que el administrador de DHCP controle las direcciones concretas de multidifusin que pueden utilizar las aplicaciones de multidifusin. Las aplicaciones deben haberse escrito para obtener la concesin de las direcciones de IP de multidifusin mediante DHCP.
Soporte BOOTP
DHCP se basa en BOOTP, un protocolo ms antiguo con una funcionalidad similar. BOOTP se dise inicialmente para permitir la configuracin en el arranque de estaciones de trabajo sin
disco. Los servidores de DHCP modernos responden tanto a las peticiones de DHCP como de BOOTP. Los clientes de BOOTP se inicializan a s mismos en los siguientes dos pasos: 1. El cliente de BOOTP solicita una direccin de IP y otra informacin de configuracin como la direccin de pasarela predeterminada, la direccin de IP del servidor de DNS, y otra informacin, desde un servidor de BOOTP. Esta informacin incluye un nombre de archivo de la imagen de arranque y el nombre del servidor de donde se debera obtener la direccin de IP. 2. El cliente de BOOTP se pone en contacto con el servidor y descarga el archivo con la imagen de arranque usando el Protocolo Trivial de Transferencia de Archivos (TFTP). Aunque DHCP ha superado a BOOTP, el servidor de DHCP de Windows 2000 permite el uso de clientes de BOOTP. El administrador puede definir un mbito de uso slo para los clientes de BOOTP. Adems puede definir un mbito para su uso tanto por clientes de BOOTP como de DHCP.
Instalacin y configuracin de un Servidor DHCP

Antes de instalar el servidor DHCP hay que determinar el esquema de direcciones IP. Tambin se deben completar estos pasos adicionales antes de instalar DHCP:
q
q q
Determinar el intervalo de direcciones IP libres y nicas que manejar el servidor DHCP adems de cualquier direccin IP que sea necesario excluir para soportar hosts con direcciones IP estticas. Hacer una lista de los servidores para los que se desea reservar una IP (como servidores DNS y WINS). Si el servidor DHCP utilizara direcciones IP registradas en Internet, hay que registrar las direcciones IP con el ISP Determinar los requisitos de hardware y de almacenamiento del servidor DHCP Configurar manualmente las direcciones estticas en el equipo donde se instalar el servicio DHCP
Para instalar el servicio DHCP hay que seguir estos pasos: 1. Abrir la herramienta Configurar el servidor ejecutndola desde la carpeta Herramientas
administrativas.
2.
Pulsar el ttulo Red en la columna de la izquierda y pulsar despus el subttulo DHCP 3. Pulsar en el hipervnculo Iniciar para ejecutar el Asistente para componentes de Windows. 4. Pulsar Siguiente en la primera pantalla del Asistente para componentes de Windows. 5. Seleccionar Servicios de red en la lista de componentes y pulsar Detalles. 6. Seleccionar la casilla de verificacin junto a Protocolo de configuracin dinmica de host (DHCP) y pulsar Aceptar. Pulsar Siguiente para instalar el servicio. Todos los archivos necesarios se copian al disco duro.
Creacin de un nuevo mbito

Ahora ya se puede ejecutar el Administrador DHCP y crear un nuevo mbito de direcciones IP para que las gestione el servidor DHCP. Pero antes de hacer esto, hay que asegurarse de que se conoce el intervalo de direcciones IP aprobado, qu direcciones IP son necesarias excluir para los sistemas con direcciones IP estticas y qu direcciones son necesarias reservar para servidores DNS o WINS. Para abrir el Administrador DHCP y crear el nuevo mbito, hay que seguir los siguientes pasos: 1. Escoger DHCP del men Herramientas administrativas. 2. Seleccionar el servidor DHCP en el rbol de la consola. Seleccionar el men Accin y escoger mbito nuevo para ejecutar el Asistente para mbito nuevo. 3. Pulsar Siguiente e introducir el nombre y la descripcin del mbito que servirn para
distinguir este mbito de otros. Pulsar Siguiente. 4. Introducir la direccin IP por la que se desea que comience el mbito en el campo Iniciar, e introducir la direccin IP por la que se desea qu finalice el mbito en el campo Fin. 5. Introducir la mscara de subred de la red en el cuadro Mscara de subred, o utilizar el cuadro Longitud para ajustar la longitud de la mscara de subred. Despus, pulsar Siguiente. 6. Para excluir un intervalo de direcciones del mbito, en el cuadro Iniciar direccin IP, hay que introducir la direccin IP de comienzo para el intervalo de exclusin; en el cuadro Fin de direccin IP hay que introducir la direccin IP final del intervalo de exclusin. Despus hay que pulsar Agregar. Hay que aadir las exclusiones que sean necesarias y pulsar Siguiente cuando se haya terminado. 7. Especificar la duracin de la concesin a los clientes y pulsar Siguiente. Conviene utilizar concesiones ms largas en redes sin servidores DHCP redundantes para permitir ms tiempo de recuperacin de un servidor DHCP sin conexin antes de que los clientes pierdan sus concesiones, o para minimizar el trfico de red a expensas de una renovacin de direcciones menos frecuente. Tambin se pueden utilizar concesiones ms largas si las direcciones del mbito son abundantes (al menos un 20 por ciento disponible), la red es estable y los equipos rara vez se mueven. Por el contrario, los mbitos que soportan clientes que acceden telefnicamente pueden tener concesiones ms cortas y, por lo tanto, funcionar bien con menos direcciones. 8. Para configurar las opciones de DHCP, existen dos opciones:
q
Configurar estas opciones ahora; Si se decide especificar las opciones DHCP continua el asistente solicitando las opciones ms corrientes dentro del servidor DHCP. Estas opciones son:

q
Puertas de enlace (enrutadores) que se desee que utilicen los clientes en el cuadro Direccin IP, pulsando el botn Agregar despus de introducir cada uno. Cuando se haya terminado de introducir puertas de enlace hay que pulsar Siguiente.
Nombre del dominio: en el cuadro Dominio primario, y aadir las direcciones IP de los servidores DNS en el cuadro Direccin IP, pulsando Agregar tras introducir cada una. Hay que pulsar Siguiente cuando se haya terminado. q Direccin IP de Servidores WINS, hay que introducir las direcciones de todos los servidores WINS que se hayan configurado en la red para asignar direcciones IP a los nombres NetBIOS de los clientes de nivel inferior. Pulsar Siguiente. q Configurar estas opciones ms tarde. Si seleccionamos esta opcin se finaliza la instalacin del Servidor. 9. Para activar el mbito inmediatamente, hay que pulsar Activar este mbito ahora; en caso contrario, hay que pulsar Activar este mbito ms tarde. Hay que pulsar Siguiente y pulsar despus Finalizar para completar la configuracin del mbito.
Autorizacin del servidor DHCP y activacin de los mbitos

Despus de configurar el servidor DHCP y crear los mbitos, es necesario activar los mbitos antes de que cualquier cliente pueda utilizar el servidor para obtener direcciones IP. Antes de que se puedan activar los mbitos, el servidor tiene que ser autorizado a realizar concesiones, a menos que se haya instalado DHCP en un controlador de dominio, en cuyo caso el servidor DHCP ser autorizado automticamente la primera vez que se aada el servidor a la consola Administrador DHCP. La autorizacin de un servidor DHCP es una opcin importante que proporciona Windows 2000 para reducir la capacidad de los hackers de configurar servidores DHCP corrompidos: servidores no autorizados configurados para proporcionar direcciones IP falsas a los clientes. Para autorizar el servidor DHCP despus de instalar el servicio, hay que seguir los siguientes pasos:
1. En el Administrador DHCP hay que seleccionar DHCP en la raz del rbol de la consola. 2. Escoger Administrar servidores autorizados en el men Accin. 3. Seleccionar Autorizar en el cuadro de dilogo Administrar servidores autorizados. 4. Introducir el nombre o la direccin IP del servidor en el cuadro de texto proporcionado y pulsar Aceptar. 5. Verificar que la informacin es correcta en el cuadro de dilogo que se muestra y entonces pulsar S. Hay que pulsar Aceptar para cerrar el cuadro de dilogo Administrar servidores autorizados. 6. Para activar un mbito hay que seleccionarlo en el rbol de la consola y escoger despus Activar en el men Accin. No se debe activar un mbito hasta que se hayan terminado de seleccionar todas las opciones deseadas. Una vez activado un mbito, el comando Activar del men cambia a Desactivar. No se debe desactivar un mbito a no ser que vaya a ser retirado permanentemente de la red.
Concesiones y reservas de DHCP

Las direcciones de IP que adquiere DHCP normalmente no son permanentes. Cuando un cliente de DHCP se configura mediante DHCP, adquiere una concesin de la direccin asignada. La duracin de la concesin la define el administrador de DHCP. En Windows 2000, el administrador puede especificar un tiempo de concesin, entre 1 minuto y 999 das, o un tiempo de concesin sin lmite. Aunque se asignarn dinmicamente la mayora de las direcciones de IP, Windows 2000 permite que un administrador de DHCP cree una reserva. Una reserva es una concesin permanente de una direccin que crea el administrador de DHCP para asignar una direccin de IP concreta (y las opciones de DHCP) a un cliente concreto. El administrador crea la reserva especificando la direccin de IP que se asigna y la direccin MAC del host. La reserva asegura que el cliente de DHCP con una Tarjeta de interfaz de red, NIC (Network Interface Card), con esa direccin MAC siempre obtenga la misma direccin de IP y las mismas opciones. Para aadir un reserva de direccin a un mbito:
1. Seleccionar la carpeta Reservas bajo el mbito deseado y en el men Accin escoger Reserva nueva. 2. Introducir el nombre de la reserva en el cuadro Nombre de reserva. 3. Introducir la direccin IP para el cliente en el cuadro Direccin IP e introducir la direccin MAC del cliente en el cuadro Direccin MAC. 4. Introducir una descripcin para la reserva en el cuadro Descripcin. 5. Determinar a qu tipo de cliente se desea permitir que utilice la reserva seleccionando Slo DHCP, Slo BOOTP o Ambos. A continuacin, pulsar Agregar. Para obtener la direccin MAC hay que ir al equipo cliente y escribir Ipconfig /all en el smbolo del sistema. La direccin MAC se muestra como direccin fsica.
Activacin de las actualizaciones dinmicas de un servidor DNS

Los servidores DHCP y DNS de Windows 2000 soportan ahora actualizaciones dinmicas con un servidor DNS. Los clientes Windows 2000 pueden actualizar dinmicamente sus registros de bsquedas directas ellos mismos con el servidor DNS despus de obtener una nueva direccin IP de un servidor DHCP Adems, el servidor DHCP de Windows 2000 soporta tambin actualizacin dinmica de registros DNS para clientes anteriores a Windows 2000 que no lo puedan hacer ellos mismos. Esta caracterstica slo funciona actualmente con los servidores DHCP y DNS de Windows 2000. Para permitir que un servidor DHCP actualice dinmicamente los registros DNS de sus clientes, hay que seguir los siguientes pasos: 1. Seleccionar el mbito o el servidor DHCP en el cual se desea permitir actualizaciones
dinmicas. 2. En el men Accin, escoger Propiedades y pulsar despus la pestaa DNS. 3. Actualizar automticamente la informacin del cliente DHCP en DNS. Actualizar DNS slo a peticin del cliente DHCP: Para actualizar los registros DNS de un cliente basndose en el tipo de peticin DHCP que hace el cliente y slo cuando sea solicitado. q Actualizar siempre DNS: Para actualizar siempre los registros de bsqueda directa e inversa de un cliente. 4. Descartar las bsquedas directas al caducar la concesin: se debe seleccionar para permitir que el servidor DHCP borre el registro de recurso Host de un cliente cuando su concesin DHCP caduque y no sea renovada. 5. Habilitar actualizaciones para clientes DNS que no sean compatibles con actualizaciones dinmicas: se debe seleccionar para permitir que el servidor DHCP actualice los registros de bsqueda directa e inversa de los clientes que no pueden actualizar sus propios registros de bsqueda directa. Si no se selecciona esta casilla de verificacin, el servidor DHCP no actualizar dinmicamente los registros DNS de los clientes que no sean Windows 2000.
q
Si se tienen servidores DNS estticos como los de Windows NT 4, estos servidores no podrn interactuar dinmicamente cuando las configuraciones de los clientes DHCP cambien. Esta incompatibilidad puede provocar bsquedas fallidas en los clientes DHCP Para evitar este problema, hay que actualizar los servidores DNS estticos con un DNS que soporte DNS dinmico (Windows 2000).
Liberar, renovar o verificar una concesin con Ipconfig

En un equipo que ejecuta Windows con DHCP activado se puede ejecutar una utilidad de lnea de comandos para liberar, renovar o verificar la concesin de direccin del cliente. En el smbolo del sistema (o en la ventana Ejecutar) hay que utilizar alguno de los siguientes comandos:
q q q
Para liberar una concesin de un cliente, hay que escribir Ipconfig /release. Para renovar una concesin, hay que escribir Ipconfig /renew. Para verificar la concesin del cliente, hay que escribir Ipconfig /all.
Con clientes Windows 95/98/ME hay que utilizar Winipcfg con los mismos parmetros. El programa Ipconfig es til a la hora de solucionar problemas porque muestra cada detalle de la configuracin TCP/IP actual.
Funcionamiento de DHCP
Los hosts utilizan el protocolo DHCP para obtener una concesin inicial, renovar una existente y detectar servidores de DHCP no autorizados.
Obtencin de una concesin inicial

La adquisicin de una concesin inicial ocurre la primera vez que un cliente de DHCP arranca. El cliente de DHCP difunde, en primer lugar, el mensaje DHCPDISCOVER para buscar un servidor de DHCP. Como el host no tiene direccin de IP, se comunica con el servidor de DHCP mediante un mensaje de difusin en el rea local. Si hay ms de un servidor de DHCP que puede proporcionar al cliente de DHCP una direccin de IP vlida, es posible que el cliente reciba una o ms respuestas DHCPOFFER. Si ocurre esto, el cliente elige la mejor de ellas, que en Windows 2000 ser la primera recibida. Para ayudar al cliente a decidir cul es la mejor oferta, el mensaje DHCPOFFER contiene valores para las opciones que el cliente haba solicitado y que se configuran en el servidor de DHCP que la entrega. Cualquier servidor de DHCP que recibe un mensaje DHCPREQUEST y puede asignar al cliente de DHCP una concesin, enviar un mensaje DHCPOFFER con la direccin de IP ofrecida y valores de opcin. Si el cliente puede aceptar esta concesin, enva una DHCPREQUEST al servidor de DHCP, solicitando la direccin de IP ofrecida. Esta solicitud tambin contendr todas las opciones de configuracin que el cliente de DHCP desea obtener. El mensaje final, DHCPACK, se enva desde el servidor de DHCP hasta el cliente de DHCP para confirmar que el cliente tiene la direccin de IP y los valores de las opciones solicitadas que especific el administrador de DHCP en el servidor.
Renovacin de una concesin

Los clientes de DHCP intentarn renovar la concesin tras cada reinicio o a intervalos regulares despus del inicio del cliente de DHCP. La renovacin de una concesin supone slo dos mensajes de DHCP, DHCPREQUEST y DHCPACK. Si el cliente de DHCP renueva una concesin mientras se reinicia, se usan paquetes de IP de difusin para enviar estos mensajes. Si la renovacin de la concesin se realiza mientras se est ejecutando el cliente de DHCP, el cliente y el servidor de DHCP se comunican mediante direccin IP unicast. Cuando un cliente obtiene una concesin, DHCP proporciona los
valores para las opciones de configuracin solicitadas por el cliente. Reduciendo el tiempo de concesin, el administrador fuerza a los clientes a solicitar peridicamente una renovacin de la concesin y obtener detalles actualizados de configuracin. Puede ser til cuando el administrador desea cambiar la configuracin de IP de una subred. Un cliente de DHCP intenta en primer lugar volver a conseguir su concesin a la mitad del tiempo de concesin, conocido como T1. Si falla el cliente intentar de nuevo una nueva renovacin de la concesin al 87,5 por 100 del tiempo de concesin, conocido como T2. Si no se consigue obtener
la concesin antes de que expire (por ejemplo, si el servidor de DHCP no est accesible), en cuanto expira la concesin el cliente libera la direccin de IP e intenta conseguir una nueva concesin.
Cambios en subredes y servidores

Si el cliente de DHCP solicita una conexin mediante un mensaje DHCPREQUEST y el servidor de DHCP no puede cumplir (por ejemplo, cuando se traslada un porttil a una subred distinta), el servidor de DHCP enva un mensaje DHCPNAK al cliente. El cliente conseguir una nueva concesin usando el proceso de adquisicin de concesin inicial. Cuando arranca un cliente de DHCP difunde un mensaje DHCPREQUEST para renovar su concesin. Ello le asegura que la solicitud de renovacin de DHCP se enva al servidor de DHCP que proporciona direcciones de DHCP para la subred en la que se encuentra ahora el cliente, que puede ser distinta de la del servidor de DHCP que proporcion la concesin inicial. Cuando el servidor de DHCP recibe la difusin, compara la direccin del cliente de DHCP solicitante con el mbito configurado en el servidor. Si es imposible satisfacer la solicitud del cliente, el servidor de DHCP enva un DHCPACK y el cliente consigue una nueva concesin. Si el cliente de DHCP no es capaz de localizar ningn servidor de DHCP cuando se reinicia, para renovar su concesin enva una difusin de ARP para la pasarela predeterminada que se obtuvo anteriormente, si la hubo. Si la direccin de IP de la pasarela predeterminada se resuelve correctamente, el cliente de DHCP supone que se encuentra situado en la misma red donde obtuvo su concesin actual que contina usando. Si la difusin de ARP del cliente enviada para la pasarela predeterminada no recibe respuesta, el cliente supone que el cliente se ha trasladado a una red que no dispone actualmente de servicios de DHCP, como la red de casa, y se autoconfigura l mismo mediante APIPA. Una vez autoconfigurado a s mismo, el cliente de DHCP intentar, cada 5 minutos, localizar un servidor de DHCP.
Uso del agente rel de DHCP

Los agentes rel de DHCP escuchan los mensajes DHCPDISCOVER y DHCPREQUEST (y DHCPINFORM) que se difundan. El agente rel de DHCP espera un cierto tiempo configurado y, si no se detecta respuesta, enva un mensaje al servidor de DHCP configurado mediante unicast. El servidor acta entonces en el mensaje y reenva la respuesta de vuelta al agente rel de DHCP. El agente rel difunde el mensaje por la red consiguiendo que el cliente de DHCP lo reciba.
Deteccin de servidores de DHCP no autorizados

Como parte de la inicializacin del servicio de DHCP, todos los servidores de DHCP realizan una deteccin de servicios rogue. Si el servidor no est autorizado en el Active Directory, se apaga. La deteccin de servidor rogue comienza con la inicializacin del servidor de DHCP enviando una solicitud DHCPINFORM para determinar si existen otros servidores de DHCP inicializados en cualquier red conectada. Si es as, estos servidores responden con un mensaje DHCPACK que contiene el nombre del dominio en el que tienen autorizacin. Si se encuentran otro
servidor de DHCP, el servicio de DHCP de Windows 2000 que est arrancando se conecta con el Active Directory y enva una serie de llamadas LDAP para descubrir si est autorizado o no. Si el servidor no est autorizado, el servicio termina. Esta deteccin se lleva a cabo una vez cada hora por el servidor de DHCP para detectar nuevos servidores no autorizados. Si est activado el registro de sucesos de DHCP, se escribe un mensaje en el registro de sucesos de DHCP.
Actualizacin de las entradas de DNS

Cuando se concede una concesin de DHCP a un host de IP, es importante que la correspondencia entre el nombre y la direccin de IP se guarde en el DNS. Normalmente era una tarea manual, que involucraba la creacin de entradas directas de DNS y de bsqueda inversa. Windows 2000 implementa el protocolo de actualizacin dinmica de DNS descrito en la RFC 2136. Este protocolo permite a los clientes de Windows 2000 enviar automticamente entradas de DNS a un servidor de DNS. Cada vez que un cliente de DHCP recibe una nueva concesin o renueva una existente, el cliente enva su nombre completo cualificado al servidor de DHCP dentro del mensaje DHCPREQUEST. El mensaje DHCPREQUEST solicita al servidor de DHCP que registre la correspondencia de bsqueda inversa en el servidor de DNS de parte del cliente. El cliente de DHCP, normalmente, maneja el registro de bsqueda inversa por su cuenta, si es posible. El administrador de DHCP puede configurar el servidor de DHCP para que enve actualizaciones de DHCP tanto de la correspondencia de direcciones directas como inversas al servidor de DNS. Es til para los clientes de DHCP de bajo nivel que no disponen de actualizacin dinmica de DNS. El servidor de DHCP solicita el registro Inicio de autoridad, SOA (Start of Authority), de DNS para la zona de bsqueda directa, despus actualiza la entrada de bsqueda directa del cliente de DHCP. El servidor de DHCP solicita, a continuacin, al servidor de DNS la zona de bsqueda inversa y realiza la actualizacin de la entrada de bsqueda inversa del cliente de DHCP. Para que las actualizaciones dinmicas funcionen correctamente, el servidor de DNS debe disponer de actualizaciones dinmicas de DNS y tener configuradas las zonas de bsqueda directa e inversa para permitir actualizaciones dinmicas. El servicio de DNS de Windows 2000 admite las actualizaciones dinmicas de DNS, pero, por defecto, para las nuevas zonas no se permite la actualizacin dinmica. Si, por alguna razn, no est configurada la actualizacin dinmica de una zona cuando el servidor de DHCP intenta actualizar la entrada de DNS, el servidor recibir un error del servidor de DNS.
Mensajes de DHCP
El formato de los mensajes de DHCP se basa en el formato de los mensajes usados en el protocolo BOOTP.
Formato general de los mensajes

En la RFC 2131 se define el formato de los mensajes enviados entre un cliente y un servidor de DHCP. El formato bsico de los mensajes contiene los siguientes campos:
q q
Tipo de mensaje (Op) 8 bit.Tipo de mensaje. Tipo de direccin hardware (Htype) 8 bit. Tipo de direccin de hardware tal como se define en la seccin ARP de la RFC 1700; por ejemplo, < 0x1> significa 10 Mb Ethernet. Tamao de la direccin hardware (Hlen) 8 bit. Tamao de la direccin de hardware en bytes; por ejemplo, < 0x6> para 10 Mb Ethernet. Saltos (Hops) 8 bit. El cliente de DHCP lo establece a 0. Los agentes rel pueden utilizarlo opcionalmente cuando el cliente de DHCP arranca a travs del agente rel. ID de transaccin (Xid) 32 bit. Nmero aleatorio que se utiliza para indicar una conversacin entre un cliente de DHCP y un servidor de DHCP; por ejemplo, una
q q q
adquisicin de una concesin. Segundos (Secs) 16 bit. Lo rellena el cliente de DHCP. Nmero de segundos transcurridos desde que el cliente de DHCP inici el proceso de adquisicin de direccin. Indicadores (Flags) 16 bit. Indicadores que establece el cliente. En la RFC 2131 slo se define el indicador Difusin (Broadcast). Un cliente de DHCP que no puede recibir datagramas de IP unicast hasta que se haya configurado con una direccin de IP establece este indicador de Difusin. Direccin de IP del cliente (Ciaddr) 32 bit. Se rellena slo si el cliente tiene una direccin de IP y puede responder a las solicitudes de ARP para defender su direccin de IP. Su direccin de IP (Yiaddr) 32 bit. La direccin que da el servidor de DHCP al cliente de DHCP. Direccin de IP del servidor de DHCP (Siaddr) 32 bit. Direccin de IP del servidor de DHCP que ofrece la concesin (devuelto por DHCPOFFER). Direccin de IP de la pasarela (Giaddr) 32 bit. Direccin de IP del agente rel de DHCP usado cuando se arranca mediante un agente rel de DHCP. Direccin hardware del cliente (Chaddr) 16 bytes. Direccin de hardware del cliente. Nombre de host del servidor (Sname) 64 bytes. Windows 2000 no utiliza este campo. Nombre del archivo de arranque (File) 32 bit. Nombre del archivo que contiene una imagen del arranque para el cliente de BOOTP. Opciones (Options) tamao variable. Conjunto de tamao variable de campos con opciones de DHCP.
Los mensajes de DHCP constan de una parte fija -de 236 bytes de tamao- y una seccin de tamao variable para opciones. Como los mensajes de DHCP se transmiten usando UDP, todos los mensajes de DHCP deben caber completos en un datagrama, lo que limita la seccin de tamao variable a una MTU de 264 bytes, permitiendo una cabecera de IP de 20 bytes y una cabecera de UDP de 8 bytes. Por tanto, el lmite para Ethernet es de 1.236 bytes.
DHCPDISCOVER
Un cliente de DHCP que desea encontrar un servidor para conseguir una concesin enva el mensaje DHCPDISCOVER. Mediante DHCP, ste es el primer paso para conseguir una direccin de IP. Como el cliente de DHCP tiene una direccin de IP vlida, el mensaje DHCPDISCOVER se transmite usando la direccin de IP de difusin limitada 255.255.255.255 y una direccin de IP de origen 0.0.0.0. Antes de transmitir el mensaje DHCPDISCOVER, el cliente de DHCP rellena los campos de la porcin de tamao fijo del mensaje de DHCP de la siguiente forma:
q q q q q q
Op. Se establece a 1, BOOTREQUEST. Htype, Hlen. Se establecen segn el tipo de red utilizado. Hops, Secs, Glags. Se establecen a 0. Xid. El cliente selecciona un valor aleatorio de 32 bits. Ciaddr, Yiaddr, Siaddr, Giaddr. Todos a 0. Chaddr. Se establece a la direccin MAC del cliente de la interfaz que consigue la concesin de DHCP y es la direccin que se utiliza en los mensajes de DHCP siguiente para referirse a esta interfaz en el cliente. Cname, File. Se establecen a 0.
El cliente de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPDISCOVER. Las opciones son las siguientes:
q
q q q
Cookie mgica. Siempre se establece a 99.130.83.99 para indicar que sigue una extensin del fabricante. Identificador de cliente. Se establece a la direccin de hardware del cliente de DHCP. Nombre de host. Se establece al nombre de host del cliente. Clase del cliente. Se establece a <MSFT 5.0> para indicar que es un sistema con Windows 2000. Lista de parmetros solicitados. Indica los parmetros que el cliente desea obtener del servidor. Para Windows 2000 son 0x01 (mscara de subred), 0x0F (nombre de dominio de DNS), 0x03 (pasarela predeterminada), 0x06 (servidores de DNS), 0x2C (direccin del servidor WINS), 0x2E (tipo de nodo de NetBIOS), 0x2F (ID de mbito de NetBIOS), 0x2B (informacin de clase del fabricante).
El mensaje DHCPDISCOVER de Windows 98 no enva informacin de clase del cliente y no solicita informacin de clase del fabricante. Adems, el mensaje DHCPDISCOVER de Windows 98 enva un mensaje Solicitud de opcin con la Opcin 57, un mensaje de DHCP de tamao mximo que no acta con un servidor de DHCP de Windows 2000.
DHCPOFFER
Cuando un servidor de DHCP recibe un DHCPREQUEST, el servidor usa el campo Chaddr para identificar al cliente que solicita la concesin de DHCP. El servidor comprueba en primer lugar en la base de datos si el cliente de DHCP que solicita la concesin ya tiene una concesin o una reserva de una concesin. Si no es as, el servidor de DHCP comprueba si tiene configurado un mbito desde el que asignar una concesin de direccin de IP. Para determinar qu mbito utilizar para la asignacin de direccin, el servidor de DHCP examina el campo Giaddr del mensaje DHCPDISCOVER. Si Giaddr es 0, el servidor de DHCP usa la interfaz por la que se recibi el mensaje para determinar el mbito. Al contrario, si el campo Giaddr no es 0, el servidor usa el mbito que corresponde a la subred donde se encuentra el agente rel de DHCP. Si no existe una concesin al cliente, el servidor de DHCP examina el mbito elegido donde buscar una direccin de IP para el cliente. Si el cliente ya tiene asignada una concesin previa, pero ha expirado, y la direccin est disponible, el servidor de DHCP ofrece esta direccin. En otro caso, el servidor escoge una direccin disponible del mbito que se usa para asignar. Si el servidor de DHCP puede ofrecer una concesin, construye un mensaje DHCPOFFER con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q q q
Op. Se establece a 2. Htype. Se establece segn el hardware de red que se utilice. Xid. Se establece al Xid del DHCPDISCOVER recibido. Yiaddr. Se establece a la direccin de IP que se ofrece al cliente de DHCP. Siaddr. Se establece a la direccin de IP del servidor de DHCP que ofrece la concesin. Chaddr. Se establece a la direccin de hardware del cliente como se recibi en el mensaje DHCPDISCOVER.
El servidor de DHCP tambin establece la siguiente serie de opciones:

q q q q
q q q
Cookie mgica. Se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 2 (DHCPOFFER). Mscara de subred. Se obtiene de la definicin de mbito. Tiempo de renovacin (T1). Se establece al 50 por 100 del tiempo de concesin, en segundos. Tiempo de reconexin (T2). Se establece al 87,5 por 100 del tiempo de concesin, en segundos. Tiempo de concesin de la direccin de IP. Duracin de la concesin, en segundos. Identificacin del servidor. Direccin de IP del servidor que ofrece la concesin. Nombre de dominio. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), el nombre de dominio de DNS especificado en la definicin de mbito. Servidor de nombre de dominios. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), la lista de los servidores de DNS especificados en la definicin de mbito. Servidor de nombre de NetBIOS. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), la lista de servidores WINS especificados en el mbito. Tipo de nodo de NetBIOS. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), el tipo de nodo de NetBIOS especificado en la definicin de mbito.
El cliente de DHCP que envi un DHCPDISCOVER puede recibir cero o ms mensajes DHCPOFFER. Si no se reciben mensajes DHCPOFFER, el cliente de DHCP retransmite el mensaje DHCPDISCOVER. Si el cliente no recibe ninguna oferta tras tres intentos, el cliente inicia la autoconfiguracin mediante APIPA.
DHCPREQUEST
Un cliente de DHCP enva DHCPREQUEST a un servidor de DHCP, normalmente durante la adquisicin inicial de una concesin, es decir, en respuesta a un DHCPOFFER, o dentro de una renovacin de la concesin posterior. Un host DHCP puede usarlo para confirmar la direccin de IP asignada anteriormente y los parmetros asociados de configuracin. Con la informacin del mensaje DHCPOFFER, o con las propiedades de DHCP configuradas actualmente, el cliente de Windows 2000 construye un mensaje DHCPREQUEST con los siguientes campos en la porcin de tamao fijo del mensaje:
q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER original (en concesiones nuevas) o a un nuevo ID de transaccin (en las renovaciones de concesin y las confirmaciones de IP). Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original. Ciaddr. En las nuevas concesiones, este campo se establece a 0; en la renovacin de una concesin se establece a la direccin que se desea renovar, o si la concesin ha expirado, a la direccin de IP que se concedi anteriormente al cliente de DHCP.
El cliente de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPREQUEST. Estas opciones son las siguientes:
q q q q
q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x03 (DHCPREQUEST). Identificador de cliente. Se establece a la direccin de hardware del cliente de DHCP. Direccin solicitada. Es la direccin ofertada en el mensaje DHCPOFFER. Si se reciben varias ofertas, es la direccin que el cliente eligi del conjunto de direcciones recibidas y, por tanto, la que pide ahora el cliente. ID de servidor. El cliente dirige la solicitud de DHCP a este servidor. Nombre de host. Es el nombre de host del cliente de DHCP. Actualizacin dinmica de DNS. Esta opcin, no definida en la RFC 2131, contiene el nombre de host que usar el servidor de DHCP para dar formato a las actualizaciones directas a inversas de DNS. Informacin de clase del cliente. Especifica la clase del fabricante del cliente de DHCP. En los equipos con Windows 2000, la cadena identificador de clase es MSFT 5.0. El servidor de DHCP la utiliza para identificar el tipo de clase de cliente a identificar cualquier informacin especfica de un fabricante que deba devolver. Lista de parmetros solicitados. Lista de los parmetros de configuracin que el cliente desea obtener. En los clientes con Windows 2000 esta lista contiene las opciones 0x01 (mscara de subred), 0x03 (enrutador), 0x06 (lista de servidores de DNS), 0x0F (nombre de dominio), 0x2B (informacin concreta del fabricante), 0x2C (lista de servidores de WINS), 0x2E (tipo de nodo de NetBIOS) y 0x2F (mbito de NetBIOS). Los mensajes DHCPREQUEST de Windows 98 son similares a los que envan los clientes de Windows 2000. El cliente de Windows 98 enva la Opcin 57 (tamao mximo de mensaje de DHCP), aunque el servidor de DHCP de Windows 2000 no lo asiente. El cliente de Windows 98, sin embargo, no enva la opcin actualizacin dinmica de DNS, ni informacin de clase del fabricante en la lista Parmetros solicitados.
DHCPACK
El servidor de DHCP enva el mensaje DHCPACK al cliente de DHCP en respuesta a los mensajes DHCPREQUEST o DHCPINFORM. El mensaje DHCPACK es una confirmacin del servidor de DHCP de que ha enviado al cliente de DHCP una concesin con la direccin de IP y proporciona los valores de todas las opciones solicitadas, como se han especificado en la lista de parmetros solicitados del mensaje DHCPREQUEST. El servidor de DHCP de Windows 2000 construye un mensaje DHCPACK con los siguientes campos en la porcin de tamao fijo del mensaje:
q q q
Op. Se establece a 2. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER original (en nuevas concesiones) o a un nuevo ID de transaccin (en renovacin de concesin y confirmacin de la direccin de IP). Yiaddr. Se establece a la direccin de IP del cliente. El servidor de DHCP enva esta direccin al cliente. Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original.
El servidor de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPREQUEST. Las opciones son las siguientes:
q q q
q q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x05 (DHCPACK). Tiempo de renovacin (T1). Se establece al 50 por 100 del tiempo de concesin, en segundos. Tiempo de reconexin (T2). Se establece al 87,5 por 100 del tiempo de concesin, en segundos. Tiempo de concesin de la direccin de IP. Duracin de la concesin, en segundos. ID de servidor. El cliente dirige la solicitud de DHCP a este servidor Mscara de subred. La mscara de subred del cliente. Actualizacin dinmica de DNS. Se enva en respuesta a la actualizacin dinmica de DNS del mensaje DHCPREQUEST.
Adems, en el servidor de DHCP se enviarn todos los valores de opcin para cualquier opcin solicitada en el mensaje DHCPREQUEST.
DHCPDECLINE
Cuando un cliente de DHCP recibe una direccin de IP de un servidor de DHCP, el cliente debe determinar si esa direccin de IP ya se est utilizando. De hecho, el servidor de DHCP de Windows 2000 se puede configurar para que compruebe si la direccin se est utilizando antes de enviarla. Sin embargo, los clientes de Windows 2000 y Windows 98 realizan esta comprobacin tras recibir el mensaje DHCPACK. El cliente realiza la comprobacin enviando una difusin de ARP con dicha direccin. Si el cliente de DHCP recibe una respuesta de ARP que indique que la direccin ya se est utilizando, el cliente difunde un DHCPDECLINE al servidor de DHCP y desactiva la direccin. El servidor de DHCP de Windows 2000 marca la direccin como <bad> (errnea) en la base de datos de DHCP. El cliente es libre de adquirir otra concesin de otra direccin de IP. El servidor de DHCP ofrece y asiente una direccin de IP contra la que el cliente realiza una ARP gratuita. Como la direccin ya se encontraba en uso, ARP descubre un host que la usaba y el cliente de DHCP difunde el DHCPDECLINE. Ello permite al servidor de DHCP marcar la direccin como <bad address> en la base de datos de DHCP. El cliente de DHCP tambin escribe un mensaje de Aviso de registro de suceso en el registro de sucesos del cliente de DHCP, as como en el registro de sucesos del cliente que dispone actualmente la direccin de IP en disputa, si el sistema es un equipo con Windows 2000. El cliente con Windows 2000 construye un mensaje DHCPDECLINE con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER o DHCPREQUEST originales. Ciaddr. Se establece a la direccin de IP en disputa, es decir, la que recibi el cliente pero que se ha determinado que ya est en uso. Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original.
El cliente de DHCP de Windows 2000 tambin establece la siguiente serie de opciones en el

mensaje DHCPDECLINE:
q q q
q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x04 (DHCPDECLINE). Identificador del cliente. La direccin MAC del cliente que enva el mensaje DHCPDECLINE. Direccin solicitada. La direccin de IP en disputa. ID de servidor. La direccin de IP del servidor que envi al cliente la direccin de IP en disputa.
DHCPNAK
El servidor de DHCP usa los mensajes DHCPNAK para indicar al cliente de DHCP que no se puede proporcionar la direccin solicitada. Puede ocurrir cuando un cliente con una concesin est desconectado o, por razones administrativas, el administrador de DHCP cancela la concesin. En este caso, el servidor de DHCP podra conceder la direccin a otro cliente. Tambin puede ocurrir con clientes que se trasladan a otras subredes. Si la direccin solicitada proviene de un mbito que no coincide con el mbito del valor en el campo Giaddr o el mbito de la interfaz por la que se recibe (si el campo Giaddr es 0), el servidor de DHCP determina que el cliente de DHCP se ha trasladado a una subred diferente. Tras recibir un mensaje DHCPNAK, los clientes de DHCP de Windows liberan inmediatamente la direccin de IP e intentan conseguir una nueva direccin de IP.
DHCPRELEASE
El cliente de DHCP enva este mensaje al servidor de DHCP liberando la direccin de IP y cancelando la concesin. La direccin de IP liberada se puede volver a usar para otros clientes de DHCP. El servidor de DHCP de Windows 2000 no asiente los DHCPRELEASE. El mensaje DHCPRELEASE es un mensaje unicast desde el cliente de DHCP hasta el servidor de DHCP que envi originalmente la concesin que cancela el cliente. El cliente de DHCP de Windows 2000 construye un mensaje DHCPRELEASE con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al ID de la nueva transaccin. Ciaddr. Se establece a la direccin de IP del cliente que se libera. Chaddr. Se establece a la direccin de hardware del cliente que se indic originalmente en el mensaje DHCPDISCOVER.
El cliente de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPRELEASE. Dichas opciones son las siguientes:
q q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x07 (DHCPRELEASE). Identificador de servidor. El servidor que emiti originalmente la concesin. Identificador de cliente. La direccin MAC del cliente de DHCP.
DHCPINFORM
En la RFC 2131 se define un nuevo tipo de mensaje de DHCP, DHCPINFORM, que los clientes pueden utilizar para solicitar informacin adicional de configuracin, independientemente de cuando se configuraron originalmente. Por ello, un cliente de DHCP, configurado con una direccin de IP esttica, podra utilizar mensajes DHCPINFORM para solicitar parmetros de configuracin local adicional de un servidor de DHCP. DHCPINFORM tambin lo usan los clientes de acceso remoto de Windows 2000 para obtener automticamente un nombre de dominio de DNS, tras configurarse la conexin del Protocolo Punto a punto (PPP).
En Windows 2000, el uso clave del mensaje DHCPINFORM es para permitir que un servidor de DHCP con Windows 2000 descubra el nombre de la raz empresarial de los Servicios de directorio, DS (Directory Services), en el que se instala cada servidor como parte de la deteccin de servidores rogue de DHCP. Esta informacin se solicita mediante un mensaje DHCPINFORM incluyendo en el mensaje informacin propia del fabricante en el rea de opciones. Cuando otros servidores de DHCP que ejecutan el servicio Servidor de DHCP de Windows 2000 reciben el mensaje DHCPINFORM, el servidor lo procesa, lo asiente y responde con la informacin solicitada sobre la raz del DS empresarial. El servidor de Windows 2000 construye un mensaje DHCPINFORM con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. El servidor de DHCP genera un nuevo ID de transaccin. Ciaddr. Se establece a la direccin de IP del servidor de DHCP.
El servidor de DHCP de Windows 2000 tambin establece la siguiente serie de opciones en el mensaje DHCPINFORM:
q q q
Cookie mgica. Siempre se establece al valor 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x08 (DHCPINFORM). Informacin especfica del fabricante. Para la deteccin de servidor autorizado se establece en 0xSE.
Opciones de DHCP
El servidor de Windows 2000 proporciona una concesin de DHCP, lo que incluye la direccin de IP, la mscara de subred y de ciertas opciones solicitadas por el cliente. Una opcin de DHCP es un parmetro de configuracin que puede enviar un servidor de DHCP a un cliente. Puede tratarse de opciones estndar, utilizadas en todos los mensajes de DHCP, o en todos los mensajes de un determinado tipo como DHCPDISCOVER, como la opcin Cookie mgica o el tipo de mensaje de DHCP. Adems, las opciones de DHCP pueden contener parmetros de configuracin que se soliciten explcitamente por los clientes de DHCP, como la direccin de IP de la pasarela predeterminada. El servidor de DHCP de Windows 2000 admite los tipos de opcin estndar, definidos en la RFC 2132. Adems, Windows 2000 define opciones extra especficas del fabricante que puede usar el administrador para proporcionar a los clientes de DHCP informacin adicional.
Formatos de las opciones

Como se define en las RFC 2121 y 2132, las opciones pueden ser de tamao fijo o de tamao variable y pueden contener, o no, datos asociados. Todas las opciones empiezan con un byte que identifica el cdigo de opcin. Las opciones de tamao fijo, sin datos, constan de un byte de etiqueta. Las nicas opciones de tamao fijo sin datos son la Opcin 0 (Pad-Relleno) y la Opcin 255 (End-Fin). El resto de las opciones son de tamao variable y tienen un byte de tamao a continuacin del byte etiqueta. El valor del byte tamao excluye los dos bytes que indica la etiqueta y el tamao. El valor de tamao indica el nmero de bytes que puede contener la opcin. Algunas opciones de tamao variable tienen un campo de tamao fijo, pero se seguir especificando la opcin tamao. La clase de opcin especfica del fabricante tiene un formato ligeramente diferente en el que existe una nica opcin (informacin especfica del fabricante) que consiste en una lista de subopciones.
Opciones que admite Windows 2000

El servicio de DHCP de Windows 2000 admite todas las opciones especificadas en la RFC 2132. Sin embargo, la mayora de las opciones definidas ya no se usan o los clientes de Windows y MS-DOS no las usan. Las opciones que admite el servidor de DHCP de Windows 2000 pertenecen a alguno
de los siguientes tres grupos:

q
Opciones presentes en todos los mensajes, o en todas las ocurrencias de un tipo de mensaje dado. Opciones estndar que pueden solicitar los clientes y que el servidor de DHCP proporciona si el administrador ha definido un valor para la opcin. Opciones del fabricante que se devuelven segn la clase del cliente. Opciones de DHCP presentes en todos los mensajes de DHCP Nombre de opcin Pad (Relleno) Cdigo Tamao 0 1 byte Descripcin Se usa para alinear el resto de campos. Se puede usar en cualquier mensaje de DHCP. Se usa junto con una direccin de IP ofrecida. Se usa en los mensajes DHCPOFFER y DHCPACK. Especifica el nombre del cliente. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST y DHCPNAK. La utilizan los clientes y servidores para intercambiar informacin especfica del fabricante. La definicin de este tipo de informacin especfica no est definido en la RFC 2132. Se usa en los mensajes DHCPINFORM. La direccin que el cliente de DHCP solicita, o rechaza. Se usa en los mensajes DHCPREQUEST y DHCPDELCINE. Tiempo de la concesin en segundos. Pre sente en los mensajes DHCPOFFER y DHCPACK. Se usa para definir el tipo de mensaje de DHCP. Los valores son los siguientes: 1. 2. 3. 4. 5. 6. 7. 8. DHCPDISCOVER. DHCPOFFER. DHCPREQUEST. DHCPDECLINE. DHCPACK. DHCPNAK. DHCPRELEASE. DHCPINFORM.
Subnet Mask (Mscara de subred)
4 bytes
Host Name 12 (Nombre de host)
Tamao variable; el tamao mnimo es 1 byte Tamao variable
Vendor Specific Information (Informacin especfica del fabricante)
43
Requested Address (Direccin solicitada) Lease Time (Tiempo de concesin) DHCP Message Type (Tipo de mensaje de DHCP)
50
4 bytes
51
4 bytes
53
1 byte
Se usa en todos los mensajes de DHCP. Server Identifier (Identificador de servidor) 54 4 bytes La direccin de IP del servidor de DHCP. Se usa en los mensajes DHCPREQUEST, DHCPACK, DHCPDECLINE y DHCPRELEASE.
Parameter Request List (Lista de parmetros solicitados)
55
Tamao variable; pero los clientes de Windows 2000 ser de 8 bytes
Lo usa un cliente de DHCP para solicitar valores de parmetros especficos de configuracin. Cada byte es un cdigo de opcin vlida de DHCP (definida en la RFC 2132) para las opciones para las que el cliente solicita valores del servidor. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST y DHCPINFORM. Tiempo hasta que el cliente est en el estado de renovacin. Se usa en los mensajes DHCPOFFER y DHCPACK. Tiempo hasta que el cliente est en el estado de reconexin. Se usa en los mensajes DHCPOFFER y DHCPACK. Valor para identificar unvocamente el cliente. Para los clientes de Windows 2000 es la direccin MAC del cliente. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPNAK y DHCPRELEASE.
Renewal Time (T1) (Tiempo de renovacin) Rebinding Time (T2) (Tiempo de reconexin) Client Identifier (Identificador de cliente)
58
4 bytes
59
4 bytes
61
Tamao variable; el tamao mnimo es de 2 bytes; para Ethernet el tamao es de 6 bytes Tamao variable
81 Dynamic DNS Update (Actualizacin dinmica de DNS)
Es el nombre completo de dominio cualificado del host y el servidor lo utiliza para enviar actualizaciones dinmicas de DNS al servidor de DNS. Se usa en los mensajes DHCPREQUEST. Marca el fin del campo Opciones de un mensaje DHCP. Se usa en todos los mensajes de DHCP.
End (Fin)
255
1 byte
Opciones solicitadas por los clientes DHCP(1) Nombre de opcin Cdigo Tamao Variable, pero siempre mltiplo de 4 Descripcin Una lista de direcciones de IP para los enrutadores de la subred del cliente, que se debera presentar en orden de preferencia. Normalmente slo existir un enrutador -la pasarela predeterminada-, pero se pueden especificar varios. Una lista de las direcciones de IP de los servidores del Sistemas de nombres de dominio (para RFC 1035) a los que puede acceder el cliente.
Router (Enrutador) 3
Domain Name Servers (Servidores de nombres de dominio)
Variable, pero siempre mltiplo de 4
DNS Domain Name (Nombre de dominio de DNS)
15
Tamao variable, conjunto de caracteres ASCII Variable, pero siempre mltiplo de 4
El nombre de dominio de DNS que el cliente de DHCP debera usar cuando resuelve los nombres de hosts utilizando DNS. Una lista de direcciones de IP de servidores WINS que puede usar el cliente. Normal mente se tratar de un servidor primario y uno secundario. Se usa para indicar a un cliente de TCP/IP cmo se deberan resolver los nombres de NetBIOS, de acuerdo con: 0x1 nodo B (difusin). 0x2 nodo P (punto a punto). 0x4 nodo M (mixto). 0x8 nodo H (hbrido). Especifica el mbito de NetBIOS sobre TCP/IP para los clientes, como se especifica en las RFC 1001 y 1002.
WINS Server Names (Nombres de servidores WINS)
44
NetBIOS Over TCP/ 46 IP Node Type (Tipo de nodo TCP/ IP sobre NetBIOS)
1 byte
NetBIOS Scope ID (ID del mbito de NetBIOS)
47
Variable, tamao mnimo 1
(1)
Estas opciones se entregan si el administrador ha especificado valores para ellas. Opciones especficas del fabricante(2) Nombre de opcin Microsoft Disable NetBIOS Option (Opcin desactivar Microsoft NetBIOS) Microsoft Release On Shutdown (Liberar en el apagado de Microsoft) Cdigo Tamao Descripcin 1 4 Indica al cliente de Windows 2000 si desactivar o no NetBIOS. Indica al cliente de Windows 2000 si libera la concesin de DHCP al apagar. Especifica la base de mtrica predeterminada del enrutador
3 Microsoft Default Router Metric Base (Base de mtrica predeterminada del enrutador de Microsoft)
(2)
Adems de las opciones estndar anteriores, el administrador puede especificar opciones a devolver a los clientes de una determinada clase, como Windows 2000, Windows 98, etc. ltima actualizacin del tema completo: 23/12/2005 v1.0.1
Volver al principio del Tema
Volver al ndice General
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01.htm
Para que un host con TCP/IP se comunique correctamente con otro, ambos deben estar configurados apropiadamente. Requieren una direccin de IP vlida y nica, una mscara de subred y una direccin de pasarela predeterminada, aunque se puede omitir si el host slo se va a comunicar en la subred local. Para redes mayores se necesita configurar otros elementos, como la direccin de IP de un servidor de DNS, la direccin de IP de un servidor WINS y los tipos de nodo NetBIOS. En grandes redes, asegurar que todos los hosts se han configurado correctamente puede ser una tarea de administracin y gestin importante, especialmente en redes dinmicas con usuarios mviles con ordenadores porttiles. La configuracin manual o la reconfiguracin de un gran nmero de equipos es una tarea que lleva mucho tiempo y un error en la configuracin de un host puede hacer que sea imposible que se comunique con el resto de la red. DHCP es un protocolo cliente-servidor que simplifica la administracin de la configuracin de los clientes de IP y la asignacin de los datos de configuracin de IP. Mediante DHCP, el administrador define todos los parmetros de configuracin necesarios en un servidor central, quien proporciona a los hosts toda la informacin de configuracin de IP. DHCP proporciona tres ventajas clave en la planificacin, diseo y mantenimiento de una red de IP:
q
Administracin centralizada de las configuraciones de IP. El administrador de DHCP puede administrar de manera centralizada toda la informacin de configuracin de IP. De esta forma se elimina la necesidad de configurar manualmente los hosts individualmente cuando se implanta por primera vez TCP/IP o cuando se necesitan cambios en la infraestructura de IP. Sencillez en la configuracin de IP de host. Mediante DHCP se asegura que los clientes de DHCP obtienen parmetros de configuracin de IP precisos y en tiempo, sin intervencin del usuario. Como la configuracin es automtica se elimina gran parte de los problemas. Flexibilidad. Utilizando DHCP, el administrador aumenta su flexibilidad para el cambio de la informacin de configuracin de IP, lo que permite que el administrador cambie la configuracin de IP de manera sencilla cuando se necesitan los cambios.
Descripcin general de DHCP en Windows 2000

DHCP es un protocolo cliente-servidor que proporciona automticamente a un host de IP su direccin IP y otra informacin de configuracin relacionada como la mscara de subred y la pasarela predeterminada. En las RFC 2131 y 2132 se define DHCP como un estndar del Internet Engineering Task Force (IETF) basado en el Protocolo de arranque, BOOTP (Bootstrap Protocol), con el que comparte muchos detalles de implementacin. DHCP permite que todos los hosts obtengan toda la informacin de configuracin necesaria desde un servidor de DHCP. Todos los Windows 2000 Server (incluyendo Server, Advanced Server y Data Center Server) incluyen el servicio Servidor de DHCP, que se instala como opcional. Todos los clientes de Microsoft Windows instalan automticamente el servicio cliente de DHCP como parte de TCP/IP, incluidos Windows 2000, Windows NT 4.0, Windows 98 y Windows 95.
Clientes y servidores de DHCP

Un equipo que obtiene su informacin de configuracin mediante DHCP se le conoce como un cliente de DHCP. Los clientes de DHCP se comunican con un servidor de DHCP para obtener su direccin de IP e informacin de configuracin de TCP/IP relacionada. Los servidores de DHCP mantienen la informacin sobre las direcciones de IP disponibles e informacin relacionada que haya definido el administrador de DHCP.
mbitos y opciones de DHCP
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01.htm (1 of 24)06/01/2006 5:06:18
Se puede proporcionar a un cliente de DHCP un conjunto de direcciones de IP y la informacin de configuracin asociada, lo que se conoce como un mbito (scope). Un mbito es un conjunto de direcciones de IP que el servidor puede enviar a los clientes de DHCP, junto con una o ms opciones. Una opcin es un elemento concreto de configuracin como una mscara de subred o una direccin de IP de pasarela predeterminada, que el administrador de DHCP quiere que el servidor de DHCP proporcione a los clientes de DHCP. Un administrador de DHCP puede crear uno o ms mbitos en uno o ms servidores Windows 2000 ejecutando el servicio DHCP. Sin embargo, como los servidores de DHCP no se comunican informacin de mbito unos con otros, el administrador debe ser cuidadoso para asegurarse de que los mbitos estn definidos de forma que varios servidores de DHCP no manejen las mismas direcciones de IP para diferentes clientes, o manejen direcciones que se han asignado a hosts de IP configurados manualmente. Las direcciones de IP definidas en un mbito de DHCP son contiguas y asociadas con una mscara de subred. Para permitir que algunas de las direcciones de IP del mbito ya estn asociadas y en uso, el administrador de DHCP puede especificar una exclusin -una o ms direcciones de IP en el mbito que no se pueden enviar a los clientes de DHCP. En redes con mltiples subredes y mltiples redes es til tener estndares para separar las direcciones dinmicas de IP que ofrece DHCP de las direcciones que se usan para configurar manualmente los hosts. En el paquete del protocolo de DHCP, cada opcin comienza con un nico byte de marca que define la opcin. Una opcin puede ser de tamao fijo, como el Tipo de nodo de NetBIOS (Opcin 46); de tamao variable, como el Nombre de dominio del Servidor de nombres de dominio (DNS) (Opcin 15); o un array de elementos como la lista de Servidores de DNS (Opcin 6). Con el servicio DHCP de Windows 2000, el administrador de DHCP puede administrar las opciones en los siguientes cinco niveles:
q
Opciones predefinidas. Permite al administrador de DHCP especificar los valores de las opciones predeterminadas para todas las opciones que admite el servidor de DHCP y crear nuevos tipos de opcin para su uso en este servidor. Opciones de servidor. Valores asignados a todos los clientes y mbitos definidos en el servidor DHCP, a no ser que prevalezcan las opciones de mbito, clase o cliente. Opciones de mbito. Valores que se aplican slo a clientes de un mbito concreto, a no ser que prevalezcan las opciones de clase y de cliente. Opciones de clase. Permite que el administrador establezca opciones de clase por usuario o fabricante, proporcionando datos de opcin a una clase concreta de clientes DHCP, es decir, a todos los clientes de Windows 2000. Ante el conjunto de opciones de este nivel slo prevalecen las opciones asignadas en el nivel de cliente. Opciones reservadas por clientes. Se establecen para un cliente de DHCP individual. Slo prevalecen, a las opciones de este nivel, las opciones asignadas manualmente en el equipo cliente.
Clases de opciones
Una clase de opcin de DHCP es un conjunto adicional de opciones que se pueden proporcionar a un cliente de DHCP si el equipo forma parte de una clase de equipos. El administrador puede usarlo para administrar los valores de opcin que proporciona a los clientes de DHCP. Existen dos tipos de clases de opciones en un servidor de DHCP de Windows 2000: clases del fabricante y clases del usuario. Cuando el administrador configure las clases de opciones en un servidor de DHCP, un cliente que pertenezca a dicha clase, por ejemplo todos los equipos con Windows 2000, se les puede dar tipos de opciones concretas para esta clase para su configuracin. Para poder usar clientes anteriores de DHCP que no puedan enviar el ID de clase, el administrador puede configurar clases por defecto para los valores de opcin. De esta forma, los administradores pueden aprovechar opciones concretas para clases particulares de clientes a la vez que le proporciona todas las
opciones necesarias para otros clientes. Un cliente de DHCP puede indicar en los mensajes del protocolo DHCP que enva a un servidor que el cliente es miembro de una clase de usuario o fabricante en particular. El administrador puede usar DHCP para definir los valores de opcin que se devuelven para esta clase de cliente. Por ejemplo, el administrador puede configurar opciones especficas para equipos con Windows 2000, que se envan como valores de opcin (por ejemplo, si se enva un abandono de DHCP cuando se apaga el equipo). Otros clientes, como Windows 95, que no disponen de esta funcin, no deberan recibir estos valores. Para que un cliente de DHCP reciba valores de opcin de estas opciones extendidas, el cliente debe especificar una cadena opcin de clase de usuario que contenga una cadena con la identificacin del tipo de cliente. El servidor de DHCP puede usar esta identidad para enviar opciones extra al cliente. La opcin clase de usuario se establece con el comando IPCONFIG.
Agentes rel de DHCP

Cuando se arranca inicialmente un cliente de DHCP de Windows 2000, difunde mensajes de DHCP para obtener o renovar una concesin de un servidor de DHCP. El administrador de DHCP usa un Agente Rel de DHCP para centralizar los servidores de DHCP y evitar la necesidad de un servidor de DHCP en cada una de las subredes. Tambin conocido como agente rel de BOOTP, un agente rel de DHCP es un host o un enrutador de IP que escucha los mensajes de clientes de DHCP que se difunden en la subred y transfiere los mensajes a un servidor configurado con DHCP. El servidor DHCP enva mensajes de DHCP al agente rel que vuelve a difundirlos en la subred para el cliente de DHCP. El servicio Enrutamiento y acceso remoto de Windows 2000 Server incluye un agente rel de DHCP. El administrador de DHCP tiene que activar el Servicio Enrutamiento y acceso remoto, aadir el agente rel de DHCP y configurar las direcciones de IP del servidor de DHCP. Adems, la mayora de los enrutadores modernos se pueden configurar para proporcionar funciones rel. En muchos enrutadores se refiere a ello como Reenvo de BOOTP (BOOTP Forwarding).
Deteccin de servidor de DHCP no autorizado

Los servidores de DHCP configurados apropiadamente proporcionan informacin de configuracin de IP a las redes de IP. Sin embargo, cuando se introduce en una red un servidor de DHCP configurado de forma incorrecta, o se introduce un servidor de DHCP en una red equivocada, puede haber problemas. Por ejemplo, si un cliente consigue una concesin de un servidor configurado incorrectamente, el cliente puede recibir una direccin de IP no vlida, lo que impide que se pueda comunicar con el resto de la red. Ello impide que los usuarios se conecten. Con Windows 2000, un servidor de DHCP no autorizado es simplemente un servidor de DHCP que no ha sido autorizado explcitamente. A los servidores de DHCP no autorizados tambin se les denomina servidores rogue. En un entorno de dominios de Windows 2000, el servicio de DHCP de un servidor no autorizado fallar al inicializarse. El administrador debe autorizar explcitamente a todos los servidores de DHCP de Windows 2000 que funcionan en el entorno de un dominio de Active Directory. Durante la inicializacin, el servicio de DHCP de Windows 2000 comprobar su autorizacin y no arrancar si el servidor detecta que est en el entorno de un dominio y el servidor no tiene autorizacin explcita.
Direccionamiento de IP privada automtica (APIPA)

Los clientes de DHCP necesitan encontrar un servidor de DHCP para conseguir una concesin inicial. En la mayora de los casos, el cliente de DHCP encontrar un servidor en la subred local o a travs de un agente rel. Para permitir la posibilidad de que el servidor de DHCP no est disponible, Windows 2000 y Windows 98 proporcionan APIPA (Automatic Private IP Addressing). APIPA es una facilidad de la implementacin de TCP/IP de Windows 2000 para que un equipo obtenga informacin de configuracin de IP sin un servidor de DHCP ni configuracin manual. Con APIPA se evita el problema de los hosts de IP que les es imposible comunicarse si, por alguna razn, el servidor
de DHCP no est disponible. APIPA tambin es til en pequeos grupos de trabajo donde no existe un servidor de DHCP. Como la autoconfiguracin no dispone de pasarela predeterminada, slo funciona en una nica subred y no es apropiado para grandes redes. Si el cliente de DHCP no es capaz de localizar un DHCP, el equipo se autoconfigura con una direccin de IP aleatoria elegida de la red de clase B 169.254.0.0 de las reservadas para la IANA, con la mscara de red 255.255.0.0. El equipo as autoconfigurado comprueba si la direccin de IP elegida ya est en uso mediante una difusin de ARP gratuita. Si la direccin de IP elegida ya est en uso, el equipo elige aleatoriamente otra direccin. El equipo realiza diez intentos de encontrar una direccin de IP disponible. Una vez se ha verificado que la direccin seleccionada est libre, el cliente se configurar con esa direccin. El cliente de DHCP continuar comprobando si existe un servidor de DHCP cada 5 minutos, y si se encuentra, se usar la configuracin que indique el servidor de DHCP.
Integracin de DNS
Los clientes de Windows 2000 admiten la actualizacin dinmica de DNS, lo que permite que los clientes de DHCP actualicen su servidor de DNS configurado con la informacin de reenvo y bsqueda inversa.
Integracin del Servicio Enrutamiento y acceso remoto

El Servicio Enrutamiento y acceso remoto de Windows 2000 incluye una funcionalidad del servidor del Servicio de acceso remoto que permite que clientes de la Conexin telefnica o Redes privadas virtuales (VPN) accedan al servidor del Servicio Enrutamiento y acceso remoto unindose a la red local. Para el resto de equipos de la red local, estos clientes aparecen como iguales. En este caso el servidor de acceso remoto se comporta como una pasarela entre el cliente remoto y la red local. Los clientes del servicio de acceso remoto necesitarn una direccin de IP para la red local antes de empezar a funcionar. Aunque se puede configurar manualmente el cliente del Servicio de acceso remoto con una direccin de IP apropiada, es una sobrecarga de trabajo de administracin. Otra alternativa es que el Servicio Enrutamiento y acceso remoto de Windows 2000 est configurado para obtener cualquier direccin de IP necesaria de un servidor de DHCP. Cuando un servidor de acceso remoto de Windows 2000 se configura para que utilice DHCP para obtener las direcciones de IP, el servidor de acceso remoto obtiene 10 direcciones de IP de un servidor de DHCP. El servidor de acceso remoto usa la primera direccin conseguida para s mismo y asigna la otras direcciones a los clientes de acceso remoto con TCP/IP segn se conectan. Las direcciones de IP que se liberan cuando un cliente se desconecta se reutilizan. Cuando se estn utilizando las 10 direcciones de IP, el servidor de acceso remoto consigue otras diez ms. Cuando el Servicio Enrutamiento y acceso remoto se detiene, todas las direcciones conseguidas mediante DHCP se liberan. Si cuando se arranca el Servicio Enrutamiento y acceso remoto no hay disponible ningn servidor de DHCP, se usan las direcciones APIPA en el intervalo 169.254.0.1 a 169.254.255.254.
mbitos de multidifusin
Adems de dar concesiones de direcciones de IP, el servicio DHCP de Windows 2000 admite mbitos de multidifusin. Un mbito de multidifusin es un conjunto de direcciones de clase D para su uso en aplicaciones de multidifusin. Esta caracterstica permite que el administrador de DHCP controle las direcciones concretas de multidifusin que pueden utilizar las aplicaciones de multidifusin. Las aplicaciones deben haberse escrito para obtener la concesin de las direcciones de IP de multidifusin mediante DHCP.
Soporte BOOTP
DHCP se basa en BOOTP, un protocolo ms antiguo con una funcionalidad similar. BOOTP se dise inicialmente
para permitir la configuracin en el arranque de estaciones de trabajo sin disco. Los servidores de DHCP modernos responden tanto a las peticiones de DHCP como de BOOTP. Los clientes de BOOTP se inicializan a s mismos en los siguientes dos pasos: 1. El cliente de BOOTP solicita una direccin de IP y otra informacin de configuracin como la direccin de pasarela predeterminada, la direccin de IP del servidor de DNS, y otra informacin, desde un servidor de BOOTP. Esta informacin incluye un nombre de archivo de la imagen de arranque y el nombre del servidor de donde se debera obtener la direccin de IP. 2. El cliente de BOOTP se pone en contacto con el servidor y descarga el archivo con la imagen de arranque usando el Protocolo Trivial de Transferencia de Archivos (TFTP). Aunque DHCP ha superado a BOOTP, el servidor de DHCP de Windows 2000 permite el uso de clientes de BOOTP. El administrador puede definir un mbito de uso slo para los clientes de BOOTP. Adems puede definir un mbito para su uso tanto por clientes de BOOTP como de DHCP.
Instalacin y configuracin de un Servidor DHCP

Antes de instalar el servidor DHCP hay que determinar el esquema de direcciones IP. Tambin se deben completar estos pasos adicionales antes de instalar DHCP:
q
q q
q q
Determinar el intervalo de direcciones IP libres y nicas que manejar el servidor DHCP adems de cualquier direccin IP que sea necesario excluir para soportar hosts con direcciones IP estticas. Hacer una lista de los servidores para los que se desea reservar una IP (como servidores DNS y WINS). Si el servidor DHCP utilizara direcciones IP registradas en Internet, hay que registrar las direcciones IP con el ISP Determinar los requisitos de hardware y de almacenamiento del servidor DHCP Configurar manualmente las direcciones estticas en el equipo donde se instalar el servicio DHCP
Para instalar el servicio DHCP hay que seguir estos pasos: 1. Abrir la herramienta Configurar el servidor ejecutndola desde la carpeta Herramientas
administrativas. 2. Pulsar el ttulo Red en la columna de la izquierda y pulsar despus el subttulo DHCP 3. Pulsar en el hipervnculo Iniciar para ejecutar el Asistente para componentes de Windows. 4. Pulsar Siguiente en la primera pantalla del Asistente para componentes de Windows. 5. Seleccionar Servicios de red en la lista de componentes y pulsar Detalles. 6. Seleccionar la casilla de verificacin junto a Protocolo de configuracin dinmica de host (DHCP) y pulsar Aceptar. Pulsar Siguiente para instalar el servicio. Todos los archivos necesarios se copian al disco duro.
Creacin de un nuevo mbito

Ahora ya se puede ejecutar el Administrador DHCP y crear un nuevo mbito de direcciones IP para que las gestione el servidor DHCP. Pero antes de hacer esto, hay que asegurarse de que se conoce el intervalo de direcciones IP aprobado, qu direcciones IP son necesarias excluir para los sistemas con direcciones IP estticas y qu direcciones son necesarias reservar para servidores DNS o WINS. Para abrir el Administrador DHCP y crear el nuevo mbito, hay que seguir los siguientes pasos: 1. Escoger DHCP del men Herramientas administrativas. 2. Seleccionar el servidor DHCP en el rbol de la consola. Seleccionar el men Accin y escoger mbito nuevo para ejecutar el Asistente para mbito nuevo. 3. Pulsar Siguiente e introducir el nombre y la descripcin del mbito que servirn para distinguir este mbito de otros. Pulsar Siguiente. 4. Introducir la direccin IP por la que se desea que comience el mbito en el campo Iniciar, e introducir la
direccin IP por la que se desea qu finalice el mbito en el campo Fin. 5. Introducir la mscara de subred de la red en el cuadro Mscara de subred, o utilizar el cuadro Longitud para ajustar la longitud de la mscara de subred. Despus, pulsar Siguiente. 6. Para excluir un intervalo de direcciones del mbito, en el cuadro Iniciar direccin IP, hay que introducir la direccin IP de comienzo para el intervalo de exclusin; en el cuadro Fin de direccin IP hay que introducir la direccin IP final del intervalo de exclusin. Despus hay que pulsar Agregar. Hay que aadir las exclusiones que sean necesarias y pulsar Siguiente cuando se haya terminado. 7. Especificar la duracin de la concesin a los clientes y pulsar Siguiente. Conviene utilizar concesiones ms largas en redes sin servidores DHCP redundantes para permitir ms tiempo de recuperacin de un servidor DHCP sin conexin antes de que los clientes pierdan sus concesiones, o para minimizar el trfico de red a expensas de una renovacin de direcciones menos frecuente. Tambin se pueden utilizar concesiones ms largas si las direcciones del mbito son abundantes (al menos un 20 por ciento disponible), la red es estable y los equipos rara vez se mueven. Por el contrario, los mbitos que soportan clientes que acceden telefnicamente pueden tener concesiones ms cortas y, por lo tanto, funcionar bien con menos direcciones. 8. Para configurar las opciones de DHCP, existen dos opciones:
q
Configurar estas opciones ahora; Si se decide especificar las opciones DHCP continua el asistente solicitando las opciones ms corrientes dentro del servidor DHCP. Estas opciones son:
q
Puertas de enlace (enrutadores) que se desee que utilicen los clientes en el cuadro Direccin IP, pulsando el botn Agregar despus de introducir cada uno. Cuando se haya terminado de introducir puertas de enlace hay que pulsar Siguiente.
Nombre del dominio: en el cuadro Dominio primario, y aadir las direcciones IP de los servidores DNS en el cuadro Direccin IP, pulsando Agregar tras introducir cada una. Hay que pulsar Siguiente cuando se haya terminado. q Direccin IP de Servidores WINS, hay que introducir las direcciones de todos los servidores WINS que se hayan configurado en la red para asignar direcciones IP a los nombres NetBIOS de los clientes de nivel inferior. Pulsar Siguiente. q Configurar estas opciones ms tarde. Si seleccionamos esta opcin se finaliza la instalacin del Servidor. 9. Para activar el mbito inmediatamente, hay que pulsar Activar este mbito ahora; en caso contrario, hay que pulsar Activar este mbito ms tarde. Hay que pulsar Siguiente y pulsar despus Finalizar para completar la configuracin del mbito.
q
Autorizacin del servidor DHCP y activacin de los mbitos

Despus de configurar el servidor DHCP y crear los mbitos, es necesario activar los mbitos antes de que cualquier cliente pueda utilizar el servidor para obtener direcciones IP. Antes de que se puedan activar los mbitos, el servidor tiene que ser autorizado a realizar concesiones, a menos que se haya instalado DHCP en un controlador de dominio, en cuyo caso el servidor DHCP ser autorizado automticamente la primera vez que se aada el servidor a la consola Administrador DHCP. La autorizacin de un servidor DHCP es una opcin importante que proporciona Windows 2000 para reducir la capacidad de los hackers de configurar servidores DHCP corrompidos: servidores no autorizados configurados para proporcionar direcciones IP falsas a los clientes. Para autorizar el servidor DHCP despus de instalar el servicio, hay que seguir los siguientes pasos:
1. En el Administrador DHCP hay que seleccionar DHCP en la raz del rbol de la consola. 2. Escoger Administrar servidores autorizados en el men Accin. 3. Seleccionar Autorizar en el cuadro de dilogo Administrar servidores autorizados. 4. Introducir el nombre o la direccin IP del servidor en el cuadro de texto proporcionado y pulsar Aceptar. 5. Verificar que la informacin es correcta en el cuadro de dilogo que se muestra y entonces pulsar S. Hay que pulsar Aceptar para cerrar el cuadro de dilogo Administrar servidores autorizados. 6. Para activar un mbito hay que seleccionarlo en el rbol de la consola y escoger despus Activar en el men Accin. No se debe activar un mbito hasta que se hayan terminado de seleccionar todas las opciones deseadas. Una vez activado un mbito, el comando Activar del men cambia a Desactivar. No se debe desactivar un mbito a no ser que vaya a ser retirado permanentemente de la red.
Concesiones y reservas de DHCP

Las direcciones de IP que adquiere DHCP normalmente no son permanentes. Cuando un cliente de DHCP se configura mediante DHCP, adquiere una concesin de la direccin asignada. La duracin de la concesin la define el administrador de DHCP. En Windows 2000, el administrador puede especificar un tiempo de concesin, entre 1 minuto y 999 das, o un tiempo de concesin sin lmite. Aunque se asignarn dinmicamente la mayora de las direcciones de IP, Windows 2000 permite que un administrador de DHCP cree una reserva. Una reserva es una concesin permanente de una direccin que crea el administrador de DHCP para asignar una direccin de IP concreta (y las opciones de DHCP) a un cliente concreto. El administrador crea la reserva especificando la direccin de IP que se asigna y la direccin MAC del host. La reserva asegura que el cliente de DHCP con una Tarjeta de interfaz de red, NIC (Network Interface Card), con esa direccin MAC siempre obtenga la misma direccin de IP y las mismas opciones. Para aadir un reserva de direccin a un mbito:
1. Seleccionar la carpeta Reservas bajo el mbito deseado y en el men Accin escoger Reserva nueva. 2. Introducir el nombre de la reserva en el cuadro Nombre de reserva. 3. Introducir la direccin IP para el cliente en el cuadro Direccin IP e introducir la direccin MAC del cliente en el cuadro Direccin MAC. 4. Introducir una descripcin para la reserva en el cuadro Descripcin. 5. Determinar a qu tipo de cliente se desea permitir que utilice la reserva seleccionando Slo DHCP, Slo BOOTP o Ambos. A continuacin, pulsar Agregar. Para obtener la direccin MAC hay que ir al equipo cliente y escribir Ipconfig /all en el smbolo del sistema. La direccin MAC se muestra como direccin fsica.
Activacin de las actualizaciones dinmicas de un servidor DNS

Los servidores DHCP y DNS de Windows 2000 soportan ahora actualizaciones dinmicas con un servidor DNS. Los clientes Windows 2000 pueden actualizar dinmicamente sus registros de bsquedas directas ellos mismos con el servidor DNS despus de obtener una nueva direccin IP de un servidor DHCP Adems, el servidor DHCP de Windows 2000 soporta tambin actualizacin dinmica de registros DNS para clientes anteriores a Windows 2000 que no lo puedan hacer ellos mismos. Esta caracterstica slo funciona actualmente con los servidores DHCP y DNS de Windows 2000. Para permitir que un servidor DHCP actualice dinmicamente los registros DNS de sus clientes, hay que seguir los siguientes pasos: 1. Seleccionar el mbito o el servidor DHCP en el cual se desea permitir actualizaciones dinmicas.
2. En el men Accin, escoger Propiedades y pulsar despus la pestaa DNS. 3. Actualizar automticamente la informacin del cliente DHCP en DNS. Actualizar DNS slo a peticin del cliente DHCP: Para actualizar los registros DNS de un cliente basndose en el tipo de peticin DHCP que hace el cliente y slo cuando sea solicitado. q Actualizar siempre DNS: Para actualizar siempre los registros de bsqueda directa e inversa de un cliente. 4. Descartar las bsquedas directas al caducar la concesin: se debe seleccionar para permitir que el servidor DHCP borre el registro de recurso Host de un cliente cuando su concesin DHCP caduque y no sea renovada. 5. Habilitar actualizaciones para clientes DNS que no sean compatibles con actualizaciones dinmicas: se debe seleccionar para permitir que el servidor DHCP actualice los registros de bsqueda directa e inversa de los clientes que no pueden actualizar sus propios registros de bsqueda directa. Si no se selecciona esta casilla de verificacin, el servidor DHCP no actualizar dinmicamente los registros DNS de los clientes que no sean Windows 2000.
q
Si se tienen servidores DNS estticos como los de Windows NT 4, estos servidores no podrn interactuar dinmicamente cuando las configuraciones de los clientes DHCP cambien. Esta incompatibilidad puede provocar bsquedas fallidas en los clientes DHCP Para evitar este problema, hay que actualizar los servidores DNS estticos con un DNS que soporte DNS dinmico (Windows 2000).
Liberar, renovar o verificar una concesin con Ipconfig

En un equipo que ejecuta Windows con DHCP activado se puede ejecutar una utilidad de lnea de comandos para liberar, renovar o verificar la concesin de direccin del cliente. En el smbolo del sistema (o en la ventana Ejecutar) hay que utilizar alguno de los siguientes comandos:
q q q
Para liberar una concesin de un cliente, hay que escribir Ipconfig /release. Para renovar una concesin, hay que escribir Ipconfig /renew. Para verificar la concesin del cliente, hay que escribir Ipconfig /all.
Con clientes Windows 95/98/ME hay que utilizar Winipcfg con los mismos parmetros. El programa Ipconfig es til a la hora de solucionar problemas porque muestra cada detalle de la configuracin TCP/IP actual.
Funcionamiento de DHCP
Los hosts utilizan el protocolo DHCP para obtener una concesin inicial, renovar una existente y detectar servidores de DHCP no autorizados.
Obtencin de una concesin inicial

La adquisicin de una concesin inicial ocurre la primera vez que un cliente de DHCP arranca. El cliente de DHCP difunde, en primer lugar, el mensaje DHCPDISCOVER para buscar un servidor de DHCP. Como el host no tiene direccin de IP, se comunica con el servidor de DHCP mediante un mensaje de difusin en el rea local. Si hay ms de un servidor de DHCP que puede
proporcionar al cliente de DHCP una direccin de IP vlida, es posible que el cliente reciba una o ms respuestas DHCPOFFER. Si ocurre esto, el cliente elige la mejor de ellas, que en Windows 2000 ser la primera recibida. Para ayudar al cliente a decidir cul es la mejor oferta, el mensaje DHCPOFFER contiene valores para las opciones que el cliente haba solicitado y que se configuran en el servidor de DHCP que la entrega. Cualquier servidor de DHCP que recibe un mensaje DHCPREQUEST y puede asignar al cliente de DHCP una concesin, enviar un mensaje DHCPOFFER con la direccin de IP ofrecida y valores de opcin. Si el cliente puede aceptar esta concesin, enva una DHCPREQUEST al servidor de DHCP, solicitando la direccin de IP ofrecida. Esta solicitud tambin contendr todas las opciones de configuracin que el cliente de DHCP desea obtener. El mensaje final, DHCPACK, se enva desde el servidor de DHCP hasta el cliente de DHCP para confirmar que el cliente tiene la direccin de IP y los valores de las opciones solicitadas que especific el administrador de DHCP en el servidor.
Renovacin de una concesin

Los clientes de DHCP intentarn renovar la concesin tras cada reinicio o a intervalos regulares despus del inicio del cliente de DHCP. La renovacin de una concesin supone slo dos mensajes de DHCP, DHCPREQUEST y DHCPACK. Si el cliente de DHCP renueva una concesin mientras se reinicia, se usan paquetes de IP de difusin para enviar estos mensajes. Si la renovacin de la concesin se realiza mientras se est ejecutando el cliente de DHCP, el cliente y el servidor de DHCP se comunican mediante direccin IP unicast. Cuando un cliente obtiene una concesin, DHCP proporciona los valores para las opciones de configuracin solicitadas por el cliente. Reduciendo el tiempo de concesin, el administrador fuerza a los clientes a solicitar
peridicamente una renovacin de la concesin y obtener
detalles actualizados de configuracin. Puede ser til cuando el administrador desea cambiar la configuracin de IP de una subred. Un cliente de DHCP intenta en primer lugar volver a conseguir su concesin a la mitad del tiempo de concesin, conocido como T1. Si falla el cliente intentar de nuevo una nueva renovacin de la concesin al 87,5 por 100 del tiempo de concesin, conocido como T2. Si no se consigue obtener la concesin antes de que expire (por ejemplo, si el servidor de DHCP no est accesible), en cuanto expira la concesin el cliente libera la direccin de IP e intenta conseguir una nueva concesin.
Cambios en subredes y servidores

Si el cliente de DHCP solicita una conexin mediante un mensaje DHCPREQUEST y el servidor de DHCP no puede cumplir (por ejemplo, cuando se traslada un porttil a una subred distinta), el servidor de DHCP enva un mensaje DHCPNAK al cliente. El cliente conseguir una nueva concesin usando el proceso de adquisicin de concesin inicial. Cuando arranca un cliente de DHCP difunde un mensaje DHCPREQUEST para renovar su concesin. Ello le asegura que la solicitud de renovacin de DHCP se enva al servidor de DHCP que proporciona direcciones de DHCP para la subred en la que se encuentra ahora el cliente, que puede ser distinta de la del servidor de DHCP que proporcion la concesin inicial. Cuando el servidor de DHCP recibe la difusin, compara la direccin del cliente de DHCP solicitante con el mbito configurado en el servidor. Si es imposible satisfacer la solicitud del cliente, el servidor de DHCP enva un DHCPACK y el cliente consigue una nueva concesin. Si el cliente de DHCP no es capaz de localizar ningn servidor de DHCP cuando se reinicia, para renovar su concesin enva una difusin de ARP para la pasarela predeterminada que se obtuvo anteriormente, si la hubo. Si la direccin de IP de la pasarela predeterminada se
resuelve correctamente, el cliente de DHCP supone que se encuentra situado en la misma red donde obtuvo su concesin actual que contina usando.
Si la difusin de ARP del cliente enviada para la pasarela predeterminada no recibe respuesta, el cliente supone que el cliente se ha trasladado a una red que no dispone actualmente de servicios de DHCP, como la red de casa, y se autoconfigura l mismo mediante APIPA. Una vez autoconfigurado a s mismo, el cliente de DHCP intentar, cada 5 minutos, localizar un servidor de DHCP.
Uso del agente rel de DHCP

Los agentes rel de DHCP escuchan los mensajes DHCPDISCOVER y DHCPREQUEST (y DHCPINFORM) que se difundan. El agente rel de DHCP espera un cierto tiempo configurado y, si no se detecta respuesta, enva un mensaje al servidor de DHCP configurado mediante unicast. El servidor acta entonces en el mensaje y reenva la respuesta de vuelta al agente rel de DHCP. El agente rel difunde el mensaje por la red consiguiendo que el cliente de DHCP lo reciba.
Deteccin de servidores de DHCP no autorizados

Como parte de la inicializacin del servicio de DHCP, todos los servidores de DHCP realizan una deteccin de servicios rogue. Si el servidor no est autorizado en el Active Directory, se apaga.
La deteccin de servidor rogue comienza con la inicializacin del servidor de DHCP enviando una solicitud DHCPINFORM para determinar si existen otros servidores de DHCP inicializados en cualquier red conectada. Si es as, estos servidores responden con un mensaje DHCPACK que contiene el nombre del dominio en el que tienen autorizacin. Si se encuentran otro servidor de DHCP, el servicio de DHCP de Windows 2000 que est arrancando se conecta con el Active Directory y enva una serie de llamadas LDAP para descubrir si est autorizado o no. Si el servidor no est autorizado, el servicio termina. Esta deteccin se lleva a cabo una vez cada hora por el servidor de DHCP para detectar nuevos servidores no autorizados. Si est activado el registro de sucesos de DHCP, se escribe un mensaje en el registro de sucesos de DHCP.
Actualizacin de las entradas de DNS

Cuando se concede una concesin de DHCP a un host de IP, es importante que la correspondencia entre el nombre y la direccin de IP se guarde en el DNS. Normalmente era una tarea manual, que involucraba la creacin de entradas directas de DNS y de bsqueda inversa. Windows 2000 implementa el protocolo de actualizacin dinmica de DNS descrito en la RFC 2136. Este protocolo permite a los clientes de Windows 2000 enviar automticamente entradas de DNS a un servidor de DNS. Cada vez que un cliente de DHCP recibe una nueva concesin o renueva una existente, el cliente enva su nombre completo cualificado al servidor de DHCP dentro del mensaje DHCPREQUEST. El mensaje DHCPREQUEST solicita al servidor de DHCP que registre la correspondencia de bsqueda inversa en el servidor de DNS de parte del cliente. El cliente de DHCP, normalmente, maneja el registro de bsqueda inversa por su cuenta, si es posible. El administrador de DHCP puede configurar el servidor de DHCP para que enve actualizaciones de DHCP tanto de la correspondencia de direcciones directas como inversas al servidor de DNS. Es til para los clientes de DHCP de bajo nivel que no disponen de actualizacin dinmica de DNS. El servidor de DHCP solicita el registro Inicio de autoridad, SOA (Start of Authority), de DNS para la zona de bsqueda directa, despus actualiza la entrada de bsqueda directa del cliente de DHCP. El servidor de DHCP solicita, a continuacin, al servidor de DNS la zona de bsqueda inversa y realiza la actualizacin de la entrada de bsqueda inversa del cliente de DHCP. Para que las actualizaciones dinmicas funcionen correctamente, el servidor de DNS debe disponer de actualizaciones dinmicas de DNS y tener configuradas las zonas de bsqueda directa e inversa para permitir actualizaciones dinmicas. El servicio de DNS de Windows 2000 admite las actualizaciones dinmicas de DNS, pero, por defecto, para las nuevas zonas no se permite la actualizacin dinmica. Si, por alguna razn, no est configurada la actualizacin dinmica de una zona cuando el servidor de DHCP intenta actualizar la entrada de DNS, el servidor recibir un error del servidor de DNS.
Mensajes de DHCP
El formato de los mensajes de DHCP se basa en el formato de los mensajes usados en el protocolo BOOTP.
Formato general de los mensajes

En la RFC 2131 se define el formato de los mensajes enviados entre un cliente y un servidor de DHCP. El formato bsico de los mensajes contiene los siguientes campos:
q q
q q
q q q
Tipo de mensaje (Op) 8 bit.Tipo de mensaje. Tipo de direccin hardware (Htype) 8 bit. Tipo de direccin de hardware tal como se define en la seccin ARP de la RFC 1700; por ejemplo, < 0x1> significa 10 Mb Ethernet. Tamao de la direccin hardware (Hlen) 8 bit. Tamao de la direccin de hardware en bytes; por ejemplo, < 0x6> para 10 Mb Ethernet. Saltos (Hops) 8 bit. El cliente de DHCP lo establece a 0. Los agentes rel pueden utilizarlo opcionalmente cuando el cliente de DHCP arranca a travs del agente rel. ID de transaccin (Xid) 32 bit. Nmero aleatorio que se utiliza para indicar una conversacin entre un cliente de DHCP y un servidor de DHCP; por ejemplo, una adquisicin de una concesin. Segundos (Secs) 16 bit. Lo rellena el cliente de DHCP. Nmero de segundos transcurridos desde que el cliente de DHCP inici el proceso de adquisicin de direccin. Indicadores (Flags) 16 bit. Indicadores que establece el cliente. En la RFC 2131 slo se define el indicador Difusin (Broadcast). Un cliente de DHCP que no puede recibir datagramas de IP unicast hasta que se haya configurado con una direccin de IP establece este indicador de Difusin. Direccin de IP del cliente (Ciaddr) 32 bit. Se rellena slo si el cliente tiene una direccin de IP y puede responder a las solicitudes de ARP para defender su direccin de IP. Su direccin de IP (Yiaddr) 32 bit. La direccin que da el servidor de DHCP al cliente de DHCP. Direccin de IP del servidor de DHCP (Siaddr) 32 bit. Direccin de IP del servidor de DHCP que ofrece la concesin (devuelto por DHCPOFFER). Direccin de IP de la pasarela (Giaddr) 32 bit. Direccin de IP del agente rel de DHCP usado cuando se arranca mediante un agente rel de DHCP. Direccin hardware del cliente (Chaddr) 16 bytes. Direccin de hardware del cliente. Nombre de host del servidor (Sname) 64 bytes. Windows 2000 no utiliza este campo. Nombre del archivo de arranque (File) 32 bit. Nombre del archivo que contiene una imagen del arranque para el cliente de BOOTP. Opciones (Options) tamao variable. Conjunto de tamao variable de campos con opciones de DHCP.
Los mensajes de DHCP constan de una parte fija -de 236 bytes de tamao- y una seccin de tamao variable para opciones. Como los mensajes de DHCP se transmiten usando UDP, todos los mensajes de DHCP deben caber completos en un datagrama, lo que limita la seccin de tamao variable a una MTU de 264 bytes, permitiendo una cabecera de IP de 20 bytes y una cabecera de UDP de 8 bytes. Por tanto, el lmite para Ethernet es de 1.236 bytes.
DHCPDISCOVER
Un cliente de DHCP que desea encontrar un servidor para conseguir una concesin enva el mensaje DHCPDISCOVER. Mediante DHCP, ste es el primer paso para conseguir una direccin de IP. Como el cliente de DHCP tiene una direccin de IP vlida, el mensaje DHCPDISCOVER se transmite usando la direccin de IP de difusin limitada 255.255.255.255 y una direccin de IP de origen 0.0.0.0. Antes de transmitir el mensaje DHCPDISCOVER, el cliente de DHCP rellena los campos de la porcin de tamao fijo del mensaje de DHCP de la siguiente forma:
q q q q q q
Op. Se establece a 1, BOOTREQUEST. Htype, Hlen. Se establecen segn el tipo de red utilizado. Hops, Secs, Glags. Se establecen a 0. Xid. El cliente selecciona un valor aleatorio de 32 bits. Ciaddr, Yiaddr, Siaddr, Giaddr. Todos a 0. Chaddr. Se establece a la direccin MAC del cliente de la interfaz que consigue la concesin de DHCP y es la direccin que se utiliza en los mensajes de DHCP siguiente para referirse a esta interfaz en el cliente. Cname, File. Se establecen a 0.
El cliente de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPDISCOVER. Las
opciones son las siguientes:

q q q q q
Cookie mgica. Siempre se establece a 99.130.83.99 para indicar que sigue una extensin del fabricante. Identificador de cliente. Se establece a la direccin de hardware del cliente de DHCP. Nombre de host. Se establece al nombre de host del cliente. Clase del cliente. Se establece a <MSFT 5.0> para indicar que es un sistema con Windows 2000. Lista de parmetros solicitados. Indica los parmetros que el cliente desea obtener del servidor. Para Windows 2000 son 0x01 (mscara de subred), 0x0F (nombre de dominio de DNS), 0x03 (pasarela predeterminada), 0x06 (servidores de DNS), 0x2C (direccin del servidor WINS), 0x2E (tipo de nodo de NetBIOS), 0x2F (ID de mbito de NetBIOS), 0x2B (informacin de clase del fabricante). El mensaje DHCPDISCOVER de Windows 98 no enva informacin de clase del cliente y no solicita informacin de clase del fabricante. Adems, el mensaje DHCPDISCOVER de Windows 98 enva un mensaje Solicitud de opcin con la Opcin 57, un mensaje de DHCP de tamao mximo que no acta con un servidor de DHCP de Windows 2000.
DHCPOFFER
Cuando un servidor de DHCP recibe un DHCPREQUEST, el servidor usa el campo Chaddr para identificar al cliente que solicita la concesin de DHCP. El servidor comprueba en primer lugar en la base de datos si el cliente de DHCP que solicita la concesin ya tiene una concesin o una reserva de una concesin. Si no es as, el servidor de DHCP comprueba si tiene configurado un mbito desde el que asignar una concesin de direccin de IP. Para determinar qu mbito utilizar para la asignacin de direccin, el servidor de DHCP examina el campo Giaddr del mensaje DHCPDISCOVER. Si Giaddr es 0, el servidor de DHCP usa la interfaz por la que se recibi el mensaje para determinar el mbito. Al contrario, si el campo Giaddr no es 0, el servidor usa el mbito que corresponde a la subred donde se encuentra el agente rel de DHCP. Si no existe una concesin al cliente, el servidor de DHCP examina el mbito elegido donde buscar una direccin de IP para el cliente. Si el cliente ya tiene asignada una concesin previa, pero ha expirado, y la direccin est disponible, el servidor de DHCP ofrece esta direccin. En otro caso, el servidor escoge una direccin disponible del mbito que se usa para asignar. Si el servidor de DHCP puede ofrecer una concesin, construye un mensaje DHCPOFFER con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q q q
Op. Se establece a 2. Htype. Se establece segn el hardware de red que se utilice. Xid. Se establece al Xid del DHCPDISCOVER recibido. Yiaddr. Se establece a la direccin de IP que se ofrece al cliente de DHCP. Siaddr. Se establece a la direccin de IP del servidor de DHCP que ofrece la concesin. Chaddr. Se establece a la direccin de hardware del cliente como se recibi en el mensaje DHCPDISCOVER.
El servidor de DHCP tambin establece la siguiente serie de opciones:

q q q q q q q q
Cookie mgica. Se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 2 (DHCPOFFER). Mscara de subred. Se obtiene de la definicin de mbito. Tiempo de renovacin (T1). Se establece al 50 por 100 del tiempo de concesin, en segundos. Tiempo de reconexin (T2). Se establece al 87,5 por 100 del tiempo de concesin, en segundos. Tiempo de concesin de la direccin de IP. Duracin de la concesin, en segundos. Identificacin del servidor. Direccin de IP del servidor que ofrece la concesin. Nombre de dominio. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), el nombre de dominio de DNS especificado en la definicin de mbito. Servidor de nombre de dominios. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el
mbito), la lista de los servidores de DNS especificados en la definicin de mbito. Servidor de nombre de NetBIOS. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), la lista de servidores WINS especificados en el mbito. Tipo de nodo de NetBIOS. Si se solicita en el mensaje DHCPDISCOVER (y se configura en el mbito), el tipo de nodo de NetBIOS especificado en la definicin de mbito.
El cliente de DHCP que envi un DHCPDISCOVER puede recibir cero o ms mensajes DHCPOFFER. Si no se reciben mensajes DHCPOFFER, el cliente de DHCP retransmite el mensaje DHCPDISCOVER. Si el cliente no recibe ninguna oferta tras tres intentos, el cliente inicia la autoconfiguracin mediante APIPA.
DHCPREQUEST
Un cliente de DHCP enva DHCPREQUEST a un servidor de DHCP, normalmente durante la adquisicin inicial de una concesin, es decir, en respuesta a un DHCPOFFER, o dentro de una renovacin de la concesin posterior. Un host DHCP puede usarlo para confirmar la direccin de IP asignada anteriormente y los parmetros asociados de configuracin. Con la informacin del mensaje DHCPOFFER, o con las propiedades de DHCP configuradas actualmente, el cliente de Windows 2000 construye un mensaje DHCPREQUEST con los siguientes campos en la porcin de tamao fijo del mensaje:
q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER original (en concesiones nuevas) o a un nuevo ID de transaccin (en las renovaciones de concesin y las confirmaciones de IP). Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original. Ciaddr. En las nuevas concesiones, este campo se establece a 0; en la renovacin de una concesin se establece a la direccin que se desea renovar, o si la concesin ha expirado, a la direccin de IP que se concedi anteriormente al cliente de DHCP.
El cliente de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPREQUEST. Estas opciones son las siguientes:
q q q q
q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x03 (DHCPREQUEST). Identificador de cliente. Se establece a la direccin de hardware del cliente de DHCP. Direccin solicitada. Es la direccin ofertada en el mensaje DHCPOFFER. Si se reciben varias ofertas, es la direccin que el cliente eligi del conjunto de direcciones recibidas y, por tanto, la que pide ahora el cliente. ID de servidor. El cliente dirige la solicitud de DHCP a este servidor. Nombre de host. Es el nombre de host del cliente de DHCP. Actualizacin dinmica de DNS. Esta opcin, no definida en la RFC 2131, contiene el nombre de host que usar el servidor de DHCP para dar formato a las actualizaciones directas a inversas de DNS. Informacin de clase del cliente. Especifica la clase del fabricante del cliente de DHCP. En los equipos con Windows 2000, la cadena identificador de clase es MSFT 5.0. El servidor de DHCP la utiliza para identificar el tipo de clase de cliente a identificar cualquier informacin especfica de un fabricante que deba devolver. Lista de parmetros solicitados. Lista de los parmetros de configuracin que el cliente desea obtener. En los clientes con Windows 2000 esta lista contiene las opciones 0x01 (mscara de subred), 0x03 (enrutador), 0x06 (lista de servidores de DNS), 0x0F (nombre de dominio), 0x2B (informacin concreta del fabricante), 0x2C (lista de servidores de WINS), 0x2E (tipo de nodo de NetBIOS) y 0x2F (mbito de NetBIOS). Los mensajes DHCPREQUEST de Windows 98 son similares a los que envan los clientes de Windows 2000. El cliente de Windows 98 enva la Opcin 57 (tamao mximo de mensaje de DHCP), aunque el servidor de DHCP de Windows 2000 no lo asiente. El cliente de Windows 98, sin embargo, no enva la opcin actualizacin dinmica de DNS, ni informacin de clase del fabricante en la lista
Parmetros solicitados.
DHCPACK
El servidor de DHCP enva el mensaje DHCPACK al cliente de DHCP en respuesta a los mensajes DHCPREQUEST o DHCPINFORM. El mensaje DHCPACK es una confirmacin del servidor de DHCP de que ha enviado al cliente de DHCP una concesin con la direccin de IP y proporciona los valores de todas las opciones solicitadas, como se han especificado en la lista de parmetros solicitados del mensaje DHCPREQUEST. El servidor de DHCP de Windows 2000 construye un mensaje DHCPACK con los siguientes campos en la porcin de tamao fijo del mensaje:
q q q
q q
Op. Se establece a 2. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER original (en nuevas concesiones) o a un nuevo ID de transaccin (en renovacin de concesin y confirmacin de la direccin de IP). Yiaddr. Se establece a la direccin de IP del cliente. El servidor de DHCP enva esta direccin al cliente. Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original.
El servidor de DHCP de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPREQUEST. Las opciones son las siguientes:
q q q q q q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x05 (DHCPACK). Tiempo de renovacin (T1). Se establece al 50 por 100 del tiempo de concesin, en segundos. Tiempo de reconexin (T2). Se establece al 87,5 por 100 del tiempo de concesin, en segundos. Tiempo de concesin de la direccin de IP. Duracin de la concesin, en segundos. ID de servidor. El cliente dirige la solicitud de DHCP a este servidor Mscara de subred. La mscara de subred del cliente. Actualizacin dinmica de DNS. Se enva en respuesta a la actualizacin dinmica de DNS del mensaje DHCPREQUEST.
Adems, en el servidor de DHCP se enviarn todos los valores de opcin para cualquier opcin solicitada en el mensaje DHCPREQUEST.
DHCPDECLINE
Cuando un cliente de DHCP recibe una direccin de IP de un servidor de DHCP, el cliente debe determinar si esa direccin de IP ya se est utilizando. De hecho, el servidor de DHCP de Windows 2000 se puede configurar para que compruebe si la direccin se est utilizando antes de enviarla. Sin embargo, los clientes de Windows 2000 y Windows 98 realizan esta comprobacin tras recibir el mensaje DHCPACK. El cliente realiza la comprobacin enviando una difusin de ARP con dicha direccin. Si el cliente de DHCP recibe una respuesta de ARP que indique que la direccin ya se est utilizando, el cliente difunde un DHCPDECLINE al servidor de DHCP y desactiva la direccin. El servidor de DHCP de Windows 2000 marca la direccin como <bad> (errnea) en la base de datos de DHCP. El cliente es libre de adquirir otra concesin de otra direccin de IP. El servidor de DHCP ofrece y asiente una direccin de IP contra la que el cliente realiza una ARP gratuita. Como la direccin ya se encontraba en uso, ARP descubre un host que la usaba y el cliente de DHCP difunde el DHCPDECLINE. Ello permite al servidor de DHCP marcar la direccin como <bad address> en la base de datos de DHCP. El cliente de DHCP tambin escribe un mensaje de Aviso de registro de suceso en el registro de sucesos del cliente de DHCP, as como en el registro de sucesos del cliente que dispone actualmente la direccin de IP en
disputa, si el sistema es un equipo con Windows 2000. El cliente con Windows 2000 construye un mensaje DHCPDECLINE con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al Xid del DHCPDISCOVER o DHCPREQUEST originales. Ciaddr. Se establece a la direccin de IP en disputa, es decir, la que recibi el cliente pero que se ha determinado que ya est en uso. Chaddr. Se establece a la direccin de hardware del cliente como se especific en el mensaje DHCPDISCOVER original.
El cliente de DHCP de Windows 2000 tambin establece la siguiente serie de opciones en el mensaje DHCPDECLINE:
q q q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x04 (DHCPDECLINE). Identificador del cliente. La direccin MAC del cliente que enva el mensaje DHCPDECLINE. Direccin solicitada. La direccin de IP en disputa. ID de servidor. La direccin de IP del servidor que envi al cliente la direccin de IP en disputa.
DHCPNAK
El servidor de DHCP usa los mensajes DHCPNAK para indicar al cliente de DHCP que no se puede proporcionar la direccin solicitada. Puede ocurrir cuando un cliente con una concesin est desconectado o, por razones administrativas, el administrador de DHCP cancela la concesin. En este caso, el servidor de DHCP podra conceder la direccin a otro cliente. Tambin puede ocurrir con clientes que se trasladan a otras subredes. Si la direccin solicitada proviene de un mbito que no coincide con el mbito del valor en el campo Giaddr o el mbito de la interfaz por la que se recibe (si el campo Giaddr es 0), el servidor de DHCP determina que el cliente de DHCP se ha trasladado a una subred diferente. Tras recibir un mensaje DHCPNAK, los clientes de DHCP de Windows liberan inmediatamente la direccin de IP e intentan conseguir una nueva direccin de IP.
DHCPRELEASE
El cliente de DHCP enva este mensaje al servidor de DHCP liberando la direccin de IP y cancelando la concesin. La direccin de IP liberada se puede volver a usar para otros clientes de DHCP. El servidor de DHCP de Windows 2000 no asiente los DHCPRELEASE. El mensaje DHCPRELEASE es un mensaje unicast desde el cliente de DHCP hasta el servidor de DHCP que envi originalmente la concesin que cancela el cliente. El cliente de DHCP de Windows 2000 construye un mensaje DHCPRELEASE con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. Se establece al ID de la nueva transaccin. Ciaddr. Se establece a la direccin de IP del cliente que se libera. Chaddr. Se establece a la direccin de hardware del cliente que se indic originalmente en el mensaje DHCPDISCOVER.
El cliente de Windows 2000 tambin establece una serie de opciones en el mensaje DHCPRELEASE. Dichas opciones
son las siguientes:

q q q q
Cookie mgica. Siempre se establece a 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x07 (DHCPRELEASE). Identificador de servidor. El servidor que emiti originalmente la concesin. Identificador de cliente. La direccin MAC del cliente de DHCP.
DHCPINFORM
En la RFC 2131 se define un nuevo tipo de mensaje de DHCP, DHCPINFORM, que los clientes pueden utilizar para solicitar informacin adicional de configuracin, independientemente de cuando se configuraron originalmente. Por ello, un cliente de DHCP, configurado con una direccin de IP esttica, podra utilizar mensajes DHCPINFORM para solicitar parmetros de configuracin local adicional de un servidor de DHCP. DHCPINFORM tambin lo usan los clientes de acceso remoto de Windows 2000 para obtener automticamente un nombre de dominio de DNS, tras configurarse la conexin del Protocolo Punto a punto (PPP). En Windows 2000, el uso clave del mensaje DHCPINFORM es para permitir que un servidor de DHCP con Windows 2000 descubra el nombre de la raz empresarial de los Servicios de directorio, DS (Directory Services), en el que se instala cada servidor como parte de la deteccin de servidores rogue de DHCP. Esta informacin se solicita mediante un mensaje DHCPINFORM incluyendo en el mensaje informacin propia del fabricante en el rea de opciones. Cuando otros servidores de DHCP que ejecutan el servicio Servidor de DHCP de Windows 2000 reciben el mensaje DHCPINFORM, el servidor lo procesa, lo asiente y responde con la informacin solicitada sobre la raz del DS empresarial. El servidor de Windows 2000 construye un mensaje DHCPINFORM con los siguientes campos en la porcin de tamao fijo del mensaje de DHCP:
q q q q
Op. Se establece a 1. Htype, Hlen. Se establecen de acuerdo con el hardware de red utilizado. Xid. El servidor de DHCP genera un nuevo ID de transaccin. Ciaddr. Se establece a la direccin de IP del servidor de DHCP.
El servidor de DHCP de Windows 2000 tambin establece la siguiente serie de opciones en el mensaje DHCPINFORM:
q q q
Cookie mgica. Siempre se establece al valor 99.130.83.99. Tipo de mensaje de DHCP. Se establece a 0x08 (DHCPINFORM). Informacin especfica del fabricante. Para la deteccin de servidor autorizado se establece en 0xSE.
Opciones de DHCP
El servidor de Windows 2000 proporciona una concesin de DHCP, lo que incluye la direccin de IP, la mscara de subred y de ciertas opciones solicitadas por el cliente. Una opcin de DHCP es un parmetro de configuracin que puede enviar un servidor de DHCP a un cliente. Puede tratarse de opciones estndar, utilizadas en todos los mensajes de DHCP, o en todos los mensajes de un determinado tipo como DHCPDISCOVER, como la opcin Cookie mgica o el tipo de mensaje de DHCP. Adems, las opciones de DHCP pueden contener parmetros de configuracin que se soliciten explcitamente por los clientes de DHCP, como la direccin de IP de la pasarela predeterminada. El servidor de DHCP de Windows 2000 admite los tipos de opcin estndar, definidos en la RFC 2132. Adems, Windows 2000 define opciones extra especficas del fabricante que puede usar el administrador para proporcionar a los clientes de DHCP informacin adicional.
Formatos de las opciones

Como se define en las RFC 2121 y 2132, las opciones pueden ser de tamao fijo o de tamao variable y pueden contener, o no, datos asociados. Todas las opciones empiezan con un byte que identifica el cdigo de opcin. Las opciones de tamao fijo, sin datos, constan de un byte de etiqueta. Las nicas opciones de tamao fijo sin datos son la Opcin 0 (Pad-Relleno) y la Opcin 255 (End-Fin). El resto de las opciones son de tamao variable y tienen un byte de tamao a continuacin del byte etiqueta. El valor del byte tamao excluye los dos bytes que indica la etiqueta y el tamao. El valor de tamao indica el nmero de bytes que puede contener la opcin. Algunas opciones de tamao variable tienen un campo de tamao fijo, pero se seguir especificando la opcin tamao. La clase de opcin especfica del fabricante tiene un formato ligeramente diferente en el que existe una nica opcin (informacin especfica del fabricante) que consiste en una lista de subopciones.
Opciones que admite Windows 2000

El servicio de DHCP de Windows 2000 admite todas las opciones especificadas en la RFC 2132. Sin embargo, la mayora de las opciones definidas ya no se usan o los clientes de Windows y MS-DOS no las usan. Las opciones que admite el servidor de DHCP de Windows 2000 pertenecen a alguno de los siguientes tres grupos:
q q
Opciones presentes en todos los mensajes, o en todas las ocurrencias de un tipo de mensaje dado. Opciones estndar que pueden solicitar los clientes y que el servidor de DHCP proporciona si el administrador ha definido un valor para la opcin. Opciones del fabricante que se devuelven segn la clase del cliente. Opciones de DHCP presentes en todos los mensajes de DHCP Nombre de opcin Pad (Relleno) Cdigo Tamao 0 1 byte Descripcin Se usa para alinear el resto de campos. Se puede usar en cualquier mensaje de DHCP. Se usa junto con una direccin de IP ofrecida. Se usa en los mensajes DHCPOFFER y DHCPACK. Especifica el nombre del cliente. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST y DHCPNAK.
Subnet Mask (Mscara de subred) Host Name (Nombre de host)
4 bytes
12
Tamao variable; el tamao mnimo es 1 byte Tamao variable
Vendor Specific Information (Informacin especfica del fabricante) Requested Address (Direccin solicitada) Lease Time (Tiempo de concesin)
43
La utilizan los clientes y servidores para intercambiar informacin especfica del fabricante. La definicin de este tipo de informacin especfica no est definido en la RFC 2132. Se usa en los mensajes DHCPINFORM. La direccin que el cliente de DHCP solicita, o rechaza. Se usa en los mensajes DHCPREQUEST y DHCPDELCINE. Tiempo de la concesin en segundos. Pre sente en los mensajes DHCPOFFER y DHCPACK.
50
4 bytes
51
4 bytes
DHCP Message Type (Tipo de mensaje de DHCP)
53
1 byte
Se usa para definir el tipo de mensaje de DHCP. Los valores son los siguientes: 1. 2. 3. 4. 5. 6. 7. 8. DHCPDISCOVER. DHCPOFFER. DHCPREQUEST. DHCPDECLINE. DHCPACK. DHCPNAK. DHCPRELEASE. DHCPINFORM.
Se usa en todos los mensajes de DHCP. Server Identifier (Identificador de servidor) Parameter Request List (Lista de parmetros solicitados) 54 4 bytes La direccin de IP del servidor de DHCP. Se usa en los mensajes DHCPREQUEST, DHCPACK, DHCPDECLINE y DHCPRELEASE. Lo usa un cliente de DHCP para solicitar valores de parmetros especficos de configuracin. Cada byte es un cdigo de opcin vlida de DHCP (definida en la RFC 2132) para las opciones para las que el cliente solicita valores del servidor. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST y DHCPINFORM. Tiempo hasta que el cliente est en el estado de renovacin. Se usa en los mensajes DHCPOFFER y DHCPACK. Tiempo hasta que el cliente est en el estado de reconexin. Se usa en los mensajes DHCPOFFER y DHCPACK. Valor para identificar unvocamente el cliente. Para los clientes de Windows 2000 es la direccin MAC del cliente. Se usa en los mensajes DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPNAK y DHCPRELEASE.
55
Tamao variable; pero los clientes de Windows 2000 ser de 8 bytes
Renewal Time (T1) (Tiempo de renovacin) Rebinding Time (T2) (Tiempo de reconexin) Client Identifier (Identificador de cliente)
58
4 bytes
59
4 bytes
61
Tamao variable; el tamao mnimo es de 2 bytes; para Ethernet el tamao es de 6 bytes Tamao variable
Dynamic DNS Update (Actualizacin dinmica de DNS) End (Fin)
81
Es el nombre completo de dominio cualificado del host y el servidor lo utiliza para enviar actualizaciones dinmicas de DNS al servidor de DNS. Se usa en los mensajes DHCPREQUEST. Marca el fin del campo Opciones de un mensaje DHCP. Se usa en todos los mensajes de DHCP.
255
1 byte
Opciones solicitadas por los clientes DHCP(1)
Nombre de opcin Router (Enrutador)
Cdigo Tamao 3 Variable, pero siempre mltiplo de 4
Descripcin Una lista de direcciones de IP para los enrutadores de la subred del cliente, que se debera presentar en orden de preferencia. Normalmente slo existir un enrutador -la pasarela predeterminada-, pero se pueden especificar varios. Una lista de las direcciones de IP de los servidores del Sistemas de nombres de dominio (para RFC 1035) a los que puede acceder el cliente. El nombre de dominio de DNS que el cliente de DHCP debera usar cuando resuelve los nombres de hosts utilizando DNS. Una lista de direcciones de IP de servidores WINS que puede usar el cliente. Normal mente se tratar de un servidor primario y uno secundario. Se usa para indicar a un cliente de TCP/IP cmo se deberan resolver los nombres de NetBIOS, de acuerdo con: 0x1 nodo B (difusin). 0x2 nodo P (punto a punto). 0x4 nodo M (mixto). 0x8 nodo H (hbrido). Especifica el mbito de NetBIOS sobre TCP/IP para los clientes, como se especifica en las RFC 1001 y 1002.
Domain Name Servers (Servidores de nombres de dominio)
Variable, pero siempre mltiplo de 4
DNS Domain Name (Nombre de dominio de DNS) WINS Server Names (Nombres de servidores WINS)
15
Tamao variable, conjunto de caracteres ASCII Variable, pero siempre mltiplo de 4
44
NetBIOS Over TCP/IP Node Type (Tipo de nodo TCP/IP sobre NetBIOS)
46
1 byte
NetBIOS Scope ID (ID 47 del mbito de NetBIOS)
Variable, tamao mnimo 1
(1)
Estas opciones se entregan si el administrador ha especificado valores para ellas. Opciones especficas del fabricante(2) Nombre de opcin Microsoft Disable NetBIOS Option (Opcin desactivar Microsoft NetBIOS) Microsoft Release On Shutdown (Liberar en el apagado de Microsoft) Microsoft Default Router Metric Base (Base de mtrica predeterminada del enrutador de Microsoft) Cdigo Tamao Descripcin 1 4 Indica al cliente de Windows 2000 si desactivar o no NetBIOS. Indica al cliente de Windows 2000 si libera la concesin de DHCP al apagar. Especifica la base de mtrica predeterminada del enrutador
Adems de las opciones estndar anteriores, el administrador puede especificar opciones a devolver a los clientes de una determinada clase, como Windows 2000, Windows 98, etc. ltima actualizacin del tema completo: 23/12/2005 v1.0.1
(2)
Windows 2000 Server. Servicio de Nombres de Dominio (DNS)
Tema 2.- Servicio de Nombres de Dominio (DNS)

q q
Descripcin general de DNS en Microsoft Windows 2000 Trminos clave de DNS r Espacio de nombres r Registros de recursos de DNS r Servidores de Nombres r Resolutores de DNS Integracin de DNS y Active Directory r Resolucin de nombres r Zonas de DNS r Delegacin de Zonas r DNS Dinmico (DDNS) Replicacin y Transferencia de zona r Transferencia tradicional r Transferencia incremental r Transferencia de la zona del AD
Servicio de nombres de Dominio (DNS)

Descripcin general de DNS en Microsoft Windows 2000 Trminos clave de DNS Espacio de nombres Registros de recursos de DNS Servidores de Nombres Resolutores de DNS Integracin de DNS y Active Directory Resolucin de nombres Zonas de DNS Delegacin de Zonas DNS Dinmico (DDNS) Replicacin y Transferencia de zona Transferencia tradicional Transferencia incremental Transferencia de la zona del AD
Todos los hosts con TCP/IP tienen una direccin de IP nica que se utiliza para la comunicacin con otros equipos de la red. Una equipo trabaja fcilmente con direcciones de IP, pero no las personas; los usuarios suelen identificar los sistemas por un nombre. Para facilitar una comunicacin efectiva y eficiente, los usuarios deben poder referirse a los equipos por un nombre y permitir que su equipo use su direccin de IP transparentemente. En los primeros das de ARPANET, el antecesor de la Internet actual, slo exista un pequeo nmero de equipos conectados a la red. El Centro de Informacin de Red (NIC), ubicado en el Instituto de Investigaciones de Stanford, SRI (Stanford Research Institute), era el responsable de compilar en un nico archivo, HOSTS. TXT, los nombres y direcciones de todos los equipos. Los administradores deban mandar un mensaje al SRI, quien actualizaba el archivo HOSTS.TXT. A continuacin, los usuarios de ARPANET deban descargar la nueva versin del archivo HOSTS.TXT mediante el Protocolo de transferencia de archivos (FTP). Con el crecimiento de ARPANET, resultaba obvio que este mtodo no permita crecer apropiadamente por las siguientes razones clave:
q
El ancho de banda consumido para transmitir las versiones actualizadas de un archivo de host de ARPANET sera proporcional al cuadrado del nmero de hosts en la ARPANET. Con un nmero de hosts creciendo exponencialmente, el impacto a largo plazo probablemente sera de una sobrecarga que ningn host podra mantener. El archivo de host plano y esttico significara que no podra haber dos equipos en la ARPANET con la misma direccin. Al crecer el nmero de hosts, crece el riesgo de aadir nombres duplicados, as como la dificultad de intentar un control centralizado. La naturaleza de la red subyacente estaba cambiando -los grandes equipos de tiempo compartido con que se haba construido ARPANET se estaban viendo desplazados por estaciones de trabajo- y cada una necesitaba un nombre de host nico. Podra ser difcil, sino imposible, de controlar centralizadamente.
Con el crecimiento de ARPANET, resultaba ms claro que se necesitaba una solucin mejor. Se generaron varias propuestas segn el concepto de servicio de nombres distribuido, que se basaban en un espacio de nombres jerrquico. Nacieron las RFC 882 y 883, donde se describe el diseo de un sistema de nombres de dominio, basado en una base de datos distribuida que contiene informacin generalizada de recursos. Este diseo evolucion, y las RFC 1034 y 1035 describen el servicio del Sistema de nombres de dominio (DNS) que se usa hoy en Internet.
Ir a la pgina Principal ltima actualizacin del tema completo: 25/10/2005 v.3.0.0
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-m.htm06/01/2006 5:06:19
Todos los hosts con TCP/IP tienen una direccin de IP nica que se utiliza para la comunicacin con otros equipos de la red. Una equipo trabaja fcilmente con direcciones de IP, pero no las personas; los usuarios suelen identificar los sistemas por un nombre. Para facilitar una comunicacin efectiva y eficiente, los usuarios deben poder referirse a los equipos por un nombre y permitir que su equipo use su direccin de IP transparentemente. En los primeros das de ARPANET, el antecesor de la Internet actual, slo exista un pequeo nmero de equipos conectados a la red. El Centro de Informacin de Red (NIC), ubicado en el Instituto de Investigaciones de Stanford, SRI (Stanford Research Institute), era el responsable de compilar en un nico archivo, HOSTS.TXT, los nombres y direcciones de todos los equipos. Los administradores deban mandar un mensaje al SRI, quien actualizaba el archivo HOSTS.TXT. A continuacin, los usuarios de ARPANET deban descargar la nueva versin del archivo HOSTS. TXT mediante el Protocolo de transferencia de archivos (FTP). Con el crecimiento de ARPANET, resultaba obvio que este mtodo no permita crecer apropiadamente por las siguientes razones clave:
q
El ancho de banda consumido para transmitir las versiones actualizadas de un archivo de host de ARPANET sera proporcional al cuadrado del nmero de hosts en la ARPANET. Con un nmero de hosts creciendo exponencialmente, el impacto a largo plazo probablemente sera de una sobrecarga que ningn host podra mantener. El archivo de host plano y esttico significara que no podra haber dos equipos en la ARPANET con la misma direccin. Al crecer el nmero de hosts, crece el riesgo de aadir nombres duplicados, as como la dificultad de intentar un control centralizado. La naturaleza de la red subyacente estaba cambiando -los grandes equipos de tiempo compartido con que se haba construido ARPANET se estaban viendo desplazados por estaciones de trabajo- y cada una necesitaba un nombre de host nico. Podra ser difcil, sino imposible, de controlar centralizadamente.
Con el crecimiento de ARPANET, resultaba ms claro que se necesitaba una solucin mejor. Se generaron varias propuestas segn el concepto de servicio de nombres distribuido, que se basaban en un espacio de nombres jerrquico. Nacieron las RFC 882 y 883, donde se describe el diseo de un sistema de nombres de dominio, basado en una base de datos distribuida que contiene informacin generalizada de recursos. Este diseo evolucion, y las RFC 1034 y 1035 describen el servicio del Sistema de nombres de dominio (DNS) que se usa hoy en Internet.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-1.htm06/01/2006 5:06:20
Trminos clave de DNS

DNS es un servicio de nombres estndar del IETF. El servicio de DNS permite que un equipo cliente de la red registre y resuelva nombres de dominio de DNS. Estos nombres se utilizan para encontrar y acceder a recursos de otros equipos de la red o de otras redes como Internet. Los tres componentes principales de DNS son los siguientes:
q q q
Espacio de nombres de dominio. Registros de recursos (RR) asociados. Una base de datos distribuida de informacin de nombres. Servidores de nombre de DNS. Servidores que mantienen el espacio de nombres de dominio y los RR y responden a las peticiones de los clientes de DNS. Resolutores de DNS. Facilidad con la que un cliente de DNS se pone en contacto con servidores de nombre de DNS y enva peticiones de nombre para obtener informacin de registros de recursos.
Espacio de nombres de dominio

El espacio de nombres de dominio est estructurado de manera jerrquica en un rbol que empieza en una raz sin nombre para todas las operaciones de DNS. En el espacio de nombres de DNS cada nodo y cada hoja en el rbol del espacio de nombres de dominio representan un dominio con nombre. Cada dominio puede tener dominios hijos adicionales.
Nombres de dominio
Cada nodo en el rbol de DNS tiene un nombre distinto, llamado etiqueta (label) como se le denomina en la RFC 1034. Cada etiqueta de DNS puede tener entre 1 y 63 caracteres y el dominio raz no tiene caracteres. Un nombre de dominio concreto es la lista de etiquetas en la ruta desde el nodo nombrado hasta la raz del rbol de DNS. La convencin de DNS es que las etiquetas que componen un nombre de dominio se leen de izquierda a derecha, desde lo ms concreto hasta la raz, por ejemplo, www.midominio.com. Este nombre completo tambin se denomina nombre de dominio completo, FQDN (Fully Qualified Domain Name). Los nombres de dominio se puede almacenar en maysculas o en minsculas, pero todas las comparaciones y funciones de dominios se definen como insensibles a maysculas y minsculas en la RFC 1034. Por tanto, www. midominio.com es idntico a WWW.MIDOMINIO.COM para las operaciones de nombrado de dominios.
Dominios superiores
Un dominio superior es un dominio de DNS directamente debajo de la raz. Resulta difcil crear nombres adicionales, al menos en Internet. Las tres categoras de dominios superiores son las siguientes:
q q q
<ARPA>. Es un dominio especial, se usa en la actualidad para bsqueda inversa de nombres. Dominios de 3 letras. Existen siete dominios superiores de 3 caracteres. Nombres de 2 letras para los pases. Estos dominios con cdigo de pas se basan en los nombres de pas de la Organizacin Internacional de Normalizacin (ISO) y se usan, principalmente, por compaas y organizaciones fuera de los EE.UU. La excepcin es UK, que utiliza .uk como dominio superior, aunque el cdigo de pas de ISO es GB.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-2a.htm06/01/2006 5:06:20
Registros de recursos de DNS

Un registro de recurso es un registro que contiene informacin relacionada con un dominio que puede contener la base de datos de DNS y que puede solicitar y usar un cliente de DNS. Por ejemplo, el RR de host de un dominio concreto mantiene la direccin de IP de tal dominio (host); un cliente de DNS podr utilizar este RR para conseguir la direccin de IP para el dominio. Cada servidor de DNS contiene los RR relacionados con aquellas porciones del espacio de nombre de DNS para el que es autoridad, o para el que puede responder las solicitadas por un host. Cuando un servidor de DNS es autorizado para una porcin del espacio de nombres de DNS, dichos administradores del sistema son los responsables de asegurar que la informacin sobre esa porcin del espacio de nombres de DNS es correcta. Para aumentar la eficiencia, un servidor de DNS dado puede hacer cach de los RR relativos a un dominio de cualquier parte del rbol de dominios. Cada RR contendr un conjunto de informacin comn, como la siguiente:
q q
Propietario. Indica el dominio de DNS en el que se encuentra el registro de recurso. TTL. Tiempo que utilizan otros servidores de DNS para determinar durante cuanto tiempo se hace cach de la informacin de un registro antes de descartarla. Para la mayora de los RR, este campo es opcional. El valor de TTL se mide en segundos, con un valor de 0 que indica que el RR contiene datos voltiles que no se deben guardar en cach. Por ejemplo, los registros SOA tienen un valor de TTL predeterminado de 1 hora. De esta forma se evita que otros servidores mantengan en cach estos registros durante largos perodos de tiempo, lo que podra retrasar la propagacin de cambios. Clase. Para la mayora de los RR, este campo es opcional. Cuando se utiliza, contiene un texto mnemnico que indica la clase de un RR. Por ejemplo, una clase con IN indica que el registro pertenece a la clase Internet (IN). Alguna vez existieron muchas clases, como CH para Chaos Net, pero en la actualidad slo se usa la clase IN. Tipo. Este campo es requerido y mantiene un texto mnemnico estndar que indica el tipo del RR. Por ejemplo, el mnemnico A indica que el RR guarda la informacin de direccin (Address) del host. Datos especficos del registro. Es un campo de tamao variable que contiene informacin que describe el recurso. Este formato de informacin vara de acuerdo con el tipo y clase del RR.
Los archivos de zona de DNS estndar contienen el conjunto de RR de dicha zona en un archivo de texto. En este archivo de texto, cada RR se encuentra en una lnea separada y contiene todos los elementos de datos anteriores, como un conjunto de campos de texto separados por espacios en blanco. En el archivo de zona, cada RR consta de los elementos de datos anteriores, aunque diferentes registros pueden contener registros con formatos ligeramente diferentes para datos especficos.
Registros de recursos que admite Windows 2000

Existen numerosos tipos de RR definidos en las RFC 1035, 1036 y posteriores. La mayora de los tipos de RR ya no se necesitan ni se usan, aunque todos esos estn disponibles en Windows 2000. Los RR usados ms habitualmente, son:
Direccin de host (A) [Adress 32 bits]

Este RR contiene un RR direccin de host que hace corresponder un nombre de dominio de DNS con una direccin de IPv4 de 32 bits.
q q q
Tipo. A Sintaxis. Propietario A direccin_IPv4 Ejemplo. kona A 10.10.2.200
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-2b.htm (1 of 3)06/01/2006 5:06:21
Registro host de IPv6 (AAAA) [Adress 128 bits]

Este RR contiene un RR direccin de host que hace corresponder un nombre de dominio de DNS a una direccin de IPv6 de 128 bits.
q q q
Tipo. AAAA Sintaxis. Propietario AAAA direccin_IPv6 Ejemplo. ipv6host AAAA 4321:0:1:2:3:4:567:89a:0
Nombre cannico (CNAME) [canonical name]

El RR nombre cannico (CNAME) permite a los administradores de red crear un alias de otro nombre de dominio. El uso de RR CNAME se recomienda para su uso en los siguientes escenarios:
q
Cuando un host especificado en un RR (A) de la misma necesita cambiar de nombre. Por ejemplo, si necesita cambiar el nombre de kona.midominio.com a hilo.midominio.com, creara una entrada CNAME para kona.midominio.com que apuntase a hilo.midominio.com. Cuando un nombre genrico de un servicio conocido, como ftp o www, se necesita resolver a un grupo de equipos individuales, cada uno con un RR (A) individual. Por ejemplo, podra querer que www.midominio.com fuese un alias de kona.midominio.com y hilo.midominio.com. Un usuario que accediese a www.midominio.com normalmente no advertira qu equipo realmente sirve la solicitud.
Este RR hace corresponder un alias o nombre de dominio de DNS alternativo en el campo Propietario (Owner) con un nombre cannico, real, de DNS. Debe haber tambin un RR (A) para el nombre de dominio de DNS cannico, que se debe resolver a un nombre de dominio de DNS vlido en el mismo espacio de nombres. El nombre cannico completo debera terminar con un punto (.).
q q q
Tipo. CNAME Sintaxis. Alias CNAME Nombre_cannico o alias Ejemplo. ns1 CNAME alias.midominio.com.
Intercambiador de correo (MX) [Mail Exchange]

El registro MX proporciona enrutamiento de mensajes a un host de intercambio de correo para cualquier correo que se enve a un dominio dado. Este RR tambin contiene un valor de preferencia de 2 dgitos para indicar el orden de preferencia de los hosts, si se especifican varios intercambiadores. Cada host intercambiador que se especifique en el registro MX debe tener el correspondiente RR A direccin de host en la zona actual.
q q q
Tipo. MX Sintaxis. Propietario MX preferencia nombre_de_host_de_intercambio_de_correo Ejemplo. midominio MX 10 correo.midominio.com
Puntero (PTR) [Pointer reverse]

Este RR que se usa para los mensajes de bsqueda inversa de nombre apunta en la direccin de IP del campo Propietario (Owner) otra ubicacin en el espacio de nombres de DNS como especifica el nombre_de dominio_objetivo. Normalmente, se usa slo el rbol de dominio in-addr.arpa para la bsqueda inversa de la correspondencia direccin-nombre. En la mayora de los casos, cada registro proporciona informacin que apunta a otra ubicacin de un nombre de dominio de DNS, como un RR A de direccin de host en una zona de bsqueda inversa.
q
Tipo. PTR

q q
Sintaxis. Propietario PTR nombre_de_dominio_objetivo Ejemplo. 200 PTR kona.midominio.com
Localizador de servicio (SRV) [Server]

El RR SRV (Service Locator) permite a un equipo localizar un host que disponga de un cierto servicio, como el Controlador de dominio del Active Directory de Windows 2000. De esta forma el administrador puede tener mltiples servidores, cada uno proporcionando un servicio similar basado en TCP/IP que se puede localizar con una nica operacin de solicitud de DNS. Este registro se usa, principalmente, para disponer del AD de Windows 2000, donde todos los RR de DNS relevantes se pueden incluir automticamente en el DNS.
q q q
Tipo. SRV Sintaxis. nombre_del_protocolo_de_servicio SRV preferencia peso Puerto objetivo Ejemplo._ldap._tcp.dc _msdcs 600 SRV 0 100 389 kona.midominio.com 600 SRV 0 100 389 midominiolt.midominio.com 600 SRV 0 100 389 hilo.midominio.com
Los RR se pueden asociar a cualquier nodo del rbol de DNS, aunque los RR no existirn en algunos dominios; por ejemplo, los RR Puntero (PTR) se encuentran slo en los dominios debajo del dominio in-addr.arpa. Por ello, los dominios superiores, como microsoft.com, pueden tener RR individuales -por ejemplo, un registro de Intercambio de correo (MX) para el correo que se enve a Microsoft Corporation-, as como disponer de subdominios que tambin podran disponer de RR individuales; por ejemplo, eu.microsoft.com, que tiene un registro de host www.eu. microsoft.com.
Servidores de Nombre de DNS

Un cliente efecta una operacin de solicitud a un servidor de DNS para conseguir parte o toda la informacin de RR relacionada con un determinado dominio, por ejemplo, para determinar qu registro o registros de hosts (A) se mantienen sobre el dominio llamado midominio.com. Si el dominio existe y tambin el RR solicitado, el servidor de DNS devolver la informacin solicitada en un mensaje de respuesta a la solicitud. El mensaje de respuesta devolver tanto la solicitud inicial como la respuesta con los registros relevantes, suponiendo que el servidor de DNS pueda conseguir los RR necesarios. La solicitud de DNS, a la que se refiere la RFC 1034 como solicitud estndar, contiene un nombre de dominio objetivo, un tipo de solicitud y una clase de solicitud. La solicitud contendr una solicitud de uno o varios RR concretos que se desean obtener, o una solicitud que devuelva todos los RR relativos al dominio.
Solicitud inversa
Una solicitud inversa es aquella en la que se solicita a un servidor de DNS el nombre de dominio de DNS de un host con una determinada direccin de IP. Los mensajes de Solicitud de bsqueda inversa son, realmente, solicitudes estndar, pero relacionadas con las zonas de bsqueda inversa. Las zonas de bsqueda inversa se basan en el nombre de dominio in-addr.arpa y mantiene, principalmente, los RR de PTR. La creacin de zonas de bsqueda inversa y el uso de RR de PTR para identificar los hosts son partes optativas del estndar de DNS. Las zonas de bsqueda inversa no son obligatorias en Windows 2000, aunque algunas aplicaciones de red pueden configurarse para que usen las zonas de bsqueda inversa como forma adicional de seguridad. Las solicitudes inversas se describieron originalmente en la RFC 1032, pero ya estn obsoletas. Una solicitud inversa significa buscar un nombre de host por su direccin de IP y utilizar una operacin de solicitud de DNS no estndar. El uso de las solicitudes inversas est limitado a algunas de las primeras versiones de NSLOOKUP.EXE, una utilidad para probar y resolver problemas del servicio de DNS. El servidor de DNS de Windows 2000 reconoce y acepta los mensajes de solicitud inversa y responde con una <simulacin>.
Clases de solicitudes de DNS

Las solicitudes de DNS pueden ser de dos clases: recursivas o iterativas.
q
Una solicitud recursiva es una solicitud de DNS que se enva a un servidor de DNS en la que el host solicitante pregunta al servidor de DNS para que le proporcione una respuesta completa a la solicitud, aunque ello signifique que tenga que ponerse en contacto con otros servidores para obtener la respuesta. Cuando se enva una solicitud recursiva, el servidor de DNS usa un conjunto de solicitudes iterativas a otros servidores de DNS como intermediario del host solicitante para conseguir la respuesta a la solicitud. Una solicitud iterativa es una solicitud de DNS que se enva a un servidor de DNS en el que el host solicitante pide que se devuelva la mejor respuesta que el servidor de DNS pueda proporcionar sin buscar ayuda adicional de otros servidores de DNS.
En general, los equipos envan solicitudes recursivas. Los equipos suponen que el servidor de DNS conoce la respuesta a la solicitud, o puede encontrarla. Por otra parte, un servidor de DNS normalmente enviar solicitudes iterativas a otros servidores de DNS si no puede responder a la solicitud con la informacin de que dispone.
Operacin de Actualizacin de DNS

Una operacin de actualizacin de DNS la enva un cliente a un servidor de DNS para actualizar, aadir o eliminar
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-2c.htm (1 of 2)06/01/2006 5:06:21
algunos o todos los RR de informacin relacionada con un determinado dominio, por ejemplo, para actualizar el registro de host del equipo con nombre equipo.midominio.com para que apunte a 10.10.1.100. La operacin de actualizacin tambin se denomina actualizacin dinmica.
Resolutores de DNS
En Windows 2000, el resolutor de DNS es un componente del sistema que realiza solicitudes de DNS a otro u otros servidores de DNS. La pila de TCP/IP de Windows 2000 se configura, normalmente, con la direccin de IP de al menos un servidor de DNS al que el resolutor enva una o ms solicitudes de informacin de DNS. En Windows 2000, el resolutor forma parte del servicio Cliente de DNS. Este servicio se instala automticamente cuando se instala TCP/IP y se ejecuta como parte del proceso Services.Exe. Como la mayora de los servicios de Windows 2000, el servicio Cliente de DNS se activa en el dominio System de Windows 2000. La resolucin de nombres de DNS se produce cuando un resolutor, en un host, enva a un servidor de DNS un mensaje de solicitud con un nombre de dominio. El mensaje de solicitud indica al DNS que busque el nombre y devuelva ciertos RR. El mensaje de solicitud contiene el nombre de dominio a buscar y un cdigo que indica los registros que se deben devolver. Un cliente enva una solicitud de DNS pidiendo al servidor de DNS todos los registros A de kona.midominio.com. La respuesta a la solicitud contiene la entrada de solicitud y los RR de respuesta.
Resolucin de alias
Si el resolutor intenta realizar resolucin de nombres de un nombre que indique el usuario, no sabe a priori si el nombre se refiere a un RR (A) de host o a un CNAME. Si se refiere a un CNAME, el servidor puede devolver el CNAME. Sin embargo, en este caso, el CNAME debe resolverse todava. Para evitar trfico extra de DNS, cuando un servidor de DNS devuelve un CNAME en respuesta a una bsqueda de registro de host, el servidor de DNS tambin devuelve el registro A relativo al CNAME. El cliente de DNS enva una solicitud de DNS al servidor de DNS solicitando el registro Host de nsl.midominio.com, que en realidad es un alias de kona.midominio.com. En la respuesta de DNS existen dos RR de respuesta. El primero es el RR CNAME de nsl.midominio.com, que contiene el nombre cannico. El segundo RR de respuesta es el registro Host de kona.midominio.com, que contiene la direccin de IP de este equipo.
Cach del resolutor de DNS

Un host de IP podra necesitar ponerse en contacto peridicamente con otro host y por tanto necesitara resolver un nombre concreto de DNS muchas veces, como por ejemplo el nombre del servidor de correo electrnico. Para evitar tener que enviar solicitudes a un servidor de DNS cada vez que el host quiere resolver el nombre, Windows 2000 implementa una cach especial de informacin de DNS.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-2d.htm (1 of 2)06/01/2006 5:06:22
El servicio Cliente de DNS hace cach de los RR recibidos en las respuestas a las solicitudes de DNS. La informacin se mantiene durante un Perodo de vida, TTL (Time To Live), y se puede utilizar para responder solicitudes posteriores. De forma predeterminada, la cach utiliza el valor de TTL recibido en la respuesta de solicitud de DNS. Cuando se resuelve una solicitud, el servidor autoridad de DNS en el dominio resuelto define el TTL para un RR dado. Puede utilizar el comando IPCONFIG con la opcin /DISPLAYDNS para mostrar el contenido actual de la cach del resolutor.
Cach negativa
El servicio Cliente de DNS tambin proporciona cach negativa. La cach negativa ocurre cuando no existe un RR de un nombre de dominio solicitado o cuando el propio nombre de dominio no existe, en cuyo caso se guarda la falta de resolucin. La cach negativa evita repetir solicitudes adicionales de RR o dominios que no existen. Si se realiza una solicitud a un servidor de DNS y la respuesta es negativa, las siguientes solicitudes al mismo nombre de dominio se responden negativamente durante un tiempo predeterminado de 300 segundos. Para evitar guardar en la cach informacin negativa anticuada, cualquier informacin de solicitud respondida negativamente se mantiene durante un perodo de tiempo inferior al que se utiliza para las respuestas positivas. Con la cach negativa se reduce la carga en los servidores de DNS, pero estarn disponibles los RR relevantes, y se podrn enviar solicitudes posteriores para obtener la informacin. Si se realiza una solicitud a todos los servidores de DNS y no est disponible ninguno durante un tiempo predeterminado de 30 segundos, las solicitudes posteriores por nombre fallarn inmediatamente en lugar de esperar los plazos. De esta forma se puede ahorrar tiempo en servicios que utilizan DNS durante el proceso de arranque, sobre todo cuando se arranca de la red.
Integracin de DNS y de Active Directory

El servicio de DNS proporciona la resolucin de nombres para clientes ejecutando Windows 2000. Con la resolucin de nombres, los usuarios pueden acceder a los servidores segn su nombre en vez de tener que usar su direccin IP que es ms difcil de recordar.
Resolucin de nombres
La resolucin de nombres es el proceso de resolver nombres DNS a direcciones IP. La resolucin de nombres es similar a mirar un nombre en la gua telefnica, donde el nombre se asocia con un nmero de telfono. Por ejemplo, cuando se conecta al lugar Web de Microsoft, se utiliza el nombre www.microsoft.com. El DNS resuelve www.microsoft.com y su direccin asociada 207.46.130.149. El mapeo de nombres y direcciones IP se almacena en la base de datos distribuida de DNS. Un servidor de nombres slo puede resolver una consulta para una zona en la que tiene autoridad. Si un servidor de nombres no puede resolver la consulta, dicha consulta pasa a otros servidores de nombres que sean capaces de resolver la consulta. Los servidores de nombres almacenan en cach los resultados de las consultas para reducir el trfico de DNS en la red. El servicio de DNS utiliza el modelo cliente/servidor para la resolucin de nombres. Para resolver una consulta de bsqueda directa, un cliente pasa una consulta a un servidor de nombres local. El servidor de nombres local o resuelve la consulta o consulta a otro servidor de nombres para la resolucin.
q
q q
Los subdominios se nombran despus de los nmeros en la representacin decimal con puntos de las direcciones IP El orden de los octetos de la direccin IP se pone al contrario. Las empresas administran los subdominios del in-addr.arpa basndose en la asignacin de direcciones IP y en las mscaras de subred.
Zonas de DNS
El servicio de DNS permite dividir un espacio de nombres de DNS en zonas que almacenan informacin sobre uno o ms dominios DNS. Las zonas se convierten en la fuente autoritaria para la informacin sobre nombres de dominio DNS incluidos en la zona. El servicio de DNS proporciona la opcin de dividir el espacio de nombres en una o ms zonas, que pueden ser almacenadas, distribuidas y replicadas a otros servidores de DNS. El espacio de nombres DNS representa la estructura lgica de los recursos de red, y las zonas DNS proporcionan el almacenamiento fsico para estos recursos.
Preparacin para la implementacin de una zona

Cuando decida dividir o no el espacio de nombres de DNS para hacer zonas adicionales, considere la siguientes razones para realizar la divisin:
q
Necesidad de delegar la administracin de parte del espacio de nombres de DNS a otra localizacin o departamento dentro de la organizacin. Necesidad de dividir una gran zona en zonas ms pequeas para distribuir las cargas de trfico entre muchos servidores, mejorar el rendimiento de la resolucin de nombres DNS o crear un entorno DNS ms tolerante a fallos. Necesidad de extender el espacio de nombres mediante la agregacin de numerosos subdominios, tales como aquellos que se utilizan para acomodar la apertura de una nueva filial o sitio.
Cualquiera de estos motivos puede ser suficiente para aadir o reestructurar su espacio de nombres con zonas adicionales. Cuando elija cmo estructurar las zonas, debera usar un plan que cumpla las necesidades de la organizacin. Hay dos tipos de zonas de bsqueda: zonas de bsqueda directa y zonas de bsqueda inversa.
Zonas de bsqueda directa

Una zona de bsqueda directa permite consultas de bsqueda directa. En los servidores de nombres se debe configurar al menos una zona de bsqueda directa para permitir el funcionamiento del servicio de DNS. Cuando se instale Active Directory utilizando el Asistente de instalacin de Active Directory y permita al asistente instalar y configurar el servicio de DNS, el asistente crea automticamente una zona de bsqueda directa basada en el nombre del DNS que especific para el servidor. Hay tres tipos de zonas de bsqueda directa que puede configurar:
q
Integrada de Active Directory. Una zona integrada de Active Directory es la copia maestra de una nueva zona. La zona utiliza Active Directory para almacenar y replicar archivos de zona. Estndar principal. Una zona estndar principal es la copia maestra de una nueva zona almacenada en un archivo estndar de texto. Tiene que administrar y mantener una zona principal en un equipo en el que crea la zona. Estndar secundaria. Una zona estndar secundaria es una rplica de una zona existente. Las zonas secundarias son de slo lectura y estn almacenadas en archivos de texto estndar. Una zona principal debe estar configurada para crear una zona secundaria. Cuando cree una zona secundaria, debe especificar el servidor de DNS, denominado servidor maestro, que transferir la informacin de zona al servidor de nombres que contiene la zona secundaria estndar. Las zonas secundarias proporcionarn redundancia y reducirn la carga en el servidor de nombres que contiene el archivo de la base de datos de la zona principal.
Beneficios de las zonas integradas de Active Directory

Dentro del desarrollo con el DNS, las zonas principales integradas de Active Directory estn altamente recomendadas para proporcionar los siguientes beneficios:
q
Actualizacin multimaestro y seguridad acentuada basada en la capacidad de Active Directory. En un modelo de zona estndar de almacenamiento, las actualizaciones del DNS se realizan basndose en el modelo de actualizacin de maestro nico. En este modelo, un nico servidor autoritario del DNS para una zona se designa como fuente principal en dicha zona. Este servicio mantiene la copia maestra de la zona en un archivo local. Con este modelo, el servidor principal para la zona representa un nico punto fijo para fallos. Si este servidor no est disponible, las peticiones de actualizacin para los clientes del DNS no se procesan para la zona. Con la integracin del almacenamiento del directorio, las actualizaciones dinmicas del DNS se realizan basndose en el modelo de refresco multimaestro. En este modelo, cualquier servidor autoritario del DNS (tal como controladores de dominio con el del DNS) se designa como origen principal de la zona. Debido a que la copia maestra de la zona se mantiene en la base de datos de Active Directory, que est totalmente replicada en todos los controladores de dominio, la zona puede ser actualizada por el DNS de cualquier controlador de dominio en el dominio. Con el modelo de actualizacin multimaestro para Active Directory, cualquiera de los servidores principales para las zonas integradas del directorio puede procesar la peticin de los clientes del DNS para actualizar la zona en cuanto un controlador de dominio est disponible y accesible en la red. Tambin, cuando se utilizan zonas integradas de directorio, se puede utilizar la edicin de la lista de control de acceso (ACL - Access Control List) para proporcionar acceso selectivo a una zona o a un registro de recursos especfico de una zona. Por ejemplo, una ACL para un nombre de dominio especfico en la zona puede ser restringida de manera que las actualizaciones dinmicas estn slo permitidas para clientes especficos del DNS o se puede autorizar slo a un grupo seguro, como un dominio de administradores con permisos para actualizar una zona o registrar propiedades para la misma. Esta caracterstica de seguridad no est disponible con zonas principales estndares.
Las zonas se replican y sincronizan a nuevos controladores de dominio automticamente all donde una nueva zona se aade a un dominio de Active Directory. Aunque el DNS puede ser eliminado selectivamente de un controlador de dominio, las zonas integradas del directorio estn ya almacenadas en cada controlador de dominio, as que el almacenamiento y administracin de zonas no se consideran recursos adicionales. Tambin, los mtodos utilizados para sincronizar la informacin almacenada en el directorio ofrecen mejoras en el rendimiento con respecto a los mtodos de actualizacin estndares de zonas, que potencialmente pueden requerir la transferencia de la zona completa.
Mediante la integracin del almacenamiento del espacio de nombres del DNS en Active Directory, puede simplificar la planificacin y administracin tanto del DNS como de Active Directory. Cuando los espacios de nombres estn almacenados y replicados de forma separada (por ejemplo, uno para almacenamiento del DNS y replicacin y otro para Active Directory), se aade una complejidad administrativa adicional para planear y disear la red y permitir su eventual crecimiento. Mediante la integracin del almacenamiento del DNS, puede unificar la administracin del almacenamiento y replicacin de informacin tanto para el DNS como para Active Directory como una nica entidad administrativa.
La replicacin del directorio es ms rpida y eficiente que la replicacin estndar del DNS.
Dado que el proceso de replicacin de Active Directory se realiza con sentido propietario, slo se propagan los cambios relevantes. Esto permite utilizar y enviar menos datos para las actualizaciones de las zonas basadas en directorios de almacenamiento.
Nombre de la zona
Tpicamente, una zona se nombra despus del dominio ms superior en la jerarqua que abarca la zona, es decir, el dominio raz para la zona. Por ejemplo, para una zona que abarque tanto el dominio microsoft.com como sales. microsoft.com, el nombre de la zona sera microsoft.com.
Archivo de zona
Para el tipo de zona superior estndar de bsqueda directa debe especificar un archivo de zona. El archivo de zona es el nombre del archivo de la base de datos que por defecto impone el nombre de la zona con la extensin .dns. Por ejemplo, si el nombre de la zona es microsoft.com, el archivo por defecto para la base de datos de la zona es MICROSOFT.COM.DNS. Cuando se migra a una zona desde otro servidor, puede importar el archivo de zona que tenga en ese momento. Debe colocar el archivo en el directorio systemroot\System32\DNS del equipo destino antes de crear la nueva zona.
Servidores maestro del DNS

Para el tipo de zona estndar secundaria de bsqueda directa se debe especificar el(los) servidor(es) del DNS desde donde se quiere copiar la zona. Se debe introducir la direccin IP y uno o ms servidores del DNS.
Zonas de bsqueda inversa

Un zona de bsqueda inversa permite las consultas de bsqueda inversa. Las zonas de bsqueda inversa no son necesarias. Sin embargo, una zona de bsqueda inversa es necesaria para ejecutar herramientas de reparacin de problemas, como NSLOOKUP, y para registrar nombres en lugar de direcciones IP en los archivos registro de Internet Information Services (IIS). Para identificar la zona de bsqueda inversa, escriba el ID de red o el nombre de la zona. Por ejemplo, un ID de red con una direccin 169.254.16.200, resultara en un ID de red 169.254. Todas las consultas de bsqueda inversa a la red 169.254 se resolvern en esta nueva zona. Al igual que con las zonas de bsqueda directa, existen tres tipos de zonas de bsqueda inversa que puede configurar:
q q q
Integrada de Active Directory. Estndar principal. Estndar secundaria.
Archivo de zona
Para el tipo de zona estndar primaria de bsqueda directa, se debe especificar un archivo de zona. El ID de red y la mscara de subred determinarn el nombre del archivo de zona predeterminado. El DNS invierte los octetos de la direccin IP y aade el sufijo in-addr.arpa. Por ejemplo, la zona de bsqueda inversa para la red 169.254 sera 254.169.in-addr.arpa.dns.
Cuando se migra una zona desde otro servidor, se puede importar el archivo actual de zona. Se debe ubicar el archivo existente en el directorio systemroot\System32\DNS en el equipo destino antes de crear una nueva zona.
Servidores maestro de DNS

Para el tipo de zona estndar secundaria de bsqueda inversa, se especifica el (los) servidor(es) de DNS desde el que quiere copiar la zona. Debe especificar la direccin IP de uno o ms servidores de DNS.
Delegacin de Zonas
Una zona comienza como una base de datos de almacenamiento para un servidor de nombres de DNS concreto. Si se aaden otros dominios debajo del dominio utilizado para crear la zona, estos dominios pueden ser o bien parte de la misma zona o bien parte de otra zona. Una vez que un subdominio se aade, puede ser:
q q
Administrado o incluido como parte de la zona original de registros. Delegado a otra zona creada para dar soporte al subdominio.
Cuando el dominio microsoft.com se crea por primera vez como servidor nico, se configura como una zona nica para todo el espacio de nombres del DNS Microsoft. Si, sin embargo, el dominio microsoft.com necesita utilizar subdominios, esos subdominios deben ser incluidos en la zona o delegados a otra zona. La zona ejemplo.microsoft. com fue creada para admitir el dominio ejemplo.microsoft.com. Cuando se delegan zonas dentro de un espacio de nombres, debe crear tambin un registro de recursos SOA para apuntar al servidor autoritario de DNS para la nueva zona. Esto es necesario tanto para transferir la autoridad como para proporcionar la referencia correcta a otros servidores y clientes de DNS de los nuevos servidores hechos autoritarios para la nueva zona. El Asistente para nueva delegacin est disponible para ayudar en las zonas de delegacin. Para crear una delegacin de zona: 1. 2. 3. 4. En el rbol de consola de DNS, seleccione el subdominio para el que quiere crear la delegacin de zona. En el men Accin, haga clic en Nuevo. En la pgina de bienvenida del Asistente para la nueva delegacin, haga clic en Siguiente. En la pgina de nombres del Dominio delegado, especifique el nombre del dominio que quiere crear y haga clic en Siguiente. 5. En la pgina de Servidores de Nombre, especifique los servidores para albergar la zona delegada y haga clic en siguiente. 6. Repase las configuraciones en la pgina del asistente para completar la nueva delegacin y haga clic en finalizar. Todos los dominios (o subdominios) que aparecen como parte de la zona donde se aplica la delegacin se deben crear en la zona actual antes de realizar la delegacin.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-3c.htm06/01/2006 5:06:23
DNS dinmico (DDNS)

El servicio del DNS incluye la capacidad de realizar actualizacin dinmica. Esta capacidad se denomina DNS dinmico (DDNS). Con el DNS, cuando hay cambios en el dominio donde el servidor de nombres tiene autoridad, debe actualizar manualmente el archivo de la base de datos de la zona del servidor de nombres principal. Con el DDNS, los servidores de nombre y los clientes dentro de una red actualizan automticamente los archivos de la base de datos de la zona.
Actualizaciones dinmicas
La actualizacin dinmica de las zonas de DNS, descrita en la RFC 2136, es un mecanismo que permite a un cliente de DNS aadir o eliminar RR o conjuntos de RR (RRSets) a una zona. Adems, las solicitudes de actualizacin pueden establecer prerrequisitos, especificados de forma separada de las operaciones de actualizacin, que se pueden comprobar antes de que se produzca la actualizacin. Estas actualizaciones se denominan atmicas, es decir, se deben satisfacer todos los prerrequisitos para que se lleve a cabo la operacin. El cliente de TCP/IP de Windows 2000 y el servidor de DHCP envan solicitudes de actualizacin dinmica para actualizar el DNS con los registros A y PTR. El mensaje de actualizacin dinmica se enva de un cliente de DNS a un servidor de DNS para actualizar el RR (A) del host midominio.midominio.com, que ahora tiene la direccin de IP 10.10.1.52. Puede configurar una lista de servidores autorizados para iniciar actualizaciones dinmicas. Esta lista puede incluir servidores de nombres secundarios, controladores de dominio y otros servidores que realizan registro de red para clientes, tales como servidores ejecutando el Servicio de protocolo de configuracin dinmica de host (DHCP) o el Servicio de nombres de Internet de Microsoft Windows (WINS).
DDNS y DHCP
El DDNS interacta con el servicio de DHCP para mantener sincronizados los mapeos de nombres a direcciones IP para los host de red. De manera predeterminada, el servicio de DHCP permite a los clientes agregar sus propios registros de host (A) a la zona, y el servicio DHCP aade los registros de recurso PTR a la zona. El servicio de DHCP elimina tanto los registros de recursos A como PTR en la zona cuando la sesin acaba. Para enviar actualizaciones dinmicas, debe configurar el servidor de DHCP para apuntar a los servidores del DNS apropiados.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-3d.htm06/01/2006 5:06:24
Transferencia de informacin de zona

Existen tres mtodos de realizar la transferencia de zona:
q
Transferencia tradicional de zona. En este mtodo la zona secundaria solicita una copia completa de la zona primaria. Transferencia incremental de zona. Este mtodo se define en la RFC 1995 y requiere que el servidor de DNS que mantiene la copia primaria mantenga un registro de los cambios que se han ido realizando entre incrementos del nmero de secuencia de la zona. La copia secundaria puede solicitar slo los cambios que se han producido desde la ltima vez que se actualiz. Transferencia de zona del AD. Las zonas del AD se replican en todos los controladores de dominio en el dominio de Windows 2000 que usa la replicacin de AD.
Transferencia Tradicional
El mecanismo de transferencia tradicional de zona, definido en la RFC 1034, puede desperdiciar muchos recursos de red si los cambios en los RR transferidos son pequeos en relacin con el volumen de la zona. En una transferencia de zona de la zona midominio.com desde el servidor primario hasta un servidor secundario, el servidor secundario de DNS inicia una conexin de TCP con el servidor primario y enva un mensaje de transferencia de zona. El servidor de DNS primario de la zona transfiere los RR de la zona. En una transferencia de zona, el primer y ltimo registro transferido es el registro SOA. Una vez transferidos todos los registros, la conexin de TCP termina. Las transferencias incrementales de zona, descritas en la RFC 1995, pueden ser ms eficientes que las tradicionales tanto para zonas grandes como dinmicas. Sin embargo, necesitan requisitos de procesamiento adicional en el servidor de DNS, que debe realizar un seguimiento de las diferencias de zona y enviar slo los registros modificados. De forma predeterminada, las zonas estndar usarn la transferencia incremental si ello es posible. El servidor de DNS que inicia la transferencia de zona primero solicita un registro SOA y a continuacin una transferencia incremental de zona. En este ejemplo, la respuesta, contenida en el cuarto paquete, cabe completa en un nico datagrama de UDP. Si ste no hubiera sido el caso, el mensaje de respuesta habra indicado que la respuesta se trunc y el servidor solicitante hubiese creado una sesin de TCP al otro servidor de DNS para solicitar la transferencia de zona mediante TCP. La replicacin del Active Directory es una solucin propietaria, que slo se puede utilizar con los controladores de dominio de Windows 2000. Las transferencias de zona incremental y estndar confan en los servidores que mantienen las zonas secundarias para recoger (pull) los cambios de la zona primaria. La replicacin del AD, por otra parte, es de insertar (push) por naturaleza. En zonas que cambian poco, la replicacin del AD asegura que todos los servidores de DNS que mantienen la zona se actualizan rpidamente, mientras que en zonas ms dinmicas tender a suavizar el trfico de replicacin. Para mejorar la flexibilidad y rendimiento del servicio de DNS es habitual disponer de al menos una zona secundaria estndar para cada zona primaria estndar, en donde la zona secundaria se encuentra en otro servidor de DNS. Dependiendo de la naturaleza exacta de la organizacin, podra ser apropiado disponer de varias zonas secundarias estndar. Cuando se realizan cambios en la zona primaria es importante que la informacin de la zona se replique rpidamente a todas las zonas secundarias. El proceso de transferencia de la informacin de una zona primaria a una zona secundaria se llama una transferencia de zona. Las transferencias de zona suelen realizarse automticamente, a intervalos definidos en el registro SOA de la zona. Las transferencias tambin se pueden realizar manualmente usando el complemento MMC de DNS y podra realizarse cuando el administrador sospeche que la zona secundaria no se ha actualizado apropiadamente. Cuando se crea una zona secundaria estndar en un servidor de DNS en Windows 2000, el servidor de DNS transferir todos los RR de la zona primaria estndar a la nueva zona secundaria. El servidor de DNS lo hace para obtener y reproducir una copia completa de todos los RR de la zona. En muchas de las primeras aplicaciones de servidor de DNS se utilizaba tambin este mismo mtodo de transferencia de zona cuando se necesitaba actualizar la zona secundaria para sincronizarla con la zona primaria, despus de realizar cambios en la zona primaria. En zonas grandes, esto puede llevar mucho tiempo y un desperdicio de los recursos de la red. Puede ser un problema porque se necesita una transferencia de zona cada vez que se actualiza la zona primaria, como cuando se aade un nuevo host al dominio o si se cambia la direccin de IP de un host. Despus de que se hayan replicado los RR, el servidor en el que se encuentra la nueva zona secundaria estndar comprobar con el servidor de la zona primaria, a intervalos regulares, si hay algn cambio en la zona primaria. Se realiza un sondeo de la zona primaria a intervalos regulares, con el perodo de tiempo especificado por el Administrador en el registro SOA de zona en la zona primaria estndar y comprobando si el nmero de versin de la
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-02-4a.htm (1 of 2)06/01/2006 5:06:25
zona ha cambiado. Si el nmero de versin ha aumentado, se necesita una transferencia de zona. Para los servidores de DNS que se mantienen manualmente sola ser un problema -si se hacan cambios en una zona primaria, pero no se modificaba el nmero de versin y por tanto los cambios no se replicaban a la zona secundaria-. Con Windows 2000, los cambios que se hagan en la zona mediante una actualizacin manual con el complemento MMC de DNS o mediante el registro dinmico, activa una actualizacin en el nmero de versin y posibilita que la zona secundaria pueda llevar a cabo una transferencia de zona en el siguiente intervalo de sondeo.
Transferencia de zona incremental

En zonas grandes, las transferencias de zona pueden consumir una cantidad significativa del ancho de banda, especialmente cuando la transferencia se realiza por lentos enlaces WAN. Para mejorar la eficiencia de las transferencias de zona, Windows 2000 implementa un nuevo mtodo de replicacin de DNS, la transferencia incremental de zona, que implica nicamente la transferencia de los cambios en la zona, en lugar de la zona completa. De esta forma se puede reducir significativamente el trfico necesario para actualizar la zona secundaria. La transferencia incremental de zona se define en la RFC 1995. Con la transferencia incremental de zona, primero se determinan las diferencias entre las versiones original y rplica de las zonas. Si se comprueba que las zonas tienen la misma versin, como se indica en el campo nmero de serie del RR del SOA de cada zona, no se realiza la transferencia. Si el nmero de serie de la zona de origen es mayor que en el servidor secundario solicitante, se realiza una transferencia slo de aquellos cambios en los RR de cada versin incremental de zona. Para que se realice correctamente una transferencia incremental de zona y se enven slo los cambios, el servidor de DNS origen de zona debe mantener un histrico incremental de los cambios en la zona para utilizarlos al contestar a las solicitudes. Windows 2000 mantiene la informacin de transferencia incremental de zona para cada zona en el archivo del texto \Winnt\system32\dns cuyo nombre se base en el nombre del archivo que mantiene los datos de la zona, que se especific cuando se defini la zona. Por tanto, si la informacin de zona de la zona midominio.com se mantiene en el archivo midominio.com.dns, el registro de actualizacin incremental se mantiene en el archivo midominio.com.dns.log. IXFR se describe en el RFC 1995 como un estndar adicional del DNS para replicar zonas del DNS. IXFR proporciona un mtodo ms eficiente para propagar los cambios de zona y las actualizaciones. En versiones anteriores de las implementaciones del DNS, cualquier peticin para una actualizacin de datos de zona requera una transferencia completa de la base de datos de la zona utilizando una consulta de AXFR. Con la transferencia incremental, se utiliza una consulta IXFR en lugar de la anterior. IXFR permite depositar en el servidor secundario los cambios en la zona que necesita para sincronizar su copia de la zona con el origen, con independencia de que sta sea una copia primaria o secundaria de la zona mantenida por otro servidor del DNS. Con las transferencias IXFR, las diferencias entre el origen y la versin replicada de la zona se determinan primero. Si las zonas resultan tener la misma versin, tal como se indica en el campo de nmero de serie del registro de recurso SOA de cada zona, no se realiza ninguna transferencia. Si el nmero de serie para la zona origen es mayor que el del servidor secundario que realiza la peticin, se realiza una transferencia que contiene solamente los cambios realizados a los registros de recursos para cada versin incremental de la zona. Para que una consulta IXFR tenga xito y los cambios se enven, el servidor origen del DNS para la zona debe guardar la historia de los cambios incrementales en la zona para poder utilizarlos cuando se produzcan consultas. El proceso de transferencia incremental requiere mucho menos trfico de red y las transferencias de zona se completan ms rpidamente. Adems de un inicio manual, una transferencia de zona ocurre cuando se da una de las siguientes circunstancias:
q q q
Cuando se inicia un servicio del DNS en el servidor secundario de una zona. Cuando el intervalo de actualizacin termina para una zona. Cuando se hacen cambios en la zona principal y se configura una lista de notificacin.
Las transferencias de zona se inician siempre por parte del servidor secundario de zona que la enva al servidor configurado como origen para la zona. Este servidor del DNS puede ser cualquier otro servidor del DNS que cargue la zona, ya sea un servidor primario o bien un servidor secundario. Cuando el servidor origen recibe la peticin para la zona, puede responder bien con una transferencia parcial o bien con una transferencia total de la zona.
Las transferencias de zona entre servidores siguen la siguiente secuencia: 1. Durante la nueva configuracin, el servidor destino enva una peticin inicial de transferencia (AXFR) para la zona que tiene al servidor del DNS configurada como su servidor origen. 2. El servidor origen responde y transfiere completamente la zona al servidor destino. La zona se entrega al servidor que pide la transferencia con su versin mediante el uso del campo del nmero serie de las propiedades del registro de recurso SOA. El registro SOA tambin contiene un intervalo de refresco en segundos (de manera predeterminada, 15 minutos) para indicar el momento en el que el servidor destino debera pedir la renovacin de la zona con el servidor origen. 3. Cuando finaliza el intervalo de actualizacin, el servidor de destino pide la renovacin de la zona desde el servidor origen con una consulta SOA. 4. El servidor origen responde la consulta para su registro SOA. Esta respuesta contiene el nmero serie de la zona en su estado actual en el servidor origen. 5. El servidor destino mira el nmero serie del registro SOA de la respuesta y determina cmo renovar la zona. Si el valor del nmero serie de la respuesta del SOA es igual al nmero de serie local actual, se concluye que la zona es la misma en ambos servidores y que no se necesita, por tanto, una transferencia. El servidor destino renueva entonces la zona poniendo a cero su intervalo de refresco basndose en el valor del campo de la respuesta del SOA desde su servidor origen. Si el valor del nmero serie de la respuesta del SOA es mayor que el nmero de serie local actual, concluye que la zona ha sido actualizada y que, por tanto, es necesaria una transferencia de zona. 6. Si el servidor destino ve que la zona ha cambiado, enva una consulta IXFR al servidor origen que contiene el valor local actual para el nmero de serie en el registro SOA de la zona. 7. El servidor origen responde, bien con una transferencia de zona incremental o bien con una transferencia de zona total. Si el servidor origen admite transferencia incremental al mantener una historia de los cambios incrementales en la zona sobre la modificacin de los registros de recursos, puede responder con una transferencia de zona incremental (IXFR). Si el servidor origen no admite transferencia incremental o no tiene una historia de los cambios en la zona, puede, alternativamente, responder con una transferencia completa de la zona (AXFR). Para Windows 2000 Server, la transferencia de zona incremental a travs de la consulta IXFR est admitida. Para versiones anteriores de servidores del DNS con Windows NT Server 4.0 y para muchos otros servidores del DNS, la transferencia de zona incremental no est disponible y slo se permiten consultas de zona completa (AXFR) para replicar zonas.
Replicacin de zona integrada en el directorio

Las zonas estndar usan los mecanismos tradicionales de replicacin de zona para transferir la informacin de zona de las zonas integradas en el Active Directory. Sin embargo, se usa la replicacin de AD para la actualizacin de las rplicas. De esta forma se consiguen las siguientes ventajas:
q
Los servidores de DNS se convierten en multimaestros. Con las zonas estndar de DNS se necesita realizar todas las actualizaciones en un nico servidor de DNS, es decir, en el servidor que contenga la zona primaria. Con la integracin en el AD, cualquier servidor de DNS puede aceptar actualizaciones, lo que mejora el rendimiento y la escalabilidad, as como una mejor tolerancia frente a errores. La replicacin es ms eficiente y rpida. Las transferencias de replicacin del AD actualizan slo propiedades y no zonas completas, lo que significa que se transmite un menor nmero de cambios por la red. Adems, la replicacin entre sitios, normalmente por enlaces lentos, resulta ms comprimido. El administrador necesita tan slo planear a implementar una nica topologa de replicacin de AD. De esta forma tambin se replican los cambios de DNS.
Para las organizaciones que utilicen el AD, normalmente se recomiendan las zonas integradas en el Active Directory. Sin embargo, si la organizacin utiliza servidores de DNS de terceros, probablemente no admitirn zonas integradas en el AD.
Tema 3.- Instalacin, configuracin y administracin del servicio DNS

q q
Instalacin de un servidor DNS Configuracin del servicio DNS r Creacin de una nueva zona de bsqueda directa r Creacin de subdominios y delegacin de autoridad r Agregacin de registros de host r Interoperatividad con otros servidores DNS r Configuracin de un servidor DNS slo cach r Configuracin de las opciones de un cliente DNS Administracin del Servicio de DNS r La consola DNS r Programas de lnea de Comandos r Programas de Supervisin de Sucesos r Programas de supervisin de Rendimiento Administracin del Servidor de DNS r Ficha "Interfaces" r Ficha "Reenviadores" r Ficha "Avanzadas" r Ficha "Sugerencias de Raz" r Ficha "Registros" Administracin de las Zonas de Active Directory Integrada r Ficha "General" r Ficha "Inicio de Autoridad (SOA)" r Ficha "Servidores de Nombres" r Ficha "WINS" r Ficha "Transferencias de zona"
Instalacin y Configuracin del Servicio de DNS

Instalacin de un servidor DNS Configuracin del servicio DNS Creacin de una nueva zona de bsqueda directa Creacin de subdominios y delegacin de autoridad Agregacin de registros de host Interoperatividad con otros servidores DNS Configuracin de un servidor DNS slo cach Configuracin de las opciones de un cliente DNS Administracin del Servicio de DNS La consola DNS Programas de lnea de Comandos Programas de Supervisin de Sucesos Programas de supervisin de Rendimiento Administracin del Servidor de DNS Ficha "Interfaces" Ficha "Reenviadores" Ficha "Avanzadas" Ficha "Sugerencias de Raz" Ficha "Registros" Administracin de las Zonas de Active Directory Integrada Ficha "General" Ficha "Inicio de Autoridad (SOA)" Ficha "Servidores de Nombres" Ficha "WINS" Ficha "Transferencias de zona"
Instalacin de un servidor DNS

Los servidores DNS son una parte esencial de una red basada en TCP/IP adems de una parte esencial del Active Directory. Microsoft recomienda la instalacin de DNS en cada controlador de dominio cuando se utilice Active Directory. Esta solucin permite al servidor DNS dinmico de Windows 2000 utilizar Active Directory para almacenar informacin de la zona, permitiendo de este modo la rplica con mltiples maestros completa de la zona por medio de Active Directory, simplificando la tarea de conseguir la tolerancia a fallos y haciendo menos difcil la administracin del DNS. Si no se instal DNS en el controlador de dominio durante la instalacin de Windows 2000, es posible aadirlo fcilmente, aunque son necesarios ciertos pasos de configuracin. Primero se debe configurar TCP/IP y el sufijo DNS en la mquina donde se van a instalar los servicios. Hay que seguir estos pasos: 1. Ir a Inicio y escoger Configuracin, seleccionar despus Conexiones de red y de acceso telefnico. Seleccionar la conexin deseada y en el men Archivo escoger Propiedades. 2. Seleccionar la entrada Protocolo Internet (TCP/IP) y pulsar entonces Propiedades. Introducir la direccin IP, la mscara de subred y la puerta de enlace predeterminada que se est utilizando. Hay que asegurarse de que la opcin Usar las siguientes direcciones de servidor DNS est seleccionada. En el cuadro Servidor DNS preferido hay que introducir la direccin IP asignada al equipo. 3. Seleccionar Avanzada y escoger despus la pestaa DNS. Hay que suministrar las direcciones y nombres de los DNS. En esta ficha hay que configurar las siguientes propiedades:
q
Direcciones de servidores de DNS, por orden de utilizacin: Utilizar
los
botones Agregar, Modificar y Quitar bajo el cuadro de direcciones DNS para aadir o modificar los servidores que se deseen utilizar para esta conexin. Se pueden usar las flechas hacia arriba y hacia abajo cercanas al cuadro para cambiar el orden en el cual el servidor consulta los servidores DNS. Parmetros para resolucin de nombres no cualificados: Seleccionar las opciones apropiadas para nombres no cualificados.
r
Anexar sufijos DNS principales y de conexiones especficas: Limita la resolucin de nombres no cualificados a los sufijos de dominio y los sufijos de conexiones especficas. De esta forma, si el sufijo DNS principal es eng.dominio.com y se escribe ping srv4 en el smbolo del sistema, DNS buscar srv4.eng.dominio.com. Si se especifica tambin un nombre especfico de la conexin (bajo Sufijo DNS para esta conexin), como dev.dominio.com, DNS consultar srv4.eng.dominio.com y srv4.dev.dominio.com. i. Anexar sufijos primarios del sufijo DNS principal: Incluye sufijos primarios hasta el dominio de segundo nivel en la resolucin de nombres no cualificados. De esta forma, si el sufijo DNS principal es eng.uk.corp.dominio.com y se
escribe ping srv4 en el smbolo del sistema, DNS consultar lo siguiente: - srv4.eng.uk.corp.dominio.com - srv4.uk.corp.dominio.com - srv4.corp.dominio.com - srv4.dominio.com Anexar estos sufijos DNS (en este orden): Especifica los nicos sufijos de dominio a anexar a los nombres de dominio no cualificados durante el proceso de resolucin de nombres. Si se especifican sufijos de dominio aqu, los sufijos principal y de conexiones especficas no se utilizan. Sufijo DNS para esta conexin: Para ignorar el nombre DNS primario del dominio especificado para el equipo en la ficha Identificacin de red de la herramienta Propiedades del sistema del Panel de control, hay que escribir el nombre DNS del dominio que se desea utilizar en el cuadro de texto Sufijo DNS para esta conexin. Registrar estas direcciones de conexiones en DNS: Si la seleccionamos se impide que se registre el nombre DNS completo de la direccin IP del servidor en el servidor DNS. Utilizar este sufijo DNS de conexin para registro DNS: Debemos seleccionar esta casilla para utilizar la actualizacin dinmica de DNS para registrar las direcciones IP y el nombre de dominio especfico de la conexin. El nombre de dominio de la conexin se introduce en el cuadro de texto Sufijo DNS para esta conexin o se asigna por el servidor DHCP
r
Deberemos cambiar tambin las propiedades de la ficha Identificacin de Red del equipo de la siguiente manera: 1. Pulsar con el botn derecho del ratn en el icono Mi PC y escoger Propiedades en el men contextual. 2. En la ficha Identificacin de red seleccionar Propiedades. En el cuadro Cambios de identificacin seleccionar Ms. 3. En el cuadro de dilogo Sufijo DNS y nombre NetBIOS del equipo hay que introducir el sufijo DNS y pulsar Aceptar. Ser necesario reiniciar para que los cambios tengan efecto. Una vez configurado correctamente el servidor, se puede instalar el servidor DNS siguiendo estos pasos: 1. Abrir la herramienta Configurar el servidor desde el men Herramientas administrativas. 2. Seleccionar el ttulo Red en la columna de la izquierda y escoger entonces el subttulo DNS. 3. Para instalar el servicio DNS, hay que pulsar el hipervnculo Instalar DNS.
Ir a la pgina Principal ltima actualizacin del tema completo: 25/10/2005 v.1.0.0
Instalacin de un servidor DNS

Los servidores DNS son una parte esencial de una red basada en TCP/IP adems de una parte esencial del Active Directory. Microsoft recomienda la instalacin de DNS en cada controlador de dominio cuando se utilice Active Directory. Esta solucin permite al servidor DNS dinmico de Windows 2000 utilizar Active Directory para almacenar informacin de la zona, permitiendo de este modo la rplica con mltiples maestros completa de la zona por medio de Active Directory, simplificando la tarea de conseguir la tolerancia a fallos y haciendo menos difcil la administracin del DNS. Si no se instal DNS en el controlador de dominio durante la instalacin de Windows 2000, es posible aadirlo fcilmente, aunque son necesarios ciertos pasos de configuracin. Primero se debe configurar TCP/IP y el sufijo DNS en la mquina donde se van a instalar los servicios. Hay que seguir estos pasos: 1. Ir a Inicio y escoger Configuracin, seleccionar despus Conexiones de red y de acceso telefnico. Seleccionar la conexin deseada y en el men Archivo escoger Propiedades. 2. Seleccionar la entrada Protocolo Internet (TCP/IP) y pulsar entonces Propiedades. Introducir la direccin IP, la mscara de subred y la puerta de enlace predeterminada que se est utilizando. Hay que asegurarse de que la opcin Usar las siguientes direcciones de servidor DNS est seleccionada. En el cuadro Servidor DNS preferido hay que introducir la direccin IP asignada al equipo. 3. Seleccionar Avanzada y escoger despus la pestaa DNS. Hay que suministrar las direcciones y nombres de los DNS. En esta ficha hay que configurar las siguientes propiedades:
q
Direcciones de servidores de DNS, por orden de utilizacin: Utilizar los botones Agregar, Modificar
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-1.htm (1 of 3)06/01/2006 5:06:27
y Quitar bajo el cuadro de direcciones DNS para aadir o modificar los servidores que se deseen utilizar para esta conexin. Se pueden usar las flechas hacia arriba y hacia abajo cercanas al cuadro para cambiar el orden en el cual el servidor consulta los servidores DNS. Parmetros para resolucin de nombres no cualificados: Seleccionar las opciones apropiadas para nombres no cualificados.
r
Anexar sufijos DNS principales y de conexiones especficas: Limita la resolucin de nombres no cualificados a los sufijos de dominio y los sufijos de conexiones especficas. De esta forma, si el sufijo DNS principal es eng.dominio.com y se escribe ping srv4 en el smbolo del sistema, DNS buscar srv4.eng.dominio. com. Si se especifica tambin un nombre especfico de la conexin (bajo Sufijo DNS para esta conexin), como dev. dominio.com, DNS consultar srv4.eng.dominio. com y srv4.dev.dominio. com. i. Anexar sufijos primarios del sufijo DNS principal: Incluye sufijos primarios hasta el dominio de segundo nivel en la resolucin de nombres no cualificados. De esta forma, si el sufijo DNS principal es eng.uk.corp.dominio.com y se escribe ping srv4 en el smbolo del sistema, DNS consultar lo siguiente: - srv4.eng.uk.corp.dominio.com - srv4.uk.corp.dominio.com - srv4.corp.dominio.com - srv4.dominio.com
Anexar estos sufijos DNS (en este orden): Especifica los nicos sufijos de dominio a anexar a los nombres de dominio no cualificados durante el proceso de resolucin de nombres. Si se especifican sufijos de dominio aqu, los sufijos principal y de conexiones especficas no se utilizan. Sufijo DNS para esta conexin: Para ignorar el nombre DNS primario del dominio especificado para el equipo en la ficha Identificacin de red de la herramienta Propiedades del sistema del Panel de control, hay que escribir el nombre DNS del dominio que se desea utilizar en el cuadro de texto Sufijo DNS para esta conexin. Registrar estas direcciones de conexiones en DNS: Si la seleccionamos se impide que se registre el nombre DNS completo de la direccin IP del servidor en el servidor DNS. Utilizar este sufijo DNS de conexin para registro DNS: Debemos seleccionar esta casilla para utilizar la actualizacin dinmica de DNS para registrar las direcciones IP y el nombre de dominio especfico de la conexin. El nombre de dominio de la conexin se introduce en el cuadro de texto Sufijo DNS para esta
r
conexin o se asigna por el servidor DHCP Deberemos cambiar tambin las propiedades de la ficha Identificacin de Red del equipo de la siguiente manera: 1. Pulsar con el botn derecho del ratn en el icono Mi PC y escoger Propiedades en el men contextual. 2. En la ficha Identificacin de red seleccionar Propiedades. En el cuadro Cambios de identificacin seleccionar Ms. 3. En el cuadro de dilogo Sufijo DNS y nombre NetBIOS del equipo hay que introducir el sufijo DNS y pulsar Aceptar. Ser necesario reiniciar para que los cambios tengan efecto. Una vez configurado correctamente el servidor, se puede instalar el servidor DNS siguiendo estos pasos: 1. Abrir la herramienta Configurar el servidor desde el men Herramientas administrativas. 2. Seleccionar el ttulo Red en la columna de la izquierda y escoger entonces el subttulo DNS. 3. Para instalar el servicio DNS, hay que pulsar el hipervnculo Instalar DNS.
Configuracin del servicio DNS

Las zonas son los cerebros del DNS; por lo tanto, el servidor DNS es intil hasta que se configuren las zonas del dominio. Las zonas permiten almacenar porciones del espacio de nombres del DNS de forma que un nico servidor DNS pueda servir una porcin del espacio de nombres. Cuando se configuran los dominios, hay que comenzar por el dominio de nivel ms alto. Despus hay que crear los subdominios y delegar el control de los dominios a otros servidores DNS si fuese necesario. Los dos tipos de zonas que es necesario tomar en consideracin son las zonas de bsqueda directa y las zonas de bsqueda inversa. Las zonas de bsqueda directa son los tipos de zonas que se asocian normalmente con servidores DNS; ellas devuelven una direccin IP cuando se les proporciona un nombre DNS. Las bsquedas inversas se utilizan menos a menudo, aun siendo importantes de todos modos. Proporcionan la capacidad de asignar un nombre DNS a una direccin IP, algo que los Servicios de Internet Information Server (IIS) tambin utilizan para sus archivos de registro y herramientas de solucin de problemas como Nslookup.
Creacin de una nueva zona de bsqueda directa

Para crear una nueva zona de bsqueda directa en el servidor DNS para que los clientes puedan obtener la direccin IP de un nombre DNS, hay que seleccionar DNS en la carpeta Herramientas administrativas, Seleccionar el servidor DNS en el rbol de la consola. Escoger entonces Crear una zona nueva en el men Accin para iniciar el Asistente para crear zona nueva. Hay que pulsar Siguiente para comenzar a utilizar el asistente. Tipo de Zona: En esta ventana hay que escoger una de las siguientes opciones y pulsar entonces Siguiente para continuar:
q
Active Directory integrado: Se debe utilizar si todos los controladores de dominio ejecutan Windows 2000. Esta opcin tambin se puede utilizar en una red mixta si los servidores UNIX son compatibles con el DNS de Microsoft. Principal estndar: Se debe utilizar si el servidor DNS ejecuta Windows 2000 pero no es un controlador de dominio. Secundaria estndar: Se debe utilizar si el servidor DNS est alojado en servidores UNIX. Tambin se debe utilizar si este servidor va a tener privilegios de slo lectura en la zona para toda la informacin obtenida del servidor DNS principal.
Zona de bsqueda directa o inversa. Esta ventana nos permite escoger el tipo de zona que queremos crear.
q
Zona de bsqueda directa: Es la que permite a los clientes buscar los equipos de la red a travs de los
nombres, convirtiendo los nombres DNS a direcciones IP. Zona de bsqueda inversa: Las zonas de bsqueda inversa permiten a los clientes obtener el nombre DNS de un host a partir de una direccin IP, lo que resulta til para herramientas de solucin de problemas como Nslookup. Y realizar una bsqueda inversa junto con los archivos de registro de IIS permite el registro de un nombre DNS en lugar de una direccin IP.
Nombre de Zona: Introducir el nombre DNS para la zona en el cuadro de texto Nombre y pulsar Siguiente. Si se ha escogido la instalacin de una Zona Active Directory Integrada, se crear ahora. Si se est creando una Zona principal estndar, seguir el proceso de instalacin. Para una Zona secundaria estndar se abre la ventana Servidores maestros DNS. Hay que introducir las direcciones IP de los servidores maestros de los cuales se desea copiar la informacin de zona, pulsando Agregar despus de introducir cada una. Se puede utilizar el botn Examinar para buscar servidores. Se pueden utilizar los botones Arriba y Abajo para organizar las direcciones IP en el orden en el que se deseen contactar. Hay que pulsar Siguiente cuando se haya terminado y pulsar despus Finalizar para completar la configuracin de la zona secundaria.
Archivo de Zona: Nos permitir elegir el archivo que queremos utilizar para la Zona DNS que estamos creando.
q
Cree un archivo nuevo con este nombre de archivo: introducir el nombre que se le quiere dar al archivo de zona o utilizar el que se proporciona. Usar este archivo: Para utilizar una archivo de zona existente para almacenar la informacin de la zona, hay que copiar el archivo a la carpeta %SystemRoot% \System32\DNS. Esta es la opcin a elegir si estamos importando una Zona DNS desde otro sistema.
Creacin de subdominios y delegacin de autoridad

En muchos entornos de red grandes es necesario crear subdominios y delegar su administracin a otras zonas DNS que estn alojadas en otros servidores DNS. Este paso elimina la situacin de tener un enorme espacio de nombres alojado en una nica zona de un nico servidor. Por lo tanto, se debera tener una zona que contuviera el dominio raz dominio.com adems del subdominio marketing.dominio.com; sin embargo, se debera tener el subdominio subdominio.dominio.com y sus subdominios delegados a una zona separada administrada por otro servidor DNS. Hay que asegurarse de que se tiene un registro de host creado para el servidor DNS en la Zona de bsqueda directa y un registro del puntero para el servidor DNS en la Zona de bsqueda inversa. Puede que el DNS no los cree automticamente (especialmente el registro del puntero), por lo que conviene verificar ambos; en otro caso el servidor podra no funcionar. Conviene observar que las zonas deben tener un espacio de nombres contiguo, por lo que no es posible combinar subdominios de diferentes ramas del espacio de nombres y situarlos en una nica zona: sera necesario crear zonas separadas para cada parte no contigua del dominio. Para crear un nuevo subdominio en una zona existente y delegar despus la autoridad sobre el dominio a otro servidor DNS, hay que realizar los siguientes pasos: 1. Seleccionar el dominio en el cual se desea crear un nuevo subdominio y escoger despus Dominio nuevo en el men Accin. 2. Introducir el nombre del subdominio en el cuadro de dilogo que aparece y pulsar despus Aceptar. Este nombre no debera ser completo. Por ejemplo, si se estuviera creando el subdominio subdominio. dominio.com bajo el dominio dominio.com, slo se debera escribir sobdominio en este cuadro de dilogo.
3.
4. 5. 6.
7.
8.
9.
Los subdominios no tienen que ser delegados a un servidor DNS diferente. Los subdominios se pueden crear incluso en nuevos archivos de zona y an as ser administrados por el mismo servidor. Esta capacidad es til si se desean alojar las zonas en el mismo equipo, pero administrarlas de forma diferente. Para delegar la autoridad sobre el subdominio, hay que seleccionar el dominio principal del subdominio y escoger despus Delegacin nueva en el men Accin para iniciar el Asistente para delegacin nueva. Pulsar Siguiente e introducir entonces el nombre del subdominio para el que se desea delegar. Pulsar Siguiente. Pulsar Agregar para abrir el cuadro de dilogo Nuevo registro de recursos. Introducir el nombre del servidor al que se desea delegar la autoridad o pulsar Examinar para localizar su registro de recursos en los archivos de zona del servidor DNS. Introducir la direccin o direcciones IP del servidor, pulsando Agregar tras introducir cada una. Pulsar Aceptar cuando se haya terminado. Aadir cualquier servidor DNS adicional que vaya a alojar al subdominio delegado. Hay que pulsar Siguiente para continuar. Revisar la ventana resumen y pulsar Finalizar para completar el proceso de delegacin.
Agregacin de registros de recursos del host

Despus de crear las zonas y los subdominios se deberan aadir registros de recursos (RR) para el servidor del dominio y cualquier otro servidor con direcciones IP estticas o reservas de IP (servidores DHCP, servidores WINS, enrutadores, etc.). El servidor DNS no funcionar adecuadamente sin un registro de host y un registro del puntero, los cuales no se crearn de forma automtica. 1. Seleccionar la zona y dominio o subdominio al cual pertenece el host y escoger entonces Host nuevo en el men Accin. 2. Introducir el nombre del host o dejar el cuadro Nombre en blanco para utilizar el nombre del dominio principal. Hay que introducir la direccin IP del host. 3. Seleccionar Crear registro del puntero (PTR) asociado para crear un RR para el host en la zona de bsqueda inversa. 4. Pulsar Agregar host y rellenar despus los campos para cualquier registro de host adicional que se quiera crear o pulsar Realizado. Para actualizar manualmente el archivo de zona, hay que seleccionar la zona que se desea actualizar y escoger entonces Actualizar archivo de datos del servidor en el men accin.
Interoperacin con otros servidores DNS

De forma predeterminada, el servidor DNS de Windows 2000 realiza transferencias de zona rpidas con compresin de datos y envo de mltiples registros de recursos en cada mensaje. Este mtodo de transferencia de zona funciona con todos los servidores DNS de Windows y servidores DNS BIND versin 4.9.4 o posterior. Si se necesita realizar transferencias de zona con servidores BIND anteriores a la versin 4.9.4, ser necesario desactivar este mtodo de transferencia de zona rpida. Hay que seleccionar el servidor DNS en el rbol de la consola y escoger propiedades en el men Accin. Despus hay que pulsar la pestaa Avanzado y desactivar la casilla de verificacin Enlazar secundarios.
Configuracin de un servidor DNS slo cach

Los servidores slo cach son servidores DNS que no alojan ninguna zona y que no son autoritativos de ningn dominio, simplemente guardan en cach las consultas que realizan en nombre de los clientes que utilizan el servidor. Los servidores slo cach son tiles en sitios que utilizan un enlace WAN lento a otros servidores DNS. Simplemente guardando en cach las consultas en lugar de contener sus propios archivos de zona, un servidor slo cach reduce el trfico de red porque nunca realiza transferencias de zona. Para configurar un servidor slo cach, hay que seguir estos pasos: 1. Ejecutar DNS desde la carpeta Herramientas administrativas y escoger Conectar con el equipo en el men Accin. 2. En el cuadro de dilogo Seleccionar el equipo de destino, hay que seleccionar El siguiente equipo, introducir el nombre del servidor DNS del que se desean guardar las respuestas y pulsar Aceptar. El servidor DNS se aadir a la consola DNS del servidor cach. El servidor cach realizar consultas recursivas en nombre de sus clientes y con el tiempo acumular registros de recursos para responder consultas futuras. Se puede vaciar la cach de un servidor cach pulsando con el botn derecho en el nombre del servidor en la consola DNS y seleccionando Limpiar cach.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-2e.htm06/01/2006 5:06:30
Configuracin de las funciones del cliente de DNS

En Windows 2000, normalmente hay poco que configurar en un cliente con respecto a DNS. Generalmente, slo es necesario configurar el host con la direccin de IP de un servidor de DNS primario (y uno secundario). Se puede simplificar la tarea usando DHCP para asignar la direccin de IP del servidor o servidores de DNS. Habitualmente, el comportamiento predeterminado del cliente de DNS es el adecuado. Sin embargo, en ciertos casos, son apropiados algunos cambios al mismo. Las entradas del registro que se pueden utilizar para modificar el funcionamiento de un cliente de DNS en Windows 2000, son:
Especificacin de un TTL predeterminado

De forma predeterminada, el TTL de las actualizaciones de los RR (A) y PTR que envan un cliente de DNS son cada 20 minutos. Para modificarlo, puede configurar la siguiente entrada del registro: DefauItRegistrationTTL Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters Tipo de valor: REG_DWORD-segundos Predeterminado: 0x4B0 (1200 segundos en decimal, 0 20 minutos) Rango vlido: 0-0xffffffff Presente predeterminado: No
Desactivacin de la actualizacin dinmica

Aunque la actualizacin automtica de las zonas puede resultar muy til, en algunos entornos puede no serlo deseable. La siguiente entrada del registro permite desactivar la actualizacin dinmica de DNS en todo un equipo con Windows 2000 o slo en una interfaz del equipo. DisabIeDynamicUpdate Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services Tcpip \Parameters 0 HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services Tcpip \Parameters \Interfaces \<interfaz> Tipo de valor: REG DWORD-Boolean Rango vlido: 0, 1 (Falso, Cierto) Predeterminado: 0 (Falso; activado el DNS dinmico) Presente predeterminado: No.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-2f.htm06/01/2006 5:06:30
Administracin del Servidor DNS

El complemento DNS ofrece una interfaz grfica de usuario mejorada para administrar el servicio DNS. Adems, Windows 2000 Server proporciona varios asistentes para la configuracin nuevos que permiten realizar tareas administrativas comunes del servidor. Adems del complemento DNS, se proporcionan otras herramientas que le ayudarn a administrar y lograr la compatibilidad con los clientes y servidores DNS de la red. Windows 2000 proporciona una serie de programas para administrar, supervisar y solucionar los problemas de los clientes y los servidores DNS. Entre estos programas se cuentan:
q q
La consola DNS, que forma parte de las Herramientas administrativas. Programas de lnea de comandos, como Nslookup, que se pueden utilizar para solucionar problemas de DNS. Caractersticas de registro, como el registro del servidor DNS, que se pueden ver mediante el Visor de sucesos. Los registros basados en archivos se pueden usar tambin temporalmente como una opcin de depuracin avanzada para registrar y hacer un seguimiento de los sucesos del servicio seleccionados. Programas de supervisin del rendimiento, como los contadores de estadsticas para medir y supervisar la actividad del servidor DNS con el Supervisor del sistema.
La consola DNS
La herramienta principal de administracin de los servidores DNS de Windows 2000 es la consola DNS, que encontrar en la carpeta de Herramientas administrativas, en el Panel de control. La consola DNS aparece como un complemento Microsoft Management Console (MMC), para lograr una mayor integracin de la administracin de DNS en la administracin global de la red. Despus de instalar un servidor DNS, puede utilizar la consola DNS para realizar las siguientes tareas administrativas bsicas del servidor: 1. Realizar la configuracin inicial de un servidor DNS nuevo. 2. Conectar y administrar un servidor DNS local en el mismo equipo o servidores DNS remotos en otros equipos. 3. Agregar y quitar las zonas de bsqueda hacia adelante y hacia atrs cuando sea necesario. 4. Agregar, quitar y actualizar los registros de recursos en las zonas. 5. Modificar la forma de almacenar y duplicar las zonas entre servidores. 6. Modificar en los servidores la forma de procesamiento de las consultas y la forma de controlar las actualizaciones dinmicas. 7. Modificar la seguridad de zonas o registros de recursos especficos. Adems, tambin puede utilizar la consola DNS para realizar las tareas siguientes.
q
q q q
Realizar el mantenimiento en el servidor. Puede iniciar, detener, pausar o reanudar el servidor, o actualizar manualmente los archivos de datos del servidor. Supervisar el contenido de la memoria cach del servidor y, si es necesario, borrarlo. Ajustar las opciones avanzadas del servidor. Configurar, caducar y compactar los registros de recursos antiguos almacenados por el servidor.
Adems, tambin puede utilizar la consola DNS desde un equipo que no sea un servidor para administrar de forma remota los servidores DNS de Windows 2000 (siempre que antes haya instalado en ellos el servicio del Servidor DNS).
Programas de lnea de comandos

Windows 2000 proporciona varios programas de lnea de comandos. Puede utilizarlos para administrar y solucionar los problemas de clientes y servidores DNS. Puede ejecutar los siguientes programas escribiendo el nombre de archivo en el smbolo del sistema o mediante un archivo de proceso por lotes.
q q
Nslookup: Se utiliza para realizar pruebas de consultas del espacio de nombres del dominio DNS. Dnscmd: Una interfaz de lnea de comandos para administrar servidores DNS. Este programa es til para secuencias de comandos de proceso por lotes. Ayuda a automatizar las tareas administrativas de DNS rutinarias o a realizar la configuracin e instalacin desatendida simple de servidores DNS nuevos en la red. Ipconfig: Este comando se utiliza para ver y modificar los detalles de la configuracin IP utilizada por el equipo. En Windows 2000, se incluyen con este programa opciones adicionales de lnea de comandos que proporcionan ayuda para solucionar problemas y lograr la compatibilidad de clientes DNS.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-3b.htm06/01/2006 5:06:32
Programas de supervisin de sucesos

Windows 2000 Server incluye dos opciones para supervisar servidores DNS:
q
Registro predeterminado de mensajes de sucesos del servidor DNS en el registro del mismo. En Windows 2000 Server, los mensajes de sucesos del servidor se separan y mantienen en su propio registro de sucesos del sistema, el registro del servidor DNS, que se puede ver mediante el Visor de sucesos. El registro del servidor DNS contiene sucesos bsicos registrados por el servicio del Servidor DNS. Por ejemplo, cuando se inicia o detiene el servidor DNS, se escribe en este registro el correspondiente mensaje de suceso. Tambin se registran aqu algunos sucesos crticos adicionales del servicio DNS. Por ejemplo, el servidor se inicia pero no encuentra los datos de inicializacin, como zonas o informacin de inicio almacenada en el Registro de Windows 2000 o, en algunos casos, en Active Directory. Los tipos de suceso registrados por los servidores DNS de Windows 2000 estn predeterminados. Tambin puede utilizar el Visor de sucesos para ver y supervisar los sucesos DNS relacionados con el cliente. stos aparecen en el registro del Sistema y los escribe el servicio Cliente DNS en cualquier equipo que ejecute Windows 2000 (cualquier versin). Opciones de depuracin opcionales para registrar en el equipo servidor DNS el seguimiento en un archivo de texto. Tambin puede utilizar la consola DNS para habilitar de forma selectiva opciones de depuracin adicionales para registrar temporalmente en un archivo de texto el seguimiento de la actividad del servidor DNS. El archivo que se crea y utiliza para esta caracterstica, Dns.log, se almacena en la carpeta systemroot\System32\Dns.
Programas de supervisin del rendimiento

Puede supervisar el rendimiento de los servidores DNS de Windows 2000 mediante contadores adicionales especficos del servicio, que midan el rendimiento del servidor DNS. Tendr acceso a estos contadores a travs del Supervisor del sistema proporcionado en la consola Rendimiento. Cuando utiliza el Supervisor del sistema, puede crear grficos de las tendencias de rendimiento del servidor a lo largo del tiempo para cualquiera de los servidores DNS de Windows 2000. Los podr estudiar y analizar de forma ms detallada para determinar si es necesario un ajuste adicional del servidor. Midiendo y revisando los datos del servidor durante un perodo de tiempo podr determinar puntos de referencia del rendimiento y decidir si debe realizar ms ajustes para optimizar el sistema.
Administrar un Servidor DNS

Hay varias situaciones en las que podra agregar y configurar un servidor DNS nuevo para la red:
q q
Cuando agregue un servidor DNS nuevo a la red y configure una zona nueva para utilizarla por primera vez. Cuando haya creado una zona en otro servidor DNS y agregue un servidor nuevo que tambin necesite cargar y proporcionar servicio en la zona. Cuando tenga un servidor DNS configurado con una o ms zonas pero necesite agregar una zona nueva para otro nombre de dominio, como un subdominio.
Ficha Interfaces
En el caso de los servidores DNS multitarjeta, puede configurar el servicio DNS para habilitar de forma selectiva y enlazar slo con las direcciones IP que especifique con la consola DNS. De forma predeterminada, el servicio DNS enlaza con todas las interfaces IP configuradas para el equipo. Esto puede incluir:
q
Cualquier direccin IP adicional configurada para una conexin de red nica. Direcciones IP individuales configuradas para cada conexin diferente donde haya instaladas ms de una conexin de red en el equipo servidor.
En el caso de los servidores DNS multitarjeta, puede restringir el servicio DNS para las direcciones IP seleccionadas. Cuando se utilice esta caracterstica, el servicio DNS slo atender y responder a las peticiones DNS que se enven a las direcciones IP especificadas en la ficha Interfaz de las Propiedades del servidor. De forma predeterminada, el servicio DNS atiende en todas las direcciones IP y acepta todas las solicitudes de clientes enviadas a su puerto de servicio predeterminado (UDP 53 o TCP 53 para solicitudes de transferencia de zona). Algunos interpretadores de nombres DNS (incluidos los clientes de la versin original de Windows 95) requieren que la direccin de origen de una respuesta DNS sea la misma que la direccin de destino que se utiliz en la consulta. Si estas direcciones son diferentes, los clientes pueden rechazar la respuesta. Para adaptar estos interpretadores de nombres, puede especificar la lista de interfaces permitidas para el servidor DNS. Cuando se establezca una lista, el servicio DNS enlazar sockets slo a las direcciones IP permitidas utilizadas en el equipo. Adems de para admitir clientes que requieren el uso de enlaces explcitos, especificar las interfaces puede ser til por otras razones:
q
Si, por razones administrativas, no desea utilizar algunas direcciones IP o interfaces en un equipo servidor multitarjeta. Si el equipo servidor est configurado para utilizar un gran nmero de direcciones IP y no desea el gasto agregado que supone enlazarlas todas.
Cuando configure direcciones IP adicionales y las habilite para su uso con el servidor DNS de Windows 2000, considere lo siguiente:
q q
Se consumen recursos adicionales del sistema en el equipo servidor. El rendimiento del servidor DNS disminuye ligeramente, lo que puede afectar a la recepcin de consultas DNS para el servidor.

q
Aunque Windows 2000 proporciona los medios para configurar varias direcciones IP y utilizarlas con cualquiera de los adaptadores de red instalados, no se produce con ello ningn beneficio en el rendimiento. Incluso si el servidor DNS controla varias zonas registradas para uso de Internet, para el proceso de registro de Internet no es necesario tener registradas direcciones IP diferentes para cada zona.
Ficha Reenviadores
Ningn servidor de nombres ser capaz de responder a las consultas de todos los clientes; algunas veces los clientes solicitarn un nombre DNS que no se encuentra en ninguna de las zonas administradas por el servidor DNS. En estos casos, se puede configurar un servidor DNS para que reenve la peticin a otro servidor DNS con ms probabilidad de tener el registro en su zona o archivo cach. Esta capacidad se necesita ms frecuentemente para resolver nombres externos a la red en la que residen los clientes. Cuando un cliente quiere resolver un nombre fuera de la red interna, se puede configurar un servidor DNS interno para que reenve la consulta a un servidor DNS externo a la red, quizs al otro lado de un cortafuego. Este servidor de nombres externo puede entonces realizar consultas ms a fondo fuera de la red si es necesario y devolver los resultados al servidor DNS reenviador. Por razones de seguridad, un nico servidor DNS reenviar por regla general las peticiones de la red interna a un servidor DNS al otro lado de un cortafuegos. El resto de los servidores DNS internos reenvan sus consultas al reenviador designado para que sean pasadas al servidor de nombres externo (o resueltas a partir del archivo cach del reenviador). 1. Habilitar reenviador(es). 2. Direcciones IP del servidor o servidores DNS a los cuales se desea reenviar las consultas no resueltas, pulsando el botn Agregar tras introducir cada una. 3. Antes de avanzar al siguiente servidor de la lista de servidores a los que reenviar consultas, hay que introducir la cantidad de tiempo que se desea emplear en contactar con un servidor DNS. 4. Para configurar el servidor DNS como un servidor esclavo -un servidor que no trata de resolver ninguna consulta a partir de sus propios archivos de zona o cachhay que seleccionar la casilla de verificacin No usar recursin.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-4b.htm06/01/2006 5:06:34
Ficha Avanzadas
Cuando se inicia el servicio, los servidores DNS de Windows 2000 utilizan los valores de configuracin del servidor obtenidos de los parmetros establecidos en el archivo de informacin de inicio, en el Registro de Windows 2000 o en los valores predeterminados que proporciona la integracin de Active Directory. En la mayora de las situaciones, los valores predeterminados de la instalacin son aceptables y no deberan necesitar modificaciones. Sin embargo, cuando sea necesario puede utilizar la consola DNS para ajustar los siguientes parmetros avanzados, que permiten adaptarse a las situaciones y necesidades especiales de distribucin.
q
Deshabilitar la recursin: Determina si el servidor DNS utiliza o no la recursin. De forma predeterminada, los servidores DNS de Windows 2000 pueden utilizar la recursin. De forma predeterminada, se habilita la recursividad para el servicio DNS y, normalmente, los clientes solicitan que el servidor use la recursividad para resolver un nombre al enviar una consulta. Si se deshabilita la recursividad, el servicio DNS utiliza siempre la referencia, independientemente de la solicitud del cliente. En general, los servidores DNS pueden responder consultas de nombres fuera de las zonas autorizadas de dos maneras:
r
Los servidores pueden enviar respuestas de referencia, que son una respuesta inmediata al cliente solicitante con una lista de registros de recursos de otros servidores DNS conocidos que parecen estar ms cerca o que es ms probable que sean de ayuda en la resolucin del nombre consultado. Los servidores pueden utilizar la recursividad para consultar otros servidores en nombre del cliente solicitante e intentar resolver completamente el nombre. Las bsquedas recursivas continan hasta que el servidor recibe una respuesta autorizada del nombre consultado. El servidor reenva esta respuesta como contestacin a la consulta original del cliente solicitante.
En la mayor parte de los casos, la recursividad en un servidor DNS se deshabilita cuando los clientes DNS se van a limitar a resolver nombres administrados de forma autorizada en un servidor especfico. Por ejemplo, ste es el caso cuando un servidor DNS slo tiene datos de nombres DNS para una red interna o cuando el servidor DNS no es capaz de resolver nombres DNS externos, como los nombres DNS de Internet, y se espera que los clientes vuelvan a probar con otro servidor DNS para resolver estos nombres. Enlazar Secundarios: Determina si se utiliza el formato de transferencia rpida al transferir una zona a servidores DNS que ejecuten implementaciones de Berkeley Internet Name Domain (BIND) heredadas. De forma predeterminada, todos los servidores DNS basados en Windows utilizan un formato de transferencia de zona rpida, que utiliza la compresin y que puede incluir varios registros por mensaje TCP durante una
transferencia conectada. Este formato tambin es compatible con los servidores DNS basados en BIND ms recientes que ejecuten la versin 4.9.4 o una versin posterior. Error en carga si hay datos de zona defectuosos: Establece que el servidor DNS debe analizar estrictamente los archivos. De forma predeterminada, los servidores DNS de Windows 2000 registran los errores de los datos, pasan por alto los datos errneos de los archivos de zona y siguen cargando la zona. Se puede modificar esta opcin de forma que el servicio del servidor DNS registre los errores y no pueda cargar un archivo de zona que contenga datos de registros que contengan errores. Habilitar operacin por rondas: Determina si el servidor DNS utiliza la peticin en rueda para rotar y reordenar una lista de varios registros de recursos de direcciones de host (A) si el nombre de host consultado es de un equipo configurado con varias direcciones IP. De forma predeterminada, los servidores DNS de Windows 2000 utilizan la peticin por rondas. Habilitar orden de las mscaras de red: Determina si el servidor DNS reordena una lista de varios registros de recursos (A) basndose en la prioridad de subred local si el nombre de host consultado es de un equipo multitarjeta. De forma predeterminada, los servidores DNS de Windows 2000 utilizarn la prioridad de subred local. Asegurar Cach contra corrupcin: Determina si el servidor intenta limpiar las respuestas para evitar la contaminacin de la memoria cach. De forma predeterminada, los servidores DNS de Windows 2000 utilizan una opcin de respuesta segura que no permite agregar registros de recursos no relacionados incluidos en una respuesta de referencia a su cach. En la mayora de los casos, los nombres agregados en las respuestas de referencia se almacenan en la memoria cach y ayudan a acelerar la resolucin de consultas DNS posteriores. No obstante, con esta caracterstica el servidor podra determinar que los nombres de referencia son potencialmente contaminantes o inseguros y, por tanto, rechazarlos. El servidor determina si se almacena en la memoria cach el nombre ofrecido en una referencia basndose en si forma parte o no del rbol de nombres de dominio DNS relacionado exacto para el que se cre el nombre original consultado. Por ejemplo, si se realiza originalmente una consulta para "ejemplo.microsoft.com" y la respuesta de referencia proporciona un registro de un nombre fuera del rbol de nombres de dominio "microsoft.com", como msn.com , ese nombre no se almacenar en la memoria cach en la que se puede utilizar esta caracterstica. Comprobar los datos de zona y los nombres: Puede utilizar los siguientes mtodos de comprobacin de nombres con el servicio DNS y administrarlos con el complemento DNS.
r
RFC estricto (ANSI): Utiliza la comprobacin estricta de nombres segn las especificaciones de nombres de host de Internet RFC 1123. No RFC (ANSI): Permite nombres que no son estndar y que no siguen las especificaciones de nombres de host de Internet RFC 1123. Multibyte (UTF8): Permite el reconocimiento de caracteres que no son ASCII, incluyendo los de Unicode, que normalmente se codifican con ms de un octeto (8 bits) de longitud.
Con esta opcin, los caracteres multibyte se pueden transformar y representar mediante la compatibilidad con Unicode Transformation Format (UTF-8) (Formato 8 de transformacin de Unicode) proporcionada por Windows 2000 Server.
q
Habilitar compactacin automtica de los registros obsoletos: Los servidores DNS de Windows 2000 admiten las caractersticas de compactacin y caducidad. Estas caractersticas se proporcionan como mecanismo para realizar la limpieza y eliminacin de registros de recursos (RR) obsoletos, que se pueden acumular en los datos de la zona con el tiempo. Con la actualizacin dinmica, los registros de recursos se agregan automticamente a las zonas cuando los equipos se inician en la red. Sin embargo, en algunos casos, no se quitan automticamente cuando los equipos abandonan la red. Por ejemplo, si un equipo registra su propio RR de host (A) al inicio y ms tarde se desconecta incorrectamente de la red, su RR de host (A) puede no eliminarse. Si la red tiene usuarios y equipos mviles, esta situacin se puede producir frecuentemente. Slo se puede elegir para participar en este proceso las zonas de tipo principal que se cargan mediante el servicio Servidor DNS. Compactacin de cualquier registro de recursos que persiste ms all del perodo de actualizacin especificado. Cuando un servidor DNS de Windows 2000 realiza una operacin de compactacin, puede determinar que los registros de recursos han caducado hasta el punto de convertirse en obsoletos y eliminarlos de los datos de la zona. Los servidores se pueden configurar para realizar operaciones de compactacin repetitivas
automticamente o puede iniciar una operacin inmediata de compactacin en el servidor.
Ficha Sugerencias de Raz

Las sugerencias de raz se utilizan para preparar los servidores autoritativos para zonas que no sean de raz, a fin de que puedan aprender y descubrir servidores autoritativos que administran dominios de un nivel superior o de otros subrboles del espacio de nombres del dominio DNS. Estas sugerencias son esenciales para los servidores autoritativos de niveles inferiores del espacio de nombres cuando localicen y busquen servidores en estas condiciones. Por ejemplo, suponga que un servidor DNS (Servidor A) tiene una zona llamada sub.ejemplo.microsoft.com. En el proceso de respuesta a una consulta de un dominio de nivel superior, como el dominio microsoft.com, el Servidor A necesita ayuda para ubicar un servidor autoritativo (como el Servidor B) de este dominio. Para que el Servidor A encuentre al Servidor B o cualquier otro servidor autoritativo para el dominio microsoft.com, es necesario que pueda consultar a los servidores raz del espacio de nombres DNS. Los servidores raz pueden remitir el Servidor A a los servidores autoritativos del dominio com. A su vez, los servidores del dominio com pueden ofrecer referencia al Servidor B u otros servidores autoritativos para el dominio microsoft. com. Las sugerencias de raz utilizadas por el Servidor A deben tener sugerencias tiles para los servidores raz a fin de que este proceso localice al Servidor B (u otro servidor autoritativo), como se pretende. Para configurar y utilizar las sugerencias de raz de forma correcta, determine primero cmo se aplica lo siguiente a sus servidores DNS:
q
Utiliza DNS en Internet o en una red privada? Se utiliza el servidor como un servidor raz?
De forma predeterminada, el servicio DNS implementa las sugerencias de raz utilizando el archivo Cache.dns almacenado en la carpeta %SystemRoot%\System32\Dns del equipo servidor. Este archivo suele contener los registro de recursos A y NS de los servidores raz de Internet. No obstante, si utiliza el servicio DNS en una red privada, puede modificarlo o reemplazarlo con registros similares que apunten a sus propios servidores DNS raz internos. Otra configuracin de servidor en la que se tratan las sugerencias de raz de forma diferente es aquella en la que un servidor DNS est configurado para que lo utilicen otros servidores DNS en un espacio de nombres interno, como un servidor que reenva cualquier consulta DNS de nombres administrada externamente (Internet, por ejemplo). Aunque el servidor DNS utilizado para reenviar puede estar en la misma red que los servidores que lo utilizan para
reenviar, necesita sugerencias para que los servidores raz de Internet funcionen de forma apropiada y resuelvan los nombres externos.
Ficha Registros
Para los servidores DNS de Windows 2000 se pueden utilizar las siguientes opciones de registro de depuracin:
q
Consulta: Registra consultas recibidas por el servicio del Servidor DNS desde los clientes. Notificar: Registra mensajes de notificacin recibidos por el servicio del Servidor DNS desde otros servidores. Actualizacin: Registra actualizaciones dinmicas recibidas por el servicio del Servidor DNS desde otros equipos. Preguntas: Registra el contenido de la seccin de preguntas de cada mensaje de consulta DNS procesado por el servicio del Servidor DNS. Respuestas: Registra el contenido de la seccin de respuestas de cada mensaje de consulta DNS procesado por el servicio del Servidor DNS. Envo: Registra los distintos mensajes de consulta DNS enviados por el servicio del Servidor DNS. Recepcin: Registra los distintos mensajes de consulta DNS recibidos por el servicio del Servidor DNS. UDP: Registra las distintas solicitudes DNS recibidas por el servicio del Servidor DNS a travs de un puerto UDP. TCP: Registra las distintas solicitudes DNS recibidas por el servicio del Servidor DNS a travs de un puerto TCP. Paquetes completos: Registra los distintos paquetes completos escritos y enviados por el servicio del Servidor DNS. Escritura: Registra los distintos paquetes escritos completamente por el servicio del Servidor DNS y devueltos a la zona.
De forma predeterminada, todas las opciones de inicio de registro de depuracin estn deshabilitadas. Cuando se habilitan de forma selectiva, el servicio del Servidor DNS puede realizar un registro adicional a nivel de seguimiento de tipos seleccionados de sucesos o mensajes para solucionar problemas generales y depurar el servidor. El registro de depuracin puede emplear muchos recursos; esto afectar al rendimiento global del servidor y consumir espacio en disco. Por lo tanto, slo debe utilizarse temporalmente cuando se necesite informacin ms detallada acerca del rendimiento del servidor. Dns.log contiene actividad de registro de depuracin. Se encuentra en la carpeta windir\System32 \Dns.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-4e.htm06/01/2006 5:06:35
Administrar las propiedades de una Zona DNS

Cuando agregue una zona mediante la consola DNS, podr administrar las siguientes propiedades generales:
q q q
Realizar una pausa o iniciar la zona, para interrumpir o restaurar el servicio. Cambiar o convertir el tipo de la zona. Deshabilitar o habilitar las actualizaciones dinmicas de la zona.
Para las zonas de directorios integrados, puede habilitar el uso de las actualizaciones dinmicas seguras. Esto le permitir restringir las actualizaciones a un conjunto especfico de sistemas o usuarios autorizados. Cuando se habilite una directiva de actualizacin segura en la zona, slo se permitir actualizar la zona o los registros de recursos especficos utilizados en ella a los usuarios, sistemas o grupos autorizados a travs de Active Directory e incluidos en la lista de control de acceso (ACL) de cada zona integrada en directorios. Adems de estas propiedades generales de zona, puede configurar o administrar las propiedades de zona siguientes mediante la consola DNS:
q
Propiedades del Inicio de autoridad (SOA): Incluyen las propiedades compatibles con el registro de recursos SOA que se utiliza para iniciar la zona e indicar la autoridad de zona para un nombre de dominio DNS (y de cualquiera de sus subdominios no delegados en otros servidores) a otros recursos del espacio de nombres DNS. Este registro afecta a la frecuencia con que la zona debe renovarse y transferirse por otros servidores que la carguen, y al tiempo que los clientes pueden almacenar en la memoria cach los registros de recursos (RR) cuando se devuelvan con las consultas de nombres de la zona respondidas. Propiedades del servidor de nombres (NS): Incluyen todos los campos compatibles con el registro de recursos (RR) NS de la zona. El RR NS se utiliza para designar los nombres de servidores DNS autoritativos de la zona para otros. Propiedades de transferencia de zona: Con esta caracterstica puede configurar cmo permitir la zona hacer las transferencias. Puede elegir denegar todas las peticiones al servidor para la transferencia de esta zona, permitirlas slo para otros servidores DNS configurados en la ficha Servidores de nombres o transferir la zona slo a servidores DNS especificados por sus direcciones IP en una lista configurada. Al utilizar Notificar aqu, tambin podr habilitar y configurar la notificacin DNS para los servidores secundarios de la zona. Cuando utilice la notificacin, se notificar a otros servidores (los configurados en la ficha Servidores de nombres o en una lista que especifique) los cambios de zona. Estos servidores podrn extraer los cambios iniciando una transferencia de zona para actualizarla. Propiedades de bsqueda WINS: Puede utilizar la caracterstica de bsqueda del Servicio de nombres Internet de Windows (WINS) para proporcionar una ruta de resolucin de nombres DNS ampliada para zonas cuando no se encuentre el nombre consultado en la zona. Si se habilita la bsqueda WINS para la zona, se puede entrar en contacto con un servidor WINS (o una lista de servidores WINS) para que ayude a resolver un nombre de host en el espacio de nombres NetBIOS administrado por WINS. Esta caracterstica slo se admite en los servidores DNS de Microsoft. Para obtener ms informacin, consulte Usar la bsqueda WINS.
Ficha General
q
Estado: Nos muestra el estado en el que se encuentra actualmente la zona. Si pulsamos el botn de la derecha podemos iniciar o detener la zona Tipo: Informa del tipo de zona que estamos administrando, con el botn cambiar podemos modificar el tipo de zona Datos Almacenados en Active Directory: En Windows NT 4, el servidor DNS carece de actualizaciones dinmicas. Cada vez que se le asigna una nueva direccin IP a un host, un administrador tiene que actualizar manualmente el archivo de zona DNS con la nueva direccin IP. El servidor DNS de Windows 2000 implementa la RFC 2136compatibilidad con actualizaciones dinmicas. Estas actualizaciones dinmicas permiten que los clientes Windows 2000 actualicen sus propios registros DNS de bsqueda directa, y permiten que los servidores DHCP y WINS actualicen los registros de bsqueda directa e inversa de todos los clientes. Tambin permiten recuperar registros que no se haban refrescado en mucho tiempo, reduciendo el enorme crecimiento gradual que se produce en las bases de datos del DNS. r Permitir Actualizaciones dinmicas?: 1. No. No permite actualizaciones dinmicas para esta zona. 2. S. Permite todas las peticiones de actualizaciones dinmicas para esta zona. 3. Slo actualizaciones seguras. Permite slo el uso de actualizaciones dinmicas del DNS que utilicen el DNS seguro para esta zona. Esta es la opcin predeterminada. La opcin Slo actualizaciones seguras slo aparece si el tipo de zona es Active Directory integrado. Si selecciona la opcin Slo actualizaciones seguras, el permiso del solicitante para actualizar registros en la base de datos de la zona se prueba usando los mecanismos especificados en el protocolo de actualizacin del DNS seguro. Para que el DNS dinmico funcione correctamente, es necesario configurar el servidor DHCP para que actualice el servidor DNS cuando cambie la direccin IP de un cliente.
Ficha Inicio de Autoridad (SOA)

Las zonas se basan en el concepto de autoridad de servidor. Cuando se configura un servidor DNS para cargar una zona, utiliza dos tipos de registros de recursos para determinar las propiedades autorizadas de la zona. Primero, el registro de recursos de inicio de autoridad (SOA) indica el nombre de origen de la zona y contiene el nombre del servidor que es el origen principal de informacin acerca de la zona. Tambin indica otras propiedades bsicas de la zona. A continuacin, se utiliza el registro de recursos del servidor de nombres (NS) para anotar qu servidores DNS estn designados como autorizados para la zona. Al mostrar un servidor en el RR NS, se da a conocer a los otros como servidor autorizado para la zona. Esto significa que cualquier servidor especificado en el RR NS va a ser considerado por los dems como un origen autorizado y puede responder con seguridad cualquier consulta realizada de nombres incluidos en la zona. Los registros de recursos NS y SOA desempean una funcin especial en la configuracin de zona. Son registros necesarios para cualquier zona y, normalmente, son los primeros registros de recursos que se muestran en los archivos. De forma predeterminada, el Asistente para agregar zonas nuevas crea automticamente estos registros cuando se agrega una nueva zona principal con el complemento DNS. El registro de recursos de inicio de autoridad (SOA) se encuentra siempre el primero en cualquier zona estndar. Indica el servidor DNS que lo cre originalmente o que es ahora el servidor principal de la zona. Tambin se utiliza para almacenar otras propiedades como la informacin de la versin y las temporizaciones que afectan a la caducidad o renovacin de zonas. Estas propiedades afectan a la frecuencia con que se realizan las transferencias de la zona entre servidores autorizados de la zona.
q
Nmero de serie: El nmero de revisin del archivo de la zona. Este nmero aumenta cada vez que cambia un registro de recursos en la zona. Es importante que aumente este valor cada vez que cambia la zona, de manera que cambie cada zona parcial o se pueda replicar la zona revisada totalmente en otros servidores secundarios en transferencias posteriores. Servidor principal (propietario): El nombre de host del servidor DNS principal para la zona. Persona responsable: La direccin de correo electrnico de la persona responsable de administrar la zona. En este nom/ pe de correo electrnico se utiliza un punto (.) en lugar del smbolo arroba (@). Intervalo de actualizacin: El tiempo, en segundos, que un servidor DNS secundario espera antes de consultar a su origen la zona para intentar su renovacin. Cuando caduca el intervalo de actualizacin, el servidor DNS secundario
solicita una copia del registro SOA actual de la zona a su origen, que responde a esta solicitud. El servidor DNS secundario compara el nmero de serie del registro SOA actual del servidor de origen (como se indica en la respuesta) con el nmero de serie de su propio registro SOA local. Si son diferentes, el servidor DNS secundario solicita una transferencia de zona del servidor DNS principal. El valor predeterminado para este campo es 900 segundos (15 minutos). Intervalo de reintento: El tiempo, en segundos, que espera un servidor secundario antes de volver a intentar una transferencia de zona que ha fallado. Normalmente, este tiempo es menor que el intervalo de actualizacin. El valor predeterminado es de 600 segundos (10 minutos). Expira despus de (Intervalo de caducidad): El tiempo, en segundos, que pasa antes de que un servidor secundario deje de responder a consultas despus del transcurso de un intervalo de actualizacin tras el que la zona no se actualiz. La caducidad ocurre porque, en este momento, el servidor secundario debe considerar que sus datos locales no son confiables. El valor predeterminado es de 86.400 segundos (24 horas). TTL mnimo (predeterminado): El valor Tiempo de vida (TTL) mnimo que se aplica a todos los registros de recursos en la zona con TTL especficos del registro sin especificar. Este valor lo proporcionan los servidores de la zona en respuestas a consultas para informar a otros de la frecuencia con la que deben almacenar en la memoria cach un registro de recursos proporcionado por una respuesta. El valor predeterminado es de 3.600 segundos (1 hora).
ste es un ejemplo de registro de recursos SOA predeterminado: @ IN SOA nameserver.example.microsoft.com. postmaster.example.microsoft.com. ( 1 ; nmero de serie 3600 ; actualizar [1h] 600 ; reintentar [10m] 86400 ; caducar [1d] 3600 ) ; TTL mnimo [1h] En el ejemplo de registro SOA mostrado arriba, el servidor de origen o principal de la zona se muestra como nameserver.example.microsoft.com. La direccin de correo electrnico de la persona con la que ponerse en contacto para formular preguntas acerca de esta zona es postmaster.example.microsoft.com. Los puntos se utilizan para representar direcciones de correo electrnico al escribir y almacenar nombres de dominio DNS en una zona. En una aplicacin de correo electrnico, la direccin del ejemplo anterior podra aparecer como postmaster@example.microsoft.com. Los parntesis utilizados en el registro de recursos SOA segn aparece en un archivo de zona se utilizan para habilitar el ajuste del registro sobre mltiples lneas de texto. Si se asigna un valor TTL individual y se aplica a un registro de recursos especificado que se utilice en la zona, suplanta el TTL mnimo (predeterminado) establecido en el registro SOA. El registro de recursos NS Los registros de recursos de servidor de nombres (NS) se pueden usar para asignar autoridad a servidores especificados para un nombre de dominio DNS de dos maneras: Al establecer una lista de servidores autorizados para el dominio de manera que esos servidores puedan darse a conocer a otros que soliciten informacin acerca de este dominio (zona). Al indicar los servidores DNS autorizados para cualquier subdominio que se delegue fuera de la zona. En caso de asignar servidores con nombre de host en la misma zona, los registros de recursos de la
direccin correspondiente (A) se utilizan normalmente en la zona para resolver los nombres de los servidores especificados a sus direcciones IP. Para los servidores que se especifican con este RR como parte de una delegacin de zona en un subdominio, el registro de recursos NS normalmente contiene nombres de fuera de la zona. Para resolver los nombres de fuera de la zona, puede que se necesiten registros de recursos A para los servidores de fuera de la zona especificados. Cuando estos registros A y NS de fuera de la zona son necesarios para la delegacin, se conocen como registros con adherencia.
Ficha Servidores de Nombres

Muestra los servidores de nombres (NS) configurados para el servidor o la zona de la manera siguiente: Cuando esta lista se muestra en la ficha Sugerencias de raz, que se encuentra en las propiedades de servidor DNS correspondientes, presenta sugerencias de raz que contienen los servidores raz que el servidor debe utilizar y a los que debe hacer referencia para resolver nombres. En los servidores raz, este campo debe estar en blanco. Cuando esta lista se muestra en la ficha Servidores de nombres, que se encuentra en las Propiedades de zona correspondientes, presenta los servidores DNS configurados actualmente como autoridades para la zona. En la mayor parte de los casos, esto incluye todos los dems servidores que estn configurados como secundarios de la zona.
Ficha WINS
El Servicio de nombres Internet de Windows (WINS) se puede usar para buscar nombres DNS que no se pueden resolver mediante la consulta del espacio de nombres de dominio DNS. Para ejecutar la bsqueda WINS, se utilizan dos tipos de registros de recursos especficos que se pueden habilitar para cualquier zona cargada mediante el servicio DNS:
q
El registro de recursos WINS, que se puede habilitar para integrar la bsqueda WINS en las zonas de bsqueda directa El registro de recursos WINS-R, que se puede habilitar para integrar la bsqueda inversa WINS en las zonas de bsqueda inversa
El registro de recursos WINS

Los servicios WINS y DNS se utilizan para proporcionar la resolucin de nombres para el espacio de nombres NetBIOS y el espacio de nombres de dominio DNS, respectivamente. Aunque DNS y WINS pueden proporcionar un servicio de nombres til e independiente a los clientes, WINS se necesita, principalmente, para proporcionar compatibilidad con los clientes y programas antiguos que requieren compatibilidad con los nombres NetBIOS. Sin embargo, el servicio DNS puede funcionar con WINS para proporcionar bsquedas de nombres combinados en los dos espacios de nombres cuando en una informacin de zona no se encuentra la resolucin de un nombre de dominio DNS. Para proporcionar esta interoperabilidad, se ha definido un nuevo registro (el registro WINS) como parte del archivo de base de datos de zonas. El registro de recursos WINS es especfico para Windows 2000 Server y versiones anteriores de Windows NT Server, y se puede conectar slo al dominio de origen de una zona. La presencia de un registro de recursos WINS puede indicar al servicio DNS que utilice WINS para buscar las consultas directas de nombres de host o nombres que no se encuentran en la base de datos de zonas. Esta funcionalidad es especialmente til en la resolucin de nombres que requieren los clientes que no admiten WINS (por ejemplo, UNIX) para los nombres de los equipos que no se registraron con DNS, como los equipos con Windows 95 o Windows 98.
q
Usar bsqueda directa WINS: Para impedir que el registro WINS sea replicado a cualquier servidor secundario por motivos de compatibilidad (los servidores DNS no Microsoft no soportan registros WINS-R), hay que seleccionar la casilla de verificacin No replicar este registro. Direccin IP: Introducir la direccin IP de cada servidor WINS que se quiera consultar, pulsando Agregar tras introducir cada una.
Ficha Transferencias de zona

Dado que el servicio DNS es tan importante para una red moderna basada en TCP/IP, y dado que es tan esencial para el funcionamiento del Active Directory, se recomienda que se configuren mltiples servidores DNS en cada zona para proporcionar tolerancia a fallos en caso de que un servidor deje de responder. Windows 2000 soporta varias formas de conseguir transferencias de zona entre servidores DNS que administran una zona. Si los servidores DNS utilizan Active Directory para almacenar su informacin de zona, Active Directory maneja la rplica de zona, permitiendo a un modelo de mltiples maestros completo con zonas transferir slo los registros actualizados en lugar de realizar transferencias de zonas completas. Windows 2000 tambin soporta la Peticin de comentario (RFC) 1995, compatible con las transferencias de zona incrementales cuando se utilizan archivos de zona estndar. Si el servidor DNS que se est configurando es un servidor DNS secundario en una zona, el servidor ya est configurado para realizar transferencias de zona con el servidor maestro de la zona. Si el servidor es un servidor principal de la zona, el servidor est configurado para realizar transferencias de zona con cualquier servidor DNS que se las solicite. Esta situacin puede ser un problema de seguridad potencial si alguien quiere crear un servidor DNS corrupto y obtener la informacin de la zona, por lo que sera deseable permitir que slo ciertos servidores DNS realicen transferencias de zona con el servidor. Podemos modificar la forma en la que se producen las transferencias de zona en el servidor DNS en la ficha de Transferencia de zona:
q
Permitir zona de transferencias: Permite realizar transferencias de zona entre servidores DNS. Deberemos escoger entre tres modos de notificacin:
r
A cualquier servidor (por defecto): Para permitir que cualquier servidor DNS realice transferencias de zona con este servidor DNS. Slo a los servidores nombrados en la ficha de Nombres de servidores: Para configurar el servidor de forma que slo permita que realicen transferencias de zona con los servidores que tengan registros de servidor de nombres (NS, Name Server) Slo a los siguientes servidores: Para crear una lista de servidores aprobados con los cuales el servidor DNS puede realizar transferencias de zona, hay que seleccionar Slo a los siguientes servidores. Se puede introducir entonces la direccin IP de cada servidor en el cuadro proporcionado, pulsando Agregar tras introducir cada una.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-5e.htm (1 of 2)06/01/2006 5:06:38

q
Notificar: Para modificar si los servidores secundarios de la zona son notificados cuando se actualiza el archivo de zona, hay que pulsar Notificar. Para desactivar la notificacin a los servidores secundarios cuando se producen cambios en el archivo de zona, hay que desactivar la casilla de verificacin Notificar automticamente. Para notificar slo a servidores DNS con registros de servidor de nombres en el archivo de zona, hay que seleccionar Lista de servidores en la ficha de Nombres de servidores. Para crear una lista de servidores a los que se quieran notificar los cambios en el archivo de zona, hay que seleccionar la opcin Los siguientes servidores. Despus hay que introducir la direccin IP de cada servidor en el cuadro proporcionado, pulsando Agregar tras introducir cada una.
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-03-5e.htm (2 of 2)06/01/2006 5:06:38
file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-04-ind.htm
Tema 3.- Servicio de nombres de Internet de Windows (WINS)

q
Descripcin general de WINS en Windows 2000 r Trminos clave de WINS r Cach de nombres de NetBIOS r Liberacin de nombre r Proxy de WINS r Entradas de la base de datos de WINS r Replicacin de servidor de WINS r Estado del adaptador Instalacin y configuracin de un servidor WINS r Determinacin de la necesidad de WINS r Configuracin del servidor para prepararlo para WINS r Instalacin de WINS r Adicin de asociados de rplica Funcionamiento de WINS r Registro de los nombres de NetBIOS r Resolucin de conflictos de Registro de nombre de NetBIOS r Liberacin de nombres de NetBIOS
Servicio de Nombres de Internet para Windows WINS de Windows 2000
Servicio de nombres de Internet de Windows (WINS)
q Descripcin general de WINS en Windows 2000 -Trminos clave de WINS -Cach de nombres de NetBIOS -Liberacin de nombre -Proxy de WINS -Entradas de la base de datos de WINS -Replicacin de servidor de WINS -Estado del adaptador q Instalacin y configuracin de un servidor WINS -Determinacin de la necesidad de WINS -Configuracin del servidor para prepararlo para WINS -Instalacin de WINS -Adicin de asociados de rplica q Funcionamiento de WINS -Registro de los nombres de NetBIOS -Resolucin de conflictos de Registro de nombre de NetBIOS -Liberacin de nombres de NetBIOS
En los principios de la informtica personal, IBM y Microsoft usaban NetBIOS para proporcionar a los programadores y aplicaciones acceso a las funciones y capacidades de red. NetBIOS se desarroll originalmente para IBM por Sytek Corporation como extensin a la BIOS, que una aplicacin poda utilizar haciendo llamadas a la BIOS. En Microsoft Windows 2000, NetBIOS es tanto una interfaz de red independiente de transporte como un protocolo de administracin de sesin y de transporte de datos. NetBIOS puede funcionar sobre cualquiera de los protocolos de transporte de red de Windows 2000, incluyendo NetBEUI, NWLink (IPX) y TCP/IP. Las aplicaciones que utilizan NetBIOS pueden funcionar con cualquiera de los protocolos de transporte configurados. Los clientes de interconexin de Windows tradicionalmente han utilizado NetBIOS para distintas funciones, entre ellas la comparticin de archivos a impresoras y la exploracin. Las RFC 1001 y 1002 definen las funciones y caractersticas de un servicio de NetBIOS sobre el transporte de TCP/UDP, tambin conocido como NetBIOS sobre TCP/IP (NBT). Estas RFC, publicadas en 1987, describen los siguientes tres servicios principales para las aplicaciones de NetBIOS que se ejecuten en TCP/IP:
q
Servicio de nombres. Proporciona a los equipos la capacidad de adquirir, defender nombres de NetBIOS y localizar quin guarda dichos nombres. Servicio de sesin. Proporciona un intercambio fiable de mensajes entre dos pares de aplicaciones de NetBIOS. Servicio de datagramas. Proporciona un servicio de paso de mensajes no fiable, sin consecuencias, sin conexin, para aplicaciones NetBIOS.
Los servicios de sesin y datagramas de NetBEUI permiten a las aplicaciones de NetBIOS enviar mensajes entre ellas utilizando equipos individuales con nombres de NetBIOS. El servicio de nombres de NetBIOS proporciona la capacidad adquirir/registrar un nombre, localizar equipos con un nombre concreto y resolver un nombre de NetBIOS dada su direccin de IP. WINS es un servidor de nombres de NetBIOS que puede usar un cliente para registrar, defender y buscar nombres de NetBIOS. WINS proporciona varias ventajas a una organizacin:
q q
Funciones de registro de nombre y resolucin de nombres para equipos con NetBIOS. Mantenimiento dinmico de la base de datos para disponer de registro y resolucin de nombres de equipo. Administracin centralizada de una base de datos de nombres de NetBIOS escalable.
WINS implementa las caractersticas del servicio de nombres de un servidor de nombres de NetBIOS definidas en las RFC 1001 y 1002. Sin embargo, para crecer apropiadamente para redes grandes, WINS tambin proporciona funciones de replicacin. En las versiones iniciales de Microsoft Windows NT, WINS jug un papel crtico en la localizacin de servicios, particularmente en los servicios de directorio de Windows NT. Los clientes utilizaban NetBIOS para localizar los Controladores de dominio de Windows NT 4.0. Se usaban los servicios de sesin y datagramas de NetBIOS como base para las operaciones de directorio. La comparticin de archivos e impresoras tambin usan NetBIOS. Una organizacin que slo usa equipos con Windows 2000 o una mezcla de equipos con Windows 2000 y sistemas operativos de terceros como UNIX y cuyas aplicaciones disponen del Sistema de nombre de dominio (DNS), puede eliminar NetBIOS y no tener necesidad de WINS. Sin embargo, significa que cualquier aplicacin que use NetBIOS, como el explorador del equipo, no funcionar. La mayora de las organizaciones, sin embargo, necesitan mantener equipos antiguos, que
requieren los nombres de red de NetBIOS. En este apartado se incluyen los equipos con Microsoft Windows para trabajo en grupo, Microsoft Windows 95, Microsoft Windows 98 y todas las versiones de Windows NT. Las organizaciones con equipos con estos sistemas operativos vern que WINS es un servicio importante para el desarrollo de Windows 2000.
Descripcin general de WINS en Windows 2000

En Windows 2000, WINS consta de dos componentes: el Servicio de nombres de Internet de Windows, WINS (Windows Internet Nombre Servicio), y un servicio cliente de WINS. WINS es un servidor de nombres de NetBIOS que permite a un cliente registrar nombres de NetBIOS en una base de datos central y resolver nombres de NetBIOS a direcciones de IP. El cliente del WINS utiliza el servidor del WINS para registrar nombres y proporcionar funciones de resolucin de nombres, convirtiendo nombres de NetBIOS en direcciones de IP. En trminos funcionales, WINS es muy parecido a DNS, con clientes que registran nombres y realizan bsquedas de los nombres y servidores que manejan los registros y la resolucin. La diferencia ms importante es que WINS utiliza nombres de NetBIOS en lugar de nombres de host de DNS. En las RFC 1001 y 1002 se definen las funciones del servidor de nombres de NetBIOS con detalle. A este respecto, el servidor de WINS es un servidor de nombres de NetBIOS que cumple la RFC para proporcionar funciones de registro de nombres y resolucin de nombres. El servidor de WINS es escalable, capaz de funcionar correctamente en redes de cualquier tamao. Todos los servidores con Windows 2000, incluyendo Server, Advanced Server y Datacenter Server, incluyen el servicio WINS, aunque no se instala de manera predeterminada. Todos los clientes de Windows incluyen un cliente de WINS, entre ellos Windows 2000, Windows NT 4.0, Windows 98 y Windows 95. Para los clientes con Windows 2000, la funcin cliente de WINS se instala automticamente.
Trminos clave de WINS

En Windows 2000, NetBIOS es tanto una interfaz de red, que permite a las aplicaciones y componentes clave del sistema comunicarse por la red, como un protocolo que permite dicha comunicacin. Entre los procesos del sistema que utilizan NetBIOS estn el servicio de comparticin de archivos de Windows y el servicio de exploracin de equipos.
Recursos de red y nodos terminales

Para que las aplicaciones interoperen y los usuarios accedan a recursos clave, todos los recursos de la red necesitan un nombre. Un recurso de red es un proceso que se ejecuta en un equipo concreto. Puede ser un servicio Servidor ejecutndose en el equipo Servidor de intercambio, o un servicio Servidor ejecutando en un servidor de archivos. El equipo concreto que ejecuta el proceso recurso de red se denomina equipo terminal.
Nombres de NetBIOS
Todos los recursos de la red en Windows 2000 tienen un nombre NetBIOS. En Windows 2000, todos los nombres NetBIOS pueden tener hasta 15 caracteres. El ltimo, el decimosexto, permitido en las RFC 1001 y 1002, se reserva como sufijo del nombre NetBIOS. El nombre NetBIOS no puede empezar con un <*> y no son sensibles a las maysculas. El espacio de nombres de NetBIOS es plano, al contrario que DNS, que es jerrquico. Significa que un nombre NetBIOS slo se puede usar una vez en una red. Dos equipos que ejecuten el servicio Server no pueden tener el mismo nombre. Esto puede llevar a algunos problemas en organizaciones muy grandes y es donde el parmetro mbito de NetBIOS ofrece una solucin.
Tipos de nombres de NetBIOS

Un nombre de NetBIOS puede ser un nombre nico, que lo posee un nico nodo o puede formar
parte de un grupo de Internet, que puede incluir varios nodos terminales (end-nodes). Todos los equipos con Windows 2000 tienen un servicio Server y un servicio Workstation para comparticin de archivos. Estos servicios deberan tener nombres nicos de NetBIOS. Cuando se resuelve una direccin de NetBIOS a una direccin de IP, los nombre nicos se resuelven a una nica direccin de IP, mientras que las direcciones de grupos de Internet se resuelven a varias direcciones.
Sufijo del nombre de NetBIOS

Aunque las RFC 1001 y 1002 permiten que los nombres de NetBIOS tengan 16 caracteres, el decimosexto carcter del nombre de NetBIOS de Windows se reserva para un sufijo especial. El sufijo del nombre de NetBIOS lo usa todo el software de red de Windows para identificar la funcionalidad instalada en el dispositivo registrado. De esta forma un nodo terminal puede registrar varios nombres segn el equipo, dominio, o nombre de usuario, y un sufijo para indicar los servicios disponibles en dicha mquina. Los clientes de WINS pueden construir un nombre de NetBIOS segn el equipo, el usuario, o el nombre de dominio, y el sufijo apropiado para localizar los recursos de red relevantes. Por ejemplo, el servicio Messenger (Mensajera) tiene el sufijo 0x03. Para enviar un mensaje a COMPUTER42, el cliente enviara un mensaje al servicio Workstation en Computer42, o COMPUTER42[03]. Observe que en la notacin del nombre NetBIOS de 16 caracteres completo, los primeros 9 caracteres seran COMPUTER42, los 6 siguientes seran (blanco) y el carcter final sera un 0x03. Sufijos comunes de NetBIOS utilizados en las redes Windows Nombre Sufijo NetBIOS (hex) Tipo Uso U U U U U G U G G G Servicio Workstation. Servicio de Mensajera. Servicio de Mensajera. Servicio Server. Servicio de Mensajera. Nombre de dominio. Explorador maestro del dominio. Controlador de dominio. Eleccin del servicio explorador. Explorador maestro. <nombre de equipo> 00 <nombre de equipo> 01 <nombre de equipo> 03 <nombre de equipo> 20 <nombre de usuario> 03 <dominio> <dominio> <dominio> <dominio> <..--_MSBROWSE_> 00 1B 1C 1E O1
Adems de estos nombres comnmente utilizados en Windows 2000, otras aplicaciones como Microsoft Exchange, Lotus Notes y otras tambin registran nombres de NetBIOS.
Operaciones del servicio de nombres de NetBIOS

Entre las operaciones del servicio de nombres NetBIOS se encuentran las de registro, defensa, solicitud y liberacin de nombres de NetBIOS. Adems, los servicios de sesin y datagramas de NetBIOS utilizan estas operaciones del servicio de nombres para localizar recursos. Por ejemplo, si un usuario de un equipo con Windows 2000 quisiera acceder a un sistema de archivos remoto, el usuario introduce el nombre del equipo remoto y el nombre compartido en Microsoft Explorer. Explorer usa los servicios de nombre de NetBIOS para determinar la direccin de IP del servidor remoto y a continuacin enva comandos del nivel de sesin de NetBIOS para acceder a los recursos compartidos. Las operaciones del servicio de nombres de NetBIOS se llevan a cabo por la red usando difusin de IP o un servidor de nombres de NetBIOS. El uso de difusin podra ser aceptable en redes de rea local pequeas (LAN). Sin embargo, en redes grandes el uso de la difusin podra conducir a una tormenta de difusin, lo que no es deseable. Estas redes deberan de implantar WINS.
mbitos de NetBIOS
El espacio de nombres de NetBIOS es plano, lo que significa que todos los nombres deben ser nicos en el conjunto de redes. Si tiene un equipo llamado EQUIPO y defiende apropiadamente su nombre de equipo, ningn otro equipo de la red se puede llamar a s mismo EQUIPO. Esta limitacin puede causar dificultades en grandes organizaciones. Como se describe en la RFC 1001, una aproximacin para resolver este espacio de nombres plano es usar un cualificador adicional en el nombre NetBIOS. En la RFC 1001 se define el mbito de NetBIOS como < la poblacin de equipos en los que se conoce un nombre de NetBIOS registrado> . Para identificar el mbito de NetBIOS, se usa un identificador de mbito de NetBIOS. El identificador de mbito de NetBIOS es una cadena de caracteres, similar en formato y funcin a los nombres de dominio de DNS. El uso del mbito de NetBIOS, sin embargo, es limitado en cuanto que el usuario no puede especificar el mbito directamente. El mbito de NetBIOS en un equipo con Windows 2000 se define como parte de los parmetros de IP del equipo que se reciben del servidor de DHCP o en el registro del equipo. Por tanto, el mbito del equipo se aade automticamente a todos los nombres de NetBIOS. El efecto es que un nodo terminal con un mbito de NetBIOS dado slo se puede comunicar con otros equipos configurados con el mismo mbito de NetBIOS. Se puede establecer el mbito de NetBIOS especificando un mbito como parte del mbito de DHCP o editando el registro. La clave del registro que se utiliza para cambiar manualmente el tipo de nodo es la siguiente: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Adapters \Interface \<interfaz> Nombre del valor: ScopeId Tipo del valor: REG_SZ-Cadena de caracteres Rango del valor: Cualquier nombre vlido de dominio de DNS que consista en dos partes separadas por puntos, o un asterisco (*) Predeterminado: Ninguno Presente predeterminado: No
Tipos de nodos de NetBIOS

Para dar cabida a redes de varios tamaos de NetBIOS, las RFC 1001 y 1002 usan el concepto de tipo de nodo para determinar cmo debe manejar un equipo las funciones del servicio de nombres. El tipo de nodo define cmo se realizan las operaciones del servicio de nombres. Un nodo terminal puede pertenecer a uno de los cuatro tipos de nodos, definidos en las RFC 1001 y 1002:
q
Nodo B (Nodo de difusin, Broadcast). Usando difusin slo se realizan las operaciones de registro y resolucin de nombres. Normalmente es la mejor opcin en una red muy pequea con una nica subred. Nodo P (Nodo punto a punto). Se usa slo el servidor de nombres de NetBIOS, (WINS) para las operaciones de registro y resolucin de nombres. Este tipo de nodo se usa para eliminar las difusiones de la subred local, pero puede ocasionar que recursos de
la red en la subred local no se resuelvan. Nodo M (Nodo mixto). Una combinacin de los Nodos B y P, donde el registro y resolucin de nombres se realiza mediante difusin. Pero si la resolucin de nombres no se consigue mediante difusin, se usa el servidor de nombres de NetBIOS. Es til en los casos en los que el servidor de WINS se encuentra en una red remota, por lo que se intenta resolver localmente el nombre antes de usar recursos de WAN para resolverlo. Nodo H (Nodo hbrido). Una combinacin de los Nodos P y B, donde el registro y resolucin de nombre se hace utilizando un servidor WINS. Pero si la resolucin de nombres no se consigue mediante el servidor WINS, se usa difusin. Es el tipo de nodo predeterminado cuando se utilizan servidores WINS.
De forma predeterminada, los equipos con Windows 2000 son Nodos B. Si se configura un equipo con Windows 2000 para que use un servidor WINS, se convierte en un Nodo H. Se puede configurar el equipo para que sea un Nodo P o M editando manualmente el registro. Adems, el administrador puede establecer los parmetros del Protocolo de configuracin dinmica de host (DHCP) para determinar el tipo de nodo de un cliente de DHCP. La clave del registro que se utiliza para cambiar el tipo de nodo es la siguiente: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Adapters \Interfaces \<interfaz> Nombre de valor: NodeType Tipo de valor: REG_DWORD - Nmero Rango vlido: 1,2,4,8 (Nodo B, Nodo P, Nodo M, Nodo H) Predeterminado: 1 u 8 segn la configuracin del servidor WINS Presente predeterminado: No
Modificacin de Microsoft de los Nodos B

Como se define en las RFC 1001 y 1002, el comportamiento de los Nodos B no funciona apropiadamente para redes de ms de una nica subred. Se puede mejorar en parte configurando los enrutadores para que reenven los mensajes de difusin, pero esto no escala bien y rara vez se hace. Para superar las limitaciones inherentes Microsoft ha extendido las operaciones del servicio de nombres de los Nodos B. A estas extensiones se les conoce como Nodo B modificado, que aade las siguientes funciones de bsqueda de nombre a un Nodo B:
q
Cach de nombres de NetBIOS. Una cach en memoria de los nombres resueltos recientemente que se busca antes de intentar otros mtodos de resolucin de nombres. Archivo LMHOSTS. Un archivo plano, en la carpeta systemroot\system32\drivers\etc que contiene una lista esttica de nombres de NetBIOS y sus direcciones de IP.
Si se usa LMHOSTS por alguna razn no deseable, se puede desactivar reconfigurando los parmetros de TCP/IP del equipo.
Registro de nombre
Cuando un recurso de red est disponible para su uso -por ejemplo, cuando un servidor de archivos arranca-, el recurso de red deber registrar su nombre de NetBIOS relevante. El procedimiento de registro asegura que el nombre registrado no est ya en uso por otro equipo. Para los clientes de un Nodo P, un Nodo M o un Nodo H, el cliente tambin informa al servidor WINS del nombre y direccin de IP.
Perodo de vida (TTL)

En general, los nombres de NetBIOS no se mantienen en propiedad permanentemente. Con WINS, cada nombre que se registra correctamente tiene un perodo de vida (TTL) limitado. Cuando el TTL de un nombre de NetBIOS expira, es responsabilidad del recurso de red registrar el nombre. Si el registro de red registra el nombre con un servidor de WINS y el TTL expira, el nombre se puede eliminar del servidor WINS. Los clientes de Windows 2000 intentan registrar sus nombres de NetBIOS cuando ha transcurrido la mitad del TTL o cuando el equipo se reinicia.
Defensa de nombre
Una vez registrado, todos los nombres de NetBIOS nicos hay que defenderlos para asegurar que no hay dos recursos de red diferentes que reclamen el mismo nombre de NetBIOS. Si un equipo intenta registrar un nombre de NetBIOS que ya lo estaba utilizando otro equipo, el propietario del nombre necesita defender el nombre. Si un recurso de red descubre que el nombre que intenta registrar ya se est utilizando -por ejemplo, se inicia un equipo configurado con un nombre de equipo de otro que ya est ejecutando-, el recurso de red debera dar un error. Los procesos de Windows 2000, como el servicio Server, escribirn un suceso de error en el registro de sucesos para un posterior anlisis y solucin del problema. Si el propietario del nombre es un cliente de un Nodo B, el propietario debe aceptar la responsabilidad de defender el nombre escuchando las peticiones de registro de nombre y difundiendo una Respuesta de registro negativa. Para los clientes Nodo P, la defensa de nodo es ms complicada. Si un cliente Nodo P intenta registrar un nombre en un servidor WINS que el servidor cree estar en uso, el servidor WINS intentar en primer lugar ponerse en contacto con el equipo que registr anteriormente el nombre de NetBIOS. Si el servidor WINS consigue ponerse en contacto con el propietario registrado, el servidor enva un mensaje Registro de nombre negativo al cliente que intentaba registrar el nombre. Si, al contrario, el servidor WINS no lo consigue, enviar una respuesta Registro de nombre positivo.
Resolucin de nombre de NetBIOS

Cuando un equipo desea comunicarse con otro, mediante NetBIOS, debe determinar la direccin de IP del equipo remoto antes de establecer la comunicacin. La resolucin de nombre es el proceso de determinar la direccin de IP de un equipo por su nombre de NetBIOS. El mecanismo general que utiliza el cliente de WINS para resolver los nombres es el siguiente:
q
Comprueba si el nombre se puede realmente resolver utilizando NetBIOS. Si el nombre introducido por el usuario o especificado por la aplicacin es mayor de 15 caracteres o contiene un ., se realiza la resolucin de nombre de DNS. A continuacin el cliente comprueba si el nombre se encuentra en la cach de nombres de NetBIOS. Si el equipo est configurado para utilizar LMHOSTS, se consulta en este archivo la direccin de IP del nombre.
Si el nombre no se puede resolver con otras alternativas, por ejemplo mediante DNS, o localmente, los clientes de WINS de Windows 2000 intentarn otros pasos de resolucin de nombres. Estos pasos concretos dependern del tipo de nodo de NetBIOS y de si se ha configurado un proxy de WINS de la siguiente forma:
q
Los clientes Nodo B difundirn mensajes de solicitud de nombre de NetBIOS en la subred local. Si existe un equipo con el nombre en la subred, el equipo enviar una respuesta solicitud de nombre positiva, que contiene la direccin de IP requerida. Si existe un
agente de proxy de WINS en la subred cuando se difunde el mensaje de solicitud de nombre de NetBIOS y no existe respuesta, el agente proxy de NetBIOS intentar resolver el nombre por el cliente. Es un mtodo apropiado en redes pequeas, posiblemente sin servidores WINS, y es el comportamiento predeterminado para un equipo que no tiene configurado un servidor WINS. Los clientes Nodo P enviarn un mensaje de solicitud de nombre de NetBIOS al servidor WINS configurado. Si el servidor WINS tiene el nombre solicitado, enviar una Respuesta de solicitud de nombre positivo, con la direccin de IP requerida; si no, el equipo enviar una Respuesta de solicitud de nombre negativa. Si el cliente WINS no obtiene respuesta del servidor WINS y en su configuracin tiene ms servidores WINS, el cliente intentar con ellos. Este mtodo minimiza las difusiones en la red local. Los clientes Nodo M intentarn utilizar el comportamiento del Nodo B para resolver el nombre, y si no lo consiguen, los clientes Nodo M utilizarn el comportamiento de un Nodo P. Resulta particularmente til cuando el cliente se encuentra en el otro extremo de un enlace WAN, pero generar trfico de difusin adicional en la subred local. Los clientes Nodo H intentarn en primer lugar usar el comportamiento de los Nodos P para resolver el nombre, y si no lo consiguen, los clientes Nodo H intentarn usar el comportamiento de los Nodos B. Como con los Nodos P, este mtodo reduce el trfico de difusin local para los nombres que guarda el servidor WINS, pero utilizar la difusin local para intentar resolver el nombre. Los primeros clientes de WINS manejaban slo un mximo de dos servidores WINS, uno principal y uno secundario. Para obtener tolerancia a errores adicional en los equipos cliente, Windows 2000 o Windows 98 permiten especificar hasta 12 servidores WINS por cada interfaz. Estas direcciones de servidor WINS extra se utilizan slo si los servidores WINS principal y secundario no responden.
Si con ninguno de estos pasos se consigue resolver el nombre de NetBIOS, el equipo con Windows 2000 intentar utilizar la resolucin de nombres de host; primero comprueba el archivo HOSTS local y a continuacin ponindose en contacto con servidores de DNS. Si despus de todos estos pasos no se puede resolver el nombre, el equipo con Windows 2000 enva un mensaje Error al llamante. Esta serie de pasos intenta tanto proporcionar la mxima tolerancia a errores en el cliente como acomodar sistemas incorrectamente configurados. Si un equipo utiliza difusin para resolver un nombre de NetBIOS, no puede asegurar que una falta de respuesta sea significativa. Como se usa UDP como transporte en las operaciones de nombre de NetBIOS, puede que el paquete se haya descartado. Para compensar esta falta de fiabilidad, el cliente que resuelve un nombre, por defecto, difunde la solicitud de resolucin de nombre tres veces, a intervalos de 750 milisegundos entre cada intento. Para modificar el nmero de intentos de difusin se utiliza la siguiente entrada de registro: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters O Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters \Interfaces \<interfaz> Nombre del valor: BcastNameQueryCount Tipo de valor: REG_DWORD-Nmero Rango vlido: 1-OXFFFF Predeterminado: 3 Presente predeterminado: No
Utilice la siguiente entrada del registro para cambiar el intervalo entre difusiones: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters \Interfaces \<interfaz> Nombre de valor: BcastQueryTimeout Tipo de valor: REG_DWORD-Tiempo en milisegundos Rango vlido: 100-OxFFFFFFFF Predeterminado: Ox2ee (750 en decimal) Presente predeterminado: No Aunque podra parecer una buena idea reducir el nmero de difusiones, si se reduce a uno, o se hace demasiado pequeo el intervalo, podra aumentar la posibilidad de que un servidor WINS ocupado no responda lo suficientemente rpido. En ese caso, el cliente fallar al resolver el nombre para el sistema que de otra forma podra haber respondido (usando los valores predeterminados).
Cach de nombres de NetBIOS

Para minimizar el uso de la Solicitud de resolucin de nombre de WINS, los clientes de WINS utilizan una cach de nombres de NetBIOS para guardar los nombres de NetBIOS resueltos recientemente. Si un cliente necesita resolver un nombre de NetBIOS, examinar esta cach antes de transmitir una Solicitud de resolucin de nombre. De forma predeterminada, la cach de nombres de NetBIOS guarda 16 resoluciones, que probablemente resulte apropiado para la mayora de los equipos. Las entradas de la cach se guardan durante 10 minutos, aunque modifique este valor de plazo. Si un cliente resuelve ms nombres de NetBIOS que los que pueden mantener la cach, se descartan las entradas ms antiguas y se aade el nuevo nombre, y su direccin de IP, a la cach de nombres. Se puede configurar la cach de nombres para que tenga uno de los siguientes tamaos:
q q q
Small (pequea). Guarda 16 entradas (es el valor predeterminado). Medium (media). Guarda 128 entradas. Large (grande). Guarda 256 entradas.
Use la siguiente entrada del registro para modificar el tamao de la cach de nombres de NetBIOS: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters Nombre del valor: Size/Small/Medium/Large Tipo de valor: REG_DWORD Rango vlido: 1, 2, 3 (pequea, media, grande) Predeterminado: 1 (pequeo) Presente predeterminado: No De forma predeterminada, las entradas de la cach de nombre de NetBIOS cumplen su plazo y se eliminan tras 10 minutos. Para ajustar este plazo, use la siguiente entrada del registro:
Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters Nombre de valor: CacheTimeout Tipo de valor: REG_DWORD Rango vlido: 60000-OxFFFFFFFF Predeterminado: Ox927c0 (600000 milisegundos = 10 minutos) Presente predeterminado: No El valor mantiene el tiempo, en milisegundos, para los que se hace cach de la bsqueda de NetBIOS. Se puede utilizar el comando NBTSTAT -c desde el indicativo de comandos de Windows 2000 para ver las entradas de la cach local de nombres de NetBIOS. Al aumentar el tamao de la cach de nombres de NetBIOS y aumentar el valor del plazo de la cach se puede reducir el nmero de bsquedas que se realiza contra un servidor ocupado. En muchos entornos con un gran grupo de direcciones de IP estticas para todos los servidores clave, este cambio podra ser apropiado. Sin embargo, al realizar este cambio, tambin aumenta la probabilidad de que una entrada en la cach ya no sea la precisa, lo que podra ocurrir en una red de TCP/IP muy dinmica. Esta contrapartida entre precisin y cantidad de trfico de bsqueda se debera considerar cuidadosamente y comprobarlo mediante la Liberacin de nombres.
Liberacin de nombre
Si los recursos de la red se liberan apropiadamente, ya no puede defender el nombre, y el recurso realiza una liberacin de nombre. Para los clientes Nodo B se realiza, simplemente, dejando la defensa de nombre del nombre liberado. Para los clientes Nodo P, la liberacin del nombre se realiza enviando un mensaje de Liberacin de nombre al servidor de WINS.
Proxy de WINS
Los clientes de NetBIOS de terceros, o los antiguos, puede que se configuren para utilizar WINS. En su lugar deberan confiar en el comportamiento del Nodo B. Para ofrecer a estos clientes un uso de los recursos de un servidor WINS, utilice un proxy de WINS, que es un cliente de WINS que se puede configurar para que acte por otros equipos que no pueden utilizar WINS. Un proxy de WINS tambin se puede utilizar durante la migracin desde un entorno de difusin a un entorno de WINS. Se puede configurar un servidor de WINS y un proxy WINS, y despus migrar los sistemas uno a uno sin afectar a la resolucin de nombre de los sistemas que no se hayan convertido. Las funciones del proxy de WINS son las siguientes:
q
Cuando un cliente de WINS Nodo B registra un nombre de NetBIOS, el proxy de WINS realiza una bsqueda de nombre, primero utilizando la cach de nombres de NetBIOS y, si fuese necesario, enviando una Solicitud de resolucin de nombre al servidor de WINS. Si se encuentra el nombre, el proxy enva de vuelta una Respuesta de registro de nombre negativa al cliente de Nodo B que intenta registrar el nombre. Cuando un cliente Nodo B libera su nombre, el proxy simplemente elimina el nombre del cliente de su cach de nombres y enva una liberacin de nombre al servidor de WINS. Cuando un cliente Nodo B difunde una resolucin de nombre, el proxy intenta resolver del nombre, primero utilizando la informacin local de su cach para los nombres remotos o enviando una solicitud de resolucin de nombre al servidor de WINS. Si la bsqueda de nombres se consigue, el proxy enva una Respuesta de solicitud de nombre. Si no se consigue, el proxy enva una Respuesta de solicitud de nombre negativa.
Puede configurar el sistema para actuar como un proxy de WINS para los clientes Nodo B en la subred local editando la siguiente entrada del registro:
Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters \Interfaces \<interfaz> Nombre de valor: EnableProxy Tipo de valor: REG_DWORD-Boolean Rango vlido: 0, 1 (Falso, Cierto) Predeterminado: 0 (Falso) Presente predeterminado: No Al configurar esta entrada al valor 0x1 activa el sistema para actuar como servidor de nombre proxy para las redes a las que est conectada NetBIOS sobre TCP/IP, o a la interfaz elegida. Un servidor de nombre proxy de WINS escucha las Solicitudes de resolucin de nombres de difusin, los resuelve utilizando WINS (o la cach de nombres de NetBIOS del proxy) y difunde el resultado de vuelta al cliente. El proxy de WINS proporciona a los clientes de WINS Nodo B con la capacidad de interoperar con los servidores WINS. Los servidores de Windows 2000 que ejecutan la funcin Comparticin de conexin (NAT) del Servicio Enrutamiento y acceso remoto tambin se pueden configurar para que acten como proxy de WINS los clientes de la red privada.
Entradas de la base de datos de WINS

Cuando se registra, o libera, un nombre, el servidor de WINS actualiza su base de datos interna. Una entrada de la base de datos de WINS guarda el nombre de los recursos de la red, sus direcciones de IP asociadas, el TTL y el nmero de versin. El nmero de versin es la base para la replicacin de servidor WINS.
Replicacin de servidor de WINS

En grandes redes de empresa no se recomienda tener un nico servidor de WINS. Con un nico servidor dando el servicio a un gran nmero de clientes representara un nico punto de errores. Para proporcionar redundancia, equilibrio de carga y escalabilidad y reducir el trfico de WAN involucrado con las opciones de solicitud de nombre y Registro de nombres, los servidores de WINS se pueden configurar para la replicacin, que replica las entradas de la base de datos de WINS de un servidor a otro. La replicacin de servidor de WINS permite a un equipo cliente de WINS registrar los nombres de NetBIOS en un servidor de WINS, y disponer dicho servidor de WINS replicar los nombres, de forma que estn disponibles a todos los servidores de WINS, y a todos los clientes de WINS de una organizacin. Ello puede acelerar la resolucin de nombres de los clientes, ya que se evita el uso de enlaces de WAN en las solicitudes de WINS. Para que un servidor de WINS replique su informacin, el servidor debe configurarse al menos con otro servidor de WINS como asociado de replicacin. Los asociados de replicacin de WINS replican los nombres que conoce un servidor en el resto de servidores asociados. Existen dos roles de replicacin para un servidor de WINS: asociado pull y asociado push.
q
Un asociado pull es un servidor WINS que recoge entradas de WINS de sus asociados configurados.

q
Un asociado push es un servidor de WINS que enva actualizaciones de las entradas WINS a sus asociados configurados.
Se recoge todo el trfico de replicacin, con un asociado solicitando actualizaciones desde uno configurado. Las diferencias principales entre los asociados push y pull es quin y cundo lanza el suceso de replicacin. Los asociados pull lanzan una actualizacin de correspondencia de nombres a direcciones de IP desde sus asociados de replicacin, bien cuando el servicio de WINS se inicia o a intervalos configurados por el administrador. Por otra parte, los asociados de push informan a los asociados configurados que realicen una actualizacin, bien porque el servicio de WINS se inicia o bien tras haber acumulado un cierto nmero de actualizaciones. Una vez el asociado ha recibido la notificacin de que existe una actualizacin, el asociado puede hacer pull de estos cambios para actualizar su base de datos WINS local. La topologa de replicacin de WINS en una organizacin la determina el administrador de acuerdo con las necesidades de la resolucin de nombres de NetBIOS. La replicacin involucra a pares de servidores replicando uno del otro, lo que puede generar trfico de WAN. Microsoft recomienda realizar toda la replicacin como push/pull, que es un buen valor predeterminado, especialmente para los servidores de WINS conectados a la LAN. Cuando se replica utilizando enlaces de WAN, la replicacin pull, donde cada asociado hace un envo a intervalos predefinidos, podra ser una mejor alternativa.
Estado del adaptador

Los nodos terminales de NetBIOS pueden solicitar el estado de otro sistema. Este estado se conoce como el estado del adaptador. Se puede utilizar el comando NBTSTAT.EXE de Windows 2000 para enviar una solicitud de estado de un nodo a otro equipo, aunque devolver slo los nombres de NetBIOS que pertenecen al equipo remoto. En la RFC 1002 se define un cierto nmero de estadsticas que se devuelve en un mensaje Estado del adaptador, pero no se muestran con NBTSTAT.EXE.
Instalacin y configuracin de un servidor WINS

WINS es una parte esencial de cualquier red grande basada en NetBIOS. Proporciona el equivalente a un servidor DNS para el espacio de nombres NetBIOS: los servidores WINS asignan direcciones IP a los nombres NetBIOS utilizando la base de datos dinmica de WINS para llamar a los registros de nombres apropiados. Sin embargo, WINS y NetBIOS juntos estn en vas de extincin, lentamente, quizs, pero de forma inexorable. A causa de su naturaleza propietaria y tendente a fallar, las funciones del servidor WINS sern reemplazadas por servidores DNS a medida que los clientes que requieren soporte NetBIOS vayan desapareciendo. Aunque los clientes UNIX y los clientes de otros sistemas operativos se han apoyado exclusivamente en el DNS para la resolucin de nombres desde hace tiempo, Windows 2000 es el primer sistema operativo de Microsoft que no necesita soporte NetBIOS para el trabajo en red. De este modo, se producir un perodo de transicin significativo antes de que se pueda empezar a desechar esos servidores WINS porque los clientes Windows 95/98, Windows NT e incluso MS-DOS/Windows 3.x resistirn durante algn tiempo.
Determinacin de la necesidad de WINS

Muchas redes grandes necesitarn WINS para proporcionar resolucin de nombres NetBIOS para sus clientes Windows. Sin embargo existen dos casos en los que no se necesitan servidores WINS:
q
Todos los clientes de la red soportan resolucin de nombres por medio de otro mtodo. Windows 2000 es el primer sistema operativo de Microsoft que se puede basar nicamente en el DNS para la resolucin de nombres, por lo que, a menos que todos los
clientes Windows estn ejecutando Windows 2000, es necesario WINS. Si se tiene un entorno mixto con otros clientes como clientes UNIX, hay que asegurarse de que todos ellos estn configurados adecuadamente para utilizar DNS. La red es pequea y no hay subredes. Si toda la red consiste en un nico segmento de red, los clientes que requieren resolucin de nombres NetBIOS puede resolver nombres NetBIOS de forma efectiva mediante difusin, una tcnica que no funciona a travs de enrutadores o en grandes redes donde las difusiones NetBIOS generaran muchsimo trfico de red.
Adems, antes de implementar WINS en la red, se debera ser consciente de los clientes WINS que son soportados por el WINS de Windows 2000. OS/2 con LAN Manager versin 2.2c no es soportado como cliente WINS, pero el servidor WINS de Windows 2000 soporta los siguientes sistemas operativos como clientes WINS:
q q q q q q
Windows 2000. Windows NT 3.5 o posterior. Windows 95 o posterior. Windows para Trabajo en grupo 3.11 con TCP/IP 32, incluido en el CD de Windows 2000. MS-DOS con Cliente de redes Microsoft versin 3, incluido en el CD de Windows 2000. MS-DOS con LAN Manager versin 2.2c, incluido en el CD de Windows 2000.
No hay solucin en WINS para los clientes no WINS a menos que se aadan entradas estticas para ellos. Se desaconseja encarecidamente esta prctica; no se debera utilizar a menos que sea absolutamente necesario porque las entradas estticas sean extremadamente difciles de eliminar de la base de datos WINS despus de que tenga lugar la rplica. En lugar de eso, se deberan configurar los clientes para que utilicen DNS para resolver nombres que no se encuentren en la base de datos WINS.
Configuracin del servidor para prepararlo para WINS

La causa ms comn de problemas con WINS es una configuracin no apropiada de TCP/IP en el servidor. Hay que seguir los pasos proporcionados aqu para configurar los parmetros TCP/IP para el servidor WINS adecuadamente antes de instalar el servicio: 1. Pulsar con el botn derecho del ratn en Conexin de rea local en la carpeta Conexiones de red y de acceso telefnico, y escoger Propiedades en el men contextual.
2. Seleccionar el componente Protocolo Internet (TCP/ IP) y escoger Propiedades. 3. Configurar el servidor para que utilice una direccin IP esttica o asegurarse de que se ha configurado una reserva de direccin para el servidor en el servidor DHCP 4. Pulsar Avanzada y pulsar despus WINS. 5. Seleccionar cualquier servidor WINS que aparezca en la lista de la ficha y pulsar Quitar. No hacer esto puede provocar que el servidor WINS registre su propia direccin en otro servidor WINS en lugar de en l mismo, lo que no es deseable. 6. Pulsar Agregar e insertar la direccin IP del propio servidor. 7. Deberemos configurar tambin las siguientes opciones:
r
Habilitar la bsqueda de LMHOSTS: Para habilitar el uso de un archivo LMHOSTS para asignar direcciones IP a nombres NetBIOS, hay que seleccionar la casilla de verificacin Habilitar la bsqueda de LMHOSTS y pulsar el botn Importar LMHOSTS para importar un archivo LMHOSTS. Se recomienda no utilizar archivos LMHOSTS a menos que sea absolutamente necesario dado que tratar de mantenerlos actualizados puede ser difcil: la minscula reduccin del trfico de red que ofrecen los archivos LMHOSTS no compensa. Cuando se configura un servidor WINS hay que utilizar el comando Ipconfig en el smbolo del sistema para obtener la direccin IP actual e introducir entonces esa direccin en el campo Direcciones WINS. No se debe introducir ningn otro servidor WINS en este campo; no es deseable que el servidor WINS registre su nombre NetBIOS en otro servidor WINS si el servicio WINS no se ha iniciado a tiempo para responder en el inicio.
Habilitar NetBIOS sobre TCP/IP: Lo ms probable es que sea necesario comunicarse con clientes que ejecutan sistemas operativos de Microsoft anteriores a Windows 2000, por lo que conviene asegurarse de que esta opcin est seleccionada. Deshabilitar NetBIOS sobre TCP/IP: Slo hay que desactivarla si hay comunicacin exclusivamente con otros equipos que ejecutan Windows 2000 o equipos que se basan nicamente en DNS para los servicios de resolucin de nombres (por ejemplo, UNIX). Adems, conviene observar que cualquier aplicacin que utilice NetBIOS no funcionar si se desactiva NetBIOS sobre TCP/ IP. Usar configuracin NetBIOS del servidor DHCP: Cuando se obtiene una direccin IP a travs de DHCP, esta opcin est seleccionada de forma predeterminada para que el equipo utilice la configuracin NetBT proporcionada opcionalmente por el servidor DHCP y la configuracin mediante DHCP. Slo hay
que seleccionar esta opcin si la red tiene un servidor DHCP que configure completamente el equipo y proporcione la configuracin NetBIOS correcta.
Instalacin de WINS
Cuando los parmetros TCP/IP sean correctos, se podr instalar el componente WINS. Para hacer esto es necesario utilizar el Asistente para componentes de Windows, accesible tanto desde la herramienta Configurar el servidor como desde Agregar o quitar programas del Panel de control y seguir estos pasos para instalar WINS.
1.
Abrir Agregar o quitar programas del Panel de control y pulsar el icono Agregar o quitar componentes de Windows en el marco de la izquierda para ejecutar el Asistente para componentes de Windows. 2. Pulsar Siguiente, seleccionar Servicios de red en la lista de componentes y pulsar Detalles. 3. Seleccionar la casilla de verificacin del componente Servicio WINS, pulsar Aceptar y pulsar despus Siguiente. No se debe instalar WINS en un servidor multihusped. Se puede hacer y funcionar, pero puede provocar horribles problemas de rplica, especialmente si el servidor est en dos subredes diferentes.
Adicin de asociados de rplica

Los servidores WINS son extremadamente fciles de configurar y requieren poca administracin, excepto por los asociados de rplica. La rplica de WINS es un asunto importante y un tanto delicado que se debera examinar detenidamente antes de configurarlo. Conviene implantar los menos servidores WINS posibles para minimizar las migraas a causa de la administracin. Para instalar un asociado de rplica y configurar sus parmetros despus de planificar la implantacin de WINS, hay que seguir estos pasos: 1. Abrir WINS desde la carpeta Herramientas administrativas y, en el rbol de la consola, expandir el servidor WINS para el que se desea configurar la rplica.
2. 3. 4. 5. 6. 7. 8. 9.
Seleccionar la carpeta Asociados de rplica y escoger Nuevo asociado de rplica en el men Accin. Introducir la direccin IP del servidor WINS con el que se desea activar la rplica y pulsar Aceptar. Para modificar los parmetros de la rplica del nuevo asociado de rplica, si es necesario, hay que pulsar dos veces en el servidor en la carpeta Asociados de rplica y pulsar despus la pestaa Avanzadas. Para modificar la forma de la rplica con el servidor, hay que escoger una opcin del cuadro de lista desplegable Tipo de asociado de rplica. Para configurar una conexin permanente para extraer o insertar rplica, hay que seleccionar la casilla de verificacin Usar conexin persistente para rplica en la seccin Activar rplica de insercin, en la seccin Activar rplica de extraccin o en ambas. En los campos Hora de inicio, hay que introducir el momento en el que se desea que comience la rplica de extraccin en horas, minutos y segundos. En los campos Intervalo de rplica, hay que introducir la frecuencia -das, horas y minutos- con la que se desea hacer rplicas con el asociado de rplica. Se puede utilizar el cuadro Nmero de cambios para introducir el nmero de cambios de la copia local de la base de datos del WINS que se permitirn antes de que el servidor deba insertar los cambios en el asociado de rplica. Se recomienda el uso de rplica insercin/extraccin en todo el espacio de nombres WINS para facilitar la solucin de los problemas de rplica. Adems, los servidores WINS principal y de copia de seguridad deben utilizar rplica insercin/ extraccin.
Funcionamiento de WINS
Para comprender cmo funciona WINS, hay que comprender cmo funcionan los clientes de WINS y cmo funciona NBT, en general.
Registro de los nombres de NetBIOS

El proceso de registro y renovacin de los nombres de NetBIOS por un nodo depende del tipo de nodo de NetBIOS configurado en el nodo terminal. En general, un nodo terminal que desee registrar un nombre de NetBIOS enva una Solicitud de registro de nombre para realizarlo. Una vez registrado el nombre, el resto de equipos puede resolver el nombre y utilizar la direccin de IP resultado para comunicarse con dicho nodo terminal. Cuando se termina, normalmente la red libera el nombre.
Solicitud de registro de nombre

Cuando se inicia un elemento de red, intenta registrar los nombres de NetBIOS relacionados. El elemento de red enva una Solicitud de registro de nombre de NetBIOS, dependiendo del tipo de nodo, de la siguiente forma:
Nodo B. Cuando un cliente Nodo B registra un nombre, difunde el paquete de registro por la red local. Si el nombre ya se encuentra utilizado por otro nodo, el propietario del mismo enva una Respuesta de registro de nombre negativa. Un cliente Nodo B que no recibe una Respuesta de registro de nombre negativa considera que es l mismo el propietario del nombre y lleva a cabo la defensa de nombre del mismo. Nodo P. Cuando un cliente Nodo P registra un nombre, enva un paquete unicast con el nombre al servidor WINS configurado. Si el nombre que desea registrar ya estaba registrado, el servidor WINS intenta ponerse en contacto con su propietario para comprobar si se est utilizando activamente. Si el nombre an se est utilizando, el servidor WINS enva una Respuesta de registro de nombre negativa al cliente; si el nombre ya no est en uso, el servidor WINS enva una Respuesta de registro de nombre positiva. El servidor WINS tambin puede que enve al cliente que intenta registrar el nombre mensajes de Asentimiento de espera. Estos mensajes indican que el servidor WINS an est intentando determinar si el nombre se puede registrar con seguridad. Nodo M. Un cliente Nodo M intenta registrar el nombre usando difusin, como el cliente Nodo B. Si no existe ninguna objecin, el cliente intenta registrar el nombre usando el comportamiento del Nodo P y un servidor WINS. Aunque con la difusin podra conseguir el propietario del nombre y, por tanto, terminara el proceso de registro del nombre, es insuficiente para determinar su propietario. Nodo H. Un cliente Nodo H de Windows 2000 registra el nombre usando WINS. Si lo consigue, el cliente registrado asume la propiedad del nombre.
Respuesta de registro de nombre positivo

Las respuestas de registro de nombre positivos se envan de un servidor WINS a un cliente WINS tras un registro completo del nombre de NetBIOS. Si un cliente de WINS enva a un servidor de WINS una solicitud de registro de un nico nombre y dicho nombre no se haba registrado, el servidor de WINS lo registrar y enviar un mensaje Registro de nombre positivo al equipo que registr el nombre. Los equipos que envan la solicitud de registro de nombre de NetBIOS mediante difusin, como los clientes Nodo B, no recibirn una Respuesta de registro de nombre positivo. Si un cliente de WINS enva a un servidor de WINS una solicitud para registrar un nombre de grupo, el servidor WINS siempre enviar una Respuesta de registro de nombre positivo. Los clientes Nodo B envan el Registro de nombre de NetBIOS. El cliente Nodo B difunde varios mensajes de Registro de nombre, y si no recibe Respuestas de registro de nombre negativas, se supone el propietario del nombre de NetBIOS.
Respuesta de registro de nombre negativo

Un servidor WINS que recibe una solicitud de registro de un nombre nico de NetBIOS que ya est registrado debera rechazar la solicitud enviando un mensaje de Respuesta de registro de nombre negativo, suponiendo que el nodo terminal propietario es capaz de defenderlo. Antes de enviar la Respuesta negativa, el servidor WINS lo comprueba con el propietario actual para determinar si an sigue activo. Esta situacin podra ocurrir, por ejemplo, si se traslada un porttil a otra subred, o, por alguna razn, se reconfigura para que tenga una nueva direccin de IP. Un equipo que enva una solicitud de registro de nombre de NetBIOS mediante difusin, por ejemplo un cliente Nodo B, tambin recibe una Respuesta de registro de nombre negativo si otro equipo activo en la subred es el propietario del nombre. Un equipo que registra un nombre de NetBIOS con WINS enva los mensajes de solicitud de registro como unicast; el servidor WINS enva un mensaje de Respuesta de nombre negativo si otro nodo terminal de la red haba registrado anteriormente el nombre a registrar, y dicho nodo puede defender el nombre.
Asentimiento de espera
Si un servidor WINS recibe una solicitud de registro de un nombre nico de NetBIOS que ya est registrado, comprueba el nombre con el propietario registrado. En este caso, podra enviar mensajes de Asentimiento de espera al equipo que intenta registrar el nombre. El objeto de estos mensajes es informar al cliente que el servidor puede que todava no sea capaz de determinar
una respuesta de nombre. Para indicar al cliente que el servidor no ha fallado y sigue realizando las operaciones del servicio de nombre, el servidor WINS enva un mensaje de Asentimiento de espera si no puede responder a la solicitud pasado cierto tiempo. El servidor WINS tiene que ponerse en contacto con otro sistema y enva un Asentimiento de espera mientras consigue este contacto.
Solicitud de renovacin de nombre

Los nombres de NetBIOS registrados con un servidor de WINS tienen vida limitada y hay que refrescarlos antes de que su vida expire. El valor predeterminado para el TTL de las entradas de nombre de NetBIOS en WINS es de 6 das, pero el administrador puede modificarlo a cualquier plazo entre 1 minuto y 365 das. Cuando un nodo terminal registra un nombre de NetBIOS con un servidor WINS, el nodo recibe una Respuesta de nombre positiva que contiene el TTL para dicho nombre. Como con los clientes de DHCP, un cliente de WINS intenta renovar todos los nombres de NetBIOS que guarda a la mitad del TTL, es decir, cada 3 das. Adems, cada vez que se inicia el equipo o se reinicia el servicio de nombre de NetBIOS que registra el servicio de Windows, se enva un nuevo mensaje Registro de nombre al servidor de WINS, renovando el nombre (suponiendo, claro est, que el servidor de WINS haya realizado el registro oportuno).
Resolucin de conflictos de Registro de nombre de NetBIOS

Ocurre un conflicto de nombres cuando dos o ms nodos terminales quieren registrar el mismo nombre de NetBIOS nico. En la mayor parte de los casos se debe a errores de configuracin como puede ser haber dado a dos equipos el mismo nombre o haber configurado incorrectamente el servicio. Cuando dos equipos intentan registrar un nombre nico de NetBIOS, el segundo nodo terminal que intenta registrarlo falla, generando un error de registro.
Liberacin de nombres de NetBIOS

Un nombre se puede liberar de dos formas: activa o silenciosamente. Un equipo con Windows 2000 configurado para utilizar WINS libera cualquier nombre de NetBIOS enviando al servidor de WINS un mensaje de Liberacin de nombre que contenga el nombre de NetBIOS a liberar. Por otra parte, un nodo que falla al intentar renovar el nombre, despus de expirar el TTL del nombre, dicho nombre est disponible para que cualquier otro nodo lo utilice. En Windows 2000, el comando NBTSTAT.EXE, con la opcin -RR, libera todos los nombres de NetBIOS registrados actualmente, y luego vuelve a registrarlos. Puede ser til para diagnstico.
Solicitud de liberacin de nombre y Respuesta de liberacin de nombre

Cuando un nodo terminal quiere liberar un nombre registrado de NetBIOS, dicho nodo enva un mensaje solicitud de liberacin de nombre al servidor de WINS. El servidor de WINS enva de vuelta una Respuesta de liberacin de nombre. Normalmente, la respuesta de liberacin tiene un cdigo de 0, indicando que el nombre se ha liberado. En teora se podra enviar un mensaje de Liberacin de nombre negativo, aunque el nodo terminal que envi la solicitud de liberacin lo ignorara.
Resolucin de nombres de NetBIOS

Cuando un equipo con Windows 2000 necesita resolver un nombre de NetBIOS, enva una solicitud de peticin de nombre, mediante difusin o enviando la solicitud directamente al servidor de WINS, dependiendo del tipo de nodo. Si la solicitud de nombre se enva al servidor de WINS y el propio servidor puede resolverlo, el servidor enva una Respuesta de solicitud de nombre al equipo que envi la solicitud. Si el servidor de WINS no puede resolver el nombre,
enva una Respuesta de solicitud de nombre negativa. Si el equipo que realiza la resolucin de nombres utiliza el comportamiento de un Nodo B, enviar una solicitud de peticin de nombre; y si el nodo que es dueo del nombre se encuentra en la subred local, responder. Sin embargo, si no se encuentra en la subred local puede llevar ms tiempo que conseguir una Respuesta de solicitud de nombre negativa de un servidor de WINS.
Solicitud de peticin de nombre

Un mensaje de Solicitud de nombre contiene el nombre de NetBIOS a resolver y se enva bien a la red local o a un servidor de WINS, o a ambos, dependiendo del tipo de nodo de NetBIOS. Si en nodo terminal usa difusin para descubrir el nombre, enva tres difusiones antes de fallar. Cuando un usuario realiza alguna operacin en un equipo con Windows 2000 usando nombres, como cuando se escribe NET VIEW \\XXX en el indicativo del sistema, o escribiendo \\XXX en un cuadro de entrada de Direccin del Explorer, no siempre est claro qu tipo de nombre se resuelve: nombre de host o nombre de NetBIOS. Ni tampoco es obvio qu mtodo de resolucin de nombres obtendr el resultado ms rpidamente. En Windows NT 4.0, el sistema operativo intentaba primero una resolucin de nombre, como la resolucin NetBIOS o la resolucin de nombre de host, y si no lo consegua intentaba con el otro mtodo. Esto generaba retardos si se elega el mtodo equivocado. Para reducir el retraso, Windows 2000 intenta resolver los nombres usando ambos mtodos simultneamente.
Repuesta de Solicitud de nombre positiva

Cuando un host de NetBIOS o un servidor de WINS recibe una Solicitud de peticin de nombre para un nombre de NetBIOS que puede resolver, el sistema le devuelve una Respuesta de solicitud de nombre. Dicha respuesta tiene un cdigo de retorno a 0x0, lo que indica que la resolucin se ha realizado, y se incluye un RR con la direccin de IP del sistema propietario del nombre. Si el nombre solicitado es un nombre nico, slo se devuelve una direccin de IP. Si el nombre solicitado es un nombre de grupo, se devuelve una o ms direcciones de IP.
Respuesta de solicitud de nombre negativa

Cuando un servidor de WINS recibe una Solicitud de peticin de nombre para un nombre de NetBIOS que no se puede resolver, el servidor de WINS devuelve una Respuesta de solicitud de nombre negativa. Esta respuesta negativa tiene un cdigo de retorno que indica que el nombre solicitado no existe.
Refresco de los nombres de NetBIOS

Cada nombre de NetBIOS registrado tiene un TTL. Si el propietario del nodo desea seguir utilizando el nombre de NetBIOS, debe refrescar el nombre antes de que expire el TTL. Para los nombres registrados con WINS, el valor de TTL lo configure el administrador. Los equipos con Windows 2000 intentarn registrar el nombre a intervalos de la mitad del TTL.
Determinacin del estado del adaptador

En las RFC 1001 y 1002 se proporciona un mecanismo para que un nodo pueda determinar el estado de un adaptador local o remoto de otro nodo terminal. La informacin de estado del adaptador incluye los nombres registrados de NetBIOS en el nodo terminal y distintas estadsticas. En Windows 2000 se puede utilizar el comando NBTSTAT.EXE, con la opcin -A o -a para obtener el estado del adaptador de NetBIOS del equipo remoto. Sin embargo, si el host remoto tiene desactivado el NBT, este comando falla.
Volver al principio del Tema
En los principios de la informtica personal, IBM y Microsoft usaban NetBIOS para proporcionar a los programadores y aplicaciones acceso a las funciones y capacidades de red. NetBIOS se desarroll originalmente para IBM por Sytek Corporation como extensin a la BIOS, que una aplicacin poda utilizar haciendo llamadas a la BIOS. En Microsoft Windows 2000, NetBIOS es tanto una interfaz de red independiente de transporte como un protocolo de administracin de sesin y de transporte de datos. NetBIOS puede funcionar sobre cualquiera de los protocolos de transporte de red de Windows 2000, incluyendo NetBEUI, NWLink (IPX) y TCP/IP. Las aplicaciones que utilizan NetBIOS pueden funcionar con cualquiera de los protocolos de transporte configurados. Los clientes de interconexin de Windows tradicionalmente han utilizado NetBIOS para distintas funciones, entre ellas la comparticin de archivos a impresoras y la exploracin. Las RFC 1001 y 1002 definen las funciones y caractersticas de un servicio de NetBIOS sobre el transporte de TCP/ UDP, tambin conocido como NetBIOS sobre TCP/IP (NBT). Estas RFC, publicadas en 1987, describen los siguientes tres servicios principales para las aplicaciones de NetBIOS que se ejecuten en TCP/IP:
q
Servicio de nombres. Proporciona a los equipos la capacidad de adquirir, defender nombres de NetBIOS y localizar quin guarda dichos nombres. Servicio de sesin. Proporciona un intercambio fiable de mensajes entre dos pares de aplicaciones de NetBIOS. Servicio de datagramas. Proporciona un servicio de paso de mensajes no fiable, sin consecuencias, sin conexin, para aplicaciones NetBIOS.
Los servicios de sesin y datagramas de NetBEUI permiten a las aplicaciones de NetBIOS enviar mensajes entre ellas utilizando equipos individuales con nombres de NetBIOS. El servicio de nombres de NetBIOS proporciona la capacidad adquirir/registrar un nombre, localizar equipos con un nombre concreto y resolver un nombre de NetBIOS dada su direccin de IP. WINS es un servidor de nombres de NetBIOS que puede usar un cliente para registrar, defender y buscar nombres de NetBIOS. WINS proporciona varias ventajas a una organizacin:
q q q
Funciones de registro de nombre y resolucin de nombres para equipos con NetBIOS. Mantenimiento dinmico de la base de datos para disponer de registro y resolucin de nombres de equipo. Administracin centralizada de una base de datos de nombres de NetBIOS escalable.
WINS implementa las caractersticas del servicio de nombres de un servidor de nombres de NetBIOS definidas en las RFC 1001 y 1002. Sin embargo, para crecer apropiadamente para redes grandes, WINS tambin proporciona funciones de replicacin. En las versiones iniciales de Microsoft Windows NT, WINS jug un papel crtico en la localizacin de servicios, particularmente en los servicios de directorio de Windows NT. Los clientes utilizaban NetBIOS para localizar los Controladores de dominio de Windows NT 4.0. Se usaban los servicios de sesin y datagramas de NetBIOS como base para las operaciones de directorio. La comparticin de archivos e impresoras tambin usan NetBIOS. Una organizacin que slo usa equipos con Windows 2000 o una mezcla de equipos con Windows 2000 y sistemas operativos de terceros como UNIX y cuyas aplicaciones disponen del Sistema de nombre de dominio (DNS), puede eliminar NetBIOS y no tener necesidad de WINS. Sin embargo, significa que cualquier aplicacin que use NetBIOS, como el explorador del equipo, no funcionar. La mayora de las organizaciones, sin embargo, necesitan mantener equipos antiguos, que requieren los nombres de red de NetBIOS. En este apartado se incluyen los equipos con Microsoft Windows para trabajo en grupo, Microsoft Windows 95, Microsoft Windows 98 y todas las versiones de Windows NT. Las organizaciones con equipos con estos sistemas operativos vern que WINS es un servicio importante para el desarrollo de Windows 2000.
Descripcin general de WINS en Windows 2000

En Windows 2000, WINS consta de dos componentes: el Servicio de nombres de Internet de Windows, WINS (Windows Internet Nombre Servicio), y un servicio cliente de WINS. WINS es un servidor de nombres de NetBIOS que permite a un cliente registrar nombres de NetBIOS en una base de datos central y resolver nombres de NetBIOS a direcciones de IP. El cliente del WINS utiliza el servidor del WINS para registrar nombres y proporcionar funciones de resolucin de nombres, convirtiendo nombres de NetBIOS en direcciones de IP. En trminos funcionales, WINS es muy parecido a DNS, con clientes que registran nombres y realizan bsquedas de los nombres y servidores que manejan los registros y la resolucin. La diferencia ms importante es que WINS utiliza nombres de NetBIOS en lugar de nombres de host de DNS. En las RFC 1001 y 1002 se definen las funciones del servidor de nombres de NetBIOS con detalle. A este respecto, el servidor de WINS es un servidor de nombres de NetBIOS que cumple la RFC para proporcionar funciones de registro de nombres y resolucin de nombres. El servidor de WINS es escalable, capaz de funcionar correctamente en redes de cualquier tamao. Todos los servidores con Windows 2000, incluyendo Server, Advanced Server y Datacenter Server, incluyen el servicio WINS, aunque no se instala de manera predeterminada. Todos los clientes de Windows incluyen un cliente de WINS, entre ellos Windows 2000, Windows NT 4.0, Windows 98 y Windows 95. Para los clientes con Windows 2000, la funcin cliente de WINS se instala automticamente.
Trminos clave de WINS

En Windows 2000, NetBIOS es tanto una interfaz de red, que permite a las aplicaciones y componentes clave del sistema comunicarse por la red, como un protocolo que permite dicha comunicacin. Entre los procesos del sistema que utilizan NetBIOS estn el servicio de comparticin de archivos de Windows y el servicio de exploracin de equipos.
Recursos de red y nodos terminales

Para que las aplicaciones interoperen y los usuarios accedan a recursos clave, todos los recursos de la red necesitan un nombre. Un recurso de red es un proceso que se ejecuta en un equipo concreto. Puede ser un servicio Servidor ejecutndose en el equipo Servidor de intercambio, o un servicio Servidor ejecutando en un servidor de archivos. El equipo concreto que ejecuta el proceso recurso de red se denomina equipo terminal.
Nombres de NetBIOS
Todos los recursos de la red en Windows 2000 tienen un nombre NetBIOS. En Windows 2000, todos los nombres NetBIOS pueden tener hasta 15 caracteres. El ltimo, el decimosexto, permitido en las RFC 1001 y 1002, se reserva como sufijo del nombre NetBIOS. El nombre NetBIOS no puede empezar con un <*> y no son sensibles a las maysculas. El espacio de nombres de NetBIOS es plano, al contrario que DNS, que es jerrquico. Significa que un nombre NetBIOS slo se puede usar una vez en una red. Dos equipos que ejecuten el servicio Server no pueden tener el mismo nombre. Esto puede llevar a algunos problemas en organizaciones muy grandes y es donde el parmetro mbito de NetBIOS ofrece una solucin.
Tipos de nombres de NetBIOS

Un nombre de NetBIOS puede ser un nombre nico, que lo posee un nico nodo o puede formar parte de un grupo de Internet, que puede incluir varios nodos terminales (end-nodes). Todos los equipos con Windows 2000 tienen un
servicio Server y un servicio Workstation para comparticin de archivos. Estos servicios deberan tener nombres nicos de NetBIOS. Cuando se resuelve una direccin de NetBIOS a una direccin de IP, los nombre nicos se resuelven a una nica direccin de IP, mientras que las direcciones de grupos de Internet se resuelven a varias direcciones.
Sufijo del nombre de NetBIOS

Aunque las RFC 1001 y 1002 permiten que los nombres de NetBIOS tengan 16 caracteres, el decimosexto carcter del nombre de NetBIOS de Windows se reserva para un sufijo especial. El sufijo del nombre de NetBIOS lo usa todo el software de red de Windows para identificar la funcionalidad instalada en el dispositivo registrado. De esta forma un nodo terminal puede registrar varios nombres segn el equipo, dominio, o nombre de usuario, y un sufijo para indicar los servicios disponibles en dicha mquina. Los clientes de WINS pueden construir un nombre de NetBIOS segn el equipo, el usuario, o el nombre de dominio, y el sufijo apropiado para localizar los recursos de red relevantes. Por ejemplo, el servicio Messenger (Mensajera) tiene el sufijo 0x03. Para enviar un mensaje a COMPUTER42, el cliente enviara un mensaje al servicio Workstation en Computer42, o COMPUTER42[03]. Observe que en la notacin del nombre NetBIOS de 16 caracteres completo, los primeros 9 caracteres seran COMPUTER42, los 6 siguientes seran (blanco) y el carcter final sera un 0x03. Sufijos comunes de NetBIOS utilizados en las redes Windows Nombre Sufijo NetBIOS (hex) Tipo Uso U U U U U G U G G G Servicio Workstation. Servicio de Mensajera. Servicio de Mensajera. Servicio Server. Servicio de Mensajera. Nombre de dominio. Explorador maestro del dominio. Controlador de dominio. Eleccin del servicio explorador. Explorador maestro. <nombre de equipo> 00 <nombre de equipo> 01 <nombre de equipo> 03 <nombre de equipo> 20 <nombre de usuario> 03 <dominio> <dominio> <dominio> <dominio> <..--_MSBROWSE_> 00 1B 1C 1E O1
Adems de estos nombres comnmente utilizados en Windows 2000, otras aplicaciones como Microsoft Exchange, Lotus Notes y otras tambin registran nombres de NetBIOS.
Operaciones del servicio de nombres de NetBIOS

Entre las operaciones del servicio de nombres NetBIOS se encuentran las de registro, defensa, solicitud y liberacin de nombres de NetBIOS. Adems, los servicios de sesin y datagramas de NetBIOS utilizan estas operaciones del servicio de nombres para localizar recursos. Por ejemplo, si un usuario de un equipo con Windows 2000 quisiera acceder a un sistema de archivos remoto, el usuario introduce el nombre del equipo remoto y el nombre compartido en Microsoft Explorer. Explorer usa los servicios de nombre de NetBIOS para determinar la direccin de IP del servidor remoto y a continuacin enva comandos del nivel de sesin de NetBIOS para acceder a los recursos compartidos. Las operaciones del servicio de nombres de NetBIOS se llevan a cabo por la red usando difusin de IP o un servidor de nombres de NetBIOS. El uso de difusin podra ser aceptable en redes de rea local pequeas (LAN). Sin embargo, en redes grandes el uso de la difusin podra conducir a una tormenta de difusin, lo que no es deseable.
Estas redes deberan de implantar WINS.
mbitos de NetBIOS
El espacio de nombres de NetBIOS es plano, lo que significa que todos los nombres deben ser nicos en el conjunto de redes. Si tiene un equipo llamado EQUIPO y defiende apropiadamente su nombre de equipo, ningn otro equipo de la red se puede llamar a s mismo EQUIPO. Esta limitacin puede causar dificultades en grandes organizaciones. Como se describe en la RFC 1001, una aproximacin para resolver este espacio de nombres plano es usar un cualificador adicional en el nombre NetBIOS. En la RFC 1001 se define el mbito de NetBIOS como < la poblacin de equipos en los que se conoce un nombre de NetBIOS registrado> . Para identificar el mbito de NetBIOS, se usa un identificador de mbito de NetBIOS. El identificador de mbito de NetBIOS es una cadena de caracteres, similar en formato y funcin a los nombres de dominio de DNS. El uso del mbito de NetBIOS, sin embargo, es limitado en cuanto que el usuario no puede especificar el mbito directamente. El mbito de NetBIOS en un equipo con Windows 2000 se define como parte de los parmetros de IP del equipo que se reciben del servidor de DHCP o en el registro del equipo. Por tanto, el mbito del equipo se aade automticamente a todos los nombres de NetBIOS. El efecto es que un nodo terminal con un mbito de NetBIOS dado slo se puede comunicar con otros equipos configurados con el mismo mbito de NetBIOS. Se puede establecer el mbito de NetBIOS especificando un mbito como parte del mbito de DHCP o editando el registro. La clave del registro que se utiliza para cambiar manualmente el tipo de nodo es la siguiente: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Adapters \Interface \<interfaz> Nombre del valor: ScopeId Tipo del valor: REG_SZ-Cadena de caracteres Rango del valor: Cualquier nombre vlido de dominio de DNS que consista en dos partes separadas por puntos, o un asterisco (*) Predeterminado: Ninguno Presente predeterminado: No
Tipos de nodos de NetBIOS

Para dar cabida a redes de varios tamaos de NetBIOS, las RFC 1001 y 1002 usan el concepto de tipo de nodo para determinar cmo debe manejar un equipo las funciones del servicio de nombres. El tipo de nodo define cmo se realizan las operaciones del servicio de nombres. Un nodo terminal puede pertenecer a uno de los cuatro tipos de nodos, definidos en las RFC 1001 y 1002:
q
Nodo B (Nodo de difusin, Broadcast). Usando difusin slo se realizan las operaciones de registro y
resolucin de nombres. Normalmente es la mejor opcin en una red muy pequea con una nica subred. Nodo P (Nodo punto a punto). Se usa slo el servidor de nombres de NetBIOS, (WINS) para las operaciones de registro y resolucin de nombres. Este tipo de nodo se usa para eliminar las difusiones de la subred local, pero puede ocasionar que recursos de la red en la subred local no se resuelvan. Nodo M (Nodo mixto). Una combinacin de los Nodos B y P, donde el registro y resolucin de nombres se realiza mediante difusin. Pero si la resolucin de nombres no se consigue mediante difusin, se usa el servidor de nombres de NetBIOS. Es til en los casos en los que el servidor de WINS se encuentra en una red remota, por lo que se intenta resolver localmente el nombre antes de usar recursos de WAN para resolverlo. Nodo H (Nodo hbrido). Una combinacin de los Nodos P y B, donde el registro y resolucin de nombre se hace utilizando un servidor WINS. Pero si la resolucin de nombres no se consigue mediante el servidor WINS, se usa difusin. Es el tipo de nodo predeterminado cuando se utilizan servidores WINS.
De forma predeterminada, los equipos con Windows 2000 son Nodos B. Si se configura un equipo con Windows 2000 para que use un servidor WINS, se convierte en un Nodo H. Se puede configurar el equipo para que sea un Nodo P o M editando manualmente el registro. Adems, el administrador puede establecer los parmetros del Protocolo de configuracin dinmica de host (DHCP) para determinar el tipo de nodo de un cliente de DHCP. La clave del registro que se utiliza para cambiar el tipo de nodo es la siguiente: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Adapters \Interfaces \<interfaz> Nombre de valor: NodeType Tipo de valor: REG_DWORD - Nmero Rango vlido: 1,2,4,8 (Nodo B, Nodo P, Nodo M, Nodo H) Predeterminado: 1 u 8 segn la configuracin del servidor WINS Presente predeterminado: No
Modificacin de Microsoft de los Nodos B

Como se define en las RFC 1001 y 1002, el comportamiento de los Nodos B no funciona apropiadamente para redes de ms de una nica subred. Se puede mejorar en parte configurando los enrutadores para que reenven los mensajes de difusin, pero esto no escala bien y rara vez se hace. Para superar las limitaciones inherentes Microsoft ha extendido las operaciones del servicio de nombres de los Nodos B. A estas extensiones se les conoce como Nodo B modificado, que aade las siguientes funciones de bsqueda de nombre a un Nodo B:
q
Cach de nombres de NetBIOS. Una cach en memoria de los nombres resueltos recientemente que se busca antes de intentar otros mtodos de resolucin de nombres. Archivo LMHOSTS. Un archivo plano, en la carpeta systemroot\system32\drivers\etc que contiene una lista esttica de nombres de NetBIOS y sus direcciones de IP.
Si se usa LMHOSTS por alguna razn no deseable, se puede desactivar reconfigurando los parmetros de TCP/IP del equipo.
Registro de nombre
Cuando un recurso de red est disponible para su uso -por ejemplo, cuando un servidor de archivos arranca-, el recurso de red deber registrar su nombre de NetBIOS relevante. El procedimiento de registro asegura que el nombre registrado no est ya en uso por otro equipo. Para los clientes de un Nodo P, un Nodo M o un Nodo H, el cliente tambin informa al servidor WINS del nombre y direccin de IP.
Perodo de vida (TTL)

En general, los nombres de NetBIOS no se mantienen en propiedad permanentemente. Con WINS, cada nombre que se registra correctamente tiene un perodo de vida (TTL) limitado. Cuando el TTL de un nombre de NetBIOS expira, es responsabilidad del recurso de red registrar el nombre. Si el registro de red registra el nombre con un servidor de WINS y el TTL expira, el nombre se puede eliminar del servidor WINS. Los clientes de Windows 2000 intentan registrar sus nombres de NetBIOS cuando ha transcurrido la mitad del TTL o cuando el equipo se reinicia.
Defensa de nombre
Una vez registrado, todos los nombres de NetBIOS nicos hay que defenderlos para asegurar que no hay dos recursos de red diferentes que reclamen el mismo nombre de NetBIOS. Si un equipo intenta registrar un nombre de NetBIOS que ya lo estaba utilizando otro equipo, el propietario del nombre necesita defender el nombre. Si un recurso de red descubre que el nombre que intenta registrar ya se est utilizando -por ejemplo, se inicia un equipo configurado con un nombre de equipo de otro que ya est ejecutando-, el recurso de red debera dar un error. Los procesos de Windows 2000, como el servicio Server, escribirn un suceso de error en el registro de sucesos para un posterior anlisis y solucin del problema. Si el propietario del nombre es un cliente de un Nodo B, el propietario debe aceptar la responsabilidad de defender el nombre escuchando las peticiones de registro de nombre y difundiendo una Respuesta de registro negativa. Para los clientes Nodo P, la defensa de nodo es ms complicada. Si un cliente Nodo P intenta registrar un nombre en un servidor WINS que el servidor cree estar en uso, el servidor WINS intentar en primer lugar ponerse en contacto con el equipo que registr anteriormente el nombre de NetBIOS. Si el servidor WINS consigue ponerse en contacto con el propietario registrado, el servidor enva un mensaje Registro de nombre negativo al cliente que intentaba registrar el nombre. Si, al contrario, el servidor WINS no lo consigue, enviar una respuesta Registro de nombre positivo.
Resolucin de nombre de NetBIOS

Cuando un equipo desea comunicarse con otro, mediante NetBIOS, debe determinar la direccin de IP del equipo remoto antes de establecer la comunicacin. La resolucin de nombre es el proceso de determinar la direccin de IP de un equipo por su nombre de NetBIOS. El mecanismo general que utiliza el cliente de WINS para resolver los nombres es el siguiente:
q
q q
Comprueba si el nombre se puede realmente resolver utilizando NetBIOS. Si el nombre introducido por el usuario o especificado por la aplicacin es mayor de 15 caracteres o contiene un ., se realiza la resolucin de nombre de DNS. A continuacin el cliente comprueba si el nombre se encuentra en la cach de nombres de NetBIOS. Si el equipo est configurado para utilizar LMHOSTS, se consulta en este archivo la direccin de IP del nombre.
Si el nombre no se puede resolver con otras alternativas, por ejemplo mediante DNS, o localmente, los clientes de WINS de Windows 2000 intentarn otros pasos de resolucin de nombres. Estos pasos concretos dependern del tipo de nodo de NetBIOS y de si se ha configurado un proxy de WINS de la siguiente forma:
q
Los clientes Nodo B difundirn mensajes de solicitud de nombre de NetBIOS en la subred local. Si existe un equipo con el nombre en la subred, el equipo enviar una respuesta solicitud de nombre positiva, que contiene la direccin de IP requerida. Si existe un agente de proxy de WINS en la subred cuando se difunde el mensaje de solicitud de nombre de NetBIOS y no existe respuesta, el agente proxy de NetBIOS intentar resolver el nombre por el cliente. Es un mtodo apropiado en redes pequeas, posiblemente sin servidores WINS, y es el comportamiento predeterminado para un equipo que no tiene configurado un servidor WINS. Los clientes Nodo P enviarn un mensaje de solicitud de nombre de NetBIOS al servidor WINS configurado. Si el servidor WINS tiene el nombre solicitado, enviar una Respuesta de solicitud de nombre positivo, con la direccin de IP requerida; si no, el equipo enviar una Respuesta de solicitud de nombre negativa. Si el cliente WINS no obtiene respuesta del servidor WINS y en su configuracin tiene ms servidores WINS, el cliente intentar con ellos. Este mtodo minimiza las difusiones en la red local. Los clientes Nodo M intentarn utilizar el comportamiento del Nodo B para resolver el nombre, y si no lo consiguen, los clientes Nodo M utilizarn el comportamiento de un Nodo P. Resulta particularmente til cuando el cliente se encuentra en el otro extremo de un enlace WAN, pero generar trfico de difusin adicional en la subred local. Los clientes Nodo H intentarn en primer lugar usar el comportamiento de los Nodos P para resolver el nombre, y si no lo consiguen, los clientes Nodo H intentarn usar el comportamiento de los Nodos B. Como con los Nodos P, este mtodo reduce el trfico de difusin local para los nombres que guarda el servidor WINS, pero utilizar la difusin local para intentar resolver el nombre. Los primeros clientes de WINS manejaban slo un mximo de dos servidores WINS, uno principal y uno secundario. Para obtener tolerancia a errores adicional en los equipos cliente, Windows 2000 o Windows 98 permiten especificar hasta 12 servidores WINS por cada interfaz. Estas direcciones de servidor WINS extra se utilizan slo si los servidores WINS principal y secundario no responden.
Si con ninguno de estos pasos se consigue resolver el nombre de NetBIOS, el equipo con Windows 2000 intentar utilizar la resolucin de nombres de host; primero comprueba el archivo HOSTS local y a continuacin ponindose en contacto con servidores de DNS. Si despus de todos estos pasos no se puede resolver el nombre, el equipo con Windows 2000 enva un mensaje Error al llamante. Esta serie de pasos intenta tanto proporcionar la mxima tolerancia a errores en el cliente como acomodar sistemas incorrectamente configurados. Si un equipo utiliza difusin para resolver un nombre de NetBIOS, no puede asegurar que una falta de respuesta sea significativa. Como se usa UDP como transporte en las operaciones de nombre de NetBIOS, puede que el paquete se haya descartado. Para compensar esta falta de fiabilidad, el cliente que resuelve un nombre, por defecto, difunde la solicitud de resolucin de nombre tres veces, a intervalos de 750 milisegundos entre cada intento. Para modificar el nmero de intentos de difusin se utiliza la siguiente entrada de registro: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters O Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters
\Interfaces \<interfaz> Nombre del valor: BcastNameQueryCount Tipo de valor: REG_DWORD-Nmero Rango vlido: 1-OXFFFF Predeterminado: 3 Presente predeterminado: No Utilice la siguiente entrada del registro para cambiar el intervalo entre difusiones: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters \Interfaces \<interfaz> Nombre de valor: BcastQueryTimeout Tipo de valor: REG_DWORD-Tiempo en milisegundos Rango vlido: 100-OxFFFFFFFF Predeterminado: Ox2ee (750 en decimal) Presente predeterminado: No Aunque podra parecer una buena idea reducir el nmero de difusiones, si se reduce a uno, o se hace demasiado pequeo el intervalo, podra aumentar la posibilidad de que un servidor WINS ocupado no responda lo suficientemente rpido. En ese caso, el cliente fallar al resolver el nombre para el sistema que de otra forma podra haber respondido (usando los valores predeterminados).
Cach de nombres de NetBIOS

Para minimizar el uso de la Solicitud de resolucin de nombre de WINS, los clientes de WINS utilizan una cach de nombres de NetBIOS para guardar los nombres de NetBIOS resueltos recientemente. Si un cliente necesita resolver un nombre de NetBIOS, examinar esta cach antes de transmitir una Solicitud de resolucin de nombre. De forma predeterminada, la cach de nombres de NetBIOS guarda 16 resoluciones, que probablemente resulte apropiado para la mayora de los equipos. Las entradas de la cach se guardan durante 10 minutos, aunque modifique este valor de plazo. Si un cliente resuelve ms nombres de NetBIOS que los que pueden mantener la cach, se descartan las entradas ms antiguas y se aade el nuevo nombre, y su direccin de IP, a la cach de nombres. Se puede configurar la cach de nombres para que tenga uno de los siguientes tamaos:
q q q
Small (pequea). Guarda 16 entradas (es el valor predeterminado). Medium (media). Guarda 128 entradas. Large (grande). Guarda 256 entradas.
Use la siguiente entrada del registro para modificar el tamao de la cach de nombres de NetBIOS: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters Nombre del valor: Size/Small/Medium/Large
Tipo de valor: REG_DWORD Rango vlido: 1, 2, 3 (pequea, media, grande) Predeterminado: 1 (pequeo) Presente predeterminado: No De forma predeterminada, las entradas de la cach de nombre de NetBIOS cumplen su plazo y se eliminan tras 10 minutos. Para ajustar este plazo, use la siguiente entrada del registro: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters Nombre de valor: CacheTimeout Tipo de valor: REG_DWORD Rango vlido: 60000-OxFFFFFFFF Predeterminado: Ox927c0 (600000 milisegundos = 10 minutos) Presente predeterminado: No El valor mantiene el tiempo, en milisegundos, para los que se hace cach de la bsqueda de NetBIOS. Se puede utilizar el comando NBTSTAT -c desde el indicativo de comandos de Windows 2000 para ver las entradas de la cach local de nombres de NetBIOS. Al aumentar el tamao de la cach de nombres de NetBIOS y aumentar el valor del plazo de la cach se puede reducir el nmero de bsquedas que se realiza contra un servidor ocupado. En muchos entornos con un gran grupo de direcciones de IP estticas para todos los servidores clave, este cambio podra ser apropiado. Sin embargo, al realizar este cambio, tambin aumenta la probabilidad de que una entrada en la cach ya no sea la precisa, lo que podra ocurrir en una red de TCP/IP muy dinmica. Esta contrapartida entre precisin y cantidad de trfico de bsqueda se debera considerar cuidadosamente y comprobarlo mediante la Liberacin de nombres.
Liberacin de nombre
Si los recursos de la red se liberan apropiadamente, ya no puede defender el nombre, y el recurso realiza una liberacin de nombre. Para los clientes Nodo B se realiza, simplemente, dejando la defensa de nombre del nombre liberado. Para los clientes Nodo P, la liberacin del nombre se realiza enviando un mensaje de Liberacin de nombre al servidor de WINS.
Proxy de WINS
Los clientes de NetBIOS de terceros, o los antiguos, puede que se configuren para utilizar WINS. En su lugar deberan confiar en el comportamiento del Nodo B. Para ofrecer a estos clientes un uso de los recursos de un servidor WINS, utilice un proxy de WINS, que es un cliente de WINS que se puede configurar para que acte por otros equipos que no pueden utilizar WINS. Un proxy de WINS tambin se puede utilizar durante la migracin desde un entorno de difusin a un entorno de WINS. Se puede configurar un servidor de WINS y un proxy WINS, y despus migrar los sistemas uno a uno sin afectar a la resolucin de nombre de los sistemas que no se hayan convertido. Las funciones del proxy de WINS son las siguientes:
q
Cuando un cliente de WINS Nodo B registra un nombre de NetBIOS, el proxy de WINS realiza una bsqueda de nombre, primero utilizando la cach de nombres de NetBIOS y, si fuese necesario, enviando una Solicitud de resolucin de nombre al servidor de WINS. Si se encuentra el nombre, el proxy enva de vuelta una Respuesta de registro de nombre negativa al cliente de Nodo B que intenta registrar el nombre. Cuando un cliente Nodo B libera su nombre, el proxy simplemente elimina el nombre del cliente de su cach de nombres y enva una liberacin de nombre al servidor de WINS. Cuando un cliente Nodo B difunde una resolucin de nombre, el proxy intenta resolver del nombre, primero utilizando la informacin local de su cach para los nombres remotos o enviando una solicitud de resolucin de nombre al servidor de WINS. Si la bsqueda de nombres se consigue, el proxy enva una Respuesta de solicitud de nombre. Si no se consigue, el proxy enva una Respuesta de solicitud de nombre negativa.
Puede configurar el sistema para actuar como un proxy de WINS para los clientes Nodo B en la subred local editando la siguiente entrada del registro: Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters o Clave: HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \NetBT \Parameters \Adapters \Interfaces \<interfaz> Nombre de valor: EnableProxy Tipo de valor: REG_DWORD-Boolean Rango vlido: 0, 1 (Falso, Cierto) Predeterminado: 0 (Falso) Presente predeterminado: No Al configurar esta entrada al valor 0x1 activa el sistema para actuar como servidor de nombre proxy para las redes a las que est conectada NetBIOS sobre TCP/IP, o a la interfaz elegida. Un servidor de nombre proxy de WINS escucha las Solicitudes de resolucin de nombres de difusin, los resuelve utilizando WINS (o la cach de nombres de NetBIOS del proxy) y difunde el resultado de vuelta al cliente. El proxy de WINS proporciona a los clientes de WINS Nodo B con la capacidad de interoperar con los servidores WINS. Los servidores de Windows 2000 que ejecutan la funcin Comparticin de conexin (NAT) del Servicio Enrutamiento y acceso remoto tambin se pueden configurar para que acten como proxy de WINS los clientes de la red privada.
Entradas de la base de datos de WINS

Cuando se registra, o libera, un nombre, el servidor de WINS actualiza su base de datos interna. Una entrada de la base de datos de WINS guarda el nombre de los recursos de la red, sus direcciones de IP asociadas, el TTL y el nmero de versin. El nmero de versin es la base para la replicacin de servidor WINS.
Replicacin de servidor de WINS

En grandes redes de empresa no se recomienda tener un nico servidor de WINS. Con un nico servidor dando el
servicio a un gran nmero de clientes representara un nico punto de errores. Para proporcionar redundancia, equilibrio de carga y escalabilidad y reducir el trfico de WAN involucrado con las opciones de solicitud de nombre y Registro de nombres, los servidores de WINS se pueden configurar para la replicacin, que replica las entradas de la base de datos de WINS de un servidor a otro. La replicacin de servidor de WINS permite a un equipo cliente de WINS registrar los nombres de NetBIOS en un servidor de WINS, y disponer dicho servidor de WINS replicar los nombres, de forma que estn disponibles a todos los servidores de WINS, y a todos los clientes de WINS de una organizacin. Ello puede acelerar la resolucin de nombres de los clientes, ya que se evita el uso de enlaces de WAN en las solicitudes de WINS. Para que un servidor de WINS replique su informacin, el servidor debe configurarse al menos con otro servidor de WINS como asociado de replicacin. Los asociados de replicacin de WINS replican los nombres que conoce un servidor en el resto de servidores asociados. Existen dos roles de replicacin para un servidor de WINS: asociado pull y asociado push.
q q
Un asociado pull es un servidor WINS que recoge entradas de WINS de sus asociados configurados. Un asociado push es un servidor de WINS que enva actualizaciones de las entradas WINS a sus asociados configurados.
Se recoge todo el trfico de replicacin, con un asociado solicitando actualizaciones desde uno configurado. Las diferencias principales entre los asociados push y pull es quin y cundo lanza el suceso de replicacin. Los asociados pull lanzan una actualizacin de correspondencia de nombres a direcciones de IP desde sus asociados de replicacin, bien cuando el servicio de WINS se inicia o a intervalos configurados por el administrador. Por otra parte, los asociados de push informan a los asociados configurados que realicen una actualizacin, bien porque el servicio de WINS se inicia o bien tras haber acumulado un cierto nmero de actualizaciones. Una vez el asociado ha recibido la notificacin de que existe una actualizacin, el asociado puede hacer pull de estos cambios para actualizar su base de datos WINS local. La topologa de replicacin de WINS en una organizacin la determina el administrador de acuerdo con las necesidades de la resolucin de nombres de NetBIOS. La replicacin involucra a pares de servidores replicando uno del otro, lo que puede generar trfico de WAN. Microsoft recomienda realizar toda la replicacin como push/pull, que es un buen valor predeterminado, especialmente para los servidores de WINS conectados a la LAN. Cuando se replica utilizando enlaces de WAN, la replicacin pull, donde cada asociado hace un envo a intervalos predefinidos, podra ser una mejor alternativa.
Estado del adaptador

Los nodos terminales de NetBIOS pueden solicitar el estado de otro sistema. Este estado se conoce como el estado del adaptador. Se puede utilizar el comando NBTSTAT.EXE de Windows 2000 para enviar una solicitud de estado de un nodo a otro equipo, aunque devolver slo los nombres de NetBIOS que pertenecen al equipo remoto. En la RFC 1002 se define un cierto nmero de estadsticas que se devuelve en un mensaje Estado del adaptador, pero no se muestran con NBTSTAT.EXE.
Instalacin y configuracin de un servidor WINS

WINS es una parte esencial de cualquier red grande basada en NetBIOS. Proporciona el equivalente a un servidor DNS para el espacio de nombres NetBIOS: los servidores WINS asignan direcciones IP a los nombres NetBIOS utilizando la base de datos dinmica de WINS para llamar a los registros de nombres apropiados. Sin embargo, WINS y NetBIOS juntos estn en vas de extincin, lentamente, quizs, pero de forma inexorable. A
causa de su naturaleza propietaria y tendente a fallar, las funciones del servidor WINS sern reemplazadas por servidores DNS a medida que los clientes que requieren soporte NetBIOS vayan desapareciendo. Aunque los clientes UNIX y los clientes de otros sistemas operativos se han apoyado exclusivamente en el DNS para la resolucin de nombres desde hace tiempo, Windows 2000 es el primer sistema operativo de Microsoft que no necesita soporte NetBIOS para el trabajo en red. De este modo, se producir un perodo de transicin significativo antes de que se pueda empezar a desechar esos servidores WINS porque los clientes Windows 95/98, Windows NT e incluso MS-DOS/Windows 3.x resistirn durante algn tiempo.
Determinacin de la necesidad de WINS

Muchas redes grandes necesitarn WINS para proporcionar resolucin de nombres NetBIOS para sus clientes Windows. Sin embargo existen dos casos en los que no se necesitan servidores WINS:
q
Todos los clientes de la red soportan resolucin de nombres por medio de otro mtodo. Windows 2000 es el primer sistema operativo de Microsoft que se puede basar nicamente en el DNS para la resolucin de nombres, por lo que, a menos que todos los clientes Windows estn ejecutando Windows 2000, es necesario WINS. Si se tiene un entorno mixto con otros clientes como clientes UNIX, hay que asegurarse de que todos ellos estn configurados adecuadamente para utilizar DNS. La red es pequea y no hay subredes. Si toda la red consiste en un nico segmento de red, los clientes que requieren resolucin de nombres NetBIOS puede resolver nombres NetBIOS de forma efectiva mediante difusin, una tcnica que no funciona a travs de enrutadores o en grandes redes donde las difusiones NetBIOS generaran muchsimo trfico de red.
Adems, antes de implementar WINS en la red, se debera ser consciente de los clientes WINS que son soportados por el WINS de Windows 2000. OS/2 con LAN Manager versin 2.2c no es soportado como cliente WINS, pero el servidor WINS de Windows 2000 soporta los siguientes sistemas operativos como clientes WINS:
q q q q q q
Windows 2000. Windows NT 3.5 o posterior. Windows 95 o posterior. Windows para Trabajo en grupo 3.11 con TCP/IP 32, incluido en el CD de Windows 2000. MS-DOS con Cliente de redes Microsoft versin 3, incluido en el CD de Windows 2000. MS-DOS con LAN Manager versin 2.2c, incluido en el CD de Windows 2000.
No hay solucin en WINS para los clientes no WINS a menos que se aadan entradas estticas para ellos. Se desaconseja encarecidamente esta prctica; no se debera utilizar a menos que sea absolutamente necesario porque las entradas estticas sean extremadamente difciles de eliminar de la base de datos WINS despus de que tenga lugar la rplica. En lugar de eso, se deberan configurar los clientes para que utilicen DNS para resolver nombres que no se encuentren en la base de datos WINS.
Configuracin del servidor para prepararlo para WINS

La causa ms comn de problemas con WINS es una configuracin no apropiada de TCP/IP en el servidor. Hay que seguir los pasos proporcionados aqu para configurar los parmetros TCP/IP para el servidor WINS adecuadamente antes de instalar el servicio: 1. Pulsar con el botn derecho del ratn en Conexin de rea local en la carpeta Conexiones de red y de acceso telefnico, y escoger Propiedades en el men contextual.
2. Seleccionar el componente Protocolo Internet (TCP/IP) y escoger Propiedades. 3. Configurar el servidor para que utilice una direccin IP esttica o asegurarse de que se ha configurado una reserva de direccin para el servidor en el servidor DHCP 4. Pulsar Avanzada y pulsar despus WINS. 5. Seleccionar cualquier servidor WINS que aparezca en la lista de la ficha y pulsar Quitar. No hacer esto puede provocar que el servidor WINS registre su propia direccin en otro servidor WINS en lugar de en l mismo, lo que no es deseable. 6. Pulsar Agregar e insertar la direccin IP del propio servidor. 7. Deberemos configurar tambin las siguientes opciones:
r
Habilitar la bsqueda de LMHOSTS: Para habilitar el uso de un archivo LMHOSTS para asignar direcciones IP a nombres NetBIOS, hay que seleccionar la casilla de verificacin Habilitar la bsqueda de LMHOSTS y pulsar el botn Importar LMHOSTS para importar un archivo LMHOSTS. Se recomienda no utilizar archivos LMHOSTS a menos que sea absolutamente necesario dado que tratar de mantenerlos actualizados puede ser difcil: la minscula reduccin del trfico de red que ofrecen los archivos LMHOSTS no compensa. Cuando se configura un servidor WINS hay que utilizar el comando Ipconfig en el smbolo del sistema para obtener la direccin IP actual e introducir entonces esa direccin en el campo Direcciones WINS. No se debe introducir ningn otro servidor WINS en este campo; no es deseable que el servidor WINS registre su nombre NetBIOS en otro servidor WINS si el servicio WINS no se ha iniciado a tiempo para responder en el inicio.
Habilitar NetBIOS sobre TCP/IP: Lo ms probable es que sea necesario comunicarse con clientes que ejecutan sistemas operativos de Microsoft anteriores a Windows 2000, por lo que conviene asegurarse de que esta opcin est seleccionada. Deshabilitar NetBIOS sobre TCP/IP: Slo hay que desactivarla si hay comunicacin exclusivamente con otros equipos que ejecutan Windows 2000 o equipos que se basan nicamente en DNS para los servicios de resolucin de nombres (por ejemplo, UNIX). Adems, conviene observar que cualquier aplicacin que utilice NetBIOS no funcionar si se desactiva NetBIOS sobre TCP/IP. Usar configuracin NetBIOS del servidor DHCP: Cuando se obtiene una direccin IP a travs de DHCP, esta opcin est seleccionada de forma predeterminada para que el equipo utilice la configuracin NetBT proporcionada opcionalmente por el servidor DHCP y la configuracin mediante DHCP. Slo hay que seleccionar esta opcin si la red tiene un servidor DHCP que configure completamente el equipo y proporcione la configuracin NetBIOS correcta.
Instalacin de WINS
Cuando los parmetros TCP/IP sean correctos, se podr instalar el componente WINS. Para hacer esto es necesario utilizar el Asistente para componentes de Windows, accesible tanto desde la herramienta Configurar el servidor como desde Agregar o quitar programas del Panel de control y seguir estos pasos para instalar WINS. 1. Abrir Agregar o quitar programas del Panel de control y pulsar el icono Agregar o quitar componentes de Windows en el marco de la izquierda para ejecutar el Asistente para componentes de Windows. 2. Pulsar Siguiente, seleccionar Servicios de red en la lista de componentes y pulsar Detalles. 3. Seleccionar la casilla de verificacin del componente Servicio WINS, pulsar Aceptar y pulsar despus Siguiente. No se debe instalar WINS en un servidor multihusped. Se puede hacer y funcionar, pero puede provocar horribles problemas de rplica, especialmente si el servidor est en dos subredes diferentes.
Adicin de asociados de rplica

Los servidores WINS son extremadamente fciles de configurar y requieren poca administracin, excepto por los asociados de rplica. La rplica de WINS es un asunto importante y un tanto delicado que se debera examinar detenidamente antes de configurarlo. Conviene implantar los menos servidores WINS posibles para minimizar las migraas a causa de la administracin. Para instalar un asociado de rplica y configurar sus parmetros despus de planificar la implantacin de WINS, hay que seguir estos pasos: 1. Abrir WINS desde la carpeta Herramientas administrativas y, en el rbol de la consola, expandir el servidor WINS para el que se desea configurar la rplica.
2. Seleccionar la carpeta Asociados de rplica y escoger Nuevo asociado de rplica en el men Accin. 3. Introducir la direccin IP del servidor WINS con el que se desea activar la rplica y pulsar Aceptar. 4. Para modificar los parmetros de la rplica del nuevo asociado de rplica, si es necesario, hay que pulsar dos veces en el servidor en la carpeta Asociados de rplica y pulsar despus la pestaa Avanzadas. 5. Para modificar la forma de la rplica con el servidor, hay que escoger una opcin del cuadro de lista desplegable Tipo de asociado de rplica. 6. Para configurar una conexin permanente para extraer o insertar rplica, hay que seleccionar la casilla de verificacin Usar conexin persistente para rplica en la seccin Activar rplica de insercin, en la seccin Activar rplica de extraccin o en ambas. 7. En los campos Hora de inicio, hay que introducir el momento en el que se desea que comience la rplica de extraccin en horas, minutos y segundos. 8. En los campos Intervalo de rplica, hay que introducir la frecuencia -das, horas y minutos- con la que se desea hacer rplicas con el asociado de rplica. 9. Se puede utilizar el cuadro Nmero de cambios para introducir el nmero de cambios de la copia local de la base de datos del WINS que se permitirn antes de que el servidor deba insertar los cambios en el asociado de rplica. Se recomienda el uso de rplica insercin/extraccin en todo el espacio de nombres WINS para facilitar la solucin de los problemas de rplica. Adems, los servidores WINS principal y de copia de seguridad deben utilizar rplica insercin/extraccin.
Funcionamiento de WINS
Para comprender cmo funciona WINS, hay que comprender cmo funcionan los clientes de WINS y cmo funciona NBT, en general.
Registro de los nombres de NetBIOS

El proceso de registro y renovacin de los nombres de NetBIOS por un nodo depende del tipo de nodo de NetBIOS configurado en el nodo terminal. En general, un nodo terminal que desee registrar un nombre de NetBIOS enva una Solicitud de registro de nombre para realizarlo. Una vez registrado el nombre, el resto de equipos puede resolver el nombre y utilizar la direccin de IP resultado para comunicarse con dicho nodo terminal. Cuando se termina, normalmente la red libera el nombre.
Solicitud de registro de nombre

Cuando se inicia un elemento de red, intenta registrar los nombres de NetBIOS relacionados. El elemento de red enva una Solicitud de registro de nombre de NetBIOS, dependiendo del tipo de nodo, de la siguiente forma:
q
Nodo B. Cuando un cliente Nodo B registra un nombre, difunde el paquete de registro por la red local. Si el nombre ya se encuentra utilizado por otro nodo, el propietario del mismo enva una Respuesta de registro de nombre negativa. Un cliente Nodo B que no recibe una Respuesta de registro de nombre negativa considera que es l mismo el propietario del nombre y lleva a cabo la defensa de nombre del mismo. Nodo P. Cuando un cliente Nodo P registra un nombre, enva un paquete unicast con el nombre al servidor WINS configurado. Si el nombre que desea registrar ya estaba registrado, el servidor WINS intenta ponerse en contacto con su propietario para comprobar si se est utilizando activamente. Si el nombre an se est utilizando, el servidor WINS enva una Respuesta de registro de nombre negativa al cliente; si el nombre ya no est en uso, el servidor WINS enva una Respuesta de registro de nombre positiva. El servidor WINS tambin puede que enve al cliente que intenta registrar el nombre mensajes de Asentimiento de espera. Estos mensajes indican que el servidor WINS an est intentando determinar si el nombre se puede registrar con seguridad. Nodo M. Un cliente Nodo M intenta registrar el nombre usando difusin, como el cliente Nodo B. Si no existe ninguna objecin, el cliente intenta registrar el nombre usando el comportamiento del Nodo P y un servidor WINS. Aunque con la difusin podra conseguir el propietario del nombre y, por tanto, terminara el proceso de registro del nombre, es insuficiente para determinar su propietario. Nodo H. Un cliente Nodo H de Windows 2000 registra el nombre usando WINS. Si lo consigue, el cliente registrado asume la propiedad del nombre.
Respuesta de registro de nombre positivo

Las respuestas de registro de nombre positivos se envan de un servidor WINS a un cliente WINS tras un registro completo del nombre de NetBIOS. Si un cliente de WINS enva a un servidor de WINS una solicitud de registro de un nico nombre y dicho nombre no se haba registrado, el servidor de WINS lo registrar y enviar un mensaje Registro de nombre positivo al equipo que registr el nombre. Los equipos que envan la solicitud de registro de nombre de NetBIOS mediante difusin, como los clientes Nodo B, no recibirn una Respuesta de registro de nombre positivo. Si un cliente de WINS enva a un servidor de WINS una solicitud para registrar un nombre de grupo, el servidor WINS siempre enviar una Respuesta de registro de nombre positivo. Los clientes Nodo B envan el Registro de nombre de NetBIOS. El cliente Nodo B difunde varios mensajes de Registro de nombre, y si no recibe Respuestas de registro de nombre negativas, se supone el propietario del nombre de NetBIOS.
Respuesta de registro de nombre negativo

Un servidor WINS que recibe una solicitud de registro de un nombre nico de NetBIOS que ya est registrado debera rechazar la solicitud enviando un mensaje de Respuesta de registro de nombre negativo, suponiendo que el nodo terminal propietario es capaz de defenderlo. Antes de enviar la Respuesta negativa, el servidor WINS lo comprueba con el propietario actual para determinar si an sigue activo. Esta situacin podra ocurrir, por ejemplo, si se traslada un porttil a otra subred, o, por alguna razn, se reconfigura para que tenga una nueva direccin de IP. Un equipo que enva una solicitud de registro de nombre de NetBIOS mediante difusin, por ejemplo un cliente Nodo B, tambin recibe una Respuesta de registro de nombre negativo si otro equipo activo en la subred es el propietario del nombre. Un equipo que registra un nombre de NetBIOS con WINS enva los mensajes de solicitud de registro como unicast; el servidor WINS enva un mensaje de Respuesta de nombre negativo si otro nodo terminal de la red haba registrado anteriormente el nombre a registrar, y dicho nodo puede defender el nombre.
Asentimiento de espera
Si un servidor WINS recibe una solicitud de registro de un nombre nico de NetBIOS que ya est registrado, comprueba el nombre con el propietario registrado. En este caso, podra enviar mensajes de Asentimiento de espera al equipo que intenta registrar el nombre. El objeto de estos mensajes es informar al cliente que el servidor puede que todava no sea capaz de determinar una respuesta de nombre. Para indicar al cliente que el servidor no ha fallado y sigue realizando las operaciones del servicio de nombre, el servidor WINS enva un mensaje de
Asentimiento de espera si no puede responder a la solicitud pasado cierto tiempo. El servidor WINS tiene que ponerse en contacto con otro sistema y enva un Asentimiento de espera mientras consigue este contacto.
Solicitud de renovacin de nombre

Los nombres de NetBIOS registrados con un servidor de WINS tienen vida limitada y hay que refrescarlos antes de que su vida expire. El valor predeterminado para el TTL de las entradas de nombre de NetBIOS en WINS es de 6 das, pero el administrador puede modificarlo a cualquier plazo entre 1 minuto y 365 das. Cuando un nodo terminal registra un nombre de NetBIOS con un servidor WINS, el nodo recibe una Respuesta de nombre positiva que contiene el TTL para dicho nombre. Como con los clientes de DHCP, un cliente de WINS intenta renovar todos los nombres de NetBIOS que guarda a la mitad del TTL, es decir, cada 3 das. Adems, cada vez que se inicia el equipo o se reinicia el servicio de nombre de NetBIOS que registra el servicio de Windows, se enva un nuevo mensaje Registro de nombre al servidor de WINS, renovando el nombre (suponiendo, claro est, que el servidor de WINS haya realizado el registro oportuno).
Resolucin de conflictos de Registro de nombre de NetBIOS

Ocurre un conflicto de nombres cuando dos o ms nodos terminales quieren registrar el mismo nombre de NetBIOS nico. En la mayor parte de los casos se debe a errores de configuracin como puede ser haber dado a dos equipos el mismo nombre o haber configurado incorrectamente el servicio. Cuando dos equipos intentan registrar un nombre nico de NetBIOS, el segundo nodo terminal que intenta registrarlo falla, generando un error de registro.
Liberacin de nombres de NetBIOS

Un nombre se puede liberar de dos formas: activa o silenciosamente. Un equipo con Windows 2000 configurado para utilizar WINS libera cualquier nombre de NetBIOS enviando al servidor de WINS un mensaje de Liberacin de nombre que contenga el nombre de NetBIOS a liberar. Por otra parte, un nodo que falla al intentar renovar el nombre, despus de expirar el TTL del nombre, dicho nombre est disponible para que cualquier otro nodo lo utilice. En Windows 2000, el comando NBTSTAT.EXE, con la opcin -RR, libera todos los nombres de NetBIOS registrados actualmente, y luego vuelve a registrarlos. Puede ser til para diagnstico.
Solicitud de liberacin de nombre y Respuesta de liberacin de nombre

Cuando un nodo terminal quiere liberar un nombre registrado de NetBIOS, dicho nodo enva un mensaje solicitud de liberacin de nombre al servidor de WINS. El servidor de WINS enva de vuelta una Respuesta de liberacin de nombre. Normalmente, la respuesta de liberacin tiene un cdigo de 0, indicando que el nombre se ha liberado. En teora se podra enviar un mensaje de Liberacin de nombre negativo, aunque el nodo terminal que envi la solicitud de liberacin lo ignorara.
Resolucin de nombres de NetBIOS

Cuando un equipo con Windows 2000 necesita resolver un nombre de NetBIOS, enva una solicitud de peticin de nombre, mediante difusin o enviando la solicitud directamente al servidor de WINS, dependiendo del tipo de nodo. Si la solicitud de nombre se enva al servidor de WINS y el propio servidor puede resolverlo, el servidor enva una Respuesta de solicitud de nombre al equipo que envi la solicitud. Si el servidor de WINS no puede resolver el nombre, enva una Respuesta de solicitud de nombre negativa. Si el equipo que realiza la resolucin de nombres utiliza el comportamiento de un Nodo B, enviar una solicitud de peticin de nombre; y si el nodo que es dueo del
nombre se encuentra en la subred local, responder. Sin embargo, si no se encuentra en la subred local puede llevar ms tiempo que conseguir una Respuesta de solicitud de nombre negativa de un servidor de WINS.
Solicitud de peticin de nombre

Un mensaje de Solicitud de nombre contiene el nombre de NetBIOS a resolver y se enva bien a la red local o a un servidor de WINS, o a ambos, dependiendo del tipo de nodo de NetBIOS. Si en nodo terminal usa difusin para descubrir el nombre, enva tres difusiones antes de fallar. Cuando un usuario realiza alguna operacin en un equipo con Windows 2000 usando nombres, como cuando se escribe NET VIEW \\XXX en el indicativo del sistema, o escribiendo \\XXX en un cuadro de entrada de Direccin del Explorer, no siempre est claro qu tipo de nombre se resuelve: nombre de host o nombre de NetBIOS. Ni tampoco es obvio qu mtodo de resolucin de nombres obtendr el resultado ms rpidamente. En Windows NT 4.0, el sistema operativo intentaba primero una resolucin de nombre, como la resolucin NetBIOS o la resolucin de nombre de host, y si no lo consegua intentaba con el otro mtodo. Esto generaba retardos si se elega el mtodo equivocado. Para reducir el retraso, Windows 2000 intenta resolver los nombres usando ambos mtodos simultneamente.
Repuesta de Solicitud de nombre positiva

Cuando un host de NetBIOS o un servidor de WINS recibe una Solicitud de peticin de nombre para un nombre de NetBIOS que puede resolver, el sistema le devuelve una Respuesta de solicitud de nombre. Dicha respuesta tiene un cdigo de retorno a 0x0, lo que indica que la resolucin se ha realizado, y se incluye un RR con la direccin de IP del sistema propietario del nombre. Si el nombre solicitado es un nombre nico, slo se devuelve una direccin de IP. Si el nombre solicitado es un nombre de grupo, se devuelve una o ms direcciones de IP.
Respuesta de solicitud de nombre negativa

Cuando un servidor de WINS recibe una Solicitud de peticin de nombre para un nombre de NetBIOS que no se puede resolver, el servidor de WINS devuelve una Respuesta de solicitud de nombre negativa. Esta respuesta negativa tiene un cdigo de retorno que indica que el nombre solicitado no existe.
Refresco de los nombres de NetBIOS

Cada nombre de NetBIOS registrado tiene un TTL. Si el propietario del nodo desea seguir utilizando el nombre de NetBIOS, debe refrescar el nombre antes de que expire el TTL. Para los nombres registrados con WINS, el valor de TTL lo configure el administrador. Los equipos con Windows 2000 intentarn registrar el nombre a intervalos de la mitad del TTL.
Determinacin del estado del adaptador

En las RFC 1001 y 1002 se proporciona un mecanismo para que un nodo pueda determinar el estado de un adaptador local o remoto de otro nodo terminal. La informacin de estado del adaptador incluye los nombres registrados de NetBIOS en el nodo terminal y distintas estadsticas. En Windows 2000 se puede utilizar el comando NBTSTAT.EXE, con la opcin -A o -a para obtener el estado del adaptador de NetBIOS del equipo remoto. Sin embargo, si el host remoto tiene desactivado el NBT, este comando falla.

Configuración DHCP Windows 2000

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Configuración DHCP Windows 2000

Transféré par

Droits d'auteur :

Formats disponibles

ndice Servicios de Red en Windows 2000 Server

Servicios de Red en Windows 2003

Tema 1.- Servicio del Protocolo DHCP

Tema 1.- Servicio del Protocolo DHCP

Servicio de Protocolo DHCP de Windows 2000

Servicio del Protocolo DHCP

Descripcin general de DHCP en Windows 2000

Clientes y servidores de DHCP

Servicio de Protocolo DHCP de Windows 2000

mbitos y opciones de DHCP

Servicio de Protocolo DHCP de Windows 2000

Agentes rel de DHCP

Deteccin de servidor de DHCP no autorizado

Direccionamiento de IP privada automtica (APIPA)

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (3 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Integracin del Servicio Enrutamiento y acceso remoto

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (4 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Instalacin y configuracin de un Servidor DHCP

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (5 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Creacin de un nuevo mbito

Servicio de Protocolo DHCP de Windows 2000

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (7 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Autorizacin del servidor DHCP y activacin de los mbitos

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (8 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Concesiones y reservas de DHCP

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (9 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Activacin de las actualizaciones dinmicas de un servidor DNS

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (10 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Liberar, renovar o verificar una concesin con Ipconfig

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (11 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Obtencin de una concesin inicial

Renovacin de una concesin

Servicio de Protocolo DHCP de Windows 2000

Cambios en subredes y servidores

Uso del agente rel de DHCP

Deteccin de servidores de DHCP no autorizados

Servicio de Protocolo DHCP de Windows 2000

Actualizacin de las entradas de DNS

Formato general de los mensajes

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (14 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (15 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

El servidor de DHCP tambin establece la siguiente serie de opciones:

file:///C|/Documents%20and%20Settings/anayansi/Escritorio/axarnet/tema-01-m.htm (16 of 23)06/01/2006 5:06:15

Servicio de Protocolo DHCP de Windows 2000

Servicio de Protocolo DHCP de Windows 2000

El cliente de DHCP de Windows 2000 tambin establece la siguiente serie de opciones en el

Servicio de Protocolo DHCP de Windows 2000

Servicio de Protocolo DHCP de Windows 2000

Formatos de las opciones

Opciones que admite Windows 2000

Servicio de Protocolo DHCP de Windows 2000

de los siguientes tres grupos: