Creación y configuración de zonas DNS. ¿Qué es una zona inversa en DNS? ¿Qué es un registro PTR?

En este material, veremos la configuración del programa nombrado al organizar un servidor de dominio, cuyos hosts se distribuyen en dos redes IP físicas de Clase C (en notación CIDR x.x.x.x/24). Se prestará mayor atención a las zonas "inversas", porque La zona "directa" en este caso no difiere significativamente de la zona considerada al describir un dominio corporativo pequeño.

La situación considerada en este caso es típica de organizaciones que cuentan con más de una red Clase C donde es necesario implementar un dominio corporativo. Para ser más precisos, no estamos hablando sólo de redes de clase C.

Supongamos que los grupos de direcciones asignados a una organización y sus divisiones no son un único espacio de direcciones, sino una porción de varios bloques de direcciones. Además, estos bloques están cortados de tal manera que las direcciones parecen ser de diferentes áreas, si consideramos el espacio de direcciones desde el punto de vista de la notación CIDR x.x.x.x/24. Por ejemplo:

192.168.0.0/24 y 192.168.10.0/24

Desde el punto de vista de describir la correspondencia entre un nombre de dominio y una dirección IP en la zona "directa", aquí no hay problemas:

$ORIGIN es.
prueba EN SOA ns.test.ru. hostmaster.test.ru (
233 3600 300 9999999 3600)
;
EN NS ns.test.ru.
EN NS ns.privider.ru.
EN UN 192.168.10.1
EN MX 10 mail.test.ru.
EN MX 20 mail.provider.ru.
;
ns EN UN 192.168.10.1
correo EN A 192.168.0.1
www EN A 192.168.10.2
ftp EN UN 192.168.0.2

El ejemplo muestra que los registros de direcciones se pueden “mezclar” perfectamente en la descripción de la zona. Por tanto, se puede definir una zona directa en cualquier conjunto de conjuntos de direcciones, que pueden estar dispersas arbitrariamente por todo el espacio de direcciones.

Por supuesto, hay direcciones en las que no se debe interferir. Por ejemplo, no se deben mezclar direcciones enrutables y no enrutables. En realidad, en el ejemplo utilizamos exactamente lo último (para obtener más información sobre direcciones no enrutables, consulte RFC 1918).

Si solicita una dirección IP de Internet utilizando un nombre de dominio y, en respuesta, recibe una dirección de un grupo no enrutable, no está claro qué hacer con ella. Incluso si usted mismo se encuentra dentro de una red no enrutable, lo más probable es que la dirección recibida desde el exterior de la misma red no sea la dirección que está buscando.

De hecho, el mismo servidor de nombres de dominio puede admitir coincidencias tanto enrutables como no enrutables, pero para facilitar la presentación es mejor dejar este caso para un análisis separado en otro material.

Y así, en la zona "directa" podemos "interferir" direcciones, pero ¿cómo podemos mantener coincidencias inversas? De hecho, en el caso de las zonas “inversas”, también se trata de nombres de dominio, aunque estén formados por inversión de direcciones IP. El separador en la jerarquía de nombres de dominio es el carácter ".", por lo tanto, los límites de bytes en la dirección corresponderán a los límites de anidamiento del dominio.

La solución es simple: cree dos zonas inversas 0.168.192.in-addr.arpa y 10.168.192.in-addr.arpa. Se verá así:

$TTL 3600

10 EN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
EN NS ns.test.ru.
EN NS ns.privider.ru.
1 EN PTR ns.test.ru.
2 EN PTR www.test.ru.

Y para 0.168.192.in-addr.arpa. respectivamente:

$TTL 3600
$ORIGEN 168.192.in-addr.arpa.
0 EN SOA ns.test.ru. hostmaster.test.ru. (
75 3600 300 9999999 3600)
EN NS ns.test.ru.
EN NS ns.privider.ru.
1 EN PTR ns.test.ru.
2 EN PTR www.test.ru.

Se deben declarar dos zonas "inversas" en el servidor maestro. En BIND 4.x, se vería así en el archivo llamado.boot:

directorio /etc/namedb
prueba primaria.ru prueba.ru
host local principal
primario 127.in-addr.arpa localhost.rev
primario 10.168.192.in-addr.arpa 10.168.192.in-addr.arpa
primario 0.168.192.in-addr.arpa 0.168.192.in-addr.arpa
xfrnet 192.168.20.1 y 255.255.255.255
cache. nombre.raíz
opciones sin recursividad sin pegamento búsqueda falsa

En realidad, desde el punto de vista del contexto de este material, es importante que entre las directivas de control haya dos directivas principales para las correspondientes zonas inversas.

Aquí solo cabe aclarar que en este caso la dirección 192.168.20.1 es la dirección del servidor esclavo, al que se le permite copiar la zona. El propósito de las directivas de control restantes se analiza en detalle en "Un pequeño dominio corporativo en el dominio ru". Descripción de las zonas "directas" de la configuración de BIND.

En cuanto al archivo nombrado.conf para las versiones de BIND 8.x y 9.x, su contenido se verá así:

opciones (
directorio "/etc/namedb";
permitir-consulta (cualquiera;);
recursividad no;
consulta falsa sí;
buscar pegamento no;
use-id-pool sí;
};
//Sugerencias del servidor raíz
zona "." ( escriba sugerencia; archivo "named.root"; );
// Bucle invertido hacia adelante
zona "localhost" (
escriba maestro;
archivo "localhost";
};
// Bucle inverso
zona "0.0.127.in-addr.arpa" (
escriba maestro;
archivo "localhosr.rev";
};
// Dominio corporativo
zona "test.ru" (
escriba maestro;
archivo "test.ru";

};

zona "0.168.192.in-addr.arpa" (
escriba maestro;
archivo "0.168.192.in-addr.arpa";
permitir transferencia ( 192.168.20.1; );
};
// Dominio corporativo inverso
zona "10.168.192.in-addr.arpa" (
escriba maestro;
archivo "10.168.192.in-addr.arpa";
permitir transferencia ( 192.168.20.1; );
};

Esta descripción también contiene dos directivas para las zonas inversas a las que se asignan los nombres. La descripción es algo más larga que para BIND 4.x debido al formato diferente del archivo de configuración, pero su esencia es la misma.

Cabe señalar aquí que aparecen varias zonas inversas, por ejemplo, para redes como x.x.x.x/23. El punto es que el grupo de direcciones, por ejemplo, 192.168.0.0.23, combina dos bloques adyacentes 192.168.0.0/24 y 192.168.1.0/24. Por lo tanto, habrá dos zonas inversas correspondientes: 0.168.192.in-addr.arpa y 1.168.192.in-addr.arpa. Se pueden combinar de forma estándar sólo en el nivel 168.192.in-addr.arpa, pero no en un nivel inferior.

De lo anterior se deduce que el propietario de la zona 168.192.in-addr.arpa debe delegar la responsabilidad de gestionar las dos zonas inversas a su cliente si no quiere gestionarlas él mismo.

Comentarios similares son válidos para los grupos de direcciones x.x.x.x/16 y los grupos de direcciones x.x.x.x.8, es decir redes de clases B y A, respectivamente. El espacio de nombres de dominio de zona inversa se construyó teniendo en cuenta la antigua clasificación de direcciones, en un momento en que la notación CIDR aún no se utilizaba ampliamente.

RFC 1519 detalla el mapeo del espacio de direcciones CIDR a la "superred" de las redes Clase C, es decir. pools de direcciones que se componen de subredes de redes clase B y A. El proveedor en este caso debe delegar las zonas inversas correspondientes a los clientes, y estos brindan su soporte de manera similar al caso de 192.168.0.0/23, comentado. arriba.

