tcp ip

Los números magicos

DNS, submascara de red, IP, gateway son conceptos de red TCP/IP imprescindibles. En

esta pagina veremos su significado.

direccion IP

El número IP es la direccion numerica que identifica a tu ordenador en una red (ya sea local

o externa). Esta direccion es única para cada equipo en el mundo -o única dentro de cada

red local- y la llamamos direccion logica porque solamente con conocer el IP, cualquier

router es capaz de dirigir los datos al ordenador de destino (o a otro router que

probablemente sea capaz de enviar los datos al ordenador de destino).

Si el ordenador no se conecta directamente a Internet, no necesita tener un número IP unico

a nivel mundial, sino solo a nivel de la subred en la que esta integrado. Asi, si tienes una

red domestica con tres equipos, solamente necesitas una IP pública (única) para el equipo

que conecta a internet, disponiendo de IPs privadas a nivel de subred para cada equipo o

dispositivo (IPs privadas que seran únicas en cada subred). Por ejemplo, una direccion IP

privada de una red clase C sería 192.168.0.1 para el gateway a internet, 192.168.0.2 para la

siguiente maquina, etc.

En las subredes Clase C el rando de IPs privadas disponible va de 192.168.0 a 192.168.255,

siendo inutilizables la primera y la última, por estar reservadas a la identificacion de la

propia red y al broadcasting.

Mascara de subred

Una subred es, basicamente, un conjunto de ordenadores conectados directamente entre si.

Cada ordenador necesita, para pertenecer a una subred, conocer al menos dos datos: su

propio numero IP y la dimension de la red. Este ultimo dato es el que proporciona la

mascara de subred.

La mascara de subred indica el número de ordenadores que la integran restando dicho

número de 255: una mascara de subred tipo C sería 255.255.255.0, número que indica que

la subred tiene 255 direcciones posibles (255 - 0 = 255), mientras que una mascara

255.255.255.232 indica una subred de 24 equipos posibles. En este ultimo ejemplo, el

rango de ips que podriamos usar en nuestra red domestica seria entre y 192.168.0.1 y

192.168.0.24

Normalmente todos los ordenadores dentro de una subred usaran la misma mascara de

subred.

Gateway

Los ordenadores conectados a redes internas usualmente utilizan una pasarela para acceder

a internet (gateway, puerta de enlace). Esta pasarela actúa como un enrutador,

discriminando el trafico interno, que dirige a la subred, del externo que deriva a su destino

en la red. En el supuesto normal de disponer de solamente una IP publica, asignamos esta a

nuestra pasarela.

Servidor DNS

Un servidor DNS transforma el nombre de un host (p.ej www.gratiszona.com) a su

direccion IP (212.78.206.150). Para esta transformacion basicamente consulta una base de

datos del servidor DNS, y si no encuentra la respuesta, pasa la pregunta al siguiente

servidor DNS de nivel superior.

Servidor DHCP

Si pulsas sobre propiedades del protocolo TCP/IP de tu adaptador de red, veras que tienes

dos opciones: obtener IP dinamicamente, o bien introducirla manualmente, en cuyo caso

también tienes que introducir la IP de la pasarela de red, y la submascara de red.

La obtencion de Ips dinamicamente se consigue con un servidor DHCP, servidor que

facilita automaticamente a cada ordenador conectado no solamente IP, sino tambien

gateway, submascara, e incluso direccion del servidor WINS y de los servidores DNS.

Debido a que el usuario final de cada equipo no tiene nada que configurar (mas que marcar

la casilla de obtener ip dinamicamente) los DHCP son solucion muy utilizada por ISPs, y

claro esta, también puedes usarla tu para tu red doméstica, si tienes un router con esta

funcionalidad.

DNS - Domain Names Service

El DNS o Servicio de Nombres de Dominio es un programa que se ejecuta distribuido por

multitud de servidores de Internet (Servidores DNS) que proporciona traduccion automatica

e instantanea entre nombres de dominio www.gratiszona.com) a su direccion IP

(212.78.206.150). El proposito de esta traduccion (o resolucion) es permitir a los usuarios

utilizar una direccion mas facil de recordar, ademas de independizar el nombre de

maquinas, servicios, direcciones de correo electronico, etc. de las direcciones numéricas

concretas que en un determinado momento puedan tener sus equipos (cambio de maquinas,

de proveedores de acceso)

El DNS es una inmensa base de datos distribuida jerarquicamente por todo Internet; existen

infinidad de servidores que interactuan entre sí para encontrar y facilitar a las aplicaciones

que los consultan (navegadores, ftp, etc) la traduccion de un nombre a su direccion de red

IP asociada con la que poder efectuar la conexion deseada. Cada parte de la base de datos

esta replicada en al menos dos servidores, lo que asegura una debida redundancia.

Anteriormente, la asociacion entre nombres y direcciones IP se hacia por medio de un

listado mantenido centralmente en un único fichero (HOST.TXT) que debía ser

constantemente actualizado con cada nuevo equipo conectado y que debía residir en todos y

cada uno de los ordenadores conectados a Internet. El mantenimiento de este sistema se

hizo inviable en cuanto el número de equipos conectados llego a unos pocos miles a

mediados de los años 80.

La finalidad del DNS es la de permitir la distribucion tanto administrativa como técnica, del

sistema de nombres de Internet, por medio de una ordenacion jerarquica de dominios

delegados. Los dominios son entidades administrativas cuyo proposito es subdividir la

carga de gestion de un administrador central repartiéndola entre distintos

subadministradores. Estos, a su vez, pueden repetir el proceso si el tamaño del dominio a

administrar así lo aconseja, garantizandose así la identidad única de cualquier nombre del

DNS que se forma por yuxtaposicion (separada por puntos ".") de los distintos nombres de

dominio de abajo a arriba en la jerarquía, hasta llegar al ultimo (denominado raíz del DNS

o "."); por ejemplo: maquina.nivel3.nivel2.nivel1.

La asignacion del dominio de primer nivel (por ejemplo, de cada país) es asignado por el

Network Information Center (NIC) y es conocido y registrado internacionalmente. A su vez

los dominios de cada país son administrados por una autoridad de éste formando el primer

nivel de la jerarquía: son los "Top Level Domains" o TLD's, que son uno por país (es-nic en

españa), dominios de 2 letras correspondientes al codigo ISO-3166 de cada territorio, mas

los dominios "especiales" de 3 letras: "edu", "com", "gov", "mil", "org", "int", "info" y

"net".

Cada TLD dispone de sus propias normas acerca de quien puede registrar un dominio de

segundo nivel, que dominios estan permitidos, que procedimientos hay que seguir para

registrar un dominio de segundo nivel, etc. El hecho de que alguien cumpla los requisitos

para registrar un dominio bajo un TLD no implica que los cumpla para registrar ese u otro

dominio bajo otro TLD.

Entre las funciones principales desempeñadas por el ES-NIC esta la del registro de nombres

de dominio de DNS de segundo nivel bajo "es" para su uso en Internet por organizaciones

españolas.

Si deseas utilizar un servidor DNS para comprobar las equivalencias entre IP y nombre de

dominio, puedes probar NSLookup.

Direccion IP

El IP es un número binario de 32 bits que identifica de forma precisa y única la ubicacion

de cada ordenador en internet. Los numeros binarios de la direccion IP se expresan en en

números decimales de cuatro partes, cada una de las cuales representa 8 bits de los 32

totales.

Durante tu conexion a internet, tu proveedor te asigna un número IP. No importa el tipo de

ordenador que poseas o la clase de conexion que tengas, si estas en internet, quiere decir

que usas el protocolo de red TCP/IP, y la conexion de tu ordenador posee, en ese momento,

un número IP único.

http://www.all-nettools.com/toolbox/

Tu ordenador recibe su IP de tu proveedor de acceso (telefonica, jazztel, ...); cada

proveedor de acceso dispone de un grupo de números IP registrados para proporcionar a sus

clientes, cuya asignacion viene regulada por diversas entidades internacionales: APNIC

para Asia y Pacifico (www.apnic.net), RIPE para Europa, (www.ripe.net), y ARIN

(www.arin.net), para América y parte de Asia. Estas agencias trabajan en colaboracion con

la agencia estadounidense Internet Assigned Numbers Authority (www.iana.org).

El proveedor puede asignarte un número ip de forma dinamica o estatica. La direccion IP

dinamica es la usual en las conexiones por modem; cada vez que un cliente llama a su

proveedor, este le asigna una de sus ips durante esa conexion; cuando la llamada se corta, el

proveedor la recupera y la tiene disponible para otro cliente. Por el contrario en las

conexiones permanentes (adsl, por ejemplo) el proveedor antes solía asignar la ip de forma

estatica: cada cliente tiene una direccion ip fija, aunque ultimamente tambien suelen

asignarla dinamica.

Elementos de configuración de TCP/IP

Personas que lo han encontrado útil: 1 de 2 - Valorar este tema

elementos de configuración de TCP/IP

Para que TCP/IP funcione correctamente, debe configurar los elementos siguientes:

dirección IP Máscara de subred Puerta de enlace predeterminada Servidor DNS servidor WINS

dirección IP

Debe configurar cada interfaz en cada nodo TCP/IP (host o enrutador) con una dirección IP

única que sea correcta para el segmento de red conectado. La dirección IP es un elemento

de configuración necesario.

Para obtener más información, vea Direccionamiento IP.

Máscara de subred

Debe configurar cada interfaz en cada nodo TCP/IP (host o enrutador) con una máscara de

subred que, cuando se combine con la dirección IP, genere el Id. de red. Todas las

interfaces IP del mismo segmento de red deben utilizar el mismo Id. de red. Por tanto, todas

http://technet.microsoft.com/es-es/library/cc779798%28v=ws.10%29.aspx#feedback

http://technet.microsoft.com/es-es/library/cc787434%28v=ws.10%29.aspx

las interfaces IP del mismo segmento de red deben utilizar la misma máscara de subred. La

máscara de subred es un elemento de configuración necesario.

Para obtener más información, consulte Máscaras de subred.

Puerta de enlace predeterminada

Para la comunicación con nodos TCP/IP de otros segmentos de red, debe configurar al

menos una interfaz con la dirección IP de una puerta de enlace predeterminada (un

enrutador local que reenvíe el tráfico TCP/IP remoto a su destino).

No necesita configurar una puerta de enlace predeterminada para una red que sólo tenga un

segmento de red.

Para obtener más información, vea Enrutamiento IP.

Servidor DNS

Un servidor DNS puede resolver nombres de dominio en direcciones IP. Cuando un host

TCP/IP está configurado con la dirección IP de un servidor DNS, el host TCP/IP envía

consultas de nombres DNS al servidor DNS para su resolución. Se requiere un servidor

DNS para equipos que operen en entornos de red basados en Active Directory.

No necesita configurar un servidor DNS para una red que sólo tenga un segmento de red.

Para obtener más información, vea Resolución de nombres de host.

Los servidores que ejecutan Windows Server 2003 pueden utilizarse como servidores DNS.

Para obtener más información, consulte DNS.

servidor WINS

Un servidor WINS puede almacenar y resolver nombres NetBIOS en direcciones IP.

Cuando un host TCP/IP está configurado con la dirección IP de un servidor WINS, el host

TCP/IP registra sus propios nombres NetBIOS con el servidor WINS y envía consultas de

nombres NetBIOS al servidor WINS para su resolución. Se recomienda encarecidamente

que utilice un servidor WINS si la red tiene más de un segmento de red y si dispone de

equipos que no están basados en Active Directory (por ejemplo, equipos con

Windows NT 4.0, Windows 95, Windows 98 y Windows Millennium Edition).

No necesita configurar un servidor WINS para una red que sólo tiene un segmento de red.

Para obtener más información, vea Resolución de nombres NetBIOS.






Los servidores que ejecutan Windows Server 2003 pueden utilizarse como servidores

WINS. Para obtener más información, vea WINS.

IPSec

Si desea proporcionar seguridad para TCP/IP, debe configurar la Seguridad de Protocolo

Internet (IPSec). IPSec es un marco de estándares abiertos para lograr comunicaciones

privadas seguras a través de redes con el Protocolo Internet (IP) mediante el uso de

servicios de seguridad criptográfica. Proporciona una sólida protección contra ataques a

redes privadas e Internet mediante la seguridad de extremo a extremo. En Windows XP y la

familia Windows Server 2003, IPSec permite proteger la comunicación entre grupos de

trabajo, equipos de redes de área local, clientes y servidores de dominio, sucursales (que

físicamente pueden ser remotas), extranets y clientes itinerantes.

Para obtener más información, consulte Seguridad del protocolo Internet (IPSec).

Enrutamiento IP


Enrutamiento IP

En términos generales, el enrutamiento es el proceso de reenviar paquetes entre dos redes

conectadas. En cuanto a las redes basadas en TCP/IP, el enrutamiento forma parte del

Protocolo Internet (IP) y se utiliza junto con otros servicios de protocolo de red para

proporcionar capacidades de reenvío entre hosts que se encuentran en segmentos de red

distintos dentro de una red basada en un TCP/IP más grande.

