Estoy a punto de implementar DNSSEC para algunos de mis dominios y mientras me estaba preparando leí un poco sobre el tema. Encontré algunos artículos de Microsoft Technet que hablaban sobreTabla de políticas de resolución de nombresque permite configurar clientes DNS de Windows parautilizar IPSecal comunicarse con el servidor DNS para proporcionar integridad y (opcionalmente) autenticación.
Desde mi punto de vista, esto parece una idea bastante buena, pero lamentablemente el NRPT es exclusivo de Windows. ¿Existe un equivalente en el mundo Linux/OpenBSD? Tener DNSSEC e IPSec combinados parecería ser la solución perfecta para los administradores de servidores preocupados por la seguridad.
Respuesta1
Todo este asunto del NRPT suena como una manera de traerDNSSECalgo en consonancia conCurva DNS, excepto que en lugar de tener un único estándar y especificación como es el caso del propio DNSCurve, simplemente están arrojando un montón de estándares no relacionados en un gran lío de administración y configuración.
Implementar DNSSEC para servidores recursivos y autoritativos son dos tareas completamente diferentes.
¿Qué estás tratando de lograr exactamente? En el mundo de Linux y BSD, si simplemente desea asegurarse de que se esté realizando la verificación/validación de DNSSEC, la mejor manera de hacerlo es ejecutar su propio solucionador de almacenamiento en caché o recursivo local. Para obtener algunos detalles de cómo se hace, eche un vistazo a los cambios recientes que se realizaron en el próximo FreeBSD 10, donde introdujeron unboundel árbol base, que, cuando se usa correctamente (por ejemplo, si está configurado como el único solucionador disponible), No se supone que resuelva ningún nombre de dominio que tenga DNSSEC habilitado, pero que tenga registros que no estén firmados correctamente, pero que se suponía que estaban firmados.
Hastaautoritarioservidores, si desea un poco de seguridad y privacidad adicionales, su mejor opción es ejecutar DNSCurve como front-end y posiblemente todavía tener DNSSEC en el backend, si es necesario.
supongo que pararecursivoDNS, estaría haciendo exactamente lo mismo, pero al revés: tal vez configurar un local unboundpara que sea un solucionador de almacenamiento en caché/verificación, que emitiría todas sus consultas a través de un solucionador recursivo local compatible con DNSCurve, pero nunca de otra manera.
Sin embargo, en los dos ejemplos anteriores, creo que estás entrando en un territorio inexplorado.