Actualmente estoy configurando un servidor DNS para mi laboratorio doméstico. Creé un archivo de zona correspondiente al dominio del laboratorio, digamos home.lab, y el servidor ahora sabe que es el servidor autorizado para esa zona y ahora puede responder a consultas sobre device.home.lab.
Ahora me gustaría usar este servidor DNS en mis otros dispositivos, para que sea la autoridad en la home.labzona, pero también los necesito para poder resolver dominios globales de Internet. Parece que no hay forma de configurar los hosts finales para usarlos solo para home.labbúsquedas y algún otro en caso contrario. Hasta ahora puedo ver algunas soluciones:
- configure este servidor para que también resuelva recursivamente otras zonas (lo que funcionaría, como se describeen esta pregunta)
- hacer que el servidor, cuando se le solicite una zona distinta a la suya, responda con una referencia a los servidores raíz, y desde allí hacer que los clientes soliciten recursivamente la jerarquía por su cuenta
- configure otro servidor DNS, que cuando se le solicite
home.labreenviará la respuesta desde el servidor DNS autorizado y, de lo contrario, reenviará la respuesta almacenada en caché
La primera opción parece mala porque entonces el servidor autorizado también tiene una doble función como solucionador recursivo para el resto de los dominios. El segundo es ineficiente, ya que los clientes tendrán que resolver manualmente la jerarquía para cada nuevo dominio, lo que puede ser bastante lento.
Por tanto, la tercera opción parece la mejor hasta el momento. ¿Cómo haría para configurar esto en BIND9 y/o debería considerar una solución alternativa?
Respuesta1
La primera opción parece mala porque entonces el servidor autorizado también tiene una doble función como solucionador recursivo para el resto de los dominios.
Para un uso pequeño de LAN/laboratorio doméstico, eso no es realmente un problema.
(También se hace comúnmente, por ejemplo, en entornos de Active Directory, donde el administrador indica a todos los clientes que utilicen directamente un AD DC que aloja la zona AD DNS en lugar de un solucionador dedicado; eso esinnecesario,pero no estrictamente malo.)
Puede haber algunos casos extremos (por ejemplo, el indicador AD DNSSEC), pero creo que resultannoNo se trata de agregar funciones de resolución a un servidor autorizado, sino de todo lo contrario: hacer que las máquinas utilicen un servidor autorizado como si fuera un servidor autorizado, lo cual es lo que usted está haciendo.yahaciendo.
El segundo es ineficiente, ya que los clientes tendrán que resolver manualmente la jerarquía para cada nuevo dominio, lo que puede ser bastante lento.
Tampoco funcionaría, ya que la mayoría de los clientes sólotalónresolutores: no seguirán las referencias.
Un solucionador completo, por otro lado,cachereferencias. El solucionador de DNS público que ha estado utilizando (ya sea el ISP, Google o cualquier otra cosa) también tiene que resolver la jerarquía para cada nuevo dominio; ciertamente no guarda una copia completa de todos los registros DNS del mundo, pero sí lo hace. no es lento, porque al menos el primer nivel (TLD) generalmente se almacena en caché en la memoria y, de todos modos, no hay tantos niveles de jerarquía para un dominio típico.
Por tanto, la tercera opción parece la mejor hasta el momento. ¿Cómo haría para configurar esto en BIND9 y/o debería considerar una solución alternativa?
En BIND9, cree una type static-stubzona que apunte al servidor de autenticación de Homelab. (Es similar a una type forwardzona, pero "static-stub" espera apuntar directamente a un servidor autorizado mientras que "forward" espera encadenarse a otro solucionador. No estoy seguro de las diferencias exactas).
Para todos los demás dominios, puede especificar servidores ascendentes como forwarders{}en la configuración BIND global. Esto no es necesario: BIND9 en sí es capaz de buscar referencias desde los servidores DNS raíz (y lo hará de forma predeterminada siempre que la pseudozona de "sugerencias de raíz" esté configurada), lo que realmenteno eslento (aunque ciertamente podría ser más lento que reenviar solicitudes a un servidor ascendente con su propio caché masivo).
Una alternativa común es Unbound (que se centra más en su uso como solucionador, con solo características mínimas de servidor autorizado). La configuración de Unbound es similar, excepto que el tipo de zona es stuben lugar de "stub estático". Para realizar consultas de reenvío independientes, configúrela "."como una zona de "tipo: reenvío".
Tenga en cuenta que inventar TLD personalizados no funcionará bien con la validación de DNSSEC, ya que la zona raíz tiene registros NSEC que demuestran la inexistencia de, lab.por lo que es posible que deba excluir explícitamente su dominio de la validación, tanto en el solucionador de LAN como, a veces, en los propios hosts. . Sólo el home.arpa.dominio está reservado para este tipo de uso (teniendo registros NS deliberadamente sin firmar).
(Alternativamente, podríaspermitirDNSSEC, firme su zona interna y especifique un "ancla de confianza" personalizada en todos los resolutores de validación. Aunque DNSSEC no es realmente necesario en un laboratorio doméstico, la ventaja aquí es que agregar un ancla de confianza puede ser más fácil que agregar una exclusión, especialmente en BIND).