IP es la "oficina de correos" del protocolo TCP/IP, donde se ordenan y entregan los datos

IP. Cada paquete entrante o saliente se denomina datagrama IP. Un datagrama IP contiene

dos direcciones IP: la dirección de origen del host que realiza el envío y la dirección de

destino del host receptor. A diferencia de las direcciones de hardware, las direcciones IP de

un datagrama siguen siendo las mismas durante su transmisión a través de una red TCP/IP.

El enrutamiento es la función principal de IP. Los datagramas IP se intercambian y

procesan en cada host mediante IP en el nivel de Internet.

Por encima del nivel IP, los servicios de transporte del host de origen transmiten los datos

en forma de segmentos TCP o mensajes UDP al nivel IP. El nivel IP ensambla los

datagramas IP con la información de las direcciones de origen y destino, que se utiliza para

enrutar los datos a través de la red. A continuación, el nivel IP transmite los datagramas al

nivel de interfaz de red. En este nivel, los servicios de vínculos de datos convierten los

datagramas IP en tramas para la transmisión en una red física a través de medios

específicos de la red. Este proceso se produce en el orden inverso en el host de destino.




Cada datagrama IP contiene una dirección IP de origen y de destino. En cada host, los

servicios del nivel IP examinan la dirección de destino de cada datagrama, comparan esta

dirección con una tabla de enrutamiento mantenida localmente y, después, deciden qué

acción de reenvío se debe realizar. Los enrutadores IP están conectados a dos o más

segmentos de red IP habilitados para reenviar paquetes entre ellos. Las siguientes secciones

tratan con más detalle los enrutadores IP y el uso de tablas de enrutamiento.

Enrutadores IP

Los segmentos de red TCP/IP están conectados entre sí mediante enrutadores IP, que son

los dispositivos que transmiten los datagramas IP desde un segmento de red a otro. Este

proceso se conoce como enrutamiento IP y se muestra en la siguiente ilustración.

Los enrutadores IP proporcionan el medio principal para unir dos o más segmentos de red

IP separados físicamente. Todos los enrutadores IP comparten dos características

fundamentales:

Los enrutadores IP son de hosts múltiples. Un equipo de hosts múltiples es un host de red que utiliza dos o más interfaces de conexión de red para conectarse a cada segmento de red separado físicamente.

Los enrutadores IP permiten el reenvío de paquetes a otros hosts TCP/IP. Los enrutadores IP se diferencian de otros hosts multitarjeta en una característica importante: un enrutador IP debe ser capaz de reenviar la comunicación basada en IP entre redes para otros hosts de la red IP.

Los enrutadores IP se pueden implementar mediante varios productos de hardware y

software posibles. Comúnmente se utilizan enrutadores basados en hardware (dispositivos

de hardware dedicados que ejecutan software especializado). Además, se pueden utilizar

soluciones de enrutamiento basadas en software, como los servicios de enrutamiento y

acceso remoto.

Para obtener información acerca del enrutamiento IP con los servicios de enrutamiento y

acceso remoto, vea Enrutamiento.

Independientemente del tipo de enrutadores IP que utilice, todo el enrutamiento IP está

basado en el uso de una tabla de enrutamiento para la comunicación entre los segmentos de

red.

Tablas de enrutamiento

Los hosts TCP/IP utilizan una tabla de enrutamiento para mantener información acerca de

otras redes IP y hosts IP. Las redes y los hosts se identifican mediante una dirección IP y

una máscara de subred. Además, las tablas de enrutamiento son importantes ya que

proporcionan la información necesaria a cada host local respecto a cómo comunicarse con

redes y hosts remotos.

En cada equipo de una red IP, puede mantener una tabla de enrutamiento con una entrada

para cada equipo o red que se comunica con el equipo local. En general, esto no es práctico

y se utiliza una puerta de enlace predeterminada (enrutador IP) en su lugar.

Cuando un equipo se prepara para enviar un datagrama IP, inserta su propia dirección IP de

origen y la dirección IP de destino del destinatario en el encabezado IP. A continuación, el

equipo examina la dirección IP de destino, la compara con una tabla de enrutamiento IP

mantenida localmente y realiza la acción adecuada según la información que encuentra. El

equipo realiza una de las tres acciones siguientes:

Pasa el datagrama a un nivel de protocolo superior a IP en el host local. Reenvía el datagrama a través de una de las interfaces de red conectadas. Descarta el datagrama.

IP busca en la tabla de enrutamiento la ruta que más se parezca a la dirección IP de destino.

La ruta, en orden de más a menos específica, se localiza de la manera siguiente:

Una ruta que coincida con la dirección IP de destino (ruta de host). Una ruta que coincida con el Id. de red de la dirección IP de destino (ruta de red). La ruta predeterminada.

Si no se encuentra una ruta coincidente, IP descarta el datagrama

Implementar la traducción de direcciones

de red



Implementar la traducción de direcciones de red

Para implementar la traducción de direcciones de red en la red de una oficina pequeña o

una oficina doméstica, debe configurar:

El equipo de traducción de direcciones de red. Otros equipos de la red de la oficina pequeña o doméstica.

Configurar el equipo de traducción de direcciones de red

Para configurar el equipo de traducción de direcciones de red (NAT), puede llevar a cabo

los siguientes pasos:

1. Instale y habilite el Servicio de enrutamiento y acceso remoto. En el Asistente para la instalación del servidor de enrutamiento y acceso remoto, seleccione Traducción de direcciones de red (NAT). Cuando termine el asistente, toda la configuración de NAT estará completa. No necesita realizar los pasos del 2 al 8. Si ya ha habilitado el Servicio de enrutamiento y acceso remoto, realice los pasos del 2 al 8 que sean necesarios. Para obtener información sobre cómo instalar y habilitar el Servicio de enrutamiento y acceso remoto, vea Habilitar el servicio Enrutamiento y acceso remoto.

2. Configure la dirección IP de la interfaz de red privada. En el caso de la dirección IP del adaptador LAN que conecta con la red doméstica, debe configurar los siguientes elementos:

o Dirección IP: 192.168.0.1 o Máscara de subred: 255.255.255.0 o Ninguna puerta de enlace predeterminada.

Nota

o La dirección IP de la configuración anterior correspondiente a la interfaz de red doméstica está basada en el intervalo de direcciones predeterminado 192.168.0.0 con la máscara de subred 255.255.255.0, que está configurada para el componente de direccionamiento de la traducción de direcciones de red. Si cambia este intervalo de direcciones predeterminado, debe cambiar la dirección IP de la interfaz privada correspondiente al equipo de traducción de direcciones de red para que sea la primera dirección IP del intervalo configurado. Se recomienda usar la primera dirección IP del intervalo, aunque no es un requisito de los componentes de la traducción de direcciones de red.

3. Habilite el enrutamiento en el puerto de acceso telefónico. Si la conexión a Internet es una conexión permanente que aparece como una interfaz LAN (por ejemplo, DDS, T-Carrier, Frame Relay, ISDN (RDSI) permanente, xDSL o módem por cable) o si va a conectar el servidor que ejecuta Enrutamiento y acceso remoto a otro enrutador para realizar una conexión a Internet y la interfaz LAN está configurada con una



dirección IP, una máscara de subred y una puerta de enlace predeterminada, ya sea de forma estática o mediante DHCP, vaya al paso 6. Para obtener más información sobre cómo habilitar el enrutamiento en un puerto de acceso telefónico, vea Habilitar el enrutamiento en puertos.

4. Cree una interfaz de marcado a petición para conectar con el proveedor de servicios Internet. Debe crear una interfaz de marcado a petición que esté habilitada para enrutamiento IP y que use el equipo de acceso telefónico y las credenciales utilizadas para llamar a su proveedor de servicios Internet (ISP). Para obtener más información sobre cómo crear interfaces de marcado a petición, vea Agregar una interfaz de marcado a petición.

5. Cree una ruta estática predeterminada que utilice la interfaz de Internet. En el caso de una ruta estática predeterminada, debe seleccionar la interfaz de marcado a petición (para conexiones de acceso telefónico) o la interfaz LAN (para conexiones de enrutador permanentes o intermedias) que se utilice para conectar a Internet. El destino es 0.0.0.0 y la máscara de red es 0.0.0.0. En el caso de una interfaz de marcado a petición, la dirección IP de la puerta de enlace no se puede configurar. Para obtener más información acerca de la configuración de una ruta estática predeterminada, vea Agregar una ruta IP estática predeterminada.

6. Agregue el protocolo de enrutamiento de traducción de direcciones de red (NAT). Para obtener información sobre cómo agregar el protocolo de enrutamiento IP de de traducción de direcciones de red, vea Agregar la traducción de direcciones de red.

7. Agregue interfaces de Internet y de red doméstica al protocolo de enrutamiento de NAT. Para obtener información sobre cómo agregar interfaces al protocolo de enrutamiento IP de NAT, vea Agregar una interfaz a la traducción de direcciones de red y configurarla.

8. Habilite la resolución de nombres y el direccionamiento NAT. Para obtener información sobre cómo habilitar el direccionamiento de la traducción de direcciones de red, vea Habilitar el direccionamiento de la traducción de direcciones de red. Para obtener información sobre cómo habilitar la resolución de nombres de la traducción de direcciones de red, vea Habilitar la resolución de nombres para la traducción de direcciones de red. Nota

o La característica de direccionamiento NAT sólo asigna direcciones de un único intervalo que corresponde a una subred única. Si se agregan varias interfaces LAN de redes domésticas al protocolo de enrutamiento de NAT, se supone la configuración de una subred única (donde todas las interfaces LAN están conectadas a la misma red). Si las interfaces LAN corresponden a redes diferentes, es posible que no se produzca la conectividad entre clientes de redes distintas que reciban direcciones del equipo de NAT.

Configurar otros equipos de la red de la oficina pequeña

o doméstica.

Debe configurar el protocolo TCP/IP en los demás equipos de la red de la oficina pequeña o

doméstica para obtener una dirección IP automáticamente y, a continuación, tiene que

reiniciarlos. Cuando los equipos de la red doméstica reciben su configuración de

direcciones IP del equipo de traducción de direcciones de red, se configuran con:










La dirección IP (del intervalo de direcciones de 192.168.0.0 con la máscara de subred 255.255.255.0).

La máscara de subred (255.255.255.0). La puerta de enlace predeterminada (la dirección IP de un enrutador con acceso directo de

la red de la oficina pequeña o doméstica). El servidor DNS (la dirección IP de la interfaz correspondiente al equipo de NAT de la

oficina pequeña o doméstica).

Configuración avanzada de NAT

Para configurar las opciones avanzadas de NAT, puede llevar a cabo uno de los

procedimientos siguientes:

Si el ISP le proporciona un intervalo de direcciones IP, configúrelo en su interfaz de Internet.

Si existen servicios que se están ejecutando en la red privada a los que los usuarios necesitan tener acceso desde Internet, agregue un puerto especial que asigne la dirección IP pública y el número de puerto a una dirección IP privada y un número de puerto.

Para obtener más información, vea Configurar el Servidor de seguridad básico o NAT.

Descripción de la traducción de

direcciones de red

Este tema aún no ha recibido ninguna valoración - Valorar este tema

Descripción de la traducción de direcciones de red

Con la traducción de direcciones de red (NAT), puede configurar la red de una casa o de

una oficina pequeña para compartir una única conexión a Internet. NAT consta de los

siguientes componentes:

Componente para la traducción El servidor con Enrutamiento y acceso remoto donde NAT está habilitado traduce las direcciones IP y los números de puerto TCP/UDP de los paquetes que se envían entre la red privada e Internet.

Componente para el direccionamiento El equipo de traducción de direcciones de red proporciona información de configuración de direcciones IP a los demás equipos de la red. El componente de direccionamiento es un servidor DHCP simplificado que asigna una dirección IP, una máscara de subred, una puerta de enlace o gateway predeterminada y la dirección IP de un servidor DNS. Debe configurar los equipos de la red doméstica como clientes DHCP para recibir la configuración IP automáticamente. La configuración TCP/IP predeterminada para los equipos que ejecutan algún miembro de la familia Windows Server 2003, Windows XP,

Windows 2000, Windows NT, Windows Millennium Edition, Windows 98 o Windows 95 es como cliente DHCP.

Componente para la resolución de nombres El equipo de traducción de direcciones de red se convierte en un servidor DNS para los demás equipos de la red doméstica. Cuando el equipo de traducción de direcciones de red recibe las peticiones de la resolución de nombres, las reenvía al servidor DNS situado en Internet para el que está configurado y devuelve las respuestas al equipo de la red doméstica.

Para obtener más información acerca de la traducción de direcciones de red, vea:

Direcciones privadas de Internet Un ejemplo de NAT

Para obtener más información acerca de NAT, vea Configurar la traducción de direcciones

de red.

Para ver un ejemplo acerca de cómo utilizar NAT, vea Red SOHO con Internet.

Nota

Puesto que NAT incluye componentes para el direccionamiento y la resolución de nombres que suministran servicios DHCP y DNS para los hosts de la red privada, no podrá ejecutar:

o El servicio DHCP ni el Agente de retransmisión DHCP, si está habilitado el direccionamiento de NAT.