1. Albitz P., Lee K.. DNS y BIND. - Por. del ingles - San Petersburgo: Symbol-Plus, 2002. - 696 p.
2. P. Mockapetris. RFC-1034. NOMBRES DE DOMINIO - CONCEPTOS E INSTALACIONES. ISI, 1987. (

El sistema de nombres de dominio es la base de la Internet moderna. La gente no quiere molestarse en recordar el conjunto de números 63.245.217.105, sino que quiere que la computadora los conecte al nodo especificado usando el nombre mozilla.org. Esto es lo que hacen los servidores DNS: traducen las solicitudes de las personas a un formato digital que puedan entender. Sin embargo, en algunos casos, es posible que se requiera una dirección IP inversa → conversión de nombre DNS. Estos nombres se analizarán a continuación.

¿Para qué es?

Tener una dirección rDNS correctamente configurada es absolutamente necesario para enviar mensajes desde su propio servidor de correo electrónico corporativo. Casi todos los servidores de correo rechazarán el mensaje al inicio de la sesión si la dirección IP de su servidor no tiene una entrada en la zona DNS inversa. El motivo del fallo del servidor de correo remoto probablemente se indicará de la siguiente manera:
550-"La dirección IP no tiene un registro PTR (dirección a nombre) en el DNS, o cuando el registro PTR no tiene un registro A (nombre a dirección) coincidente. Verifique y corrija su registro DNS".

o
550-No hay un PTR correspondiente para su dirección IP (dirección IP), que es 550 requerido. Lo siento, adiós.

o simplemente
550 Tu IP no tiene Registro PTR

El número 550 en los tres casos es el código estándar del servidor de correo SMTP, que informa un error crítico que impide de manera irreparable seguir trabajando dentro de esta sesión de correo. Hay que decir que en general todos los errores de la serie 500 son críticos y es imposible seguir enviando correo después de que aparecen. El texto explica el motivo del rechazo con más detalle y afirma que el administrador del servidor de correo del destinatario lo ha configurado para comprobar si el servidor de correo emisor tiene una entrada en la zona DNS inversa (rDNS) y, si está ausente, el destinatario El servidor está obligado a rechazar la conexión al remitente (errores de la serie SMTP-5XX).

¿Cómo configurar y utilizar?

Sólo el propietario del correspondiente bloque de direcciones IP al que corresponde esta zona tiene derechos para configurar una zona DNS inversa. Este propietario suele ser el proveedor, que posee su propio sistema autónomo. Puede leer más sobre cómo registrar su sistema autónomo (AS) y el bloque de direcciones IP en este artículo. En resumen, para registrar una zona DNS inversa, el operador de un bloque de direcciones IP debe registrar un objeto del tipo "dominio" en su cuenta personal en el sitio web de RIPE, indicar la dirección de los servidores DNS que admitirán la zona rDNS y configure el soporte para una zona del tipo 3.2.1.in -addr.arpa en ellos. Un puntero, un registro PTR, es responsable de los recursos en la zona inversa. Aquí es donde van las solicitudes para resolver la dirección IP en un nombre de host.

Si no es el feliz propietario de un sistema autónomo, la configuración de rDNS para una dirección IP o direcciones de servidor de correo comienza y termina con una solicitud al servicio de soporte del proveedor o proveedor de alojamiento. En ambos casos, el nombre de la dirección IP del servidor de correo, y especialmente del servidor de correo corporativo, debe indicarse de forma significativa.

Ejemplos de buenos nombres para un servidor de correo:

correo.dominio.ru
mta.dominio.ru
dominio.mx.ru

Ejemplos de malos nombres:

host-192-168-0-1.dominio.ru
cliente192-168-0-1.dominio.ru
vpn-dailup-xdsl-clients.dominio.ru

y similares. Es muy probable que estos nombres se filtren como asignados a equipos cliente en los que no se puede instalar un servidor de correo y, por tanto, desde ellos se envía spam.

Puede y debe utilizar consultas con éxito para revertir zonas DNS inmediatamente después de iniciar el servidor de correo. Para hacer esto, sólo necesita realizar algunos ajustes menores en el software. En diferentes servidores de correo, la configuración de la verificación rDNS se realiza de manera diferente:

entonces, para el servidor de correo Postfix necesitas habilitar la opción
rechazar_cliente_desconocido

en otro servidor de correo popular Exim
verificar = búsqueda_host_inversa

Servidor MS Exchange
En el complemento Exgange Server, vaya a la sección Servidores, luego seleccione el servidor en la lista expandida, seleccione Protocolos, luego el protocolo SMTP, seleccione el servidor SMTP en la ventana derecha y haga clic derecho y seleccione en la lista Propiedades. Siguiente, pestaña Entrega → Realizar búsqueda DNS inversa en mensajes entrantes

Ahora todos los mensajes provenientes de direcciones IP que no tengan un registro DNS inverso (registros tipo PTR) serán rechazados y el flujo de spam se reducirá significativamente. Quizás este sea el método de filtrado de spam más simple, efectivo y que consume menos recursos: la verificación inversa de DNS elimina la gran mayoría del spam enviado desde computadoras infectadas de usuarios comunes que forman las botnets de los spammers.

Al volver a publicar un artículo, es necesario instalar un hipervínculo indexado activo al sitio fuente.

Rashid Achilov

Creando zonas DNS

El sistema de nombres de dominio es una especie de "sistema nervioso" de Internet. Es gracias a ella que cuando escribes llegas al sitio web de la revista "Administrador del sistema", y no a otro lugar. ¿Cómo crear, configurar y ejecutar un servidor DNS para una pequeña empresa?

estructura DNS

Actualmente, Internet es una red enorme que incluye millones de nodos ubicados en todo el mundo. Para que una solicitud realizada desde una computadora alcance un objetivo ubicado en otra computadora, primero se debe especificar este objetivo. Por supuesto, puede especificar la dirección IP directamente. Si lo conoces, claro. Pero aquí es muy fácil cometer un error: es posible que la información sobre dónde se encuentra la dirección que necesita ya haya cambiado y, en el mejor de los casos, verá un mensaje que indica que no se encontró la dirección y, en el peor de los casos, verá encontrarse en un sitio que no tiene absolutamente nada que ver con lo que se necesitaba. Será más confiable y fácil recurrir a un sistema que almacene la correspondencia entre nombres simbólicos como www.site y las direcciones IP correspondientes a ellos en este momento (en nuestro caso, 217.144.98.99). DNS es uno de esos sistemas. Dado que el funcionamiento de todo Internet depende de su funcionamiento exitoso, este sistema funciona según el principio de una base de datos distribuida: hay 13 servidores "conocidos", también llamados servidores "raíz", que contienen información sobre los servidores, que contienen información. sobre servidores, etc. Como la casa que construyó Jack.

Toda la red de Internet, que se describe mediante la zona "." (punto) se divide en los llamados TLD (Top Level Domains), distribuidos funcional o geográficamente. También existe el término dominio primario: "dominio primario" o "dominio de primer nivel", pero este término se usa con mucha menos frecuencia. La distribución geográfica se realiza de acuerdo con la norma ISO 3166, que establece códigos de dos y tres letras para todos los países del mundo. La asignación por base funcional se lleva a cabo según sea necesario para crear un nuevo TLD. Cabe señalar aquí que todas las cuestiones relacionadas con los TLD son tratadas por ICANN (Corporación de Internet para la Asignación de Nombres y Números), y es este organismo el que decide si se crea un nuevo TLD.

Los propios servidores raíz contienen solo enlaces a servidores que contienen información sobre zonas de segundo nivel, que a su vez contienen información sobre servidores que contienen información sobre zonas de tercer nivel, etc. En la mayoría de los casos, la jerarquía termina en la tercera o cuarta zona. Pero no porque haya algún tipo de limitación aquí. Simplemente recordar nombres complejos no es más fácil que las direcciones IP.

Por lo tanto, el proceso de búsqueda de información, digamos, sobre el servidor web www.granch.ru, se verá así:

• El cliente contacta con su servidor DNS, cuya dirección fue configurada por el administrador del sistema con la solicitud "Dígame la dirección correspondiente al nombre www.granch.ru".
• El servidor DNS conoce las direcciones de los servidores desde los que debe iniciar la búsqueda si la información solicitada no está almacenada en su caché, por lo que recurre a uno de ellos.
• El servidor raíz le envía la dirección del servidor responsable de Zone.ru.
• El servidor DNS accede al servidor Zone.RU.
• El servidor Zone.RU le envía la dirección del servidor responsable de la zona Grainch dentro de su zona.
• El servidor DNS accede al servidor de la zona granch.ru.
• Y finalmente, el servidor de la zona granch.ru le indica la dirección correspondiente al nombre www. En este caso será 81.1.252.58.

Este proceso se ilustra en la Fig. 1, donde los números indican la secuencia de solicitudes.

¿Cómo integrar su información en la estructura DNS?

Antes de unirse a cualquier sistema, debe tener una idea de dónde y cómo unirse.

¿Dónde lo incrustamos?

Diferentes servidores son responsables de diferentes TLD y, si, por regla general, un servidor (más precisamente, una organización) es responsable de los dominios geográficos, entonces, en términos generales, un número ilimitado de los llamados registradores, es decir, empresas que tienen celebrados acuerdos especiales, pueden ser responsables de dominios funcionales con ICANN y serán ellos quienes registren nombres en ciertos dominios funcionales. En se proporciona una breve descripción del dominio funcional y la dirección de su registrador.

Si hay varios registradores, se proporciona la dirección del principal (por ejemplo, VeriSign para dominio.com). Los dominios .gov y .mil están reservados exclusivamente para el gobierno americano y organizaciones militares americanas, y la reserva de .gov está formalizada por el correspondiente RFC - RFC 2146. Puede encontrar una lista completa de todos los TLD geográficos existentes actualmente, indicando el registrador de dominio y la información de contacto necesaria en. Aunque, si, digamos, en Zone.com puede elegir de una lista enorme, entonces para Zones.ru y.su RUTSENTR no hay opciones.

Hay varios puntos a tener en cuenta aquí. De hecho, Zone.su pertenece al inexistente estado de la Unión Soviética, aunque sigue recibiendo servicios y está abierto al registro. El registro allí es bastante caro: 100 dólares por registro o soporte al año.

No existe una prioridad por la cual una organización o persona tenga prioridad sobre otra al registrar un dominio. Un empresario estadounidense que se dedicaba a la producción de ventanas de plástico registró el dominio windows2000.com. Cuando Microsoft intentó hacer lo mismo, se sorprendió al descubrir que el nombre ya estaba en uso y la empresa tuvo que pagar una gran suma por él. Incluso existe el concepto de "ciberocupación", el proceso de registrar dominios con el fin de revenderlos posteriormente. RUTSENTR también decidió intervenir en esto y, según las nuevas reglas, que se introdujeron el 1 de junio de 2006, los dominios liberados se presentan a una "subasta de nombres de dominio" y se transfieren al mejor postor. Los nombres se mantienen en “subasta” durante un año; si nadie los reclama durante este período, el nombre se libera para su registro gratuito.

Cuando se crearon los TLD enumerados anteriormente, el TLD .xxx también se planeó para sitios con temas para adultos. ICANN rechazó esta propuesta. Recientemente se sometió a una segunda votación y la ICANN lo rechazó nuevamente. Pero apareció el TLD .tel, diseñado para usarse simultáneamente en computadoras y dispositivos móviles.

Existe el RFC 1480, que describe las reglas para registrar nombres en el dominio .us. Estas reglas son extremadamente engorrosas y confusas y requieren la creación de nombres de niveles 6-7 como Hamilton.High.LA-Unified.K12.CA.US

¿Cómo lo integramos?

Antes todo era mucho más complicado. Para registrarme en Zone.com, tuve que completar muchos formularios de texto, con datos sobre la organización, con datos sobre personas de contacto... Estos formularios luego se enviaron a direcciones especiales, de donde vinieron las respuestas, aceptadas o no. Luego se probó el archivo de zona preformado y nuevamente se envió un mensaje por correo indicando si la prueba fue exitosa o no.

Ahora todo se ha vuelto mucho más sencillo. Tanto Network Solutions como RUTSENTR han adquirido interfaces web, con la ayuda de las cuales todo lo anterior (excepto, por supuesto, la creación de un archivo de zona) se puede realizar con unos pocos clics del mouse. Todos los datos pueden corregirse, completarse o eliminarse en cualquier momento. Anteriormente, era necesario celebrar un contrato de servicio con RUCENTER, pero a partir del 1 de junio de 2006 se introducen nuevas reglas, según las cuales basta con registrarse en su sitio web. Los registradores extranjeros, por regla general, se conforman con tarjetas de crédito, pero si el dominio no se puede registrar por algún motivo, el dinero se devolverá no antes de tres días.

El registrador deberá proporcionar la dirección IP y la máscara de subred del servidor que ejecutará el programa del servidor DNS y que contendrá la base de datos principal que usted creará y editará según sea necesario. Este servidor se denominará servidor primario (servidor maestro). Además, deberá especificar al menos una dirección IP del servidor que contenga una copia de seguridad de la base de datos en caso de falla del servidor primario. Estos servidores se denominan servidores secundarios (servidores esclavos). Para no pensar durante mucho tiempo dónde colocar el DNS secundario, RUCENTER ofrece colocarlo en su sitio. El costo de los servicios de RUCENTER es de $15 por año por dominio en las zonas.ru, .net, .com, .org, $50 por dominio en las zonas .biz, .info, $100 por dominio en la zona.su y $5 por año para soporte para DNS secundario en cualquier zona (incluidas aquellas que no están registradas en ellas).

¿Por qué es obligatorio el requisito de un servidor DNS secundario? Dado que la estabilidad del DNS es extremadamente importante para la estabilidad de Internet en su conjunto, la persona u organización que registra el dominio debe cumplir ciertas condiciones relativas a la estabilidad del DNS:

• Debe haber al menos dos servidores que presten servicio a este dominio.
• Estos servidores deben estar disponibles al menos las 22 horas del día.

Según la nueva normativa, no existen requisitos para la ubicación de los servidores, aunque anteriormente se exigía que estuvieran ubicados en diferentes redes IP.

www.krokodil.ru

Entonces, digamos que queremos crear un sitio web www.krokodil.ru (en el momento de escribir este artículo era gratuito) dedicado a la cría de cocodrilos en casa. Existe una conexión de línea dedicada, una red de clase C, concretamente 212.20.5.0 - 212.20.5.255 (este rango actualmente es gratuito) asignada por el proveedor. Este ejemplo es algo inusual en la época actual con su escasez de direcciones IP, pero fue tomado específicamente para considerar la creación de una zona inversa. También se considerará la opción de conectarse a través de la red 212.20.5.0/31. La red interna de nuestra oficina de cría de cocodrilos consta de seis ordenadores y estará separada del firewall-proxy de Internet, etc., que ejecuta FreeBSD. ¿Qué necesitaremos para implementar nuestros planes?

En primer lugar, observo que hay opciones que no requieren ningún conocimiento de DNS: todo está alojado en el sitio del proveedor, todo es atendido por el proveedor, solo se le proporciona una interfaz web. Este servicio es muy popular en el extranjero, pero tiene muy poca demanda en Rusia. Su descripción está más allá del alcance de este artículo, por lo que no la consideraré.

Primero, necesitaremos un programa de servidor DNS. Hasta la fecha, sólo un programa implementa el conjunto de funciones requerido. Este es un servidor DNS BIND distribuido por ISC (Internet System Consortium Inc.), una organización sin fines de lucro que desarrolla servidores BIND, DHCP, INN y NTP. Si no está en su sistema, debe descargarlo e instalarlo. FreeBSD viene con BIND 9.3.2, por lo que este artículo se centrará en esa versión. Cabe señalar que para las versiones de BIND 8.x, las siguientes descripciones de configuración son completamente inapropiadas porque el formato de los archivos de configuración de BIND 8.x es fundamentalmente diferente del formato de los archivos de configuración de BIND 9.x.

En segundo lugar, necesitaremos distribuir las direcciones IP que se nos asignaron y asignar direcciones a las computadoras internas. Aquí todo es extremadamente simple: sea 212.20.5.1 la puerta de enlace del proveedor, 212.20.5.2 la dirección del servidor UNIX, 10.87.1.0/24 la subred interna en la que se encuentran las estaciones de trabajo 1 a 6, 254 la dirección de el servidor de interfaz interno. Las direcciones restantes quedarán reservadas para futuras ampliaciones.

En tercer lugar, necesitará un archivo de descripción de zona preparado previamente que definirá una pequeña cantidad de direcciones externas: krokodil.ru - el servidor raíz de la zona, www.krokodil.ru, ftp.krokodil.ru, mail.krokodil.ru y ns.krokodil.ru. El nombre ns (servidor de nombres) es casi el nombre tradicional de los ordenadores en los que se ejecuta el servicio DNS, aunque, por supuesto, nadie te impedirá llamarlo, por ejemplo jaws.krokodil.ru. También se definirán nombres para las computadoras en la red interna, accesibles solo desde dentro: tooth1.krokodil.ru – tooth6.krokodil.ru.

Registros DNS

Hay una gran cantidad de tipos diferentes de registros que se pueden colocar en el DNS. El alcance de este artículo nos permite considerar solo los más importantes para obtener información completa, debe consultar los RFC relevantes: RFC 1033 y RFC 1035 definen los formatos de registro básicos, RFC 1122 – el formato de registro PTR, RFC 2782 – el formato de registro SRV. Consideraremos solo aquellos registros necesarios para generar los archivos de zona necesarios para el registro de dominio:

• Un registro SOA que especifica el comienzo de la descripción de la zona.
• Un registro NS que define los servidores de nombres de la zona.
• Un registro A que asigna una dirección IP a un nombre (traducción directa).
• Un registro MX que describe la configuración de entrega de correo para esta computadora.
• Un registro CNAME que especifica nombres alternativos.
• En la descripción de la zona “inversa” se utiliza el registro PTR, que especifica la correspondencia entre el nombre y la dirección IP (traducción inversa).

El formato de registro DNS es común a todos los tipos de registro:

[nombre] [clase]<тип> <данные>

• Nombre– este es el nombre del objeto al que están asociados los datos;
• ttl– vida útil del objeto;
• Clase– clase de registro;
• tipo– tipo de registro;
• datos– datos asociados con este objeto.

El nombre puede tomar cualquier valor, en cuyo caso se considera el nombre del objeto. Si el nombre termina con un punto, entonces se considera completamente calificado; de lo contrario, el nombre de la zona se sustituye al final del nombre, que se puede especificar de dos maneras:

• Especificando el nombre de la zona en la directiva $ORIGIN, por ejemplo:

$ORIGEN krokodil.ru

• Especificando el nombre de la zona en la directiva de zona del archivo de configuración BIND.

El carácter especial "@" indica el nombre de la zona actual. Tenga en cuenta que la directiva $ORIGIN anula la directiva de zona y dura hasta que aparece la siguiente directiva $ORIGIN o hasta el final del archivo. Hasta que aparezca la primera directiva $ORIGIN, se considera que está configurada con el valor de la directiva de zona en el archivo de configuración BIND.

Si se da un nombre, debe comenzar en la primera posición de la línea.

El TTL generalmente se omite y se configura globalmente con la directiva $TTL. La directiva $TTL es obligatoria para BIND 9.x y normalmente se establece al principio del archivo. El campo de datos de esta directiva especifica la vida útil (en segundos) de un elemento durante el cual puede permanecer en la memoria caché y considerarse confiable. En este ejemplo, son dos días (48 horas).

$TTL 172800

La clase de entrada puede ser uno de los siguientes valores:

• EN– grabación de recursos de Internet.
• CH– un registro de los recursos de ChaosNet – una red completamente desconocida para el usuario ruso, utilizada en máquinas Symbolics.
• H.S.– Registro de recursos de Hesiod – Protocolo de servicio BIND.

El tipo de registro es uno de los tipos enumerados anteriormente.

Tenga en cuenta que los campos de nombre, ttl y clase se pueden omitir. En este caso, el último valor definido se toma como sus valores (en este caso, especificar @ será una definición correcta), y si el valor no se definió en ninguna parte, entonces para el campo de clase el valor predeterminado "IN" es aceptado, para otros campos genera un mensaje de error.

Además de las entradas, un archivo de zona puede contener comandos. Hay cuatro comandos en total: $TTL, $ORIGIN, $INCLUDE y $GENERATE. Se proporciona una descripción del comando $GENERATE en la documentación del programa BIND, así como en y, el comando $INCLUDE funciona de acuerdo con su ortografía: incluye el archivo especificado en el archivo actual.

Nota: firmar ";" (punto y coma) es una marca de comentario.

Registro SOA

Esta entrada define el inicio de la zona. Cualquier zona debe comenzar con una entrada SOA. La aparición de otra entrada SOA finaliza automáticamente la primera zona y comienza la segunda. El formato de registro SOA se muestra a continuación. De hecho, un registro SOA nombra una zona y establece algunos valores predeterminados para ella.

2005122001; Número de serie

3600; Reintentar cada hora

172800); Mínimo 2 días

