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

Nach anderthalb Jahren Entwicklung vorgestellt Release des zwischenspeichernden DNS-Servers PowerDNS Recursor 4.2, verantwortlich für 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öffentlicht. Der Code des Projekts wird verbreitet unter der GPLv2-Lizenz.

In der neuen Version wurden alle Anmerkungen bezüglich der Verarbeitung von DNS-Paketen mit EDNS-Flags behoben. In älteren Versionen von PowerDNS Recursor bis 2016 wurde es als gängige Praxis betrachtet, Pakete mit nicht unterstützten 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ützt, aber im Rahmen der durchgeführten Initiative im Februar DNS-Flaggentag, haben die Entwickler von DNS-Servern beschlossen, auf diesen Hack zu verzichten.

In PowerDNS wurden die hauptsächlichen Probleme bei der Verarbeitung von EDNS-Paketen bereits 2017 mit der Veröffentlichung von 4.1 behoben, während in dem 2016 veröffentlichten 4.0-Zweig einzelne Inkompatibilitäten auftraten, die unter bestimmten Umständen auftraten, aber insgesamt die normale Funktion nicht behinderten. In PowerDNS Recursor 4.2, wie auch in BIND 9.14, wurden die Workarounds zur Unterstützung 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ützt und sendete die Anfrage ohne EDNS-Flags erneut. Diese Verhaltensweise wurde nun deaktiviert, da das Vorhandensein eines solchen Codes zu höheren Verzögerungen durch die erneute Paketübertragung führte, die Netzwerklast erhöhte und Unsicherheiten im Falle von fehlenden Antworten wegen Netzwerkfehlern verursachte, sowie die Einführung EDNS-basierter Funktionen, wie die Verwendung von DNS-Cookies zum Schutz vor DDoS-Angriffen, behinderte.

Im kommenden Jahr wurde beschlossen, eine Veranstaltung abzuhalten DNS-Flag-Day 2020, die darauf abzielt, auf die Lösung der Probleme zur IP-Fragmentierung bei der Verarbeitung von großen DNS-Nachrichten. Im Rahmen der Initiative es ist geplant soll die empfohlene Buffergröße für EDNS auf Werte um 1200 Bytes festgelegt werden, sowie die die Verarbeitung von Anfragen über TCP als unbedingt unterstütztes Verfahren auf Servern. Derzeit ist die Unterstützung der Verarbeitung von Anfragen über UDP obligatorisch, während TCP wünschenswert, aber nicht zwingend erforderlich für den Betrieb ist (der Standard sieht die Möglichkeit einer Deaktivierung von TCP vor). Es wird vorgeschlagen, die Option zur Deaktivierung von TCP aus dem Standard zu entfernen und den Übergang von der Übermittlung von Anfragen über UDP zur Nutzung von TCP zu standardisieren, wenn die festgelegte Buffergöße von EDNS nicht ausreicht.

Die im Rahmen der Initiative vorgeschlagenen Änderungen werden die Verwirrung bei der Wahl der EDNS-Puffergröße beseitigen und das Problem der Fragmentierung großer UDP-Nachrichten lösen, deren Verarbeitung häufig zu Paketverlusten und Timeout-Problemen auf der Clientseite führt. Auf der Clientseite wird die EDNS-Puffergröße konstant sein, und große Antworten werden umgehend per TCP an den Client gesendet. Der Ausschluss des Versands großer Nachrichten über UDP wird auch die Möglichkeit bieten, zu blockieren Angriffe auf DNS-Caching-Vergiftungen, die auf der Manipulation fragmentierter UDP-Pakete basieren (bei der Fragmentierung enthält das zweite Fragment keinen Header mit einer ID, sodass es gefälscht werden kann, solange die Prüfziffer übereinstimmt), zu blockieren.

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

Weitere Änderungen in PowerDNS Recursor 4.2:

  • Unterstützung für den Mechanismus XPF (X-Proxied-For), was dem HTTP-Header X-Forwarded-For für DNS entspricht und es ermöglicht, Informationen über die IP-Adresse und Ports des ursprünglichen Anforderers, der über Zwischenproxies und Lastenausgleicher (zum Beispiel dnsdist) umgeleitet wurde, zu übertragen. Zur Aktivierung von XPF sind die Optionen „xpf-allow-from» und „xpf-rr-code«;
  • Die Unterstützung der EDNS-Erweiterung Client Subnet (ECS) wurde verbessert, sodass Informationen über das Subnetz, aus dem die ursprünglich über die Kette gesendete Anfrage stammte, an den autoritativen DNS-Server übergeben werden können (Daten über das ursprüngliche Klientensubnetz sind für das effektive Funktionieren von Content Delivery Networks erforderlich). Im neuen Release wurden Einstellungen für die selektive Kontrolle der Anwendung des EDNS Client Subnet hinzugefügt: „ecs-add-for“ mit einer Liste von Netzmasken, 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-Attributen nicht ersetzt werden;
  • Für Server, die eine große Anzahl an Anfragen pro Sekunde (über 100.000) verarbeiten, wurde die Direktive „distributor-threads«, die die Anzahl der Threads für den Empfang eingehender Anfragen und deren Verteilung auf Arbeitsthreads bestimmt (macht nur im Modus „ Sinn).pdns-distributes-queries=yes«).
  • Eine Einstellung für public-suffix-list-file zur Definition einer eigenen Datei mit Liste öffentlicher Suffixe von Domänen, in denen Benutzer ihre Subdomains registrieren können, anstelle der in PowerDNS Recursor integrierten Liste.

Das PowerDNS-Projekt hat auch den Übergang zu einem sechsmonatlichen Entwicklungszyklus angekündigt, gemäß dem die nächste bedeutende Version von PowerDNS Recursor 4.3 im Januar 2020 erwartet wird. Updates für bedeutende Versionen werden über das Jahr hinweg erstellt, wonach für weitere sechs Monate Sicherheitsupdates bereitgestellt werden. Die Unterstützung für den Branch PowerDNS Recursor 4.2 wird somit bis Januar 2021 dauern. Ähnliche Änderungen im Entwicklungszyklus wurden für das Produkt PowerDNS Authoritative Server verabschiedet, dessen Version 4.2 in naher Zukunft erwartet wird.

Hauptfunktionen von PowerDNS Recursor:

  • Werkzeuge zur Fernabfrage von Statistiken;
  • Sofortiger Neustart;
  • Integrierte Engine zum Anbinden von Handlern in Lua;
  • Umfassende Unterstützung für DNSSEC und DNS64;
  • Unterstützung von RPZ (Response Policy Zones) und die Möglichkeit, schwarze Listen zu definieren;
  • Mechanismen zur Bekämpfung von Spoofing;
  • Die Möglichkeit, die Ergebnisse der Auflösung in Form von BIND-Zonendateien zu protokollieren.
  • Um hohe Leistung zu gewährleisten, werden moderne Mechanismen zur Multiplexierung von Verbindungen unter FreeBSD, Linux und Solaris (kqueue, epoll, /dev/poll) sowie ein hochleistungsfähiger DNS-Paketparser eingesetzt, der in der Lage ist, zehntausende parallele Anfragen zu bearbeiten.

Quelle: opennet.ru

60GB SSD 8Gb DDR4