o El servicio DNS, si está habilitada la resolución de nombres de red TCP/IP de NAT.

Direcciones privadas de Internet


Direcciones privadas de Internet

Para comunicarse en Internet, debe utilizar direcciones asignadas por la Autoridad de

números asignados de Internet (IANA, Internet Assigned Numbers Authority). Las

direcciones asignadas por IANA pueden recibir tráfico de ubicaciones de Internet y se

conocen como direcciones públicas. A una pequeña empresa u oficina se le asigna una

dirección o direcciones públicas desde su proveedor de servicios Internet (ISP), que ha

recibido un intervalo de direcciones públicas.

Para permitir que varios equipos de una oficina pequeña o doméstica se comuniquen en

Internet, cada equipo debe tener su propia dirección pública. Este requisito supone un gran

esfuerzo para mantener el conjunto disponible de direcciones públicas.

Para aligerar esta carga, IANA ha suministrado un esquema de reutilización de direcciones

al reservar algunos identificadores de red para interconexiones de redes privadas. Entre los

identificadores de red privados se incluyen:

10.0.0.0 con la máscara de subred 255.0.0.0 172.16.0.0 con la máscara de subred 255.240.0.0 192.168.0.0 con la máscara de subred 255.255.0.0

Para obtener más información acerca de las partes de los espacios de direcciones IP que se

reservan para intranets privadas, consulte el documento RFC 1918, "Asignación de

direcciones para conexiones privadas" ("Address Allocation for Private Internets"). Todas

las direcciones de estos intervalos se conocen como direcciones privadas.

Las direcciones privadas no pueden recibir tráfico de ubicaciones de Internet. Por tanto, si

una intranet está utilizando direcciones privadas y se comunica con ubicaciones de Internet,

la dirección privada debe traducirse a una dirección pública. Entre una intranet, que utiliza

direcciones privadas, e Internet, que utiliza direcciones públicas, se coloca un traductor de

direcciones de red. El servicio de traducción de direcciones de red (NAT) traduce las

direcciones privadas de los paquetes de salida de la intranet a direcciones públicas.

Igualmente, NAT traduce las direcciones públicas de los paquetes entrantes de Internet a

direcciones privadas. Para obtener más información, vea Un ejemplo de NAT.

Un ejemplo de NAT


Un ejemplo de NAT

Si una empresa pequeña utiliza el identificador de red 192.168.0.0 en su intranet y su

proveedor de servicios Internet (ISP) le ha concedido la dirección pública w1.x1.y1.z1, la

traducción de direcciones de red (NAT, Network Address Translation) asignará

todas las direcciones privadas de 192.168.0.0 a la dirección IP w1.x1.y1.z1. En caso de que

se asignen varias direcciones privadas a una sola dirección pública, NAT utiliza puertos

TCP y UDP elegidos dinámicamente para distinguir una ubicación de la intranet de otra.

Nota

El uso de w1.x1.y1.z1 y w2.x2.y2.z2 está pensado para representar direcciones IP públicas y válidas, tal como las asigna la Autoridad de números asignados de Internet (IANA, Internet Assigned Numbers Authority) o un ISP.

En la ilustración siguiente se muestra un ejemplo del uso de NAT para conectar de manera

transparente una intranet a Internet.

Si un usuario privado que se encuentra en 192.168.0.10 utiliza un explorador Web para

conectarse con el servidor Web, en w2.x2.y2.z2, el equipo del usuario creará un paquete IP

con la información siguiente:

Dirección IP de destino: w2.x2.y2.z2 Dirección IP de origen: 192.168.0.10 Puerto de destino: puerto 80 de TCP Puerto de origen: puerto 5000 de TCP

A continuación, este paquete IP se reenvía al protocolo NAT, que traduce las direcciones

del paquete saliente como se indica a continuación:

Dirección IP de destino: w2.x2.y2.z2 Dirección IP de origen: w1.x1.y1.z1 Puerto de destino: puerto 80 de TCP Puerto de origen: puerto 1025 de TCP

El protocolo NAT mantiene la asignación de {192.168.0.10, TCP 1025} a {w1.x1.y1.z1,

TCP 5000} en una tabla.

El paquete IP traducido se envía a través de Internet. Se devuelve una respuesta que recibe

el protocolo NAT. Cuando se recibe, el paquete contiene la información de dirección

pública siguiente:

Dirección IP de destino: w1.x1.y1.z1 Dirección IP de origen: w2.x2.y2.z2 Puerto de destino: puerto 1025 de TCP Puerto de origen: puerto 80 de TCP

El protocolo NAT comprueba su tabla de traducción, asigna las direcciones públicas a las

direcciones privadas y reenvía el paquete al equipo que se encuentra en 192.168.0.10. El

paquete reenviado contiene la información de direcciones siguiente:

Dirección IP de destino: 192.168.0.10 Dirección IP de origen: w2.x2.y2.z2 Puerto de destino: puerto 5000 de TCP Puerto de origen: puerto 80 de TCP

Por lo que se refiere a los paquetes salientes del protocolo NAT, la dirección IP de origen

(una dirección privada) se asigna a la dirección ISP asignada (una dirección pública) y los

números de puerto TCP/UDP se asignan a un número de puerto TCP/UDP diferente.

En los paquetes entrantes del protocolo NAT, la dirección IP de destino (una dirección

pública) se asigna a la dirección de la intranet original (una dirección privada) y los

números de puerto TCP/UDP se vuelven a asignar a sus números de puerto TCP/UDP

originales.

Nota

NAT traduce correctamente los paquetes que contienen la dirección IP únicamente en el encabezado IP. Es posible que NAT no traduzca correctamente los paquetes que contienen la dirección IP dentro de la propia carga IP.

Tabla de enrutamiento IP


Tabla de enrutamiento IP

Todos los equipos que ejecutan TCP/IP toman decisiones de enrutamiento. Estas decisiones

están controladas por la tabla de enrutamiento IP. Para mostrar la tabla de enrutamiento IP

en equipos que ejecutan sistemas operativos Windows Server 2003, puede escribir route

print en el símbolo del sistema.

La siguiente tabla muestra un ejemplo de tabla de enrutamiento IP. En este ejemplo se

utiliza un equipo que ejecuta Windows Server 2003, Standard Edition con un adaptador de

red de 10 megabytes y la siguiente configuración:

Dirección IP: 10.0.0.169 Máscara de subred: 255.0.0.0 Puerta de enlace predeterminada: 10.0.0.1


Descripción Destino de red Máscara de red Puerta de

enlace Interfaz Métrica

Ruta predeterminada 0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.169 30

Red de bucle invertido 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

Red local 10.0.0.0 255.0.0.0 10.0.0.169 10.0.0.169 30

Dirección IP local 10.0.0.169 255.255.255.255 127.0.0.1 127.0.0.1 30

Direcciones de

multidifusión 224.0.0.0 240.0.0.0 10.0.0.169 10.0.0.169 30

Dirección de difusión

limitada 255.255.255.255 255.255.255.255 10.0.0.169 10.0.0.169 1

Nota

Las descripciones de la primera columna de la tabla anterior no se muestran en el resultado del comando route print.

La tabla de enrutamiento se genera automáticamente y está basada en la configuración de

TCP/IP actual del equipo. Cada ruta ocupa una sola línea en la tabla mostrada. El equipo

busca en la tabla de enrutamiento la entrada que más se parezca a la dirección IP de destino.

El equipo utiliza la ruta predeterminada si no hay otra ruta de host o red que coincida con la

dirección de destino incluida en un datagrama IP. Normalmente, la ruta predeterminada

reenvía el datagrama IP (para el que no hay una ruta local coincidente o explícita) a la

dirección de una puerta de enlace predeterminada de un enrutador en la subred local. En el

ejemplo anterior, la ruta predeterminada reenvía el datagrama a un enrutador con la

dirección de puerta de enlace 10.0.0.1.

Como el enrutador que corresponde a la puerta de enlace predeterminada contiene

información acerca de los Id. de red de las demás subredes IP del conjunto de redes TCP/IP

más grande, reenvía el datagrama a otros enrutadores hasta que finalmente se entrega a un

enrutador IP que está conectado al host o subred de destino que se ha especificado en la red

más grande.

En las siguientes secciones se describe cada una de las columnas de la tabla de

enrutamiento IP: destino de red, máscara de red, puerta de enlace, interfaz y métrica.

Destino de red

El destino de red se utiliza junto con la máscara de red para la coincidencia con la dirección

IP de destino. El destino de red puede encontrarse entre 0.0.0.0, para la ruta

predeterminada, y 255.255.255.255, para la difusión limitada, que es una dirección de

difusión especial para todos los hosts del mismo segmento de red.

Máscara de red

La máscara de red es la máscara de subred que se aplica a la dirección IP de destino cuando

se produce la coincidencia con el valor del destino de red. Cuando la máscara de red se

escribe en binario, los "1" deben coincidir pero no es necesario que los "0" coincidan. Por

ejemplo, una ruta predeterminada que utiliza una máscara de red 0.0.0.0 se traduce al valor

binario 0.0.0.0, por lo que no es necesario que los bits coincidan. Una ruta de host (una ruta

que coincide con una dirección IP) que utiliza una máscara de red de 255.255.255.255 se

traduce a un valor binario de 11111111.11111111.11111111.11111111, por lo que todos

los bits deben coincidir.

Puerta de enlace

La dirección de la puerta de enlace es la dirección IP que utiliza el host local para reenviar

datagramas IP a otras redes IP. Puede tratarse de la dirección IP de un adaptador de red

local o de un enrutador IP (por ejemplo, el enrutador de una puerta de enlace

predeterminada) del segmento de red local.

Interfaz

La interfaz es la dirección IP configurada en el equipo local para el adaptador de red local

que se utiliza cuando se reenvía un datagrama IP en la red.

Métrica

La métrica indica el costo del uso de una ruta, que suele ser el número de saltos al destino

IP. Cualquier destino en la subred local está a un salto de distancia y cada enrutador que se

atraviesa en la ruta es un salto adicional. Si existen varias rutas al mismo destino con

diferentes métricas, se selecciona la ruta con menor métrica.

Para obtener información acerca de cómo agregar rutas a la tabla de enrutamiento IP, vea

Agregar una ruta IP estática. Para obtener información acerca de cómo eliminar rutas en la

tabla de enrutamiento IP, vea Quitar una ruta IP estática.

Equipos de hosts múltiples

A continuación se muestra la tabla de enrutamiento predeterminada de un equipo Windows

Server 2003, Standard Edition de hosts múltiples con la configuración siguiente:

Adaptador de red 1 (10 MB) o Dirección IP: 10.0.0.169 o Máscara de subred: 255.0.0.0 o Puerta de enlace predeterminada: 10.0.0.1

Adaptador de red 2 (100 MB)



o Dirección IP: 192.168.0.200 o Máscara de subred: 255.255.0.0 o Puerta de enlace predeterminada: 192.168.0.1

Adaptado

r Descripción Destino de red Máscara de red

Puerta de

enlace Interfaz

Métric

a

1

Ruta

predetermina

da

0.0.0.0 0.0.0.0 10.0.0.1 10.0.0.169 20

2

Ruta

predetermina

da

0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.20

0 30

1 Red de bucle

invertido 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1

1 Red local 10.0.0.0 255.0.0.0 10.0.0.169 10.0.0.169 20

1 Dirección IP

local 10.0.0.169

255.255.255.2

55 127.0.0.1 127.0.0.1 20

2 Red local 192.168.0.0 255.255.0.0 192.168.0.20

0

192.168.0.20

0 30

2 Dirección IP

local 192.168.0.200

255.255.255.2

55 127.0.0.1 127.0.0.1 30

2 Difusión de

subred 192.168.0.255

255.255.255.2

55

192.168.0.20

0

192.168.0.20

0 30

1 Dirección de

multidifusión 224.0.0.0 240.0.0.0 10.0.0.169 10.0.0.169 20

2 Dirección de

multidifusión 224.0.0.0 240.0.0.0

192.168.0.20

0

192.168.0.20

0 30

1 Difusión

limitada

255.255.255.2

55

255.255.255.2

55 10.0.0.169 10.0.0.169 1

2 Difusión

limitada

255.255.255.2

55

255.255.255.2

55

192.168.0.20

0

192.168.0.20

0 1

Nota

Las descripciones de la primera y segunda columnas de la tabla anterior no se muestran en el resultado del comando route print.

Para obtener información acerca de cómo habilitar el reenvío IP en un equipo de hosts

múltiples que ejecuta un sistema operativo Windows Server 2003, vea Habilitar el servicio

Enrutamiento y acceso remoto.

Notas



Cuando se configura una puerta de enlace predeterminada para cada adaptador de red, se crea la ruta 0.0.0.0 para cada uno. Sin embargo, sólo se utiliza una ruta predeterminada. En el ejemplo anterior, la dirección IP 10.0.0.169 corresponde al primer adaptador de red de los enlaces TCP/IP y, por tanto, se utiliza la ruta predeterminada del adaptador de red 1. Como sólo se utiliza una puerta de enlace predeterminada, debe configurar únicamente un adaptador de red para que tenga una puerta de enlace predeterminada. Esto reduce la confusión y asegura los resultados deseados.