Veamos un ejemplo. El signo @ en el campo de nombre significa que es necesario tomar el nombre de la zona previamente especificada por la directiva $ORIGIN. La clase de registro es IN, el tipo de registro es SOA. SOA es la única entrada que tiene una lista de parámetros tan compleja.

El primer parámetro es la dirección del servidor de nombres maestro de la zona. En este ejemplo, esto es krokodil.ru. El segundo parámetro es la dirección de correo electrónico del responsable de esta zona. Tenga en cuenta que la dirección está escrita como "nombre de usuario.dominio" y no "nombre de usuario@dominio".

El segundo parámetro es una lista de valores entre paréntesis. Teóricamente, es posible escribirlo en una línea, pero en la práctica no he visto esto en ninguna parte; la forma de notación dada en el ejemplo se usa en todas partes; La lista consta de cinco elementos:

• Número de serie de zona. Esta configuración juega un papel extremadamente importante en la propagación de la actualización realizada en el servidor primario a todos sus servidores secundarios. Debe haber alguna forma de informar al servidor secundario que los datos en el servidor primario han cambiado. Si el servidor primario se ha reiniciado, envía una NOTIFICACIÓN DNS a todos los servidores secundarios. Al recibir esta notificación, el servidor secundario solicita un número de serie; si el servidor primario tiene un número de serie mayor que el servidor secundario, el servidor secundario emite un comando de actualización de zona. Además, el servidor secundario realiza comprobaciones periódicas del número de serie con el mismo fin. Por lo tanto, debes recordar una regla simple: si corriges la zona, ¡aumentas el número de serie! Una práctica común entre los administradores de DNS es formar el número de serie de la siguiente manera: AAAAMMDDv, donde:
  • AAAA,MM,DD– año actual (4 dígitos), mes y día, respectivamente
  • v– versión de zona para el día. Si se realizan varios cambios por día, este número se incrementa en uno de forma secuencial.
