NSD 4.14 reduziert Speicherverbrauch des DNS-Servers mit neuer RDATA-Speicherung und optionalen Compile-Zeit-Optionen
Die neuesten NSD-Versionen reduzieren den Speicherbedarf, indem sie Ressourcendatensätze als undurchsichtige Blobs speichern, mit zusätzlichen Einsparungen durch zwei Build-Optionen, und bieten schnelleres Laden und Schreiben von Zonen.
DNS-Server übersetzen menschenfreundliche Domainnamen in die numerischen Adressen, die Computer verwenden, und autoritative Nameserver halten die offiziellen Datensätze für eine Domain. NLnet Labs, die niederländische Non-Profit-Organisation hinter der autoritativen Server-Software NSD, veröffentlichte am 4. Dezember NSD 4.14.0 mit einer wesentlichen Änderung: Ressourcendatensatz-Daten (RDATA) werden nicht mehr als Liste von Zeigern auf einzelne Felder gespeichert, sondern für die meisten Datensatztypen als undurchsichtiger binärer Blob. Dieser träge Ansatz spart Speicher und Verarbeitungszeit, da autoritative Server selten die einzelnen Felder in einem Datensatz inspizieren müssen, es sei denn, sie schreiben eine Zonendatei. Das Ergebnis ist ein geringerer Speicherbedarf für Zonen, insbesondere für solche mit vielen Datensätzen, die eine große Anzahl von Feldern haben.
Vor Version 4.14.0 speicherte NSD jedes Feld eines Ressourcendatensatzes separat im Speicher, zusammen mit Zeigern auf diese Felder und verschwendetem Platz durch die Ausrichtung von Daten auf 64-Bit-Grenzen. Der neue Ansatz speichert die meisten Datensatztypen als einen einzigen undurchsichtigen binären Blob. Domainnamen-Felder, die in Antworten komprimiert werden können, werden weiterhin als Referenz gespeichert, sodass die Komprimierung effizient bleibt. Datensatztypen mit vielen Feldern profitieren am meisten, wie NSEC3 und RRSIG, die beide acht RDATA-Felder haben. Die .nl-Zone ist ein Paradebeispiel: Sie hat mehr als 6 Millionen Delegationen, von denen mehr als 62 Prozent sicher (DNSSEC-signiert) sind, und verwendet NSEC3-Opt-in, was bedeutet, dass es für jeden Namen einen NSEC3-Datensatz gibt. NLnet Labs hat eine langjährige Vereinbarung mit SIDN, der Registry für .nl, die Zone für Forschung und Softwareverbesserung zu nutzen. Mit der neuen Speicherung benötigt NSD 14,9 Prozent weniger Speicher für die .nl-Zone.
Zwei Compile-Zeit-Optionen können den Speicher weiter reduzieren. Die Option --enable-packed entfernt die Anforderung, dass Strukturmitglieder auf einer typischen 4-Byte-Grenze ausgerichtet sein müssen, wodurch Lücken zwischen Mitgliedern beseitigt werden. Nicht alle CPU-Architekturen unterstützen unausgerichteten Speicherzugriff, und es kann auf einigen zu Leistungseinbußen führen, daher ist sie standardmäßig deaktiviert. In der Praxis hat das NLnet-Labs-Team nur Leistungsverbesserungen beobachtet, wahrscheinlich weil verwandte Daten im CPU-Cache näher beieinander liegen. Die Option --disable-radix-tree wechselt von der standardmäßigen Radix-Baum-Datenstruktur zu einem Rot-Schwarz-Baum, der weniger Speicher verbraucht, aber auf Kosten der Leistung; für sehr große Zonen kann dies dennoch praktikabel sein. In Kombination mit der neuen RDATA-Speicherung ergibt die gepackte Option eine zusätzliche Reduzierung von 16,2 Prozent zusätzlich zu ihrer eigenen Einsparung von 14,2 Prozent für .nl. Für die .com-Zone, die relativ wenige sichere Delegationen hat (4,2 Prozent) und NSEC3-Opt-out verwendet, ergibt der neue RDATA-Ansatz allein nur eine Reduzierung von 2,4 Prozent, aber die Kombination aller speicherreduzierenden Optionen bringt den Speicherbedarf für .com bequem unter die 64-Gigabyte-Marke.
Tabelle 1 im ursprünglichen Beitrag listet Reduzierungen für sechs Zonen auf: .lol 18,3 Prozent, .se 17,7 Prozent, .nl 14,9 Prozent, .net 2,6 Prozent, .org 2,6 Prozent, .com 2,4 Prozent. Mit --enable-packed steigen die Reduzierungen auf 33,4 Prozent für .lol, 28,1 Prozent für .se, 30,4 Prozent für .nl, 19,6 Prozent für .net, 19,4 Prozent für .org und 19,3 Prozent für .com. Mit --disable-radix-tree allein betragen die Zahlen 41,4, 31,8, 46,5, 32,9, 33,1 bzw. 31,3 Prozent. Die Kombination beider Optionen ergibt 51,0 Prozent für .lol, 39,5 Prozent für .se, 55,2 Prozent für .nl, 44,0 Prozent für .net, 43,9 Prozent für .org und 42,6 Prozent für .com. Die Zonen haben unterschiedliche Eigenschaften: .com ist eine große NSEC3-Opt-out-signierte Zone mit 4,2 Prozent sicheren Delegationen, .net und .org sind ähnlich mit etwa 5 Prozent sicheren Delegationen, .nl verwendet NSEC3-Opt-in mit 62,2 Prozent sicheren Delegationen, .se ist eine etwas größere NSEC-signierte Zone mit 61,3 Prozent sicheren Delegationen, und .lol ist eine kleine NSEC-signierte Zone mit 9,0 Prozent sicheren Delegationen.
Nach der Veröffentlichung von 4.14.0 meldete ein Benutzer, dass der Speicherverbrauch in seiner Umgebung tatsächlich zunahm. Die betroffenen Zonen hatten eine relativ kleine Anzahl von RRsets, aber eine sehr große Anzahl von Ressourcendatensätzen pro Set, oft Tausende. NSD vergrößerte diese RRsets, indem es jeden Datensatz einzeln hinzufügte, neuen Speicherplatz zuwies und alten Speicherplatz in einen Recycling-Behälter freigab, der die ungeraden Größen nie wiederverwendete. Der Fix in NSD 4.14.1 vergrößert RRsets in Stapeln statt einen Datensatz nach dem anderen. Der gemeldete Speicherverbrauch mit dem Fix beträgt für diesen Zonentyp fast ein Sechstel dessen, was er vor 4.14.0 war. Dies ist wichtig für Betreiber, die Zonen mit vielen Datensätzen in einem einzigen RRset bedienen, wie große DNS-basierte Blocklisten oder Mailserver mit vielen MX-Datensätzen derselben Priorität.
Auch das Laden und Schreiben von Zonen wurde schneller. Das Schreiben oder Drucken von Zonen ist auch ohne zusätzliche Optionen schneller, und mit --enable-packed ist es für .nl etwa 18 Prozent schneller, für .net und .org 6,7 Prozent schneller und für .se und .lol 25 Prozent schneller. Die Zonenladezeiten verbessern sich weiter, wenn sie kombiniert werden: 21,7 Prozent für .lol, 19,6 Prozent für .se, 12,4 Prozent für .nl, 7,9 Prozent für .com, 3,9 Prozent für .org und 4,7 Prozent für .net. Diese Verbesserungen sind wichtig, da die DNS-Infrastruktur jeden Website-Besuch und jede E-Mail unterstützt, und effiziente Server senken Betriebskosten und Latenz. Für Website-Besitzer und IT-Teams, die ihr eigenes DNS betreiben oder sich auf Hosting-Anbieter verlassen, hält diese Art von Speichereffizienz auf autoritativen Servern das Adressbuch des Internets schnell und zuverlässig; gleichzeitig bietet die Verwendung eines datenschutzorientierten verschlüsselten DNS-Dienstes wie AEU DNS für Ihre eigenen Abfragen eine zusätzliche Schutzschicht gegen Tracking und Manipulation.
Begriffe erklärt
- NSD
- Name Server Daemon, eine Open-Source-Software für autoritative DNS-Server, entwickelt von NLnet Labs, die Anfragen nach Domain-Datensätzen beantwortet.
- RDATA
- Resource Record Data, der Nutzlastteil eines DNS-Datensatzes, der die eigentlichen Informationen enthält, wie eine IP-Adresse oder einen Nameserver-Namen.
- RRset
- Resource Record Set, eine Gruppe von DNS-Datensätzen, die denselben Namen, Typ und dieselbe Klasse haben, wie alle MX-Datensätze für eine Domain.
- NSEC3
- Next Secure Version 3, ein DNSSEC-Datensatztyp, der beweist, welche Domainnamen in einer Zone nicht existieren, während er die genauen Namen verbirgt.
- RRSIG
- Resource Record Signature, ein DNSSEC-Datensatz, der eine kryptografische Signatur enthält, um andere DNS-Datensätze zu authentifizieren.
- authoritative name server
- Ein DNS-Server, der die offizielle, ursprüngliche Kopie der Datensätze einer Domain besitzt, im Gegensatz zu einem Caching-Resolver, der nur Antworten speichert.
So schützen Sie sich
- Wenn Sie Ihren eigenen autoritativen DNS-Server mit NSD betreiben, aktualisieren Sie auf Version 4.14.1, um den Speicher-Fix und alle Effizienzverbesserungen zu erhalten.
- Testen Sie für große Zonen mit vielen DNSSEC-signierten Datensätzen die Compile-Zeit-Optionen --enable-packed und --disable-radix-tree in einer Staging-Umgebung, bevor Sie sie in der Produktion aktivieren.
- Überwachen Sie die Speichernutzung Ihres DNS-Servers vor und nach dem Upgrade, insbesondere für Zonen mit vielen Datensätzen in einem einzigen Datensatz-Set.
- Wenn Sie einen DNS-Hosting-Anbieter nutzen, fragen Sie, ob dieser eine aktuelle NSD- oder gleichwertige Software ausführt und ob er Speicheroptimierungen anwendet.
- Stellen Sie Ihr Gerät oder Ihren Router auf eine verschlüsselte DNS-Einstellung wie DNS über HTTPS oder DNS über TLS um, damit Ihr Internetanbieter nicht sehen kann, welche Websites Sie anfragen.
Quelle: blog.nlnetlabs.nl