Si el enrutador IP es un servidor que ejecuta Windows Server 2003 y no tiene una interfaz en una red específica, necesita una ruta para llegar allí. Puede agregar rutas estáticas o utilizar los protocolos de enrutamiento que proporcionan los servicios de enrutamiento y acceso remoto. Para obtener información acerca del enrutamiento IP con los servicios de enrutamiento y acceso remoto, vea Enrutamiento.

Resolución de nombres de host Personas que lo han encontrado útil: 3 de 4 - Valorar este tema

Resolución de nombres de host La resolución de nombres de host significa asignar correctamente un nombre de

host a una dirección IP. Un nombre de host es un alias que se asigna a un nodo IP

para identificarlo como host TCP/IP. El nombre de host puede tener un máximo

de 255 caracteres y puede incluir caracteres alfabéticos y numéricos, guiones y

puntos. Es posible asignar varios nombres al mismo host.

Los programas de Windows Sockets (Winsock), como Internet Explorer y la

utilidad FTP, pueden utilizar uno de dos valores para el destino al que desea

conectarse: la dirección IP o un nombre de host. Si se especifica la dirección IP, no

se necesita la resolución de nombres. Si se especifica un nombre de host, este

nombre se debe resolver en una dirección IP para que pueda comenzar la

comunicación basada en IP con el recurso deseado.

Los nombres de host pueden adoptar diversas formas. Las dos formas más comunes

son sobrenombres y nombres de dominio. Los sobrenombres son alias de

direcciones IP que los usuarios individuales pueden asignar y utilizar. Los nombres

de dominio son nombres estructurados en un espacio de nombres jerárquico llamado

Sistema de nombres de dominio (DNS, Domain Name System). Un ejemplo

de un nombre de dominio es www.microsoft.com.

Los sobrenombres se resuelven mediante entradas del archivo Hosts, que se

encuentra en la carpeta raízDelSistema\System32\Drivers\Etc. Para obtener más

información, vea Archivos de base de datos de TCP/IP.

Los nombres de dominio se resuelven mediante el envío de consultas de nombres

DNS a un servidor DNS configurado. El servidor DNS es un equipo que almacena

registros de asignación de nombres de dominio a direcciones IP o conoce la

existencia de otros servidores DNS. El servidor DNS resuelve el nombre de

dominio consultado en una dirección IP y devuelve el resultado.

Es necesario configurar los equipos con la dirección IP del servidor DNS para poder

resolver nombres de dominio. Asimismo, los equipos basados en Active Directory

que ejecutan Windows XP Professional o sistemas operativos Windows

Server 2003 se deben configurar con la dirección IP de un servidor DNS.

Configuración TCP/IP

Son necesarios una serie de datos para poner en marcha la comunicación via TCP/IP, que es

el protocolo usado en Internet.

Configuración de los programas de comunicaciones. Configuración para Windows 3.x. Configuración para Windows 95.

Configuración de los programas de comunicaciones

Se configuran en el CONFIG.TEL para DOS, y el TRUMPET para Windows o el TCP/IP

para Windows de Microsoft. Ya que actualmente todos los programas comerciales

funcionan bajo Windows 3.x o Windows 95, solo veremos la configuración en estos dos

sistemas operativos.Los siguientes son parámetros que deberemos configurar:

Direcciones IP

El dato más importante, es la dirección IP. Esta dirección identifica al nodo en la red y

permite comunicarnos con los demás nodos Internet. Para solicitar la dirección en la

Universidad de Sevilla, hay que ponerse en contacto con el Centro de Cálculo

correspondiente si lo hubiera, o si no, con el CPD de la Universidad, donde será facilitada

una solicitud de dirección IP. En ella se piden una serie de datos IMPRESCINDIBLES

como son el tipo y modelo del ordenador, Sistema Operativo, dirección hardware (que

suele venir en la tarjeta de comunicación Ethernet) y el nombre que queremos ponerle a

nuestro nodo. Una vez rellenos estos campos, nos darán la dirección IP. Esta dirección

pertenece a una serie de subredes asignadas por Red Iris a R.I.C.A. (Red de Informática

Científica de Andalucia), por delegación del NIC, que es un organismo internacional

encargado de la distribución mundial de direcciones IP.Una dirección IP es un numero de

32 bits. Se representa usualmente mediante notación decimal separada por puntos (cuatro

numeros, de 0 a 255, separados por puntos). Un ejemplo de dirección IP seria:

(150.214.189.65)

Máscara de red

La máscara es la forma de interpretar una dirección IP, de modo que se pueda saber cual es

la dirección de la subred y cual la del nodo dentro de la subred. Se representa usualmente

mediante 4 numeros entre 0 y 255 separados por puntos. Por ejemplo, una máscara de Red

seria: (255.255.255.0)Está máscara se puede interpretar como que el protocolo ha de leer la

dirección de red usando los tres primeros grupos de números, mientras que el nodo viene

identificado por el último número.Cuando solicite su dirección IP, tambien le

proporcionaran la máscara que debe usar.

http://www.us.es/campus/servicios/sic/comunic/servdns/tcpip.html#confi

http://www.us.es/campus/servicios/sic/comunic/servdns/tcpip.html#confiw

http://www.us.es/campus/servicios/sic/comunic/servdns/tcpip.html#config95

Nombre de dominio (Domain Name)

En un esquema jerárquico de conversión de nombres a direcciones IP, el NIC administra el

dominio raíz y delega el control a los subdominios de segundo orden. El subdominio de

segundo orden "es" es controlado por Red Iris, que a su vez delega el control en nosotros

sobre el subdominio de tercer orden "us.es".En el caso de la Universidad de Sevilla, el

nombre de dominio es: us.es. Que significa que el código del país es "es" (de "Es"paña) y el

código de la organización es "us" (de "U"niversidad de "S"evilla).Con el sistema de

dominios, es posible saber a donde pertenece un determinado nodo de una manera bastante

más intuitiva que con la dirección numérica.

Servidor de nombres (Name Domain Server)

Los Servidores de Nombres son los nodos en los que reside la aplicación que traduce los

nombres por dominio a direcciones IP y viceversa, que es con lo que en realidad trabajan

las máquinas en Internet . En el nodo existen unos ficheros que realizan la correspondencia

entre el nombre y la dirección IP.A partir del 1 de Enero de 1999, los Servidores DNS de la

Universidad de Sevilla seran :

(150.214.186.69) (Primario) (150.214.130.15) (Secundario) (150.214.4.34) (Secundario) (150.214.1.3) (Secundario) (130.206.1.3) (Secundario) (130.206.1.2) (Secundario)

En aquellas máquinas en los que el programa de configuración del TCP/IP solo admita un

servidor de nombres, el que debe de usarse es el primario 150.214.186.69.En aquellas

máquinas en las que el programa de configuración del TCP/IP admitan varios Servidores

DNS, debe incluirse como mínimo el primario (150.214.186.69) y al menos dos de los

secundarios (lo aconsejable seria 150.214.130.15 y 150.214.4.34).

Nombre de la Máquina (Host Name)

Consiste en una serie de cadenas de caracteres alfanuméricos, separadas por puntos. Un

ejemplo valido de Nombre de Host en la Universidad de Sevilla seria: ibm.us.esEn

principio, no seria necesario que el nombre de la máquina estubiera dado de alta en el

Servidor DNS para poder conectarse a Internet, pero como medida de seguridad todos los

nodos de la Universidad de Sevilla están dados de alta en el Servidor DNS. Por tanto,en la

solicitud hemos de indicar que "SI" queremos ser dados de alta, y por supuesto, indicar el

nombre que queremos ponerle a nuestro ordenador.

Dirección de la puerta de salida (Gateway)

Esta es la dirección del nodo que nos servirá para salir de la subred a la que pertenece

nuestro nodo a la gran red exterior. En cada subred existe un gateway o puerta.De igual

forma que con la máscara, cuando solicite su dirección IP, también le proporcionaran la

dirección de su gateway.Básicamente con estos datos, los programas de comunicaciones

quedan configurados para poder salir a Internet.

Definición de DNS


Definición de DNS

DNS es una abreviatura para Sistema de nombres de dominio (Domain Name

System), un sistema para asignar nombres a equipos y servicios de red que se organiza

en una jerarquía de dominios. La asignación de nombres DNS se utiliza en las redes

TCP/IP, como Internet, para localizar equipos y servicios con nombres descriptivos.

Cuando un usuario escriba un nombre DNS en una aplicación, los servicios DNS podrán

traducir el nombre a otra información asociada con el mismo, como una dirección IP.

Por ejemplo, la mayoría de los usuarios prefieren un nombre descriptivo, fácil de utilizar,

como ejemplo.microsoft.com para localizar un equipo (como un servidor Web o de correo

electrónico) en la red. Un nombre descriptivo resulta más fácil de aprender y recordar. Sin

embargo, los equipos se comunican a través de una red mediante direcciones numéricas.

Para facilitar el uso de los recursos de red, los sistemas de nombres como DNS

proporcionan una forma de asignar estos nombres descriptivos de los equipos o servicios a

sus direcciones numéricas.

La siguiente ilustración muestra un uso básico de DNS, consistente en la búsqueda de la

dirección IP de un equipo basada en su nombre.

En este ejemplo, un equipo cliente consulta a un servidor DNS, preguntando la dirección IP

de un equipo configurado para utilizar host-a.ejemplo.microsoft.com como nombre de

dominio. Como el servidor puede utilizar la base de datos local para responder la consulta,

contesta con una respuesta que contiene la información solicitada, un registro de recursos

de host (A) que contiene la información de dirección IP para host-a.ejemplo.microsoft.com.

El ejemplo muestra una consulta DNS sencilla entre un único cliente y un servidor DNS.

En la práctica, las consultas DNS pueden ser más complicadas que ésta e incluyen pasos

adicionales que no se muestran aquí. Para obtener más información, vea Cómo funcionan

las consultas DNS.

Descripción del espacio de nombres de dominio DNS

El espacio de nombres de dominio DNS, como se muestra en la ilustración siguiente, se

basa en el concepto de un árbol de dominios con nombre. Cada nivel del árbol puede

representar una rama o una hoja del mismo. Una rama es un nivel donde se utiliza más de

un nombre para identificar un grupo de recursos con nombre. Una hoja representa un

nombre único que se utiliza una vez en ese nivel para indicar un recurso específico.

La ilustración anterior muestra cómo Microsoft es la autoridad asignada por los servidores

raíz de Internet para su propia parte del árbol del espacio de nombres de dominio DNS en

Internet. Los clientes y servidores DNS usan las consultas como método fundamental para

resolver los nombres del árbol como información específica de los tipos de recurso. Los

servidores DNS proporcionan esta información a los clientes DNS en las respuestas a las



consultas, quienes, a continuación, extraen la información y la pasan al programa que la

solicita para resolver el nombre consultado.

En el proceso de resolución de un nombre, tenga en cuenta que los servidores DNS

funcionan a menudo como clientes DNS, es decir, consultan a otros servidores para

resolver completamente un nombre consultado.

Cómo se organiza el espacio de nombres de dominio DNS

Cualquier nombre de dominio DNS que se utiliza en el árbol es, técnicamente, un dominio.

Sin embargo, la mayor parte de las explicaciones de DNS identifica los nombres de una de

las cinco formas posibles, según el nivel y la forma en que se utiliza normalmente un

nombre. Por ejemplo, el nombre de dominio DNS registrado para Microsoft

(microsoft.com.) se conoce como un dominio de segundo nivel. Esto se debe a que el

nombre tiene dos partes (llamadas etiquetas) que indican que se encuentra dos niveles por

debajo de la raíz o la parte superior del árbol. La mayor parte de los nombres de dominio

DNS tienen dos etiquetas o más, cada una de las cuales indica un nuevo nivel en el árbol.

En los nombres se utilizan puntos para separar las etiquetas.

Además de los dominios de segundo nivel, en la siguiente tabla se describen otros términos

que se utilizan para describir los nombres de dominio DNS según su función en el espacio

de nombres.

Tipo de

nombre Descripción Ejemplo

Dominio raíz

Parte superior del árbol que representa

un nivel sin nombre; a veces, se

muestra como dos comillas vacías

(""), que indican un valor nulo.

Cuando se utiliza en un nombre de

dominio DNS, empieza con un punto

(.) para designar que el nombre se

encuentra en la raíz o en el nivel más

alto de la jerarquía del dominio. En

este caso, el nombre de dominio DNS

se considera completo e indica una

ubicación exacta en el árbol de

nombres. Los nombres indicados de

esta forma se llaman nombres de

dominio completos (FQDN, Fully

Qualified Domain Names).

Un sólo punto (.) o un punto usado

al final del nombre, como

"ejemplo.microsoft.com.".

Dominio de

nivel

Nombre de dos o tres letras que se

utiliza para indicar un país, una región

".com", que indica un nombre

registrado para usos comerciales o

superior o el tipo de organización que usa un

nombre. Para obtener más información,

vea Dominios de nivel superior.

empresariales en Internet.