Por supuesto, nadie te obligará a seguir esa práctica. Por ejemplo, los servidores DNS en Windows no lo respetan, sino que simplemente lo numeran 1, 2, 3, etc.
• El valor del período de actualización después del cual el servidor esclavo debe contactar al maestro y verificar si el número de serie de la zona ha cambiado. Si el número de serie ha cambiado, el servidor esclavo descargará nuevos datos. En este ejemplo, 10800 segundos (3 horas).
• El tiempo después del cual el servidor esclavo intentará comunicarse con el maestro si falla el intento de obtener un nuevo número de serie. En este ejemplo, 3600 segundos (una hora).
• El tiempo durante el cual los servidores esclavos atenderán las solicitudes de una zona determinada en caso de una ausencia prolongada del servidor maestro. El sistema debe funcionar incluso si el servidor principal no funciona durante un largo período de tiempo, por lo que el valor de este parámetro se establece en 1.728.000 segundos (20 días).
• Tiempo de almacenamiento en caché de respuesta negativa. En este ejemplo, 172800 segundos (2 días).

entrada NS

Esta entrada especifica los nombres de los servidores que admiten la zona, es decir. liderando su base. Los nombres de los servidores primario y secundario deben aparecer aquí. Normalmente, esta entrada sigue inmediatamente a la entrada SOA. Se ingresa un valor en el campo de datos: el nombre o la dirección IP del servidor de la zona DNS, independientemente de si es maestro o esclavo. Todos los nombres especificados aquí deben estar completamente calificados, es decir, ¡terminar con un punto!

EN NS ns.krokodil.ru.

EN NS NS4.NIC.RU.

En el ejemplo dado, primero describimos el servidor principal de nuestra zona ns.krokodil.ru, y luego el servidor esclavo: el nodo RU CENTER ns4.nic.ru.

Registro A

Un registro de tipo A es el contenido principal de los archivos en una zona de conversión directa o simplemente una zona "directa", es decir, que indica el nombre de una computadora por su dirección. Está compilado para cada computadora. Para facilitar la lectura, estos registros generalmente se agrupan en orden ascendente de direcciones IP y también se agrupan con los registros MX correspondientes a una dirección IP determinada, aunque esto, por supuesto, no es obligatorio. En el campo de nombre se ingresa el nombre asignado a la dirección IP, en el campo de datos, la dirección IP a la que se asigna el nombre. Cuando una dirección tiene nombres adicionales, el nombre asignado a la dirección por un registro A se denomina nombre principal.

diente1 EN A 10.87.1.1

diente2 EN A 10.87.1.2

diente3 EN A 10.87.1.3

diente4 EN A 10.87.1.4

diente5 EN A 10.87.1.5

diente6 EN A 10.87.1.6

Este ejemplo describe la asignación de direcciones IP a computadoras en la red interna, que tiene la dirección 10.87.1.0/24. Para las computadoras de la red interna, por regla general, no es necesario crear ningún registro adicional, con la posible excepción de CNAME.

Registro CNAME

Un registro CNAME es una característica adicional de DNS. Le permite asignar más de un nombre a una dirección IP. En el campo de nombre se ingresa el nombre adicional asignado a la dirección IP, en el campo de datos, el nombre principal previamente asignado por el registro tipo A, u otro nombre adicional asignado por el registro CNAME. En este caso, el nombre en el campo de datos del registro se llama canónico (de ahí el nombre del registro: Nombre canónico). A una única dirección IP se le puede asignar una cantidad ilimitada de nombres adicionales a través de registros CNAME, pero otros tipos de registros deben usar el nombre asignado por el registro A en lugar del registro CNAME. A continuación se muestra un ejemplo de asignación correcta e incorrecta de nombres adicionales.

Bien:

ns EN UN 10.87.1.1

nombre1 EN CNAME ns

EN MX 10 ns

Equivocado:

ns EN UN 10.87.1.254

nombre1 EN CNAME ns

EN MX 10 nombre1

Los registros CNAME pueden apuntar entre sí, pero no más de siete niveles, el octavo debe ser un registro que apunte al nombre asignado por el registro tipo A. En la literatura existe una recomendación de utilizar múltiples registros tipo A en lugar de asignar múltiples. nombres adicionales a la dirección. Al respecto podemos decir que este punto se menciona en el RFC 2219 en términos de “no existen recomendaciones absolutas en este tema, cada uno debe decidir por sí mismo qué es lo mejor para él”. Varios CNAME son más fáciles de administrar, varios registros A son más fáciles de manejar porque se producen menos redirecciones.

Registro MX

El registro MX es el segundo elemento principal del archivo de zona. Esta entrada significa "Mail eXchanger" y tiene como objetivo indicar las direcciones IP o los nombres de las computadoras que aceptan correo para el nodo descrito en el campo de nombre. Este campo puede estar vacío y ser un nombre total o parcialmente calificado. Si el campo de nombre está vacío o se especifica un nombre incompleto, entonces el nombre se complementa con la directiva $ORIGIN. Generar registros MX en casos complejos, cuando se configura una zona bastante grande con un esquema de recepción de correo extenso, es una tarea muy no trivial, que está estrechamente relacionada con el trabajo de los programas que utilizan el protocolo SMTP para la entrega de correo, por lo que Consideremos sólo el caso más simple: todo el correo es recibido por un servidor UNIX. Se ingresan dos valores en el campo de datos: prioridad y el nombre o dirección IP de la computadora que recibe el correo enviado a esta computadora. Una única dirección IP generalmente puede tener una cantidad ilimitada de registros MX asociados y todos deben tener diferentes prioridades. El correo se enruta según la prioridad: el agente de correo clasifica los registros en orden de prioridad creciente e intenta entregar el correo de esa manera. Supongamos que hemos acordado con el administrador del nodo behemot.ru que podemos utilizar su servidor como nodo de tránsito que recibirá nuestro correo para su posterior entrega a sus destinatarios cuando se restablezca la conexión. Entonces la descripción del servidor krokodil.ru se verá así:

krokodil.ru. EN UN 212.20.5.2

EN MX 10 krokodil.ru.

EN MX 50 behemot.ru.

www EN CNAME krokodil.ru.

correo EN CNAME krokodil.ru.

ftp EN CNAME krokodil.ru.

Este es un ejemplo completo y muestra inmediatamente el uso de registros MX, A y CNAME. Aquí estamos:

• Asignamos el nombre krokodil.ru a la dirección 212.20.5.2.
• Indicamos que el correo enviado a direcciones como [correo electrónico protegido], aceptará (en este orden):
• servidor krokodil.ru;
• servidor behemot.ru.
• Definimos nombres adicionales www.krokodil.ru, mail.krokodil.ru y ftp.krokodil.ru. Tenga en cuenta que todos los nombres del lado derecho están completamente calificados, es decir, terminan con un punto. Si no se hace esto, el valor de la directiva $ORIGIN actual se sustituirá automáticamente al final del nombre. En este caso, esto daría lugar a la aparición de nombres como www.krokodil.ru.krokodil.ru.

Registro RPP

Este es un tipo de registro muy especial. En nuestro ejemplo, tomamos "especialmente" la subred completa para considerar el caso de trabajo "normal" con registros PTR. El caso de la red 212.20.5.0/31 se analizará un poco más adelante.

El registro PTR está diseñado para realizar la traducción inversa de nombres a direcciones IP. Este tipo de conversiones se utilizan ampliamente en varios programas que brindan acceso a ciertos recursos de la red: verifican la correspondencia de las conversiones directa e inversa y, si el registro PTR no coincide o falta, pueden denegar el acceso. La zona que contiene registros PTR se denomina zona de traducción inversa o simplemente zona "inversa".

Los registros PTR no tienen relación con A, MX, CNAME y otros registros que describen conversión directa. Esto se hizo intencionalmente para utilizar el mismo conjunto de módulos de software para ambas transformaciones. Aquí, sin embargo, nos enfrentamos al siguiente tipo de complejidad: un nombre de dominio completo con la forma www.krokodil.ru. "aumenta la dimensión" de izquierda a derecha (es decir, los nodos se agrandan a medida que se desplaza por el texto del nombre de izquierda a derecha), y la dirección IP 212.20.5.2 es de derecha a izquierda. Para unificar los módulos del programa, se adoptó la siguiente convención: todas las direcciones IP son nombres incluidos en el TLD especial in-addr.arpa. Las "zonas" de este dominio son subredes y el nombre de la zona se escribe como la dirección IP leída al revés. Así, el “nombre” de nuestra zona inversa será 5.20.212.in-addr.arpa para la zona inversa que contiene la descripción de la red externa y 1.87.10.in-addr.arpa para la zona inversa que contiene la descripción de la red interna.

Así como para utilizar un nombre de dominio debes registrarlo, para utilizar una traducción inversa debes registrar una “zona” inversa con un coordinador de zona inversa. A diferencia de las zonas de conversión directa, aquí hay un solo coordinador y la inscripción en él es gratuita. El registro de zonas inversas está a cargo de RIPE NCC. Toda la información sobre el registro de la zona inversa se proporciona en.

