Tengo un servidor DHCP/DNS (ISC Bind 9.6, DHCP 3.1.1) en funcionamiento ejecutándose en Debian al que me gustaría agregar la funcionalidad DynamicDNS. Tengo una pregunta bastante simple: ¿DynamicDNS requiere (o recomienda) subdominios separados? He visto algunos tutoriales en los que los clientes que adquieren sus direcciones IP y otra información de red a través de DHCP están en un subdominio diferente al de los servidores que están configurados estáticamente (tanto en términos de IP como de DNS). Por ejemplo: todos los clientes están en ws.example.org y los servidores en example.org.
En este momento, todos nuestros servidores y clientes están en el mismo dominio (ejemplo.org) pero distribuidos en diferentes archivos de zona (porque tenemos varias subredes). Los clientes se configuran con DHCP y los servidores se configuran estáticamente. Si quiero configurar DynamicDNS para los clientes, ¿debo usar un subdominio separado? ¿Cuál es la mejor práctica aquí (y por qué o no sería una mala idea hacer lo contrario)?
Gracias.
Respuesta1
No, técnicamente no es necesario tener una zona separada para actualizaciones dinámicas.
Creo que el factor más importante en el uso de subdominios para DNS dinámico tiene que ver con las políticas de seguridad para actualizar la zona. En mi opinión, los permisos que puedes establecer en bind no son muy flexibles, aunque las versiones más nuevas son algo mejores. Con allow-update(Bind 8.*) los permisos se aplican a nivel de zona y no por registro. Por lo tanto, el cliente a podría actualizar el registro de su servidor crítico si tuviera una dirección IP autorizada para realizar actualizaciones.
Entonces, al decidir sobre su configuración de DNS dinámico, debe decidir si cree que es una buena idea permitir que sus estaciones de trabajo puedan cambiar los registros de actualización para algún servicio crítico. ¿O desea separar los servicios críticos en una zona sin actualizaciones dinámicas y otras máquinas en las zonas más dinámicas?
Respuesta2
El DNS dinámico nonecesidadun subdominio separado, pero esa es la forma más fácil (y mejor) de configurarlo.
Si restringe las actualizaciones de DynamicDNS a un subdominio (ws.example.org) y una subred (ambas sin servidores), es bastante sencillo configurar las restricciones para que no pueda suceder nada demasiado malo. El peor caso de que algo salga mal es que una estación de trabajo se identifique como otra estación de trabajo.
Si configura actualizaciones de DynamicDNS en el mismo dominio principal donde se encuentran los servidores, debe tener cuidado al configurar restricciones para que las estaciones de trabajo no puedan actualizarse dinámicamente para ser, por ejemplo, www.example.org. Ha pasado mucho tiempo desde que lo miré, pero es posible que termines necesitando una ACL separada para cada servidor (u otro dispositivo para el que quieras proteger el nombre). Problemas similares con las subredes.