Dominio de

segundo

nivel

Nombres de longitud variable

registrados que un individuo u

organización utiliza en Internet. Estos

nombres siempre se basan en un

dominio de nivel superior apropiado,

según el tipo de organización o

ubicación geográfica donde se utiliza el

nombre.

"microsoft.com.", que es el nombre

de dominio de segundo nivel

registrado para Microsoft por el

registrador de nombres de dominio

DNS de Internet.

Subdominio

Nombres adicionales que puede crear

una organización derivados del nombre

de dominio registrado de segundo

nivel. Incluyen los nombres agregados

para desarrollar el árbol de nombres de

DNS en una organización y que la

dividen en departamentos o

ubicaciones geográficas.

"ejemplo.microsoft.com.", que es un

subdominio ficticio asignado por

Microsoft para utilizarlo en nombres

de ejemplo de documentación.

Nombre de

recurso o de

host

Nombres que representan una hoja en

el árbol DNS de nombres e identifican

un recurso específico. Normalmente, la

etiqueta situada más a la izquierda de

un nombre de dominio DNS identifica

un equipo específico en la red. Por

ejemplo, si un nombre de este nivel se

utiliza en un RR de host (A), éste se

utiliza para buscar la dirección IP del

equipo según su nombre de host.

"host-a.ejemplo.microsoft.com.",

donde la primera etiqueta ("host-a")

es el nombre de host DNS de un

equipo específico en la red.

Interpretar un nombre de dominio DNS

DNS tiene un método para anotar e interpretar la ruta de acceso completa de un nombre de

dominio DNS de forma similar a como se anotan o muestran las rutas de acceso completas

de archivos o directorios en el símbolo del sistema.

Por ejemplo, una ruta de acceso del árbol de directorios ayuda a indicar la ubicación exacta

de un archivo almacenado en el equipo. Para los equipos con Windows, la barra diagonal

inversa (\) indica cada nuevo directorio que dirige a la ubicación exacta de un archivo. Para

DNS, lo equivalente es un punto (.) que indica cada nuevo nivel de dominio que se utiliza

en un nombre.

Por ejemplo, para un archivo llamado Servicios, la ruta de acceso completa de este archivo

como se muestra en el símbolo del sistema de Windows será:


C:\Windows\System32\Drivers\Etc\Servicios

Para interpretar la ruta de acceso completa del archivo, el nombre se lee de izquierda a

derecha desde el grupo de información más alto o más general (unidad C:, la unidad donde

está almacenado el archivo) a su información más específica, el nombre de archivo

"Servicios". Este ejemplo muestra cinco niveles jerárquicos independientes que conducen a

la ubicación del archivo Servicios en la unidad C:

1. Carpeta raíz de la unidad C (C:\). 2. Carpeta raíz del sistema donde está instalado Windows (Windows). 3. Una carpeta del sistema donde están almacenados los componentes del sistema

(System32). 4. Una subcarpeta donde están almacenadas las unidades de dispositivos del sistema

(Drivers). 5. Una subcarpeta donde están almacenados archivos diversos utilizados por el sistema y los

controladores de dispositivos de red (Etc).

Para DNS, un ejemplo de un nombre de dominio con varios niveles es el siguiente, un

nombre de dominio completo (FQDN):

host-a.ejemplo.microsoft.com.

A diferencia del ejemplo de nombre de archivo, un FQDN de DNS, cuando se lee de

izquierda a derecha, va de la información más específica (el nombre DNS de un equipo

llamado "host-a") al grupo de información más alto o más general (el punto final (.) que

indica la raíz del árbol de nombres DNS). Este ejemplo muestra los cuatro niveles de

dominio DNS independientes que parten de la ubicación de host específica del "host-a":

1. Dominio "ejemplo", que corresponde a un subdominio donde el nombre de equipo "host-a" está registrado para su uso.

2. Dominio "microsoft", que corresponde al dominio principal que es la raíz del subdominio "ejemplo".

3. Dominio "com", que corresponde al dominio de nivel superior designado para ser usado por empresas u organizaciones comerciales y es la raíz del dominio "microsoft".

4. Punto final (.), que es un carácter de separación estándar que se utiliza para calificar el nombre de dominio DNS completo en el nivel raíz del árbol del espacio de nombres DNS.

Antecedentes de DNS e Internet

El Sistema de nombres de dominio (DNS) se desarrolló debido a la necesidad de

proporcionar un servicio de asignación de nombres a direcciones para los equipos en

Internet. Antes de presentar DNS en 1987, la asignación de nombres descriptivos de

equipos a direcciones IP se realizaba principalmente mediante el uso de un archivo estático

compartido, llamado archivo Hosts.

Originalmente, Internet era lo suficientemente pequeña para utilizar un archivo

administrado de forma centralizada que se publicaba y descargaba mediante FTP en los

sitios conectados a Internet. Periódicamente, cada sitio Internet actualizaba su copia del

archivo Hosts y se enviaban versiones actualizadas del mismo para reflejar los cambios en

la red.

Con el aumento del número de equipos en Internet, el hecho de tener una autoridad

centralizada para administrar un solo archivo Hosts para todos los host de Internet llegó a

ser inviable. El tamaño de este archivo aumentaba progresivamente, lo que hacía muy

pesado el mantenimiento y la distribución a todos los sitios de su versión actualizada más

reciente.

El sistema DNS estándar se desarrolló para proporcionar una alternativa a los archivos

Hosts. Los documentos RFC 1034 y 1035 especifican la mayor parte de los protocolos

básicos y se han agregado y actualizado con otros documentos RFC adicionales enviados al

Grupo de trabajo de ingeniería Internet (IETF, Internet Engineering Task Force). El

IETF revisa y aprueba nuevos borradores continuamente, de modo que los estándares para

DNS evolucionan y cambian en función de las necesidades.

Notas

Es necesario que los nombres de dominio DNS sean únicos en cada nivel, pero se pueden reutilizar etiquetas de nombres individuales en otros dominios. Por ejemplo, el nombre "servidorcorreo" se puede utilizar sólo una vez en los dominios ejemplo.microsoft.com y microsoft.com.

Los archivos Hosts se admiten como método de archivo estático local para asignar nombres de dominio DNS en equipos host a sus direcciones IP. Al iniciar el servicio de Cliente DNS, éste carga previamente todas las entradas asignadas que se han agregado a este archivo en las cachés de nombres DNS locales.

El archivo Hosts se encuentra en la carpeta raízSistema\System32\Drivers\Etc. Para ver o modificar este archivo, puede utilizar el Bloc de notas u otro procesador de texto.

Cómo funcionan las consultas DNS

Cuando un cliente DNS necesita buscar un nombre que se utiliza en un programa, consulta

los servidores DNS para resolver el nombre. Cada mensaje de consulta que envía el cliente

contiene tres grupos de información, que especifican una pregunta que tiene que responder

el servidor:

Un nombre de dominio DNS especificado, indicado como un nombre de dominio completo (FQDN)

Un tipo de consulta especificado, que puede establecer un registro de recursos por tipo o un tipo especializado de operación de consulta

Una clase especificada para el nombre de dominio DNS. Para servidores DNS de Windows, esto se debe especificar siempre como la clase Internet (IN).

Por ejemplo, el nombre especificado puede ser el nombre completo de un equipo, como

"host-a.ejemplo.microsoft.com.", y el tipo de consulta especificado para buscar un registro

de recursos de dirección (A) por ese nombre. Considere una consulta DNS como una

pregunta de un cliente a un servidor en dos partes, como "¿Tiene algún registro de recursos

de dirección (A) de un equipo llamado 'nombrehost.ejemplo.microsoft.com'?". Cuando el

cliente recibe una respuesta del servidor, lee e interpreta el registro de recursos A

respondido, y aprende la dirección IP del equipo al que preguntó por el nombre.

Las consultas DNS se resuelven de diferentes formas. A veces, un cliente responde a una

consulta localmente mediante la información almacenada en la caché obtenida de una

consulta anterior. El servidor DNS puede utilizar su propia caché de información de

registros de recursos para responder a una consulta. Un servidor DNS también puede

consultar o ponerse en contacto con otros servidores DNS en nombre del cliente solicitante

para resolver el nombre por completo y, a continuación, enviar una respuesta al cliente.

Este proceso se llama recursividad.

Además, el mismo cliente puede intentar ponerse en contacto con servidores DNS

adicionales para resolver un nombre. Cuando un cliente lo hace, utiliza consultas

adicionales e independientes en función de respuestas de referencia de los servidores. Este

proceso se llama iteración.

En general, el proceso de consulta DNS se realiza en dos partes:

La consulta de un nombre comienza en un equipo cliente y se pasa al solucionador, el servicio Cliente DNS, para proceder a su resolución.

Cuando la consulta no se puede resolver localmente, se puede consultar a los servidores DNS según sea necesario para resolver el nombre.

Estos dos procesos se detallan en las secciones siguientes.

Parte 1: el solucionador local

En la figura siguiente se muestra un resumen del proceso de consulta DNS completo.

Como se muestra en los pasos iniciales del proceso de consulta, en un programa del equipo

local se utiliza un nombre de dominio DNS. A continuación, la solicitud se pasa al servicio

Cliente DNS para proceder a su resolución mediante la información almacenada en la caché

local. Si se puede resolver el nombre consultado, se responde a la consulta y el proceso

finaliza.

La caché del solucionador local puede incluir información de nombres obtenida de dos

orígenes posibles:

Si un archivo Hosts está configurado localmente, las asignaciones de nombre a dirección de host de ese archivo se cargan previamente en la caché cuando se inicia el servicio Cliente DNS.

Los registros de recursos obtenidos en las respuestas de consultas DNS anteriores se agregan a la caché y se mantienen durante un período.

Si la consulta no coincide con una entrada de la caché, el proceso de resolución continúa

con la consulta del cliente al servidor DNS para resolver el nombre.

Parte 2: consultar un servidor DNS

Como se indicó en la figura anterior, el cliente consulta un servidor DNS preferido. El

servidor real utilizado durante la parte de la consulta inicial cliente-servidor del proceso se

selecciona de una lista global. Para obtener más información acerca de cómo se compila y

se actualiza esta lista global, vea Características del cliente.

Cuando el servidor DNS recibe una consulta, primero comprueba si puede responder la

consulta con autoridad en función de la información de registro de recursos contenida en

una zona configurada localmente en el servidor. Si el nombre consultado coincide con un

registro de recursos correspondiente en la información de zona local, el servidor responde

con autoridad y usa esta información para resolver el nombre consultado.

Si no existe ninguna información de zona para el nombre consultado, a continuación el

servidor comprueba si puede resolver el nombre mediante la información almacenada en la

caché local de consultas anteriores. Si aquí se encuentra una coincidencia, el servidor

responde con esta información. De nuevo, si el servidor preferido puede responder al

cliente solicitante con una respuesta coincidente de su caché, finaliza la consulta.

Si el nombre consultado no encuentra una respuesta coincidente en su servidor preferido, ya

sea en su caché o en su información de zona, el proceso de consulta puede continuar y se

usa la recursividad para resolver completamente el nombre. Esto implica la asistencia de

otros servidores DNS para ayudar a resolver el nombre. De forma predeterminada, el

servicio Cliente DNS solicita al servidor que utilice un proceso de recursividad para

resolver completamente los nombres en nombre del cliente antes de devolver una respuesta.

En la mayor parte de los casos, el servidor DNS se configura, de forma predeterminada,

para admitir el proceso de recursividad como se muestra en el gráfico siguiente.


Para que el servidor DNS realice la recursividad correctamente, primero necesita

información de contacto útil acerca de los otros servidores DNS del espacio de nombres de

dominio DNS. Esta información se proporciona en forma de sugerencias de raíz, una lista

de los registros de recursos preliminares que puede utilizar el servicio DNS para localizar

otros servidores DNS que tienen autoridad para la raíz del árbol del espacio de nombres de

dominio DNS. Los servidores raíz tienen autoridad para el dominio raíz y los dominios de

nivel superior en el árbol del espacio de nombres de dominio DNS.

Un servidor DNS puede completar el uso de la recursividad utilizando las sugerencias de

raíz para encontrar los servidores raíz. En teoría, este proceso permite a un servidor DNS

localizar los servidores que tienen autoridad para cualquier otro nombre de dominio DNS

que se utiliza en cualquier nivel del árbol del espacio de nombres.

Por ejemplo, piense en la posibilidad de usar el proceso de recursividad para localizar el

nombre "host-b.ejemplo.microsoft.com." cuando el cliente consulte un único servidor DNS.

El proceso ocurre cuando un servidor y un cliente DNS se inician y no tienen información

almacenada en la caché local disponible para ayudar a resolver la consulta de un nombre. El

servidor supone que el nombre consultado por el cliente es para un nombre de dominio del

que el servidor no tiene conocimiento local, según sus zonas configuradas.

Primero, el servidor preferido analiza el nombre completo y determina que necesita la

ubicación del servidor con autoridad para el dominio de nivel superior, "com". A

continuación, utiliza una consulta iterativa al servidor DNS "com" para obtener una

referencia al servidor "microsoft.com". Después, desde el servidor "microsoft.com" se