¿Por qué necesitas registrar una zona inversa? El servidor de nivel superior en la zona in-addr.arpa debe saber que para realizar una solicitud de traducción inversa debe contactar con tal o cual servidor, en este caso nuestro 212.20.5.2. Por supuesto, no es necesario registrar la zona inversa de la subred interna en ningún lugar.

El registro PTR en sí parece muy simple: la última parte de la dirección IP se ingresa en el campo de nombre y el nombre de traducción directa completo se ingresa en el campo de datos. Llamo su atención sobre lo último: el nombre ingresado en el campo de datos debe estar completamente calificado, ya que los propios registros PTR definen la relación entre la dirección IP y el nombre, no pueden recibir información de ningún lugar sobre en qué zona se encuentra la traducción directa no completamente calificada. el nombre debe asignarse a .

$ORIGIN 1.87.10.in-addr.arpa

1 EN PTR diente1.krokodil.ru.

2 EN PTR diente2.krokodil.ru.

3 EN PTR diente3.krokodil.ru.

4 EN PTR diente4.krokodil.ru.

5 EN PTR diente5.krokodil.ru.

6 EN PTR diente6.krokodil.ru.

En el ejemplo anterior, especificamos la asignación inversa para computadoras en la red interna. Para el servidor, escribiremos una línea (en el ejemplo real no es necesario especificar las directivas $ORIGIN, se dan solo para dejar claro de qué zona estamos hablando):

$ORIGIN 5.20.212.in-addr.arpa

2 EN PTR krokodil.ru

Cabe señalar aquí que los registros CNAME no se utilizan para especificar múltiples coincidencias inversas, por lo que cuando se pregunta "qué nombre coincide con la dirección 212.20.5.2", el resultado siempre será krokodil.ru, independientemente del número de alias establecidos para él.

¿En qué se diferenciará cuando el proveedor asigne el bloque 212.20.5.0/31 en lugar de una subred completa? Desde el punto de vista de generar todos los registros excepto PTR, nada. El procedimiento para crear una zona directa y registrarla no depende de la cantidad de direcciones, especialmente porque en la mayoría de los casos no se necesitan muchas direcciones. Sin embargo, en cuanto a los registros PTR hay una diferencia. Hacia la simplificación. O tal vez no, dependiendo del proveedor. Y radica en que los registros:

gate.krokodil.ru. EN UN 212.20.5.1

krokodil.ru. EN UN 212.20.5.2

estará en su servidor y será administrado por usted, pero las entradas:

1 EN PTR gate.krokodil.ru.

2 EN PTR krokodil.ru.

debe ser formado por el proveedor, porque la posibilidad de registrar una zona inversa y administrarla usted mismo solo se proporciona si tiene una red de al menos clase C. Esto, por un lado, facilita el trabajo: no es necesario. Es necesario registrarse en RIPE, pero por otro lado, complica los cambios en el nombre del servidor, hay que contactar con el proveedor cada vez.

Estructura de archivos

A BIND, por supuesto, no le importa en qué orden están los registros ni cómo están formateados. Esto es importante sólo para aquellos que mantendrán la zona, especialmente si se realizarán cambios con frecuencia. Aquí describiré la distribución de zonas por archivos tal como se usa en las zonas que mantengo. Por supuesto, este no es el único orden posible, y quizás tampoco el mejor. Pero funciona.

Zonas externas e internas.

BIND 8.x tenía un inconveniente extremadamente grande: no permitía diferenciar la salida de información según ningún factor; era necesario mostrar lo innecesario u ocultar lo necesario. No hay absolutamente ninguna necesidad de que los clientes externos sepan sobre la presencia de computadoras en la red interna, pero como no había forma de separar la información, cualquier computadora podría establecer la estructura de la red interna a través de consultas DNS. BIND 9.x está libre de este inconveniente: le permite distribuir solicitudes entre "vistas" utilizando Listas de control de acceso (ACL). Las vistas pueden tener nombres arbitrarios, creando generalmente una vista interna que satisfacen los clientes en la subred interna y una vista externa que satisfacen todos los demás. Recuerde aquí que esta es la misma zona, solo que se muestra de manera diferente; como regla general, los archivos de zona externos contienen solo la información que los clientes externos necesitan: sobre el servidor externo, sobre las rutas de entrega de correo, etc. y los archivos de zona internos reflejan toda la topología de la red. Además, si va acompañada de la zona inversa, entonces es necesario dividir la información sobre las direcciones de conversión inversa en archivos de la misma forma.

Así que volvamos a nuestro ejemplo.

La estructura del archivo será la siguiente. Tenemos una zona directa krokodil.ru y una zona inversa 5.20.212.in-addr.arpa. Además, la zona inversa 0.0.127.in-addr.arpa debe estar presente para garantizar la traducción inversa correcta de localhost 127.0.0.1. Esta zona es necesaria para evitar que BIND intente consultar a los servidores raíz sobre sí mismo, lo que sucede cuando 127.0.0.1 apunta a "localhost". El registro de conversión directa 127.0.0.1 localhost.krokodil.ru se escribirá en el archivo de conversión directa de la zona interna. Para no cargar la red con la transferencia de datos inútiles, se utilizan diferentes registros SOA para las zonas externas e internas: los registros en las zonas externas cambian muy raramente y en las zonas internas con bastante frecuencia. Por lo tanto tenemos los siguientes archivos:

• localhost.rev– archivo de zona de conversión inversa 0.0.127.in-addr.arpa. Este archivo existe únicamente para representación interna.
• zona212.rev– archivo de zona de conversión inversa 5.20.212.in-addr.arpa.
• zona10.rev– archivo de zona de inversión interna 1.87.10.in-addr.arpa.
• directo-krokodil-ru.int– archivo interno de zona de conversión directa krokodil.ru.
• directo-krokodil-ru.ext– archivo de zona de conversión directa externa krokodil.ru.
• krokodil-ru-int.soa– un archivo con registros SOA y NS para zonas internas.
• krokodil-ru-ext.soa– un archivo con registros SOA y NS para zonas externas.

A pesar de la extensa lista, los archivos son bastante breves, por lo que aquí se presentan completos, con excepción de los comentarios.

Hagamos una nota con respecto al nombre del host local. RFC 1912 menciona específicamente la configuración de archivos para que se resuelvan en 127.0.0.1 y localhost. En nuestro ejemplo, la zona localhost cumple con RFC 1912, aunque en la vida real es muy posible encontrar la resolución de nombre 127.0.0.1 localhost.domain.tld y la resolución inversa correspondiente.

Archivo localhost.rev. Utiliza un único registro SOA junto con una zona de inversión interna:

$INCLUIR /etc/namedb/krokodil-ru-int.soa

1 EN PTR localhost.

Archivo zona212.rev:

1 EN PTR gate.krokodil.ru.

2 EN PTR krokodil.ru.

Archivo zona10.rev:

$INCLUIR /etc/namedb/krokodil-ru-int.soa

1 EN PTR diente1.krokodil.ru.

2 EN PTR diente2.krokodil.ru.

3 EN PTR diente3.krokodil.ru.

4 EN PTR diente4.krokodil.ru.

5 EN PTR diente5.krokodil.ru.

6 EN PTR diente6.krokodil.ru.

Archivo directo-krokodil-ru.int:

$INCLUIR /etc/namedb/krokodil-ru-int.soa

krokodil.ru. EN UN 10.87.1.254

EN MX 10 krokodil.ru.

www EN CNAME krokodil.ru.

correo EN CNAME krokodil.ru.

proxy EN CNAME krokodil.ru.

ftp EN CNAME krokodil.ru.

ns EN CNAME krokodil.ru.

servidor local. EN UN 127.0.0.1

diente1 EN A 10.87.1.1

diente2 EN A 10.87.1.2

diente3 EN A 10.87.1.3

diente4 EN A 10.87.1.4

diente5 EN A 10.87.1.5

diente6 EN A 10.87.1.6

Archivo directo-krokodil-ru.ext:

$INCLUIR /etc/namedb/krokodil-ru-ext.soa

krokodil.ru. EN UN 212.20.5.2

EN MX 10 krokodil.ru.

EN MX 50 behemot.ru.

www EN CNAME krokodil.ru.

correo EN CNAME krokodil.ru.

ftp EN CNAME krokodil.ru.

puerta EN A 212.20.5.1

Archivo krokodil-ru-int.soa:

@ EN SOA krokodil.ru. hostmaster.krokodil.ru. (

2006051202; Número de serie

10800; Actualizar cada 3 horas

3600; Reintentar cada hora

1728000; Caducan cada 20 días

172800); Mínimo 2 días

EN NS krokodil.ru.

Archivo krokodil-ru-ext.soa:

$TTL 172800

@ EN SOA korkodil.ru. hostmaster.krokodil.ru. (

2005122001; Número de serie

10800; Actualizar cada 3 horas

3600; Reintentar cada hora

1728000; Caducan cada 20 días

172800); Mínimo 2 días

EN NS krokodil.ru.

EN NS NS4.NIC.RU.

Conclusión

¿Cómo crear, configurar y ejecutar un servidor DNS para una pequeña empresa? De hecho, no es tan difícil como parece inicialmente: basta con recorrer este camino una vez, las siguientes acciones se realizarán "automáticamente".

Solicitud

Dominios de nivel superior

Inicialmente, según RFC 920, la lista de TLD funcionales incluía solo .com, .gov, .mil, .edu, .org, que representaban respectivamente organizaciones comerciales, gubernamentales, militares, educativas y sin fines de lucro. Posteriormente, esta lista se amplió un poco: en 1985, se agregó el TLD .net, que representa a las organizaciones que brindan servicios de red, y en 1988, se agregó el TLD .int, que representa a las organizaciones internacionales. En 2001-2002, se agregaron a esta lista los TLD prácticamente desconocidos para el usuario ruso .aero, .biz, .cat, .coop, .jobs, .mobi, .museum, .name, .pro y .travel. Se proporciona información más detallada en. Los dominios geográficos se distribuyen de una vez por todas. Aunque esto no significa que no puedas registrar tu dominio con él. Muchos dominios geográficos que casualmente coinciden con abreviaturas "conocidas" son extremadamente atractivos. Por ejemplo, .md (Moldavia) es muy atractivo para instituciones médicas y residentes de Maryland, EE. UU.; .tv (Tuvalu) – para sitios web relacionados con la televisión; .tm (Turkmenistán) coincide con la ortografía de la abreviatura "Marca comercial", y .nu (Niue, existe una colonia de islas de este tipo), para sitios en estilo "desnudo".

