Después de un año y medio de desarrollo lanzamiento del servidor DNS de almacenamiento en caché , responsable de la conversión recursiva de nombres. PowerDNS Recursor se basa en la misma base de código que PowerDNS Authoritative Server, pero los servidores DNS autoritativos y recursivos de PowerDNS se desarrollan a través de diferentes ciclos de desarrollo y se lanzan como productos separados. Código de proyecto licenciado bajo GPLv2.
La nueva versión elimina todos los problemas relacionados con el procesamiento de paquetes DNS con indicadores EDNS. Las versiones anteriores de PowerDNS Recursor anteriores a 2016 tenían la práctica de ignorar paquetes con indicadores EDNS no compatibles sin enviar una respuesta en el formato anterior, descartando los indicadores EDNS según lo exige la especificación. Anteriormente, este comportamiento no estándar era compatible con BIND como solución alternativa, pero dentro del alcance de en febrero iniciativas , los desarrolladores del servidor DNS decidieron abandonar este truco.
En PowerDNS, los principales problemas al procesar paquetes con EDNS se eliminaron en 2017 en la versión 4.1, y en la rama 2016 lanzada en 4.0, surgieron incompatibilidades individuales que surgen bajo un cierto conjunto de circunstancias y, en general, no interfieren con la normalidad. operación. En PowerDNS Recursor 4.2, como en , Se eliminaron soluciones alternativas para admitir servidores autorizados que responden incorrectamente a solicitudes con indicadores EDNS. Hasta ahora, si después de enviar una solicitud con banderas EDNS no había respuesta después de un cierto período de tiempo, el servidor DNS asumía que las banderas extendidas no eran compatibles y enviaba una segunda solicitud sin banderas EDNS. Este comportamiento ahora se ha deshabilitado ya que este código resultó en una mayor latencia debido a las retransmisiones de paquetes, una mayor carga de la red y ambigüedad al no responder debido a fallas de la red, e impidió la implementación de funciones basadas en EDNS, como cookies DNS para proteger contra ataques DDoS.
Se ha decidido celebrar el evento el próximo año. diseñado para centrar la atención en con fragmentación de IP al procesar mensajes DNS grandes. Como parte de la iniciativa fijar los tamaños de búfer recomendados para EDNS a 1200 bytes, y El procesamiento de solicitudes a través de TCP es una característica imprescindible en los servidores. Ahora se requiere soporte para procesar solicitudes a través de UDP, y TCP es deseable, pero no necesario para la operación (el estándar requiere la capacidad de deshabilitar TCP). Se propone eliminar la opción de deshabilitar TCP del estándar y estandarizar la transición del envío de solicitudes a través de UDP al uso de TCP en los casos en que el tamaño del búfer EDNS establecido no sea suficiente.
Los cambios propuestos como parte de la iniciativa eliminarán la confusión a la hora de elegir el tamaño del búfer EDNS y resolverán el problema de la fragmentación de grandes mensajes UDP, cuyo procesamiento a menudo provoca pérdida de paquetes y tiempos de espera en el lado del cliente. En el lado del cliente, el tamaño del búfer EDNS será constante y se enviarán respuestas grandes inmediatamente al cliente a través de TCP. Evitar enviar mensajes grandes a través de UDP también le permitirá bloquear para envenenar el caché DNS, basado en la manipulación de paquetes UDP fragmentados (cuando se divide en fragmentos, el segundo fragmento no incluye un encabezado con un identificador, por lo que puede ser falsificado, para lo cual solo es suficiente que la suma de verificación coincida) .
PowerDNS Recursor 4.2 tiene en cuenta los problemas con paquetes UDP grandes y cambia al uso del tamaño de búfer EDNS (edns-outgoing-bufsize) de 1232 bytes, en lugar del límite utilizado anteriormente de 1680 bytes, lo que debería reducir significativamente la probabilidad de perder paquetes UDP. . Se eligió el valor 1232 porque es el máximo en el que el tamaño de la respuesta DNS, teniendo en cuenta IPv6, encaja en el valor mínimo de MTU (1280). El valor del parámetro umbral de truncamiento, que es responsable de recortar las respuestas al cliente, también se ha reducido a 1232.
Otros cambios en PowerDNS Recursor 4.2:
- Soporte de mecanismo agregado (X-Proxied-For), que es el equivalente DNS del encabezado HTTP X-Forwarded-For, que permite reenviar información sobre la dirección IP y el número de puerto del solicitante original a través de servidores proxy intermedios y balanceadores de carga (como dnsdist) . Para habilitar XPF hay opciones ""Y"';
- Soporte mejorado para la extensión EDNS (ECS), que le permite transmitir en consultas DNS a un servidor DNS autorizado información sobre la subred desde la cual se envenenó la solicitud inicial transmitida a lo largo de la cadena (los datos sobre la subred de origen del cliente son necesarios para el funcionamiento efectivo de las redes de entrega de contenido) . La nueva versión agrega configuraciones para el control selectivo sobre el uso de la subred del cliente EDNS: "» con una lista de máscaras de red para las cuales se utilizará la IP en ECS en solicitudes salientes. Para direcciones que no se encuentran dentro de las máscaras especificadas, la dirección general especificada en la directiva "". A través de la directiva "» puede definir subredes desde las cuales no se reemplazarán las solicitudes entrantes con valores ECS completos;
- Para servidores que procesan una gran cantidad de solicitudes por segundo (más de 100 mil), la directiva “", que determina la cantidad de subprocesos para recibir solicitudes entrantes y distribuirlas entre subprocesos de trabajo (tiene sentido solo cuando se usa "").
- Configuración agregada para definir su propio archivo con dominios en los que los usuarios pueden registrar sus subdominios, en lugar de la lista integrada en PowerDNS Recursor.
El proyecto PowerDNS también anunció un paso a un ciclo de desarrollo de seis meses, y se espera el próximo lanzamiento importante de PowerDNS Recursor 4.3 para enero de 2020. A lo largo del año se desarrollarán actualizaciones para versiones importantes, después de lo cual se publicarán correcciones de vulnerabilidad durante otros seis meses. Por lo tanto, el soporte para la rama PowerDNS Recursor 4.2 durará hasta enero de 2021. Se han realizado cambios similares en el ciclo de desarrollo para PowerDNS Authoritative Server, que se espera que lance la versión 4.2 en un futuro próximo.
Características principales de PowerDNS Recursor:
- Herramientas para la recopilación remota de estadísticas;
- Reinicio instantáneo;
- Motor incorporado para conectar controladores en lenguaje Lua;
- Soporte completo DNSSEC y ;
- Soporte para RPZ (Zonas de Política de Respuesta) y la capacidad de definir listas negras;
- Mecanismos antisuplantación de identidad;
- Capacidad para registrar resultados de resolución como archivos de zona BIND.
- Para garantizar un alto rendimiento, se utilizan modernos mecanismos de multiplexación de conexiones en FreeBSD, Linux y Solaris (kqueue, epoll, /dev/poll), así como un analizador de paquetes DNS de alto rendimiento capaz de procesar decenas de miles de solicitudes paralelas.
Fuente: opennet.ru