proporciona una respuesta de referencia al servidor DNS para "ejemplo.microsoft.com".

Finalmente, se entra en contacto con el servidor "ejemplo.microsoft.com.". Ya que este

servidor contiene el nombre consultado como parte de sus zonas configuradas, responde

con autoridad al servidor original que inició la recursividad. Cuando el servidor original

recibe la respuesta que indica que se obtuvo una respuesta con autoridad a la consulta

solicitada, reenvía esta respuesta al cliente solicitante y se completa el proceso de consulta

recursiva.

Aunque el proceso de consulta recursiva puede usar muchos recursos cuando se realiza

como se describe anteriormente, tiene algunas ventajas en el rendimiento para el servidor

DNS. Por ejemplo, durante el proceso de recursividad, el servidor DNS que realiza la

búsqueda recursiva obtiene información acerca del espacio de nombres de dominio DNS.

Esta información se almacena en la caché del servidor y se puede utilizar de nuevo para

ayudar a acelerar la obtención de respuestas a consultas subsiguientes que la utilizan o

concuerdan con ella. Con el tiempo, esta información almacenada en caché puede crecer

hasta ocupar una parte significativa de los recursos de memoria del servidor, aunque se

limpia siempre que el servicio DNS se activa y desactiva.

Respuestas de consultas alternativas

En las afirmaciones anteriores acerca de las consultas DNS se supone que el proceso

finaliza con una respuesta positiva devuelta al cliente. Sin embargo, las consultas también

pueden devolver otras respuestas. Las más habituales son:

Una respuesta con autoridad Una respuesta positiva Una respuesta de referencia Una respuesta negativa

Una respuesta con autoridad es una respuesta positiva devuelta al cliente y entregada con el

bit de autoridad activado en el mensaje DNS para indicar que la respuesta se obtuvo de un

servidor con autoridad directa para el nombre consultado.

Una respuesta positiva puede estar formada por el registro de recursos consultado o por una

lista de registros de recursos (también llamada RRset) que se ajusta al nombre de dominio

DNS consultado y el tipo de registro especificado en el mensaje de la consulta.

Una respuesta de referencia contiene registros de recursos adicionales no especificados por

el nombre o el tipo de la consulta. Si el proceso de recursividad no se admite, se devuelve al

cliente este tipo de respuesta. Los registros deben actuar como respuestas de referencia

útiles que el cliente puede utilizar para continuar la consulta mediante la iteración.

Una respuesta de referencia contiene datos adicionales como registros de recursos (RR)

distintos de los del tipo consultado. Por ejemplo, si el nombre de host consultado era

"www" y no se encontró ningún registro de recursos de dirección (A) para este nombre en

esta zona pero, en su lugar, se encontró un registro de recursos de CNAME para "www", el

servidor DNS puede incluir esa información cuando responda al cliente.

Si el cliente puede utilizar la iteración, puede hacer consultas adicionales con la

información de referencia en un intento de resolver completamente el nombre por sí mismo.

Una respuesta negativa del servidor puede indicar que se encontró uno de los dos resultados

posibles mientras el servidor intentaba procesar y resolver de forma recursiva la consulta

completamente y con autoridad:

Un servidor con autoridad informó de que el nombre consultado no existe en el espacio de nombres DNS.

Un servidor con autoridad informó de que el nombre consultado existe, pero no existen registros del tipo especificado para ese nombre.

El solucionador devuelve el resultado de la consulta, en forma de respuesta positiva o

negativa, al programa solicitante y almacena en caché la respuesta.

Notas

Si la respuesta resultante de una consulta es demasiado larga para poderla enviar y resolver en un sólo paquete de mensaje UDP, el servidor DNS puede iniciar una respuesta de conmutación por error a través del puerto 53 de TCP para responder al cliente completamente en una sesión conectada de TCP.

Generalmente, se deshabilita el uso de la recursividad en un servidor DNS cuando los clientes DNS se limitan a la resolución de nombres en un servidor DNS específico, como el que se encuentra en una intranet. También se puede deshabilitar la recursividad cuando el servidor DNS no puede resolver nombres DNS externos y se espera que los clientes conmuten por error a otro servidor DNS para la resolución de estos nombres. Puede deshabilitar el uso de la recursividad mediante la configuración de las propiedades Avanzadas en la consola DNS del servidor correspondiente..

Si deshabilita la recursividad en el servidor DNS, no podrá utilizar reenviadores en el mismo servidor.

De forma predeterminada, los servidores DNS utilizan varios tiempos predeterminados cuando realizan una consulta recursiva y se ponen en contacto con otros servidores DNS. Son los siguientes:

o Un intervalo de reintento de recursividad de tres segundos. Éste es el tiempo que espera el servicio DNS antes de reintentar una consulta realizada durante una búsqueda recursiva.

o Un intervalo de tiempo de espera de recursividad de quince segundos. Se trata del tiempo que espera el servicio DNS antes de dar como errónea una búsqueda recursiva que se ha reintentado.

Cómo funciona la iteración

La iteración es el tipo de resolución de nombres que se utiliza entre clientes y servidores

DNS cuando se dan las condiciones siguientes:

El cliente solicita el uso de la recursividad, pero ésta se encuentra deshabilitada en el servidor DNS.

El cliente no solicita el uso de la recursividad cuando consulta el servidor DNS.

Una solicitud iterativa de un cliente informa al servidor DNS de que el cliente espera la

mejor respuesta que el servidor DNS pueda proporcionar inmediatamente, sin entrar en

contacto con otros servidores DNS.

Cuando se utiliza la iteración, un servidor DNS responde al cliente en función de su propio

conocimiento específico acerca del espacio de nombres, sin tener en cuenta los datos de los

nombres que se están consultando. Por ejemplo, si un servidor DNS de una intranet recibe

una consulta de un cliente local para "www.microsoft.com", es posible que devuelva una

respuesta de su caché de nombres. Si el nombre consultado no está almacenado actualmente

en la caché de nombres del servidor, puede que, para responder, el servidor proporcione

una referencia, es decir, una lista de registros de recursos de dirección (A) y de servidor de

nombres (NS) para otros servidores DNS que estén más cerca del nombre consultado por el

cliente.

Cuando se proporciona una referencia, el cliente DNS asume la responsabilidad de

continuar efectuando consultas iterativas a otros servidores DNS configurados para resolver

el nombre. Por ejemplo, en el caso más complicado, el cliente DNS puede expandir su

búsqueda a los servidores de dominio raíz en Internet en un esfuerzo por localizar los

servidores DNS que tienen autoridad para el dominio "com". Una vez en contacto con los

servidores raíz de Internet, puede recibir más respuestas iterativas de estos servidores DNS

que señalan a los servidores DNS de Internet reales para el dominio "microsoft.com".

Cuando se proporcionan registros de estos servidores DNS al cliente, éste puede enviar otra

consulta iterativa a los servidores DNS externos de Microsoft en Internet, que pueden

responder con una respuesta definitiva y con autoridad.

Cuando se utiliza la iteración, un servidor DNS puede ayudar en la resolución de la

consulta de un nombre además de devolver su mejor respuesta propia al cliente. En la

mayor parte de las consultas iterativas, un cliente utiliza su lista de servidores DNS

configurada localmente para entrar en contacto con otros servidores de nombres a través del

espacio de nombres DNS si su servidor DNS principal no puede resolver la consulta.

Cómo funciona el almacenamiento en caché

El almacenamiento en caché aumenta el rendimiento de la resolución DNS para las

consultas subsiguientes de nombres muy utilizados, al tiempo que reduce sustancialmente

el tráfico de las consultas relativas a DNS en la red.

Cuando los servidores DNS realizan consultas recursivas en nombre de clientes, almacenan

temporalmente en caché los registros de recursos. Los registros de recursos almacenados en

caché contienen información obtenida de los servidores DNS que tienen autoridad para los

nombres de dominio DNS aprendidos durante las consultas iterativas para buscar y

responder por completo una consulta recursiva realizada en nombre de un cliente.

Posteriormente, cuando otros clientes realizan consultas nuevas que solicitan información

de un registro de recursos que coincide con los registros de recursos almacenados en la

caché, el servidor DNS puede utilizar la información de registro de recursos almacenada en

la caché para responderlas.

Cuando la información se almacena en la caché, se aplica el valor Tiempo de vida (TTL) a

todos los registros de recursos almacenados en la caché. Mientras el tiempo de vida de un

registro de recursos almacenado en la caché no caduque, un servidor DNS puede seguir

almacenando el registro de recursos en la caché y utilizándolo de nuevo al responder a

consultas de sus clientes que coincidan con estos registros de recursos. Al valor de los TTL

del almacenamiento en caché usados por los registros de recursos en la mayor parte de las

configuraciones de zona se le asigna el TTL mínimo (predeterminado) que se utiliza en el

registro de recursos de inicio de autoridad (SOA) de la zona. De forma predeterminada, el

tiempo de vida mínimo es de 3.600 segundos (1 hora), pero se puede ajustar o, si es

necesario, se pueden establecer tiempos de vida individuales de almacenamiento en caché

para cada registro de recursos.

Notas

Puede instalar un servidor DNS como servidor de sólo caché. De forma predeterminada, los servidores DNS utilizan un archivo de sugerencias de raíz,

Cache.dns, que se almacena en la carpeta raízSistema\System32\Dns del equipo servidor. El contenido de este archivo se carga previamente en la memoria del servidor cuando se inicia el servicio y contiene información de punteros a servidores raíz para el espacio de nombres DNS donde funcionan los servidores DNS.

Búsqueda inversa

En la mayor parte de las búsquedas DNS, los clientes normalmente realizan una búsqueda

directa, que es la que se basa en el nombre DNS de otro equipo según se almacenó en un

registro de recursos de dirección (A). Este tipo de consulta espera una dirección IP como

datos de recurso para la respuesta a la consulta.

DNS también proporciona un proceso de búsqueda inversa, que permite a los clientes

utilizar una dirección IP conocida durante la búsqueda de un nombre y busca un nombre de

equipo en función de su dirección. Una búsqueda inversa tiene forma de pregunta, como

"¿Puede decirme el nombre DNS del equipo que utiliza la dirección IP 192.168.1.20?".

DNS no se diseñó originalmente para aceptar este tipo de consulta. Un problema de

compatibilidad con el proceso de consulta inversa es la diferencia en la forma en que el

espacio de nombres DNS organiza e indiza los nombres, y cómo se asignan las direcciones

IP. Si el único método para responder a la pregunta anterior fuera buscar en todos los

dominios del espacio de nombres DNS, una consulta inversa llevaría demasiado tiempo y

requeriría un procesamiento demasiado largo como para ser útil.

Para resolver este problema, en el estándar DNS se definió y se reservó un dominio

especial, el dominio in-addr.arpa, en el espacio de nombres DNS de Internet con el fin de

proporcionar una forma práctica y confiable para realizar las consultas inversas. Al crear el

espacio de nombres inverso, los subdominios del dominio in-addr.arpa se crean con el

orden inverso de los números en la notación decimal con puntos de las direcciones IP.

Este orden inverso de los dominios para el valor de cada octeto es necesario porque, a

diferencia de los nombres DNS, cuando se leen las direcciones IP de izquierda a derecha se

interpretan al contrario. Cuando se lee una dirección IP de izquierda a derecha, se ve desde

su información más general (una dirección IP de red) en la primera parte de la dirección a

la información más específica (una dirección IP de host) que contienen los últimos octetos.

Por esta razón, se debe invertir el orden de los octetos de las direcciones IP cuando se crea

el árbol del dominio in-addr.arpa. Las direcciones IP del árbol DNS in-addr.arpa se pueden

delegar a las organizaciones ya que se les asigna un conjunto de direcciones IP específico o

limitado en las clases de direcciones definidas en Internet.

Finalmente, el árbol del dominio in-addr.arpa, tal como se crea en DNS, requiere que se

defina un tipo de registro de recursos (RR) adicional, el registro de recursos de puntero

(PTR). Este registro de recursos se utiliza para crear una asignación en la zona de búsqueda

inversa que, normalmente, corresponde a un registro de recurso de dirección (A) de host

con nombre para el nombre del equipo DNS de un host en su zona de búsqueda directa.

Nota

El dominio in-addr.arpa se usa en todas las redes TCP/IP que se basan en el direccionamiento del Protocolo de Internet versión 4 (IPv4). El Asistente para crear zona nueva supone de forma automática que se usa este dominio cuando se crea una zona de búsqueda inversa nueva. Si está instalando DNS y configurando zonas de búsqueda inversa en una red con el Protocolo de Internet versión 6 (IPv6), puede especificar un nombre exacto en el Asistente para crear zona nueva. Esto le permitirá crear zonas de búsqueda inversa en la consola DNS que se puedan usar para admitir redes IPv6, que usan un nombre de dominio especial diferente, el dominio ip6.arpa.

Ejemplo: consulta inversa (para redes IPv4)

En el gráfico siguiente se muestra un ejemplo de una consulta inversa iniciada por un

cliente DNS (host-b) para aprender el nombre de otro host (host-a) basándose en su

dirección IP, 192.168.1.20.

