Die Veröffentlichung von PowerDNS Recursor 4.2 und die Initiative DNS Flag Day 2020

Nach anderthalb Jahren Entwicklung wurde vorgestellt Release des zwischenspeichernden DNS-Servers PowerDNS Recursor 4.2, der für die rekursive Namensauflösung zuständig 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. steht unter der GPLv2-Lizenz.

In der neuen Version wurden alle Probleme im Zusammenhang mit der Verarbeitung von DNS-Paketen mit EDNS-Flags behoben. In älteren Versionen des PowerDNS Recursor bis 2016 wurde die Annahme von Paketen mit nicht unterstützten EDNS-Flags praktiziert, ohne im alten Format zu antworten, indem die EDNS-Flags gemäß den Spezifikationen verworfen wurden. Ein solches nicht standardmäßiges Verhalten wurde in BIND in Form eines Umgehungsmanövers unterstützt, aber im Rahmen der durchgeführten Initiative im Februar DNS-Flag-Woche, haben die Entwickler von DNS-Servern beschlossen, auf diesen Hack zu verzichten.

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öffentlichten Version 4.0 traten sporadische Inkompatibilitäten auf, die unter bestimmten Umständen auftreten konnten, jedoch im Allgemeinen die normale Funktionsweise nicht beeinträchtigten. In PowerDNS Recursor 4.2, wie auch in BIND 9.14, Umgehungswege für die Unterstützung 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ützt 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öhten Latenzen aufgrund von wiederholten Paketübertragungen, einer höheren Netzbelastung und Unklarheiten bei fehlenden Antworten wegen Netzwerkstörungen führten und die Einführung von EDNS-basierten Funktionen, wie die Anwendung von DNS-Cookies zum Schutz vor DDoS-Angriffen, erschwerten.

Im nächsten Jahr wird entschieden, eine Veranstaltung DNS Flag Day 2020, um auf das Thema Lösung problemen mit IP-Fragmentierung bei der Verarbeitung von großen DNS-Nachrichten durchzuführen. Im Rahmen der Initiative wird geplant sollen die empfohlenen Puffergrößen für EDNS auf Werte von 1200 Byte festgelegt werden, sowie Verarbeitung von Anfragen über TCP als zwingend unterstützte Funktion auf Servern zu definieren. In Die Verarbeitung von Anfragen über TCP sollte auf Servern unbedingt unterstützt werden. Aktuell ist die Unterstützung der Verarbeitung von Anfragen über UDP erforderlich, während TCP wünschenswert, aber nicht zwingend für den Betrieb ist (der Standard sieht die Möglichkeit vor, TCP zu deaktivieren). Es wird vorgeschlagen, die Option zur Deaktivierung von TCP aus dem Standard zu entfernen und den Übergang von der Versendung von Anfragen über UDP zur Anwendung von TCP zu standardisieren, wenn die Größe des EDNS-Puffers nicht ausreicht.

Die im Rahmen der Initiative vorgeschlagenen Änderungen werden die Verwirrung bei der Auswahl der Größe des EDNS-Puffers beseitigen und das Problem mit der Fragmentierung großer UDP-Nachrichten lösen, deren Verarbeitung häufig zu Paketverlusten und Zeitüberschreitungen auf der Client-Seite führt. Auf der Client-Seite wird die EDNS-Puffergröße konstant sein, und große Antworten werden sofort über TCP an den Client gesendet. Der Ausschluss des Versands großer Nachrichten über UDP ermöglicht zudem die Blockierung von schützt man sich vor 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ält, kann es genug gefälscht werden, sodass nur die Prüfziffer übereinstimmt).

