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

Nach anderthalb Jahren Entwicklung wurde vorgestellt<\/a><\/noindex> Release des zwischenspeichernden DNS-Servers PowerDNS Recursor 4.2<\/a><\/noindex>, der f\u00fcr die rekursive Namensaufl\u00f6sung zust\u00e4ndig ist. PowerDNS Recursor basiert auf demselben Code-Base wie PowerDNS Authoritative Server, jedoch entwickeln sich rekursive und autoritative DNS-Server von PowerDNS in unterschiedlichen Entwicklungszyklen und werden als separate Produkte angeboten. Der Projektcode wird unter der GPLv3-Lizenz bereitgestellt.<\/a><\/noindex> steht unter der GPLv2-Lizenz. <\/p>\n

In der neuen Version wurden alle Probleme im Zusammenhang mit der Verarbeitung von DNS-Paketen mit EDNS-Flags behoben. In \u00e4lteren Versionen des PowerDNS Recursor bis 2016 wurde die Annahme von Paketen mit nicht unterst\u00fctzten EDNS-Flags praktiziert, ohne im alten Format zu antworten, indem die EDNS-Flags gem\u00e4\u00df den Spezifikationen verworfen wurden. Ein solches nicht standardm\u00e4\u00dfiges Verhalten wurde in BIND in Form eines Umgehungsman\u00f6vers unterst\u00fctzt, aber im Rahmen der durchgef\u00fchrten<\/a><\/noindex> Initiative im Februar DNS-Flag-Woche<\/a><\/noindex>, haben die Entwickler von DNS-Servern beschlossen, auf diesen Hack zu verzichten. <\/p>\n

In PowerDNS wurden die Hauptprobleme bei der Verarbeitung von EDNS-Paketen bereits 2017 in der Version 4.1 behoben. In der im Jahr 2016 ver\u00f6ffentlichten Version 4.0 traten sporadische Inkompatibilit\u00e4ten auf, die unter bestimmten Umst\u00e4nden auftreten konnten, jedoch im Allgemeinen die normale Funktionsweise nicht beeintr\u00e4chtigten. In PowerDNS Recursor 4.2, wie auch in BIND 9.14<\/a><\/noindex>, Umgehungswege f\u00fcr die Unterst\u00fctzung autorisierter Server, die nicht korrekt auf Anfragen mit EDNS-Flags reagieren, wurden entfernt. Bis jetzt ging der DNS-Server davon aus, dass erweiterte Flags nicht unterst\u00fctzt werden, wenn nach dem Senden einer Anfrage mit EDNS-Flags nach einer bestimmten Zeit keine Antwort eintraf, und er sendete die Anfrage ohne EDNS-Flags erneut. Dieses Verhalten wurde nun abgeschaltet, da derartige Kodierungen zu erh\u00f6hten Latenzen aufgrund von wiederholten Paket\u00fcbertragungen, einer h\u00f6heren Netzbelastung und Unklarheiten bei fehlenden Antworten wegen Netzwerkst\u00f6rungen f\u00fchrten und die Einf\u00fchrung von EDNS-basierten Funktionen, wie die Anwendung von DNS-Cookies zum Schutz vor DDoS-Angriffen, erschwerten. <\/p>\n

Im n\u00e4chsten Jahr wird entschieden, eine Veranstaltung DNS Flag Day 2020<\/a><\/noindex>, um auf das Thema L\u00f6sung<\/a><\/noindex> problemen<\/a><\/noindex> mit IP-Fragmentierung bei der Verarbeitung von gro\u00dfen DNS-Nachrichten durchzuf\u00fchren. Im Rahmen der Initiative wird geplant<\/a><\/noindex> sollen die empfohlenen Puffergr\u00f6\u00dfen f\u00fcr EDNS auf Werte von 1200 Byte festgelegt werden, sowie Verarbeitung von Anfragen \u00fcber TCP als zwingend unterst\u00fctzte Funktion auf Servern zu definieren. In<\/a><\/noindex> Die Verarbeitung von Anfragen \u00fcber TCP sollte auf Servern unbedingt unterst\u00fctzt werden. Aktuell ist die Unterst\u00fctzung der Verarbeitung von Anfragen \u00fcber UDP erforderlich, w\u00e4hrend TCP w\u00fcnschenswert, aber nicht zwingend f\u00fcr den Betrieb ist (der Standard sieht die M\u00f6glichkeit vor, TCP zu deaktivieren). Es wird vorgeschlagen, die Option zur Deaktivierung von TCP aus dem Standard zu entfernen und den \u00dcbergang von der Versendung von Anfragen \u00fcber UDP zur Anwendung von TCP zu standardisieren, wenn die Gr\u00f6\u00dfe des EDNS-Puffers nicht ausreicht.<\/p>\n

Die im Rahmen der Initiative vorgeschlagenen \u00c4nderungen werden die Verwirrung bei der Auswahl der Gr\u00f6\u00dfe des EDNS-Puffers beseitigen und das Problem mit der Fragmentierung gro\u00dfer UDP-Nachrichten l\u00f6sen, deren Verarbeitung h\u00e4ufig zu Paketverlusten und Zeit\u00fcberschreitungen auf der Client-Seite f\u00fchrt. Auf der Client-Seite wird die EDNS-Puffergr\u00f6\u00dfe konstant sein, und gro\u00dfe Antworten werden sofort \u00fcber TCP an den Client gesendet. Der Ausschluss des Versands gro\u00dfer Nachrichten \u00fcber UDP erm\u00f6glicht zudem die Blockierung von sch\u00fctzt man sich vor<\/a><\/noindex> DNS-Cache-Vergiftungen auf der Grundlage der Manipulation fragmentierter UDP-Pakete auftreten (da beim Zerlegen in Fragmente das zweite Fragment keinen Header mit der Kennung enth\u00e4lt, kann es genug gef\u00e4lscht werden, sodass nur die Pr\u00fcfziffer \u00fcbereinstimmt).<\/p>\n

In PowerDNS Recursor 4.2 wurden Probleme mit gro\u00dfen UDP-Paketen ber\u00fccksichtigt, und es fand eine Umstellung auf die Nutzung der EDNS-Puffergr\u00f6\u00dfe (edns-outgoing-bufsize) von 1232 Byte statt, anstelle des zuvor verwendeten Limits von 1680 Byte. Dies sollte die Wahrscheinlichkeit des Verlusts von UDP-Paketen erheblich verringern. Der Wert 1232 wurde gew\u00e4hlt, da er das Maximum ist, bei dem die Gr\u00f6\u00dfe der DNS-Antwort unter Ber\u00fccksichtigung von IPv6 das minimale MTU (1280) einh\u00e4lt. Auch der Parameter truncation-threshold, der f\u00fcr das Trimmen von Antworten an den Client zust\u00e4ndig ist, wurde auf 1232 gesenkt.<\/p>\n

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