El proceso de búsqueda inversa que se muestra en este gráfico se produce en los siguientes

pasos:

1. El cliente, "host-b", consulta al servidor DNS un registro de recursos de puntero (PTR) que asigna la dirección IP 192.168.1.20 a "host-a". Ya que esta consulta se realiza en los registros de puntero, el solucionador invierte la

dirección y agrega el dominio in-addr.arpa al final de la dirección inversa. De esta manera, forma el nombre de dominio completo ("20.1.168.192.in-addr.arpa.") que se va a buscar en una zona de búsqueda inversa.

2. Una vez localizado, el servidor DNS con autoridad en "20.1.168.192.in-addr.arpa" puede responder con la información del registro de puntero PTR. Esto incluye el nombre de dominio DNS para "host-a", lo que completa el proceso de búsqueda inversa.

Tenga en cuenta que, si el servidor DNS no puede responder el nombre de la consulta

inversa, se puede utilizar la resolución DNS normal (ya sea la recursividad o la iteración)

para localizar un servidor DNS con autoridad para la zona de búsqueda inversa y que

contenga el nombre consultado. En este sentido, el proceso de resolución de nombres

utilizado en una búsqueda inversa es idéntico al de una búsqueda directa.

Nota

La consola DNS permite configurar una zona de búsqueda inversa con subredes "sin clases" cuando se selecciona la vista Avanzada. Esto permite configurar una zona en el dominio in-addr.arpa para un conjunto limitado de direcciones IP asignadas donde se utiliza una máscara de subred IP sin predeterminar con estas direcciones.

Las consultas inversas son una práctica anticuada. Originalmente se propusieron como

parte del estándar DNS para buscar un nombre de host en función de su dirección IP.

Utilizan una operación de consulta DNS no estándar y su uso se limita a algunas versiones

anteriores de Nslookup, una utilidad de la línea de comandos para solucionar problemas y

probar el servicio DNS.

El servicio DNS reconoce y acepta los mensajes de consultas inversas y los responde con

una respuesta de consulta inversa falsa.

Notas

La configuración de registros de recursos de puntero (PTR) y zonas de búsqueda inversa para identificar hosts mediante consultas inversas constituye meramente una parte opcional de la implementación DNS estándar. No tiene por qué utilizar las zonas de búsqueda inversa, si bien algunas aplicaciones de red las necesitan, se utilizan para realizar comprobaciones de seguridad.

Las direcciones web pueden cambiar, por lo que es posible que no pueda conectar con el sitio o los sitios web mencionados aquí.

Descripción de los reenviadores

Un reenviador es un servidor de Sistema de nombres de dominio (DNS) de una red que se

utiliza para reenviar consultas DNS para nombres DNS externos a servidores DNS que se

encuentran fuera de la red. También se pueden enviar consultas según nombres de dominio

específicos utilizando reenviadores condicionales.



Un servidor DNS de una red se designa como reenviador haciendo que los demás

servidores DNS de la red le reenvíen las consultas que no pueden resolver localmente. Al

utilizar un reenviador, se puede administrar la resolución de los nombres fuera de la red,

como nombres en Internet, y mejorar la eficacia de la resolución de nombres para los

equipos de la red.

En la figura siguiente se ilustra cómo se dirigen las consultas de nombres externos mediante

reenviadores.

Si no se designa un servidor DNS específico como reenviador, todos los servidores DNS

pueden enviar consultas fuera de una red utilizando sus sugerencias de raíz. Como

resultado, puede quedar expuesta en Internet una gran cantidad de información DNS interna

y posiblemente fundamental. Además de este problema de seguridad y privacidad, este

método de resolución puede producir un gran volumen de tráfico externo que resulta

costoso e ineficiente para una red con una conexión a Internet lenta o una compañía con

altos costes de servicio de Internet.

Al designar un servidor DNS como reenviador, éste será el responsable de controlar el

tráfico externo, por lo que limitará la exposición del servidor DNS a Internet. Un

reenviador generará una memoria caché de gran tamaño con información DNS externa,

puesto que todas las consultas DNS externas de la red se resuelven a través de ella. En poco

tiempo, los servidores de envío resuelven una parte considerable de consultas DNS externas

utilizando estos datos almacenados en la caché y, por tanto, disminuyen el tráfico de

Internet a través de la red y el tiempo de respuesta para los clientes DNS.

Un servidor DNS configurado para utilizar un reenviador se comportará de manera

diferente que un servidor DNS que no esté configurado para utilizar un reenviador. Un

servidor DNS configurado para utilizar un reenviador se comporta de la siguiente manera:

1. Cuando el servidor DNS recibe una consulta, intenta resolverla utilizando las zonas principal y secundaria que aloja y su caché.

2. Si no se puede resolver la consulta utilizando estos datos locales, reenviará la consulta al servidor DNS designado como reenviador.

3. El servidor DNS esperará brevemente una respuesta del reenviador antes de intentar ponerse en contacto con los servidores DNS especificados en sus sugerencias de raíz.

Cuando un servidor DNS envía una consulta a un reenviador, envía una consulta recursiva

al reenviador. Esto es diferente de la consulta iterativa que un servidor DNS enviará a otro

servidor DNS durante la resolución de nombres estándar (resolución de nombres que no

implica un reenviador).

Reenviadores condicionales

Un reenviador condicional es un servidor DNS de una red que se utiliza para reenviar

consultas DNS de acuerdo con el nombre de dominio DNS de la consulta. Por ejemplo, se

puede configurar un servidor DNS de modo que reenvíe todas las consultas que reciba para

los nombres que terminen con widgets.ejemplo.com a la dirección IP de un servidor DNS

específico o a las direcciones IP de varios servidores DNS.

Resolución de nombres de intranet

Se puede utilizar un reenviador condicional para mejorar la resolución de nombres para

dominios dentro de la intranet. La resolución de nombres de intranet puede mejorarse

mediante la configuración de servidores DNS con reenviadores para nombres de dominio

internos específicos. Por ejemplo, todos los servidores DNS del dominio

widgets.ejemplo.com puede configurarse para reenviar consultas para nombres que

terminen con prueba.ejemplo.como para servidores DNS autorizados para

merged.widgets.ejemplo.com, eliminando de esta manera el paso de consultar a los

servidores raíz de ejemplo.com, o bien eliminando el paso de configurar servidores DNS en

la zona widgets.ejemplo.com con zonas secundarias para prueba.ejemplo.com.

Resolución de nombres de Internet

Los servidores DNS pueden utilizar reenviadores condicionales para resolver consultas

entre los nombres de dominio DNS de organizaciones que compartan información. Por

ejemplo, las compañías Widgets Toys y TailspinToys quieren mejorar la forma en que los

clientes DNS de Widgets Toys resuelven los nombres de los clientes DNS de Tailspin

Toys. Los administradores de Tailspin Toys informan a los administradores de Widgets

Toys acerca del conjunto de servidores DNS de la red de Tailspin Toys a la que Widgets

puede enviar consultas para el dominio muñecas.tailspintoys.com. Los servidores DNS de

la red de Widgets Toys están configurados para reenviar todas las consultas para nombres

que terminen con muñecas.tailspintoys.com a los servidores DNS designados en la red para

Tailspin Toys. Por consiguiente, los servidores DNS de la red de Widgets Toys no

necesitan consultar sus servidores raíz internos ni los servidores raíz de Internet para

resolver consultas de nombres que terminen con muñecas.tailspintoys.com

Descripción de las zonas de código auxiliar


Descripción de las zonas de código auxiliar

Una zona de código auxiliar es una copia de una zona que contiene sólo aquellos registros

de recursos necesarios para identificar los servidores de Sistema de nombres de dominio

(DNS) autorizados para dicha zona. La zona de código auxiliar se utiliza para resolver

nombres entre espacios de nombres DNS independientes. Este tipo de resolución puede ser

necesaria cuando una fusión de empresa requiere que los servidores DNS de dos espacios

de nombres DNS independientes resuelvan nombres para clientes en ambos espacios de

nombres.

Una zona de código auxiliar consta de:

El registro de recursos de inicio de autoridad (SOA), registros de recursos de servidor de nombres (NS) y registros de recursos A de adherencia para la zona delegada.

La dirección IP de uno o más servidores maestros que puede utilizarse para actualizar la zona de código auxiliar.

Los servidores maestros de una zona de código auxiliar son uno o varios servidores DNS

autorizados para la zona secundaria; normalmente el servidor DNS que aloja la zona

principal del nombre de dominio delegado.

Para obtener más información, vea Utilizar zonas de código auxiliar.

Resolución de zonas de código auxiliar

Cuando un cliente DNS realiza una operación de consulta recursiva en un servidor DNS

que aloja una zona de código auxiliar, el servidor DNS utiliza los registros de recursos de la

zona de código auxiliar para resolver la consulta. El servidor DNS envía una consulta

iterativa a los servidores DNS autorizados especificados en los registros de recursos NS de

la zona de código auxiliar como si estuviera utilizando registros de recursos NS de la caché.

Si el servidor DNS no puede encontrar los servidores DNS autorizados de su zona de

código auxiliar, el servidor DNS que aloja la zona de código auxiliar intenta la recursividad

estándar utilizando sus sugerencias de raíz.

El servidor DNS almacenará los registros de recursos que reciba de los servidores DNS

autorizados enumerados en una zona de código auxiliar de su caché, pero no almacenará

estos registros de recursos en la propia zona de código auxiliar; ya que sólo los registros de

recursos SOA, NS y A de adherencia devueltos como respuesta a la consulta se almacenan

en la zona de código auxiliar. Los registros de recursos almacenados en la caché se guardan

en la memoria según el valor de Tiempo de vida (TTL) de cada registro de recursos. Los



registros de recursos SOA, NS y A de adherencia, que no están grabados en la caché,

caducan según el intervalo de caducidad especificado en el registro SOA de la zona de

código auxiliar, que se genera durante la creación de la zona de código auxiliar y se

actualiza durante las transferencias a la zona de código auxiliar desde la zona principal

original.

Si la consulta era iterativa, el servidor DNS devuelve una referencia que contiene los

servidores especificados en la zona de código auxiliar.

Comunicación entre servidores DNS que alojan zonas

principales y secundarias

Un servidor DNS que ha delegado un dominio a una zona secundaria de otro servidor DNS

conoce los nuevos servidores DNS autorizados para la zona secundaria sólo cuando los

registros de recursos de estos nuevos servidores DNS se agregan a la zona principal alojada

en el servidor DNS. Este proceso debe hacerse manualmente y requiere que los

administradores de los diferentes servidores DNS se comuniquen con frecuencia. Con las

zonas de código auxiliar, un servidor DNS que aloja una zona de código auxiliar para uno

de sus dominios delegados puede obtener actualizaciones de los servidores DNS

autorizados para la zona secundaria cuando se actualiza la zona de código auxiliar. La

actualización se realiza desde el servidor DNS que aloja la zona de código auxiliar y no es

necesario ponerse en contacto con el administrador del servidor DNS que aloja la zona

secundaria. Esta funcionalidad se explica en el siguiente ejemplo.

Situación de zona de código auxiliar

Un servidor DNS autorizado para la zona principal, ejemplo.com, ha delegado un

subdominio, widgets.ejemplo.com, a servidores DNS independientes. Cuando la delegación

del dominio widgets.ejemplo.com se realizó originalmente, la zona principal contenía sólo

dos registros NS para los servidores DNS autorizados de la zona widgets.ejemplo.com.

Posteriormente, los administradores de la zona secundaria configuraron otros servidores

DNS adicionales autorizándolos para la zona, pero no se lo notificaron a los

administradores del servidor DNS que aloja la zona principal, ejemplo.com. En

consecuencia, el servidor DNS que aloja la zona principal, ejemplo.com, no conoce los

nuevos servidores DNS autorizados para su zona secundaria, widgets.ejemplo.com, y

continúa consultando a los dos únicos servidores DNS autorizados que conoce.

Esta situación se puede remediar configurando el servidor DNS autorizado para la zona

principal, ejemplo.com, de forma que aloje una zona de código auxiliar para el dominio

delegado, widgets.ejemplo.com. Cuando el administrador del servidor DNS autorizado para

ejemplo.com actualiza la zona de código auxiliar, consulta a los servidores maestros de la

zona de código auxiliar para obtener los registros de recursos de servidores DNS

autorizados para widgets.ejemplo.com. Por consiguiente, el servidor DNS autorizado para

la zona principal conocerá los nuevos servidores DNS autorizados para la zona secundaria

widgets.ejemplo.com y podrá llevar a cabo la recursividad en todos los servidores DNS

autorizados de la zona secundaria.

En la figura siguiente se muestra cómo una zona de código auxiliar alojada en el mismo

servidor DNS que la zona principal actualiza los datos del servidor autorizado para la zona

secundaria.

Para obtener más información, vea Active Directory-integrated stub zones, Descripción de

las zonas y de la transferencia de zonas y Delegar zonas.

Actualización dinámica


Actualización dinámica

La actualización dinámica permite a los equipos cliente DNS guardar y actualizar

dinámicamente sus registros de recursos con un servidor DNS siempre que se produzcan

