{"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\/de\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Ver\u00f6ffentlichung von PowerDNS Recursor 4.2 und Initiative DNS Flag Day 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nach anderthalb Jahren Entwicklung vorgestellt<\/a><\/noindex> Release des zwischenspeichernden DNS-Servers PowerDNS Recursor 4.2<\/a><\/noindex>, verantwortlich f\u00fcr die rekursive Umwandlung von Namen. PowerDNS Recursor basiert auf demselben Code wie der PowerDNS Authoritative Server, jedoch entwickeln sich der rekursive und der autoritative DNS-Server von PowerDNS innerhalb unterschiedlicher Entwicklungszyklen und werden als separate Produkte ver\u00f6ffentlicht. Der Code des Projekts wird verbreitet<\/a><\/noindex> unter der GPLv2-Lizenz. <\/p>\n

In der neuen Version wurden alle Anmerkungen bez\u00fcglich der Verarbeitung von DNS-Paketen mit EDNS-Flags behoben. In \u00e4lteren Versionen von PowerDNS Recursor bis 2016 wurde es als g\u00e4ngige Praxis betrachtet, Pakete mit nicht unterst\u00fctzten EDNS-Flags zu ignorieren, ohne eine Antwort im alten Format zu senden, wobei die EDNS-Flags, wie es die Spezifikation verlangt, verworfen wurden. Solches nicht standardkonformes Verhalten wurde zuvor in BIND in Form eines Workarounds unterst\u00fctzt, aber im Rahmen der durchgef\u00fchrten<\/a><\/noindex> Initiative im Februar DNS-Flaggentag<\/a><\/noindex>, haben die Entwickler von DNS-Servern beschlossen, auf diesen Hack zu verzichten. <\/p>\n

In PowerDNS wurden die haupts\u00e4chlichen Probleme bei der Verarbeitung von EDNS-Paketen bereits 2017 mit der Ver\u00f6ffentlichung von 4.1 behoben, w\u00e4hrend in dem 2016 ver\u00f6ffentlichten 4.0-Zweig einzelne Inkompatibilit\u00e4ten auftraten, die unter bestimmten Umst\u00e4nden auftraten, aber insgesamt die normale Funktion nicht behinderten. In PowerDNS Recursor 4.2, wie auch in BIND 9.14<\/a><\/noindex>, wurden die Workarounds zur Unterst\u00fctzung von autoritativen Servern entfernt, die auf Anfragen mit EDNS-Flags inkorrekt antworten. Bisher betrachtete der DNS-Server, wenn nach dem Senden einer Anfrage mit EDNS-Flags nach einer bestimmten Zeit keine Antwort eintraf, die erweiterten Flags nicht als unterst\u00fctzt und sendete die Anfrage ohne EDNS-Flags erneut. Diese Verhaltensweise wurde nun deaktiviert, da das Vorhandensein eines solchen Codes zu h\u00f6heren Verz\u00f6gerungen durch die erneute Paket\u00fcbertragung f\u00fchrte, die Netzwerklast erh\u00f6hte und Unsicherheiten im Falle von fehlenden Antworten wegen Netzwerkfehlern verursachte, sowie die Einf\u00fchrung EDNS-basierter Funktionen, wie die Verwendung von DNS-Cookies zum Schutz vor DDoS-Angriffen, behinderte. <\/p>\n

Im kommenden Jahr wurde beschlossen, eine Veranstaltung abzuhalten DNS-Flag-Day 2020<\/a><\/noindex>, die darauf abzielt, auf die L\u00f6sung<\/a><\/noindex> der Probleme<\/a><\/noindex> zur IP-Fragmentierung bei der Verarbeitung von gro\u00dfen DNS-Nachrichten. Im Rahmen der Initiative es ist geplant<\/a><\/noindex> soll die empfohlene Buffergr\u00f6\u00dfe f\u00fcr EDNS auf Werte um 1200 Bytes festgelegt werden, sowie die<\/a><\/noindex> die Verarbeitung von Anfragen \u00fcber TCP als unbedingt unterst\u00fctztes Verfahren auf Servern. Derzeit ist die Unterst\u00fctzung der Verarbeitung von Anfragen \u00fcber UDP obligatorisch, w\u00e4hrend TCP w\u00fcnschenswert, aber nicht zwingend erforderlich f\u00fcr den Betrieb ist (der Standard sieht die M\u00f6glichkeit einer Deaktivierung von TCP vor). Es wird vorgeschlagen, die Option zur Deaktivierung von TCP aus dem Standard zu entfernen und den \u00dcbergang von der \u00dcbermittlung von Anfragen \u00fcber UDP zur Nutzung von TCP zu standardisieren, wenn die festgelegte Bufferg\u00f6\u00dfe von EDNS nicht ausreicht.<\/p>\n

Die im Rahmen der Initiative vorgeschlagenen \u00c4nderungen werden die Verwirrung bei der Wahl der EDNS-Puffergr\u00f6\u00dfe beseitigen und das Problem der Fragmentierung gro\u00dfer UDP-Nachrichten l\u00f6sen, deren Verarbeitung h\u00e4ufig zu Paketverlusten und Timeout-Problemen auf der Clientseite f\u00fchrt. Auf der Clientseite wird die EDNS-Puffergr\u00f6\u00dfe konstant sein, und gro\u00dfe Antworten werden umgehend per TCP an den Client gesendet. Der Ausschluss des Versands gro\u00dfer Nachrichten \u00fcber UDP wird auch die M\u00f6glichkeit bieten, zu blockieren Angriffe<\/a><\/noindex> auf DNS-Caching-Vergiftungen, die auf der Manipulation fragmentierter UDP-Pakete basieren (bei der Fragmentierung enth\u00e4lt das zweite Fragment keinen Header mit einer ID, sodass es gef\u00e4lscht werden kann, solange die Pr\u00fcfziffer \u00fcbereinstimmt), zu blockieren.<\/p>\n

In PowerDNS Recursor 4.2 wurden Probleme mit gro\u00dfen UDP-Paketen ber\u00fccksichtigt, und es wurde auf eine EDNS-Puffergr\u00f6\u00dfe (edns-outgoing-bufsize) von 1232 Bytes umgestellt, anstelle des zuvor verwendeten Limits von 1680 Bytes, was die Wahrscheinlichkeit von UDP-Paketverlusten erheblich verringern sollte. Der Wert von 1232 wurde gew\u00e4hlt, da er das Maximum darstellt, bei dem die Gr\u00f6\u00dfe der DNS-Antwort unter Ber\u00fccksichtigung von IPv6 in das minimale MTU (1280) passt. Auch der Parameter truncation-threshold, der f\u00fcr das K\u00fcrzen von Antworten an den Client verantwortlich ist, wurde auf 1232 reduziert.<\/p>\n

Weitere \u00c4nderungen in PowerDNS Recursor 4.2:<\/p>\n