http://www.ripe.net.

http://www.ripe.net/rs/reverse/rdns-project/index.html.

Nemeth E, Snyder G, Seabass S, Hayne TR. UNIX: Guía del administrador del sistema. Para profesionales/Trans. del ingles – San Petersburgo: Pedro; K.: Grupo Editorial BHV, 2002 – 928 págs.: enfermo.

Cricket Liu, Paul Albitz, DNS y BIND, tercera edición, 1998 (O'Reilly, ISBN 1-56592-512-2).

Vista directa necesario para resolver nombres de dominio en direcciones IP, búsqueda inversa– para resolver direcciones IP en nombres de dominio.

Cada segmento de red debe tener una zona de búsqueda inversa. Específicamente, si tiene las subredes 192.168.10.0, 192.168.11.0 y 192.168.12.0, debería tener tres zonas de búsqueda inversa.

El nombre de la zona de búsqueda inversa estándar se compone del ID de red en orden inverso y el sufijo in-addr.arpa. Las zonas de búsqueda inversa del ejemplo anterior se denominarían 10.168.192. en-addr.arpa, 11.168.192.en-addr.arpa y 12.168.192.en-addr.arpa. Las grabaciones de zonas de búsqueda inversa y directa deben estar sincronizadas. Si la sincronización falla en el dominio, es posible que falle la autenticación.

Para crear una zona de búsqueda inversa, siga estos pasos:

1. Consola abierta Administrador de DNS y conectarse al servidor deseado.

2. Haga clic derecho en el elemento del servidor y seleccione el comando Crea una nueva zona (Nueva Zona). se abrirá Asistente de nueva zona. Hacer clic Próximo.

3. Si está configurando un servidor primario que está integrado en Active Directory, seleccione el botón de opción Zona Primaria y asegúrese de que la casilla de verificación esté marcada . Si no desea integrar DNS en Active Directory, seleccione el botón de opción Zona Primaria y desmarca la casilla Almacenar la zona en Active Directory. Hacer clic Próximo.

4. Si está configurando una zona de búsqueda inversa para un servidor secundario, seleccione el botón de opción Zona Secundaria y haga clic Próximo.

5. Si está integrando una zona con Active Directory, elija una de las siguientes estrategias de replicación:

Para todos los servidores DNS de este bosque (es decir, todos los servidores DNS de este bosque) Esta es una estrategia de replicación extensa. Recuerde que un bosque de Active Directory incluye todos los árboles de dominio que comparten datos del directorio con el dominio actual.

Para todos los servidores DNS de este dominio (es decir, todos los servidores DNS de este dominio) Seleccione esta estrategia para replicar la información DNS dentro del dominio actual y sus dominios secundarios.

Para todos los controladores de dominio en este dominio (es decir, todos los controladores de dominio en este dominio) Seleccione esta estrategia si desea replicar la información DNS en todos los controladores de dominio dentro del dominio actual y sus dominios secundarios. Aunque esta estrategia permite una replicación más amplia de la información DNS dentro de un dominio, no todos los controladores de dominio son servidores DNS (no es necesario configurar todos los controladores de dominio como servidores DNS).

6. Establecer el interruptor Zona de búsqueda inversa. Hacer clic Próximo.

7. Especifique para qué direcciones desea crear una zona de búsqueda inversa (IPv4 o IPv6) y haga clic Próximo. Haga una de las siguientes cosas:

Si está configurando IPv4, ingrese el ID de red para la zona de búsqueda inversa. Los valores que ingresa determinan el nombre predeterminado para la zona de búsqueda inversa. Hacer clic Próximo.

Si está configurando IPv6, ingrese el prefijo de red para la zona de búsqueda inversa. Los nombres de las zonas se generan automáticamente en función de los valores que ingresa. Dependiendo del prefijo ingresado, puedes crear hasta ocho zonas. Hacer clic Próximo.

8. Si está configurando un servidor primario o secundario que no está integrado con Active Directory, especifique un nombre de archivo de zona. Ya debería haberse ingresado el nombre de archivo predeterminado para la base de datos de la zona DNS. Déjelo sin cambios o ingrese un nuevo nombre. Hacer clic Próximo.

9. Seleccione si desea permitir actualizaciones dinámicas. Tienes tres opciones:

Permitir solo actualizaciones dinámicas seguras Si su zona está integrada con Active Directory, puede usar ACL para limitar qué clientes pueden realizar actualizaciones dinámicas. Si selecciona este modificador, solo los clientes con cuentas de computadora autenticadas y ACL aprobadas pueden actualizar dinámicamente los registros de recursos.

Permitir actualizaciones dinámicas seguras y no seguras Seleccione este modificador para permitir que cualquier cliente actualice sus registros de recursos en DNS cuando se produzcan cambios.

No permitir actualizaciones dinámicas Este modificador deshabilita las actualizaciones dinámicas de DNS. Sólo debe usarse si la zona no está integrada con Active Directory.

Después de instalar zonas de búsqueda inversa, debe asegurarse de que la delegación se procese correctamente para la zona. Comuníquese con su departamento de TI o ISP para verificar los registros de zona en el dominio principal.

Antecedentes históricos: El sistema de nombres de dominio fue desarrollado en 1983 por Paul Mockapetris. Al mismo tiempo, se llevaron a cabo las primeras pruebas exitosas del DNS, que luego se convirtió en uno de los componentes básicos de Internet. Con DNS, es posible implementar un mecanismo distribuido y escalable que asigna nombres de sitios jerárquicos a direcciones IP numéricas.

En 1983, Paul Mokapetris trabajó como investigador en el Instituto de Ciencias de la Información. ISI), parte de la Escuela de Ingeniería de la Universidad del Sur de California ( USC). Su supervisor, Jon Postel, sugirió que Paul ideara un nuevo mecanismo que establecería conexiones entre nombres de computadoras y direcciones de Internet, para reemplazar el entonces actual directorio centralizado de nombres de host y direcciones mantenido por la empresa de California SRI International.

“Todo el mundo entendió que el viejo esquema no podía funcionar para siempre”, recuerda Mockapetris. “El crecimiento de Internet se convirtió en una avalancha de nuevas empresas e institutos de investigación que se unieron a la red que surgió sobre la base del proyecto ARPANET. Pentágono."

La solución de Mockapetris, DNS, era una base de datos distribuida que permitía a las organizaciones que se conectaban a Internet obtener su dominio.

"Una vez que una organización se conecta a la red, puede utilizar tantas computadoras como quiera y darles un nombre", enfatizó Mockapetris. Los nombres de dominio para empresas recibieron el sufijo .com, universidades - .edu, etc.

DNS se diseñó originalmente para admitir 50 millones de registros y podría ampliarse de forma segura a varios cientos de millones de registros. Mockapetris estima que en la actualidad existen alrededor de mil millones de nombres DNS, incluidos casi 20 millones de nombres públicos. El resto pertenece a sistemas ubicados detrás de firewalls. Sus nombres son desconocidos para los usuarios habituales de Internet.

El nuevo sistema se introdujo gradualmente a lo largo de varios años. En ese momento, varios investigadores experimentaron con sus capacidades y Mokapetris estudió ISI dar servicio y mantener el funcionamiento estable del “servidor raíz” integrado en los mainframes de equipos digitales. Se guardaron copias de las tablas de host en cada computadora conectada a Internet hasta aproximadamente 1986. Entonces comenzó una transición masiva hacia el uso de DNS.

La necesidad de asignar nombres de host de red a direcciones IP

Las computadoras y otros dispositivos de red usan direcciones IP para enviarse paquetes entre sí a través de la red. Sin embargo, es mucho más fácil y conveniente para un usuario (humano) recordar algunos nombres simbólicos de nodos de red que cuatro números sin significado. Sin embargo, si las personas van a utilizar nombres de host en lugar de direcciones IP en sus interacciones con los recursos de la red, entonces debe haber un mecanismo que asigne los nombres de host a sus direcciones IP.

Existen dos mecanismos de este tipo: un archivo de hosts local para cada computadora y un servicio de nombres DNS jerárquico centralizado.

Uso del archivo de hosts locales y DNS para resolver nombres de hosts de red

En la etapa inicial del desarrollo de la red, cuando el número de nodos en cada red era pequeño, bastaba con almacenar y mantener el estado actual de un archivo de texto simple en cada computadora, que contenía una lista de nodos de red de esta red. La lista está estructurada de forma muy sencilla: cada línea del archivo de texto contiene el par "dirección IP - nombre de host de la red". En los sistemas de la familia Windows, este archivo se encuentra en la carpeta %system root%\system32\drivers\etc (donde %system root% indica la carpeta en la que está instalado el sistema operativo). Inmediatamente después de instalar el sistema Windows, se crea un archivo de hosts con una entrada 127.0.0.1 localhost.

A medida que las redes crecen, resulta cada vez más difícil mantener actualizada y precisa la información del archivo de hosts. Para hacer esto, necesita actualizar constantemente el contenido de este archivo en todos los nodos de la red. Además es tan sencillo tecnología no le permite organizar el espacio de nombres en ninguna estructura. Por lo tanto, era necesaria una base de datos de nombres centralizada que permitiera convertir los nombres en direcciones IP sin almacenamiento lista coincidente en cada computadora. Esta base fue el DNS (Domain Name System), un sistema de nombres de dominio que comenzó a operar masivamente en 1987.

Tenga en cuenta que con la llegada del servicio DNS, la relevancia del uso del archivo host no ha desaparecido en algunos casos, el uso de este archivo resulta muy efectivo;

Servicio DNS: espacio de nombres, dominios

DNS es base de datos jerárquica, que asigna los nombres de los nodos de red y sus servicios de red a las direcciones IP de los nodos. El contenido de esta base de datos se distribuye, por un lado, entre un gran número de servidores de servicios DNS y, por otro, se gestiona de forma centralizada. en el nucleo estructura jerárquica de la base de datos DNS es un espacio de nombres de dominio, cuya unidad estructural principal es un dominio que une nodos de red (hosts), así como subdominios. El proceso de buscar en la base de datos DNS el nombre de un host de red y hacer coincidir ese nombre con una dirección IP se denomina "resolución de nombre de host en el espacio de nombres DNS".

El servicio DNS consta de tres componentes principales:

Espacio de nombres DNS y registros de recursos correspondientes (RR, registro de recursos)- esta es la propia base de datos DNS distribuida;

Servidores de nombres DNS- computadoras que almacenan la base de datos DNS y responden a solicitudes Clientes DNS;

Clientes DNS (clientes DNS, solucionadores de DNS)-computadoras que envían consultas a servidores DNS para obtener registros de recursos.

Espacio de nombres.

El espacio de nombres DNS es una estructura de árbol jerárquica que comienza en la raíz, que no tiene nombre y se indica con un punto ".". El diseño del espacio de nombres DNS se ilustra mejor utilizando Internet como ejemplo ( arroz. 4.8).

Arroz. 4.8.

Para los dominios de 1er nivel existen 3 categorías de nombres:

ARPA- un nombre especial utilizado para la resolución DNS inversa (desde la dirección IP hasta el nombre completo del host);

Nombres genéricos de 1er nivel- 16 (actualmente) nombres, cuyo propósito se da en mesa 4.4;

Nombres de dos letras para países.- nombres de dominios registrados en los países correspondientes (por ejemplo, ru - para Rusia, ua - para Ucrania, uk - para Gran Bretaña, etc.).

Tabla 4.4.
Nombre de dominio	Objetivo
	Comunidades de aviación
	Empresas (sin referencia al país)
	Organizaciones comerciales, principalmente en los Estados Unidos (por ejemplo, el dominio microsoft.com de Microsoft Corporation)
	Cooperativas
	Instituciones educativas en EE. UU.
	agencias gubernamentales de EE. UU.
	Dominio para organizaciones que proporcionan información a los consumidores.
	organizaciones internacionales (por ejemplo, dominio OTAN.int para la OTAN)
	departamentos militares de estados unidos
	Dominio global para particulares
	Dominio para proveedores de Internet y otras organizaciones que gestionan la estructura de Internet.
	Organizaciones sin fines de lucro y no gubernamentales, principalmente en EE. UU.
	Dominio para colegios profesionales (médicos, abogados, contadores, etc.)
	agencias de reclutamiento
	Operadores turísticos

Para asignar directamente un espacio de nombres a un espacio de direcciones IP, utilice el llamado. registros de recursos (RR, registro de recursos). Cada servidor DNS contiene registros de recursos para la parte del espacio de nombres del que es responsable ( autorizado). mesa 4.5 contiene una descripción de los tipos de registros de recursos más utilizados.

Tabla 4.5.
Tipo de registro de recursos	Función de grabación	Descripción de uso
	Dirección de host Dirección de host o nodo	Asigna un nombre de host a una dirección IP (por ejemplo, para el dominio microsoft.com a un host llamado www.microsoft.com la dirección IP se asigna mediante la siguiente entrada: www A 207.46.199.60)
	Nombre canónico (alias)	Asigna un nombre a otro
	Intercambiador de correo Intercambio de correo	Controla el enrutamiento de mensajes de correo para el protocolo SMTP.
	Servidor de nombres Servidor de nombres	Apunta a los servidores DNS responsables de un dominio específico y sus subdominios.
	Puntero	Se utiliza para resolver inversamente direcciones IP en nombres de host en el dominio in-addr.arpa.
	Inicio de Autoridad Entrada a zona de salida	Se utiliza para especificar el servidor principal para una zona determinada y describir las propiedades de la zona.
	Localizador de servicios Puntero a un servicio	Se utiliza para buscar servidores que ejecutan servicios específicos (por ejemplo, controladores de dominio de Active Directory o servidores de catálogo global)

Un nombre de dominio completo (FQDN) consta de varios nombres, llamados etiquetas, separados por un punto. La etiqueta más a la izquierda se refiere directamente al nodo, las etiquetas restantes son una lista de dominios desde el dominio de primer nivel hasta el dominio en el que se encuentra el nodo (esta lista se ve de derecha a izquierda).

Servidores de nombres DNS.

Los servidores de nombres DNS (o servidores DNS) son computadoras que almacenan aquellas partes de la base de datos del espacio de nombres DNS de las cuales estos servidores son responsables y ejecutan software que procesa las solicitudes de resolución de nombres de clientes DNS y proporciona respuestas a las solicitudes recibidas.

Clientes DNS.

Un cliente DNS es cualquier nodo de red que se ha puesto en contacto con un servidor DNS para resolver un nombre de host en una dirección IP o, por el contrario, una dirección IP en un nombre de host.

Servicio DNS: Dominios y Zonas

Como se mencionó anteriormente, cada servidor DNS es responsable de servir una porción específica del espacio de nombres DNS. La información del dominio almacenada en la base de datos del servidor DNS está organizada en unidades especiales llamadas zonas. Una zona es la unidad básica de replicación de datos entre servidores DNS. Cada zona contiene una cierta cantidad de registros de recursos para el dominio correspondiente y, posiblemente, sus subdominios.

Los sistemas de la familia Windows Server admiten los siguientes tipos de zonas:

Primaria estándar- copia principal de la zona estándar; Sólo en esta instancia de una zona se pueden realizar cambios, que luego se replican en servidores que almacenan zonas adicionales;

Secundaria estándar- una copia de la zona principal, disponible en modo de solo lectura, diseñada para aumentar la tolerancia a fallas y distribuir la carga entre los servidores responsables de una zona específica; El proceso de replicar cambios en los registros de zona se denomina "transferencia de zona" ( transferencia de zona

) (la información en las zonas estándar se almacena en archivos de texto, los archivos se crean en la carpeta "%system root%\system32\dns", el nombre del archivo generalmente se forma a partir del nombre de la zona con la adición de la extensión del archivo " .dns"; el término "estándar" se utiliza sólo en sistemas de la familia Windows);- toda la información de la zona se almacena como una única entrada en la base de datos de Active Directory (este tipo de zonas sólo pueden existir en servidores Windows que sean controladores de dominio de Active Directory; en las zonas integradas, los derechos de acceso a las entradas de la zona se pueden controlar más estrictamente; los cambios en Las entradas de zona entre diferentes instancias de la zona integrada no se producen de acuerdo con tecnologías transferencia de zona por el servicio DNS y por los mecanismos de replicación del servicio Active Directory);

zona corta (talón;

Windows 2003 únicamente) es un tipo especial de zona que, para una parte determinada del espacio de nombres DNS, contiene el conjunto mínimo de registros de recursos (el registro de zona SOA inicial, una lista de servidores de nombres responsables de esa zona y algunos tipos A registros para referencias a servidores de nombres para esa zona). Veamos la relación entre los conceptos de dominio y zona como ejemplo. Analicemos la información presentada en.

arroz. 4.9

Arroz. 4.9. En este ejemplo, el espacio de nombres DNS comienza con dominio microsoft.com , que contiene 3 subdominios:, ventas.microsoft.com es.microsoft.com Y educa.microsoft.com almacenamiento(Los dominios en la figura están indicados por pequeños óvalos horizontales). Un dominio es un concepto puramente lógico que se relaciona únicamente con la distribución de nombres. El concepto de dominio no tiene nada que ver con la tecnología. información sobre dominio. Zona

- esta es una forma de presentar información sobre un dominio y sus subdominios en el almacenamiento de aquellos servidores DNS que son responsables de un dominio y subdominios determinados. En esta situación, si se selecciona la tecnología de zona estándar para el almacenamiento, entonces la ubicación de la información del dominio se puede implementar de la siguiente manera: En este ejemplo, el espacio de nombres DNS comienza con dominio registros relacionados con el dominio Y Y

, se almacenan en una zona del archivo "microsoft.com.dns" (en la figura, la zona está indicada por un gran óvalo inclinado); , que contiene 3 subdominios: registros relacionados con el dominio ventas.microsoft.com gestión de dominio

delegados a otros servidores DNS, se han creado los archivos correspondientes “sales.microsoft.com.dns” y “it.microsoft.com.dns” para estos dominios en otros servidores (estas zonas están indicadas por grandes óvalos verticales).

La delegación de control es la transferencia de responsabilidad de parte del espacio de nombres a otros servidores DNS.

Zonas de búsqueda directa e inversa Las zonas discutidas en el ejemplo anterior son zonas de búsqueda directa

. Estas zonas se utilizan para resolver nombres de host en direcciones IP. Los tipos de registros más utilizados para esto son A, CNAME, SRV. Zonas de búsqueda inversa ( zonas), el principal tipo de grabación en zonas “inversas” es PTR. Para solucionar este problema, se creó un dominio especial llamado in-addr.arpa. Para cada red IP en dicho dominio, se crean los subdominios correspondientes, formados a partir del identificador de red escrito en orden inverso. Los registros en dicha zona harán coincidir el ID del host con el nombre FQDN completo de ese host. Por ejemplo, para la red IP 192.168.0.0/24, necesita crear una zona llamada "0.168.192.in-addr.arpa". Para un nodo con la dirección IP 192.168.0.10 y el nombre host.company.ru, se debe crear un registro "10 PTR host.company.ru" en esta zona.

Algoritmos para consultas DNS iterativas y recursivas

Todo solicitudes, enviados por el cliente DNS al servidor DNS para la resolución de nombres, se dividen en dos tipos:

consultas iterativas (el cliente envía al servidor DNS pedido, que requiere que usted dé la mejor respuesta sin contactar con otros servidores DNS);

consultas recursivas (el cliente envía una consulta al servidor DNS en la que solicita una respuesta final, incluso si el servidor DNS tiene que enviar consultas a otros servidores DNS; las consultas enviadas en este caso a otros servidores DNS serán iterativas).

Los clientes DNS habituales (como las estaciones de trabajo de los usuarios) suelen enviar consultas recursivas.

Veamos ejemplos de cómo interactúan el cliente DNS y el servidor DNS al procesar consultas iterativas y recursivas.

Digamos que el usuario inició el programa Navegador de Internet e ingresó la dirección en la barra de direcciones. http://www.microsoft.com. Antes de que el navegador pueda establecer una sesión HTTP con un sitio web, la computadora cliente debe determinar la dirección IP del servidor web. Para ello, la parte cliente del protocolo TCP/IP de la estación de trabajo del usuario (la llamada solucionador) primero busca en su caché local de nombres previamente resueltos en un intento de encontrar el nombre allí www.microsoft.com. Si no se encuentra el nombre, entonces el cliente envía una solicitud al servidor DNS especificado en la configuración TCP/IP de esta computadora (llamemos a este servidor DNS "servidor DNS local"), para resolución de nombres www.microsoft.com a la dirección IP de este nodo. Luego, el servidor DNS procesa la solicitud según el tipo de solicitud.

Opción 1 (consulta iterativa).

Si el cliente envió una solicitud iterativa al servidor (recuerde que los clientes suelen enviar solicitudes recursivas), entonces la solicitud se procesa de acuerdo con el siguiente esquema:

En este ejemplo, el espacio de nombres DNS comienza con dominio;

si se encuentra dicha zona, se busca en ella una entrada para el nodo www; si se encuentra un registro, el resultado de la búsqueda se devuelve inmediatamente al cliente;

www.microsoft.com en su caché de consultas DNS previamente resueltas;

si el nombre buscado está en la memoria caché, el resultado de la búsqueda se devuelve al cliente; si el servidor DNS local no encuentra el registro requerido en su base de datos, entonces la dirección IP de uno de los servidores DNS raíz se envía al cliente;

el cliente obtiene la dirección IP del servidor raíz y le repite la solicitud de resolución de nombre www.microsoft.com;

el servidor raíz no contiene la zona "microsoft.com" en su base de datos, pero conoce los servidores DNS responsables de la zona "com", y el servidor raíz envía al cliente la dirección IP de uno de los servidores responsables de esta zona ;

el cliente recibe la dirección IP del servidor responsable de la zona "com" y le envía una solicitud de resolución de nombre www.microsoft.com;

el servidor responsable de la zona com no contiene zonas en su base de datos En este ejemplo, el espacio de nombres DNS comienza con dominio, pero conoce los servidores DNS responsables de la zona. En este ejemplo, el espacio de nombres DNS comienza con dominio, y este servidor DNS envía al cliente la dirección IP de uno de los servidores responsables de la zona En este ejemplo, el espacio de nombres DNS comienza con dominio;

el cliente recibe la dirección IP del servidor responsable de la zona En este ejemplo, el espacio de nombres DNS comienza con dominio y le envía una solicitud de resolución de nombre. www.microsoft.com;

servidor responsable de la zona En este ejemplo, el espacio de nombres DNS comienza con dominio, recibe esta solicitud, encuentra en su base de datos la dirección IP del nodo www ubicado en la zona En este ejemplo, el espacio de nombres DNS comienza con dominio, y envía el resultado al cliente;

el cliente obtiene la dirección IP que está buscando, almacena la solicitud resuelta en su caché local y pasa la dirección IP del sitio web al navegador de Internet (después de lo cual el navegador se comunica con el sitio web a través de HTTP).

Opción 2 ( consulta recursiva).

Si el cliente envió al servidor consulta recursiva, luego la solicitud se procesa de acuerdo con el siguiente esquema:

Primero, el servidor DNS local busca entre las zonas de las que es responsable. En este ejemplo, el espacio de nombres DNS comienza con dominio;

si se encuentra dicha zona, se busca en ella una entrada para el nodo www; www.microsoft.com si se encuentra un registro, el resultado de la búsqueda se devuelve inmediatamente al cliente;

de lo contrario, el servidor DNS local busca el nombre solicitado www.microsoft.com en su caché de consultas DNS previamente resueltas; si el nombre buscado está en la memoria caché, el resultado de la búsqueda se devuelve al cliente;

Si el servidor DNS local no encuentra el registro requerido en su base de datos, entonces el servidor DNS local realiza una serie de consultas iterativas para resolver el nombre.

y se envía al cliente la dirección IP encontrada o un mensaje de error.

Implementación del servicio DNS en sistemas de la familia Windows Server

La característica principal del servicio DNS en la familia de sistemas Windows Server es que el servicio DNS fue diseñado para admitir el servicio de directorio Active Directory. Para realizar esta función se deben cumplir dos condiciones:

El DNS de Windows Server satisface ambas condiciones y los servicios de directorio de Active Directory sólo se pueden implementar en servidores basados ​​en Windows Server.

Veamos algunos ejemplos sencillos de gestión del servicio DNS:

instalar el servicio DNS;

creación de un área de visualización directa principal y adicional;

crear una zona de búsqueda inversa;

realizar el registro dinámico de nodos en la zona.

la red consta de dos servidores Windows 2003;

sistema operativo: versión rusa de 120 días por tiempo limitado de Windows 2003 Server Enterprise Edition;

el primer servidor está instalado en una PC con un procesador Intel Pentium-4 de 3 GHz y 512 MB de RAM, nombre del servidor - DC1, dirección IP - 192.168.0.1/24;

el segundo servidor se ejecuta como un sistema virtual utilizando Microsoft VirtualPC 2004, nombre del servidor -DC2, dirección IP - 192.168.0.2/24;

el nombre de dominio en el espacio DNS y el nombre correspondiente en el servicio de directorio Active Directory - world.ru (la red está completamente aislada de otras redes, por lo que en este ejemplo los autores tuvieron la libertad de elegir el nombre de dominio; en la situación real de una institución educativa en particular, el maestro debe corregir esta información).

Las recomendaciones detalladas para organizar una red para estudiar este curso (tanto bajo la guía de un profesor en un grupo organizado como durante el estudio independiente) se encuentran en las instrucciones para realizar ejercicios de laboratorio al final del manual.

Instalación del servicio DNS

Instalar el servicio DNS (así como otros componentes del sistema) es bastante sencillo utilizando el Asistente de instalación de componentes de Windows:

Abierto Panel de control.

Seleccione un elemento "Agregar o quitar programas".

Haga clic en el botón "Instalación de componentes de Windows".

Seleccionar "Servicios de red"- botón "Además"(bajo ningún concepto desmarque el nombre "Servicios de red").

Verifique el servicio DNS.

Arroz. 4.10.

Si el sistema le pide que especifique la ruta a la distribución del sistema, ingrese la ruta a la carpeta con la distribución.

Realicemos esta acción en ambos servidores.

Creación de una zona principal de visión delantera.

En el servidor DC1 crearemos una zona principal estándar llamada world.ru.

Abramos la consola DNS.

Seleccionemos una sección "Zonas de visión delantera".

Iniciemos el asistente de creación de zonas (tipo de zona - "Básico", actualizaciones dinámicas - permitir, otros parámetros - predeterminados).

Ingresemos el nombre de la zona: world.ru.

Permitamos que esta zona se transfiera a cualquier servidor DNS (Consola DNS - zona world.ru - Propiedades- Marcador "Transferencias de zona"- Controlar "Permitir transferencias" es.microsoft.com "A cualquier servidor").

Crear una zona de visión delantera adicional.

En el servidor DC2, crearemos una zona adicional estándar llamada world.ru.

Abramos la consola DNS.

Seleccionemos una sección "Zonas de visión delantera"

"Adicional", la dirección IP del servidor maestro (desde el cual se copiará la zona) es la dirección del servidor DC1, otros parámetros son predeterminados)

Ingresemos el nombre de la zona: world.ru.

Comprobemos la apariencia de la zona en la consola DNS.

Configuración de hosts para realizar registro DNS dinámico.

Para completar esta tarea, debe realizar una serie de acciones tanto en el servidor DNS como en la configuración del cliente DNS.

Servidor DNS.

Cree la zona adecuada.

Permitir actualizaciones dinámicas.

Ya hemos hecho esto.

Cliente DNS.

Especifique en la configuración del protocolo TCP/IP la dirección del servidor DNS preferido: el servidor en el que se permiten actualizaciones dinámicas (en nuestro ejemplo, el servidor DC1).

En el nombre completo de la computadora, indique el sufijo DNS apropiado (en nuestro ejemplo, world.ru). Para esto - - "Mi computadora""Propiedades" - Marcador"Nombre de la computadora" - Botón"Nombre de la computadora" "Además""Cambiar" - ingrese el nombre de dominio world.ru en el campo de texto vacío - botón"DE ACUERDO"

(3 veces)).

Arroz. 4.11. Después de esto, el sistema le pedirá que reinicie su computadora. Después de reiniciar el servidor DNS en la zona world.ru, se crearán automáticamente registros tipo A para nuestros servidores ().

arroz. 4.12

Arroz. 4.12..

Abramos la consola DNS.

Seleccionemos una sección Crear una zona de búsqueda inversa.

"Zonas de búsqueda inversa" "Básico" Iniciemos el asistente de creación de zonas (seleccione: tipo de zona -

, actualizaciones dinámicas - permitir, otros parámetros - predeterminado) en el campo"Código de red (ID)"

Ingresemos los parámetros de ID de red: 192.168.0.

Ejecutemos el comando para forzar al cliente a registrarse en el servidor DNS: ipconfig /registerdns. Nuestros servidores se registrarán con zona inversa DNS ():