cambios. Esto disminuye la necesidad de administrar de forma manual los registros de

zona, especialmente para los clientes que mueven o cambian ubicaciones con frecuencia y

utilizan DHCP para obtener una dirección IP.

Los servicios de Cliente y Servidor DNS admiten el uso de actualizaciones dinámicas, tal

como se describe en el documento de Solicitud de comentarios (RFC) 2136, relativo a las

actualizaciones dinámicas en el Sistema de nombres de dominio. El servicio Servidor DNS

permite habilitar o deshabilitar la actualización dinámica por zonas en cada servidor

configurado para cargar una zona principal estándar o integrada en directorio. De forma

predeterminada, el servicio de Cliente DNS actualizará dinámicamente los registros de

recursos (RR) de host (A) en DNS cuando esté configurado para TCP/IP. Para obtener más

información sobre documentos RFC, vea RFC de DNS.

Cómo actualizan sus nombres DNS los equipos cliente y servidor

De forma predeterminada, los equipos configurados estáticamente para TCP/IP intentan

registrar dinámicamente los registros de recursos (RR) de host (A) y punteros (PTR) para

las direcciones IP configuradas y utilizadas por sus conexiones de red instaladas. De forma

predeterminada, todos los equipos guardan los registros según sus nombres de dominio

completos (FQDN).

El nombre de equipo principal completo, un FQDN, se basa en el sufijo DNS principal de

un equipo agregado a su Nombre de equipo.

Estos dos valores se muestran o configuran en la ficha Nombre de equipo en Propiedades

del sistema. Para obtener más información, vea Ver las propiedades del sistema.








Notas

De forma predeterminada, el cliente DNS de Windows XP no intenta realizar actualizaciones dinámicas en una conexión de Servicio de acceso remoto (RAS) o de red privada virtual (VPN). Para cambiar esta configuración, puede modificar las opciones avanzadas de TCP/IP de la conexión de red particular, o bien modificar el Registro. Para obtener más información, vea Configurar TCP/IP para utilizar DNS y el sitio Web de kits de recursos de Microsoft Windows.

De forma predeterminada, el cliente DNS no intenta realizar actualizaciones dinámicas de zonas de dominio de nivel superior (TLD). Cualquier zona con un nombre de etiqueta única se considera una zona TLD; por ejemplo, com, edu, en blanco o mi-empresa. Para configurar el cliente DNS de modo que permita la actualización dinámica de zonas TLD, puede utilizar la configuración de directiva Actualización de zonas de dominio de nivel superior, o bien modificar el Registro.

De forma predeterminada, la parte del sufijo DNS principal del nombre de dominio completo (FQDN) de un equipo coincide con la del nombre del dominio de Active Directory al que se une el equipo. Para permitir diferentes sufijos de DNS principales, un administrador de dominio puede crear una lista restringida de sufijos permitidos mediante la modificación del atributo msDS-AllowedDNSSuffixes en el contenedor de objetos del dominio. Este atributo lo crea y administra el administrador del dominio mediante Interfaces de servicio de Active Directory (ADSI) o el Protocolo ligero de acceso a directorios (LDAP). Para obtener más información, vea Interfaces de programación y Protocolo de acceso al directorio.

Las actualizaciones dinámicas se pueden enviar por cualquiera de las siguientes razones o

sucesos:

Se agregó, quitó o modificó una dirección IP en la configuración de propiedades de TCP/IP para una de las conexiones de red instaladas.

Una concesión de dirección IP cambia o renueva con el servidor DHCP cualquiera de las conexiones de red instaladas. Por ejemplo, cuando se inicia el equipo o si se utiliza el comando ipconfig /renew.

El comando ipconfig /registerdns se utiliza para forzar manualmente una actualización del registro de nombres de clientes en DNS.

En el inicio, cuando se enciende el equipo. Un servidor miembro se promueve a un controlador de dominio.

Cuando uno de los sucesos anteriores activa una actualización dinámica, el servicio Cliente

DHCP (no el servicio Cliente DNS) envía las actualizaciones. Este proceso se ha diseñado

de forma que, si se produce un cambio en la información de la dirección IP a causa de

DHCP, se realicen las actualizaciones correspondientes en DNS para sincronizar las

asignaciones de nombre a dirección para el equipo. El servicio Cliente DHCP realiza esta

función para todas las conexiones de red utilizadas en el sistema, incluidas las conexiones

no configuradas para utilizar DHCP.

Notas


http://go.microsoft.com/fwlink/?LinkId=428





La forma en que se realizan las actualizaciones dinámicas para los equipos que ejecutan los sistemas operativos Windows 2000, Windows XP o Windows Server 2003 que usan DHCP para obtener sus direcciones IP es diferente de la descrita en esta sección. Para obtener más información, vea Usar servidores DNS con DHCP.

En el proceso de actualización descrito en esta sección se da por sentado que se aplican las opciones predeterminadas de instalación para equipos que ejecutan Windows 2000, Windows XP o servidores que ejecutan Windows Server 2003. Los nombres específicos y el comportamiento de la actualización se pueden ajustar donde se configuran las propiedades de TCP/IP avanzadas para utilizar valores de DNS no predeterminados. Además del nombre completo (o principal) del equipo, se pueden configurar y, opcionalmente, registrar o actualizar en DNS los nombres DNS adicionales específicos para la conexión. Para obtener más información, vea Configurar varios nombres o Configurar TCP/IP para utilizar DNS.

Ejemplo: cómo funciona la actualización dinámica

Las actualizaciones dinámicas normalmente se solicitan cuando cambia en el equipo un

nombre DNS o una dirección IP. Por ejemplo, suponga que un cliente llamado

"antiguohost" se configuró en Propiedades del sistema con los nombres siguientes:

Nombre de equipo antiguohost

Nombre de dominio DNS del equipo ejemplo.microsoft.com

Nombre completo de equipo antiguohost.ejemplo.microsoft.com

En este ejemplo, no se configuraron para el equipo nombres de dominio DNS específicos

de la conexión. Más tarde, se cambió el nombre del equipo de "antiguohost" a "nuevohost",

lo que conlleva los cambios de nombre siguientes en el sistema:

Nombre de equipo nuevohost

Nombre de dominio DNS del equipo ejemplo.microsoft.com

Nombre completo de equipo nuevohost.ejemplo.microsoft.com

Una vez aplicado el cambio de nombre en Propiedades del sistema, se le pedirá que

reinicie el equipo. Cuando el equipo reinicia Windows, el servicio Cliente DHCP realiza la

siguiente secuencia para actualizar DNS:

1. El servicio Cliente DHCP envía una consulta de tipo inicio de autoridad (SOA) con el nombre de dominio DNS del equipo. El equipo cliente utiliza el nombre completo actualmente configurado del equipo (como "nuevohost.ejemplo.microsoft.com") como el nombre especificado en esta consulta.

2. El servidor DNS autorizado para la zona que contiene el nombre completo del cliente responde a la consulta de tipo SOA. Para las zonas principales estándar, el servidor principal (propietario) devuelto en la





respuesta de la consulta de inicio de autoridad (SOA) es fijo y estático. Siempre coincide de forma exacta con el nombre DNS como aparece en el RR del SOA almacenado con la zona. Sin embargo, si la zona que se está actualizando está integrada en el directorio, cualquier servidor DNS que se carga en la zona puede responder e insertar dinámicamente su propio nombre como el servidor principal (propietario) de la zona en la respuesta de la consulta de inicio de autoridad.

3. A continuación, el servicio Cliente DHCP intenta ponerse en contacto con el servidor DNS principal. El cliente procesa la respuesta de la consulta de inicio de autoridad para su nombre con el fin de determinar la dirección IP del servidor DNS autorizado como servidor principal para aceptar su nombre. A continuación, ejecuta la siguiente secuencia de pasos según sea necesario para ponerse en contacto con su servidor principal y actualizarlo dinámicamente:

1. Envía una solicitud de actualización dinámica al servidor principal determinado en la respuesta de la consulta de inicio de autoridad. Si la actualización es correcta, no se realiza ninguna otra acción.

2. Si esta actualización es errónea, el siguiente cliente envía una consulta del tipo de servidor de nombres para el nombre de zona especificado en el registro de inicio de autoridad (SOA).

3. Cuando recibe una respuesta a esta consulta, envía una consulta de inicio de autoridad al primer servidor DNS que se enumera en la respuesta.

4. Después de resolver la consulta de inicio de autoridad, el cliente envía una actualización dinámica al servidor especificado en el registro SOA devuelto. Si la actualización es correcta, no se realiza ninguna otra acción.

5. Si esta actualización es errónea, a continuación, el cliente repite el proceso de la consulta de inicio de autoridad y la envía al siguiente servidor DNS enumerado en la respuesta.

4. Después de entrar en contacto con el servidor principal que puede realizar la actualización, el cliente envía la solicitud de actualización y el servidor la procesa. El contenido de la solicitud de actualización incluye instrucciones para agregar registros de recursos de host (A), y posiblemente de punteros (PTR), para "nuevohost.ejemplo.microsoft.com" y quita estos mismos tipos de registros para "antiguohost.ejemplo.microsoft.com", el nombre que se había registrado previamente. El servidor también comprueba si se permiten las actualizaciones para la solicitud del cliente. En las zonas principales estándar, las actualizaciones dinámicas no se aseguran, por lo que cualquier intento del cliente de realizar actualizaciones será correcto. Para las zonas integradas en Active Directory, las actualizaciones se aseguran y se realizan mediante la configuración de seguridad basada en directorios.

Las actualizaciones dinámicas se envían o actualizan periódicamente. De forma

predeterminada, los equipos envían una actualización una vez cada 7 días. Si la

actualización no provoca ningún cambio en los datos de la zona, la zona permanece en su

versión actual y no se escribe ningún cambio. Las actualizaciones sólo producen cambios

reales en la zona o aumentan el número de transferencias de la misma si los nombres o las

direcciones cambian realmente.

Observe que los nombres no se quitan de las zonas DNS si pasan a estado inactivo o no se

actualizan en el intervalo de actualización (7 días). DNS no usa un sistema para liberar o

desechar los nombres, aunque los clientes DNS intentan eliminar o actualizar los registros

de nombres antiguos cuando se aplica un nuevo nombre o cambia una dirección.

Cuando el servicio Cliente DHCP registra los registros de recursos de host (A) y de puntero

(PTR) para un equipo, utiliza un período de vida (TTL) predeterminado de almacenamiento

en caché de 15 minutos para los registros del host. Esto determina durante cuánto tiempo

otros servidores y clientes DNS almacenan en caché los registros de un equipo cuando se

incluyen en la respuesta a una consulta.

Actualización dinámica segura

La seguridad de la actualización DNS está disponible sólo para las zonas integradas en

Active Directory. Una vez integrada la zona en el directorio, en la consola DNS están

disponibles las características de modificación de la lista de control de acceso (ACL) para

que pueda agregar o quitar usuarios o grupos de la misma para una zona o un registro de

recursos especificado. Para obtener más información, vea Modificar la seguridad de un

registro de recursos o Modificar la seguridad de una zona integrada en directorio.

De forma predeterminada, la seguridad de las actualizaciones dinámicas para servidores y

clientes DNS se puede controlar de la forma siguiente:

Los clientes DNS primero intentan utilizar la actualización dinámica sin asegurar. Si se rechaza una actualización dinámica sin asegurar, los clientes intentan utilizar la actualización segura. Además, los clientes usan una directiva de actualización predeterminada que les permite intentar sobrescribir un registro de recursos registrado anteriormente, a menos que estén bloqueados específicamente por la seguridad de la actualización.

Una vez que una zona pasa a ser integrada en Active Directory, de forma predeterminada, a los servidores DNS que ejecutan Windows Server 2003 sólo se les permite realizar actualizaciones dinámicas seguras. Cuando se utiliza el almacenamiento de zonas estándar, el comportamiento predeterminado del servicio Servidor DNS es no permitir actualizaciones dinámicas en sus zonas. Para las zonas que son integradas en el directorio o utilizan el almacenamiento estándar basado en archivos, se puede cambiar la zona para permitir todas las actualizaciones dinámicas, lo que hace que se puedan aceptar todas las actualizaciones.

Importante

El servicio Servidor DHCP puede realizar el registro con proxy y actualizar registros DNS para clientes heredados que no admiten actualizaciones dinámicas. Para obtener información, vea Usar servidores DNS con DHCP.

Notas

La actualización dinámica es una especificación adicional, estándar y reciente de DNS, definida en el documento RFC 2136. Para obtener más información, vea el RFC. Para obtener más información acerca de cómo obtener documentos RFC, vea RFC de TCP/IP.






Para obtener más información acerca de actualizaciones dinámicas y actualizaciones seguras de DNS, vea Utilizar los Kits de recursos e implementación de Microsoft Windows.

El registro dinámico de registros de recursos DNS puede limitarse mediante entradas de registro. Para obtener más información, vea el artículo Q246804, relativo a la habilitación o deshabilitación de registros DNS dinámicos de Windows 2000, en la Microsoft Knowledge Base.




tcp ip

Documents

Transcript of tcp ip