In PowerDNS Recursor 4.2 wurden Probleme mit großen UDP-Paketen berücksichtigt, und es fand eine Umstellung auf die Nutzung der EDNS-Puffergröße (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ählt, da er das Maximum ist, bei dem die Größe der DNS-Antwort unter Berücksichtigung von IPv6 das minimale MTU (1280) einhält. Auch der Parameter truncation-threshold, der für das Trimmen von Antworten an den Client zuständig ist, wurde auf 1232 gesenkt.

Weitere Änderungen in PowerDNS Recursor 4.2:

  • Unterstützung für den Mechanismus hinzugefügt XPF (X-Proxied-For), der das Äquivalent des HTTP-Headers X-Forwarded-For für DNS darstellt. Er ermöglicht die Übertragung von Informationen zu der IP-Adresse und der Portnummer des ursprünglichen Anfragestellers, der über ZwischProxy und Lastverteilers (z. B. dnsdist) umgeleitet wurde. Um XPF zu aktivieren, sind die Optionen „xpf-allow-from» und «xpf-rr-code«;
  • Verbesserte Unterstützung für die EDNS-Erweiterung Client Subnet (ECS), das autoritativen DNS-Servern Informationen über das Subnetz überträgt, aus dem die ursprüngliche, durchgereichte Anfrage gesendet wurde (Daten über das ursprüngliche Subnetz des Clients sind für eine effektive Funktionsweise von Content Delivery Networks erforderlich). In dieser Version wurden Einstellungen für die selektive Kontrolle der Anwendung von EDNS Client Subnet hinzugefügt: „ecs-add-for“ mit einer Liste von Netzwerkmasken, für die die IP in ECS in ausgehenden Anfragen verwendet wird. Für Adressen, die nicht unter die angegebenen Masken fallen, wird die allgemeine Adresse verwendet, die in der Direktive „ecs-scope-zero-address“ angegeben ist. Über die Direktive „use-incoming-edns-subnet“ können Subnetze definiert werden, aus denen eingehende Anfragen mit ausgefüllten ECS-Werten nicht ersetzt werden;
  • Für Server, die eine große Anzahl von Anfragen pro Sekunde (mehr als 100.000) bearbeiten, wurde die Direktive „distributor-threads“ eingeführt, die die Anzahl der Threads zur Annahme eingehender Anfragen und deren Verteilung auf die Arbeits-Threads definiert (sinnvoll nur bei aktivierter Option „pdns-distributes-queries=yes«).
  • Eine Einstellung wurde hinzugefügt public-suffix-list-file zur Definition einer eigenen Datei mit einer Liste von öffentlichen Suffixen Domains, in denen Benutzer ihre Subdomains registrieren können, anstelle der integrierten Liste im PowerDNS Recursor.

Das PowerDNS-Projekt kündigte außerdem den Wechsel zu einem sechsmonatigen Entwicklungszyklus an, nach dem die nächste bedeutende Version von PowerDNS Recursor 4.3 für Januar 2020 erwartet wird. Updates für bedeutende Veröffentlichungen werden über das Jahr hinweg erstellt, gefolgt von einem weiteren halben Jahr, in dem Sicherheitsupdates veröffentlicht werden. Somit wird der Support für die PowerDNS Recursor-Version 4.2 bis Januar 2021 fortgesetzt. Ähnliche Änderungen am Entwicklungszyklus wurden für das Produkt PowerDNS Authoritative Server beschlossen, dessen Version 4.2 in Kürze erwartet wird.

Wesentliche Funktionen von PowerDNS Recursor:

  • Werkzeuge zur Fernabfrage von Statistiken;
  • Sofortiger Neustart;
  • Integrierte Engine zur Anbindung von Lua-Handlern;
  • Umfassende Unterstützung für DNSSEC und DNS64;;
  • Unterstützung von RPZ (Response Policy Zones) und Möglichkeit zur Definition von Blacklists;
  • Mechanismen zur Bekämpfung von Spoofing;
  • Möglichkeit, die Ergebnisse der Auflösung in Form von BIND-Zonen-Dateien zu speichern.
  • Um hohe Leistung zu gewährleisten, kommen moderne Mechanismen zur Verbindungsmultiplexierung in FreeBSD, Linux und Solaris (kqueue, epoll, /dev/poll) sowie ein hochleistungsfähiger DNS-Paketparser zum Einsatz, der in der Lage ist, zehntausende parallele Anfragen zu verarbeiten.

Quelle: opennet.ru

Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster