Después de año y medio de desarrollo lanzamiento del servidor DNS con caché , responsable de la transformación recursiva de nombres. PowerDNS Recursor se basa en el mismo código que PowerDNS Authoritative Server, pero los servidores DNS recursivos y autoritativos de PowerDNS se desarrollan en ciclos de desarrollo diferentes y se lanzan como productos separados. El código del proyecto bajo la licencia GPLv2.
en la nueva versión se han corregido todos los problemas relacionados con el manejo de paquetes DNS con banderas EDNS. En versiones anteriores de PowerDNS Recursor hasta 2016, se ignoraban los paquetes con banderas EDNS no soportadas sin enviar una respuesta en el formato antiguo, descartando las banderas EDNS, como lo exige la especificación. Este comportamiento no estándar fue soportado anteriormente en BIND como un mecanismo de elusión, pero en el marco de en febrero , los desarrolladores de servidores DNS decidieron abandonar este hack.
En PowerDNS, los principales problemas en el tratamiento de paquetes con EDNS se solucionaron ya en 2017 con la versión 4.1, y en la rama 4.0 lanzada en 2016 surgieron algunas incompatibilidades aisladas que, dadas ciertas circunstancias, no interferían en el funcionamiento normal. En PowerDNS Recursor 4.2, al igual que en , se eliminaron los caminos alternativos para soportar servidores autoritativos que responden incorrectamente a las solicitudes con banderas EDNS. Hasta ahora, si tras enviar una solicitud con banderas EDNS no se recibía respuesta después de un cierto período de tiempo, el servidor DNS consideraba que las banderas extendidas no eran soportadas y enviaba una solicitud de nuevo sin las banderas EDNS. A partir de ahora, este comportamiento está desactivado, ya que la presencia de dicho código provocaba un aumento en las latencias debido al reenvío de paquetes, añadía carga a la red y generaba ambigüedad por la falta de respuesta debido a fallas en la red, así como impedía la implementación de capacidades basadas en EDNS, como el uso de cookies DNS para protegerse contra ataques DDoS.
El próximo año se ha decidido llevar a cabo un evento , destinado a centrar la atención en de la fragmentación IP al procesar mensajes DNS grandes. En el marco de la iniciativa se recomienda fijar los tamaños de los buffers para EDNS a valores de hasta 1200 bytes, así como el procesamiento de solicitudes por TCP se considera obligatorio en los servidores. Actualmente, es fundamental el soporte para el procesamiento de solicitudes por UDP, mientras que TCP es deseable pero no obligatorio para el funcionamiento (el estándar prescribe la posibilidad de desactivar TCP). Se propone eliminar la opción de desactivar TCP del estándar y estandarizar la transición del envío de solicitudes por UDP al uso de TCP en los casos en que el tamaño del búfer EDNS sea insuficiente.
Los cambios propuestos en el marco de la iniciativa eliminarán la confusión respecto a la elección del tamaño del búfer EDNS y resolverán el problema de la fragmentación de grandes mensajes UDP, cuya gestión a menudo resulta en la pérdida de paquetes y tiempos de espera del lado del cliente. Del lado del cliente, el tamaño del búfer EDNS será constante, y las respuestas grandes se enviarán inmediatamente al cliente a través de TCP. La exclusión del envío de mensajes grandes por UDP también permitirá bloquear la manipulación del caché DNS basada en la manipulación de paquetes UDP fragmentados (al dividirse en fragmentos, el segundo fragmento no incluye el encabezado con el identificador, por lo que puede ser falsificado siempre que coincida la suma de verificación).
En PowerDNS Recursor 4.2 se han abordado los problemas con grandes paquetes UDP y se ha cambiado el uso del tamaño del búfer EDNS (edns-outgoing-bufsize) a 1232 bytes, en lugar del límite anterior de 1680 bytes, lo que debería reducir significativamente la probabilidad de pérdida de paquetes UDP. El valor 1232 fue elegido porque es el máximo en el que el tamaño de la respuesta DNS, considerando IPv6, se ajusta al valor mínimo de MTU (1280). También se ha reducido el valor del parámetro truncation-threshold, que es responsable de truncar las respuestas al cliente a 1232.
Otros cambios en PowerDNS Recursor 4.2:
- Se ha añadido soporte para el mecanismo (X-Proxied-For), que es equivalente al encabezado HTTP X-Forwarded-For para DNS, permitiendo transmitir información sobre la dirección IP y el número de puerto del iniciador original de la solicitud, redirigida a través de proxies intermedios y balanceadores de carga (por ejemplo, dnsdist). Para habilitar XPF, hay opciones como» y ««;
- Se ha mejorado el soporte para la extensión EDNS (ECS), que permite transmitir información sobre la subred desde la que se envió la consulta original a un servidor DNS autoritativo en las solicitudes DNS (los datos de la subred original del cliente son necesarios para el funcionamiento efectivo de las redes de entrega de contenido). La nueva versión incluye configuraciones para el control selectivo de la aplicación de EDNS Client Subnet: «» con una lista de máscaras de red para las que se utilizará la IP en ECS en las solicitudes salientes. Para las direcciones que no se ajustan a las máscaras especificadas, se utilizará la dirección general indicada en la directiva ««. A través de la directiva «» se pueden definir las subredes cuyos valores ECS completados en las solicitudes no serán reemplazados;
- Para servidores que manejan un gran número de solicitudes por segundo (más de 100,000), se propone la directiva ««, que define el número de hilos para recibir solicitudes entrantes y distribuirlas entre los hilos de trabajo (solo tiene sentido cuando se utiliza el modo ««).
- Se añadió la configuración de para definir su propio archivo con de dominios en los que los usuarios pueden registrar sus subdominios, en lugar de la lista incorporada en PowerDNS Recursor.
El proyecto PowerDNS también ha anunciado el cambio a un ciclo de desarrollo de seis meses, según el cual se espera que la próxima versión importante de PowerDNS Recursor 4.3 sea lanzada en enero de 2020. Las actualizaciones para las versiones importantes se formarán a lo largo del año, después de lo cual se lanzarán correcciones de vulnerabilidades durante seis meses más. Así, el soporte para la rama PowerDNS Recursor 4.2 se extenderá hasta enero de 2021. Cambios similares en el ciclo de desarrollo han sido adoptados para el producto PowerDNS Authoritative Server, cuya versión 4.2 se espera en breve.
Principales características de PowerDNS Recursor:
- Herramientas para la recopilación remota de estadísticas;
- Reinicio instantáneo;
- Motor incorporado para conectar controladores en Lua;
- Soporte completo para DNSSEC y ;
- Soporte para RPZ (Response Policy Zones) y capacidad para definir listas negras;
- Mecanismos de lucha contra el spoofing;
- Posibilidad de grabar resultados de resolución en forma de archivos de zona BIND.
- Para garantizar un alto rendimiento, se utilizan mecanismos modernos de multiplexión de conexiones en FreeBSD, Linux y Solaris (kqueue, epoll, /dev/poll), así como un parser de paquetes DNS de alto rendimiento capaz de manejar decenas de miles de solicitudes paralelas.
Fuente: opennet.ru
