Archivo de configuración rndc.conf

Primero veamos la configuración del comando rndc. La configuración del comando rndc se controla en dos lugares: en el archivo de configuración rndc.conf y mediante controles y declaraciones clave que necesita agregar al archivo de configuración named.conf.

El archivo de configuración rndc.conf contiene las opciones de configuración que especifican cómo el comando rndc se conecta al demonio nombrado. Este archivo también contiene un hash criptográfico, como el que usa TSIG (ver la sección “TSIG”), que autentica el comando en el canal de control. La declaración de controles en el archivo named.conf especifica las opciones para configurar el canal de control al que se conecta el comando rndc, y la declaración clave del archivo named.conf contiene una copia del hash criptográfico especificado en el archivo rndc.conf. Definido tanto en la configuración del comando rndc como en la configuración del servidor BIND, el hash criptográfico actúa como un secreto compartido. 

De forma predeterminada, el archivo rndc.conf se encuentra en / etc. Si ha chrooteado el demonio nombrado, necesita crear un enlace simbólico al archivo en la cárcel chroot; por ejemplo, usando la cárcel chroot creada en la sección "Chrooting BIND", crearía el enlace simbólico en el directorio / chroot / named / etc

El archivo rndc.conf puede contener tres tipos de instrucciones: opciones, servidor y clave. Estas sentencias usan la misma sintaxis que las sentencias named.conf, y todas deben terminar con punto y coma.
La primera declaración, opciones, especifica los valores predeterminados del comando rndc.

El servidor se puede especificar por dirección IP o nombre de host. Para la declaración d
el servidor, he especificado la dirección IP del host local 127.0.0.1. Para cada declaración de servidor, también debe especificar la clave que se utilizará para este servidor. Puede hacer esto usando la subenunciación clave.

BIND - Vistas Parte 2

 Las vistas deben tener un nombre y debe colocar el nombre entre comillas para permitir el uso de cualquier nombre, incluidas las palabras de configuración BIND protegidas. Para ello hemos definido una vista llamada interna. Después del nombre de la vista, he especificado su clase, IN. Esta es la clase de Internet y debería usarse para casi todas las vistas. Si no especifica una clase, BIND se establecerá de forma predeterminada en una clase de IN. Finalmente, el contenido de la vista está incluido entre llaves, y la última llave debe terminar con un punto y coma, en línea con el estilo estándar de instrucción de configuración named.conf.

La declaración de vista tiene tres secciones principales: las opciones de coincidencia del cliente, las opciones de vista y las zonas definidas en esta vista. La opción de coincidencia de clientes es necesaria para todas las vistas y, para ello, especifico la subenunciación de coincidencias de clientes. Esta sub-declaración le permite especificar los clientes particulares que pueden usar esta vista. Debe especificar esta subdeclaración para asegurarse de que la vista coincida con clientes particulares. En la subenunciado match-clients, he especificado un acl, de confianza, anteriormente en este capítulo. Esto configura BIND para que coincida con todas las direcciones especificadas en ese acl con esta vista. La opción match-clients también puede usar los parámetros normales de la lista de coincidencias de direcciones BIND, como direcciones IP, redes o claves.

También puede especificar una subenunciación de coincidencia de cliente adicional, destinos de coincidencia. La subdeclaración de destinos coincidentes le permite hacer coincidir los clientes por el destino al que se han conectado. También puede usar estas dos sub-declaraciones juntas para hacer coincidir el origen y el destino de un cliente.
Por último, también puede especificar la subenunciación solo recursiva de coincidencia, que indica que solo las consultas recursivas de clientes coincidentes se compararán con la vista. Otros tipos de consultas no coincidirán con la vista.

BIND - Declaración de vistas

La declaración de vista está vinculada a la declaración de zona y se introdujo en la versión 9 de BIND. La declaración de vista actúa como un contenedor para una serie de declaraciones de zona y le permite responder una consulta de DNS de manera diferente dependiendo de quién la esté preguntando. Por ejemplo, suponga que tiene un host bastión que ejecuta BIND y está conectado tanto a su red interna como a Internet. Al usar vistas, podría proporcionar una respuesta a una consulta de su red interna y una respuesta diferente a la misma consulta de Internet.
¿Por qué es útil esto? Bueno, puede ofrecerle dos ventajas. En primer lugar, puede permitir que un solo host BIND tenga autoridad simultáneamente para los dominios internos de su red y externos a Internet. En segundo lugar, puede permitir que un solo host BIND realice funciones de servidor y de almacenamiento en caché.
Entonces, ¿cómo ofrecen las vistas estas ventajas? Tomemos el host BIND meme.yourdomain.com. Es un host bastión conectado a la red local 192.168.0.0/24 con una dirección IP de 192.168.0.100 y también conectado a Internet con una dirección IP de 203.28.13.12. El dominio meme.yourdomain.com está autorizado para el dominio yourdomain.com. Desde la red interna, si alguien consulta el nombre de host mole.yourdomain.com, desea que el servidor BIND devuelva la dirección IP 192.168.0.10. 

Desde Internet, si alguien consulta el mismo nombre de host, desea que el servidor BIND devuelva su dirección IP de acceso a Internet, 203.28.13.13. Pero antes de tener vistas, solo podía definir una zona sudominio.com con un archivo de zona en un archivo named.conf. Esto significaba que no podía proporcionar ambas respuestas desde un solo host, a menos que estuviera ejecutando dos instancias de BIND. Esta configuración requería una sobrecarga considerable y era muy complicada de administrar.
Con las vistas puede definir una vista para cada tipo de consulta, interna o externa. 

Luego, hace coincidir los clientes entrantes con la vista adecuada. Luego, tiene dos zonas de sudominio.com definidas, una en cada vista y cada una con sus propios archivos de zona. Los clientes de la red interna recibirán respuestas de la vista interna y los clientes que realicen consultas desde Internet recibirán respuestas de la vista externa. Esto combina la funcionalidad de dos servidores BIND en un servidor.

Puede usar la misma funcionalidad de vista para proporcionar dos tipos diferentes de funcionalidad BIND, servidor y almacenamiento en caché, en un host. Con las vistas, puede hacer coincidir un conjunto de clientes (por ejemplo, cualquier cliente externo que no sea de confianza) con una vista que resuelve consultas solo para los dominios para los que tiene autoridad y no proporciona almacenamient
o en caché ni recursividad. Otro conjunto de clientes (por ejemplo, sus clientes internos de confianza) se puede hacer coincidir con una vista que permite el almacenamiento en caché y las consultas recursivas, pero no tiene autoridad para ningún dominio.