{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Lanzamiento de PowerDNS Recursor 4.2 e iniciativa DNS Flag Day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Despu\u00e9s de a\u00f1o y medio de desarrollo presentado<\/a><\/noindex> lanzamiento del servidor DNS con cach\u00e9 PowerDNS Recursor 4.2<\/a><\/noindex>, responsable de la transformaci\u00f3n recursiva de nombres. PowerDNS Recursor se basa en el mismo c\u00f3digo 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\u00f3digo del proyecto se distribuye<\/a><\/noindex> bajo la licencia GPLv2. <\/p>\n

en la nueva versi\u00f3n 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\u00f3n. Este comportamiento no est\u00e1ndar fue soportado anteriormente en BIND como un mecanismo de elusi\u00f3n, pero en el marco de la iniciativa realizada<\/a><\/noindex> en febrero DNS flag day<\/a><\/noindex>, los desarrolladores de servidores DNS decidieron abandonar este hack. <\/p>\n

En PowerDNS, los principales problemas en el tratamiento de paquetes con EDNS se solucionaron ya en 2017 con la versi\u00f3n 4.1, y en la rama 4.0 lanzada en 2016 surgieron algunas incompatibilidades aisladas que, dadas ciertas circunstancias, no interfer\u00edan en el funcionamiento normal. En PowerDNS Recursor 4.2, al igual que en BIND 9.14<\/a><\/noindex>, 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\u00eda respuesta despu\u00e9s de un cierto per\u00edodo 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\u00e1 desactivado, ya que la presencia de dicho c\u00f3digo provocaba un aumento en las latencias debido al reenv\u00edo de paquetes, a\u00f1ad\u00eda carga a la red y generaba ambig\u00fcedad por la falta de respuesta debido a fallas en la red, as\u00ed como imped\u00eda la implementaci\u00f3n de capacidades basadas en EDNS, como el uso de cookies DNS para protegerse contra ataques DDoS. <\/p>\n

El pr\u00f3ximo a\u00f1o se ha decidido llevar a cabo un evento DNS flag day 2020<\/a><\/noindex>, destinado a centrar la atenci\u00f3n en la soluci\u00f3n<\/a><\/noindex> problemas<\/a><\/noindex> de la fragmentaci\u00f3n IP al procesar mensajes DNS grandes. En el marco de la iniciativa est\u00e1 previsto<\/a><\/noindex> se recomienda fijar los tama\u00f1os de los buffers para EDNS a valores de hasta 1200 bytes, as\u00ed como traducir<\/a><\/noindex> 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\u00e1ndar prescribe la posibilidad de desactivar TCP). Se propone eliminar la opci\u00f3n de desactivar TCP del est\u00e1ndar y estandarizar la transici\u00f3n del env\u00edo de solicitudes por UDP al uso de TCP en los casos en que el tama\u00f1o del b\u00fafer EDNS sea insuficiente.<\/p>\n

Los cambios propuestos en el marco de la iniciativa eliminar\u00e1n la confusi\u00f3n respecto a la elecci\u00f3n del tama\u00f1o del b\u00fafer EDNS y resolver\u00e1n el problema de la fragmentaci\u00f3n de grandes mensajes UDP, cuya gesti\u00f3n a menudo resulta en la p\u00e9rdida de paquetes y tiempos de espera del lado del cliente. Del lado del cliente, el tama\u00f1o del b\u00fafer EDNS ser\u00e1 constante, y las respuestas grandes se enviar\u00e1n inmediatamente al cliente a trav\u00e9s de TCP. La exclusi\u00f3n del env\u00edo de mensajes grandes por UDP tambi\u00e9n permitir\u00e1 bloquear del ataque<\/a><\/noindex> la manipulaci\u00f3n del cach\u00e9 DNS basada en la manipulaci\u00f3n 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\u00f3n).<\/p>\n

En PowerDNS Recursor 4.2 se han abordado los problemas con grandes paquetes UDP y se ha cambiado el uso del tama\u00f1o del b\u00fafer EDNS (edns-outgoing-bufsize) a 1232 bytes, en lugar del l\u00edmite anterior de 1680 bytes, lo que deber\u00eda reducir significativamente la probabilidad de p\u00e9rdida de paquetes UDP. El valor 1232 fue elegido porque es el m\u00e1ximo en el que el tama\u00f1o de la respuesta DNS, considerando IPv6, se ajusta al valor m\u00ednimo de MTU (1280). Tambi\u00e9n se ha reducido el valor del par\u00e1metro truncation-threshold, que es responsable de truncar las respuestas al cliente a 1232.<\/p>\n

Otros cambios en PowerDNS Recursor 4.2:<\/p>\n