Tag Archives: opennic

Ein Jahr mit NbIServ für das OpenNIC Projekt

Seit über einem Jahr betreibe ich für das OpenNIC-Projekt einen zensurfreien alternativen Nameserver unter der IP-Adresse 46.182.18.228. Berichtet habe ich bereits hier und nach einem vierteljahr hier darüber.

In dem vollen Jahr gab es mehrere Probleme mit Denial of Service Angriffen auf den offenen Nameserver, bei denen der Server nicht durch NbIServ abgeschaltet wurde, sodass eine Intervention möglich war. Der virtuelle Server lief bisher so stabil und zuverlässig, dass der Dienst bis auf die regelmäßigen Mail zu Sicherheitsupdates völlig unauffällig nebenher mitlief.

Sehr unspektakulär.

Auch wurde ich nicht aufgefordert Gastbeiträge zuzulassen, oder ohne Testmöglichkeit Artikel über Produkte zu schreiben.

nbiserv

Und genau diese Art des Serverbetriebs und Projekt-Sponsorings ist nicht mehr selbstverständlich, wie ich seit Juni am eigenen Leib erfahren durfte.

Skrupellose SEO-Agenturen, die für Backlinks Leistungsbeschreibungen gegen geringes Honorar von Bloggern abschreiben lassen, scheinen Gang und Gäbe zu sein. Darum kann ich den Anbieter NbIServ nur ausdrücklich für klassisch unspektakuläre Serverdienste empfehlen.

Wenn es laufen soll, ist langweilig eben doch besser.

Technische Argumente gibt es im Artikel zum vierteljährlichen mit NbIServ.

Alternativer DNS-Server

Wie in meinem Artikel über NbIServ beschrieben, betreibe ich einen frei zugänglichen Nameserver für das OpenNIC-Projekt. Der Nameserver führt keine individuellen Protokolle, sondern nur aggregierte und öffentlich einsehbare Statistiken.

IPv4-Adresse: 46.182.18.228

IPv6-Adresse: 2a02:2970:1002::ffa6

Weitere Informationen dazu gibt es hier und die Statistiken gibt es hier. Über Fragen oder Anregungen würde ich mich freuen.

Ein Vierteljahr mit NbIServer für OpenNIC


Nicht oft gibt es bei Internet Service Providern etwas geschenkt. Zumindest war das meine Vermutung, bevor ich für ein nicht-kommerzielles Projekt auf die Suche nach einem langfristigen Sponsor ging.

Es ging darum, für das Projekt OpenNIC Serverkontingente zu finden, die einzig für den Betrieb von rekursiven Nameservern genutzt werden sollten. So ein Nameserver ist eine Software, die Namen wie zum Beispiel falkhusemann.de in IP-Adressen wie 94.23.233.6 auflöst. Ohne DNS und die dafür notwendigen Nameserver wäre eine Benutzung des Internets nur über IP-Adressen möglich.

Zusätzlich erschwerend kam hinzu, dass das OpenNIC Projekt kein Verein ist, sondern aus einzelnen Personen besteht, die freiwillig Nameserver betreiben. Freiwilligenarbeit also.

Als einer der Provider, die Interesse zeigten, das Projekt zu unterstützen, meldete sich der Bethenhausener Anbieter NbIServ. Nach kurzer Verifizierung meiner persönlichen Daten wurde ein vServer vom Typ VS-2012-XS zur Verfügung gestellt.

“…Wir freuen uns ein Projekt wie die openNIC aktiv unterstützen zu dürfen…” , so Martin Prager Geschäftsführer von NbIServ

Die eingesetze Virtualisierungstechnik ist OpenVZ und das System bietet folgende Eckdaten:

  • 256 MiB Arbeitsspeicher
  • 20 GiB Festspeicher
  • Flatrate bei fairer Benutzung

Verwalten lässt sich der virtuelle Server über die Software oVZManager, wie das folgende Bildschirmfoto zeigt.

Folgend meine Erfahrungen mit dem Anbieter und der gebotenen technischen Dienstleitung:

Verfügbarkeit

Für NbIServ spricht eindeutig, dass der virtuelle Server seit einem Vierteljahr ohne Ausfall läuft. In dieser Zeit konnte meine Netzwerküberwachung zwar mehrere Ausfälle des Nameservers, nicht aber des virtuellen Servers oder dessen Anbindung feststellen.

Kundendienst

Der Kontakt mit dem Eigentümer Herrn Prager erfolgte direkt und sehr zügig. Dieser Punkt ist gerade bei Ausfällen eine willkommene Seltenheit und als Zusatzdienstleistung bei anderen Anbietern kaum bezahlbar.

Technische Leistung

Der zugesicherte Arbeitsspeicher, die Anbindung und der Festspeicher standen zur Verfügung. Hier findet offensichtlich keine oder nur eine begrenzte Überbuchung der Server statt. Der sequentielle Maximaldurchsatz des E/A-Subsystems lag bei durchschnittlich circa 200 MB/sec wie der folgende Benchmark belegt.

root@NbI-545:~# spew -g -i 3 --read-after-write 1g testfile
Total iterations:                                3
Total runtime:                            00:01:02
Total write transfer time (WTT):          00:00:22
Total write transfer rate (WTR):   140608.38 KiB/s
Total write IOPS:                  281216.77 IOPS
Total read transfer time (RTT):           00:00:12
Total read transfer rate (RTR):    251710.17 KiB/s
Total read IOPS:                   503420.35 IOPS

Und einige weitere Benchmarks:

IPv6 ist ebenso verfügbar. Einzig bei Tests des Maximaldurchsatzes der Anbindung des vServers fielen Einschränkungen auf. Der steigt nur gelegentlich über 4 MB/sec und bewegt sich bei Quellen aus dem deutschen Forschungsnetz oder QSC ansonsten bei circa 2MB/sec. Das spielt zwar für den darauf laufenden OpenNIC Nameserver keine Rolle, kann aber bei Verwendung als Backupsystem wichtig sein.

Fazit

Zusammengefasst bietet NbIServ mit dem gestellten vServer ein Produkt, dass die Ansprüche an Verlässlichkeit und kontinuierliche Leistung von fortgeschrittenen Kunden befriedigt. Einziger Kritikpunkt ist der nicht mehr zeitgemäße Maximaldurchsatz der Anbindung.

DNS-Query Limits mit iptables und Burstrate

Seit etwas über zwei Monaten betreibe ich einen OpenNIC Nameserver, über den jeder Mensch auf der Welt Hostnamen in IP-Adressen auflösen kann (mehr zum Nameserver gibt es hier). Jeder Mensch, aber leider auch jeder durch Viren befallene Zombie-Computer. Die massiven Anfragen nach Mailservern führten bereits zweimal dazu, dass mein Router die Anzahl von Anfragen nicht mehr bearbeiten konnte und der Internetzugang sich verabschiedete.

Query Flood! Was tun?

Im Blog von Benny Baumann werden Tips vorgestellt, die sehr spezifisch bestimmte Anfragen mit einfachen iptables Regeln verwerfen. Da ich leider nicht Nachfragen nach den Rootservern ablehnen kann (öffentliche Nameserver müssen hier antworten) und auch leider nicht nach einer einzigen Domain gefragt wird, kam nur eine Limitierung in Frage. Dabei wird die Anzahl der maximal in einem Zeitintervall (zum Beispiel eine Sekunde) verarbeiteten Pakete begrenzt.

Durch Nachfragen bei anderen OpenNIC Serveradmins und Analyse anonymisierter Logfiles konnte ich 5 Anfragen pro Sekunde als Durchschnitt pro IP feststellen. Diese Einstellung brachte zwar Besserung, führte aber dazu, dass bei einem Rechnerstart einige Programmer länger brauchten. Klar, die Anfragen pro Sekunde sind zu stark begrenzt. Die Lösung des Problems möchte ich gern mit euch teilen.

Es wird die Anzahl der Pakete pro Sekunde einer Quell-IP nicht über den Zeitraum einer Sekunde gemessen, sondern über einen längeren Zeitraum. Das würde zu einer Reduzierung der Anfragen führen (fünf pro Sekunde ist trivialierweise mehr als 5 pro zehn Sekunden), also wird die Anzahl der Anfragen mit den Sekunden multipliziert. Jetzt ist es natürlich möglich, alle erlaubten Anfragen in der ersten Sekunde zu senden, was wieder zu einer Überlastung der Anbindung führen würde. Dem wird ein Riegel vorgeschoben, indem die Anzahl der Anfragen pro Sekunde auch limitiert wird, aber eben auf einen höheren als den angestrebten Wert.

Ich habe die Anfragen pro Sekunde auf 5 limitiert, was dazu führt, dass in 7 Sekunden 35 Anfragen erlaubt sind.
Um das Erste-Sekunde Problem zu lösen, sind in jeder der sieben Sekunden nur maximal 15 Anfragen erlaubt.

Skript schreiben statt manuell blockieren!

Hier das Skript für Interessierte:

#!/bin/bash
# This script limits the queries per second to 5/s
# with a burst rate of 15/s and does not require
# buffer space changes

# Requests per second
RQS="15"

# Requests per 7 seconds
RQH="35"

iptables --flush
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSQF --rsource
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 1 --hitcount ${RQS} --name DNSQF --rsource -j DROP
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --set --name DNSHF --rsource
iptables -A INPUT -p udp --dport 53 -m state --state NEW -m recent --update --seconds 7 --hitcount ${RQH} --name DNSHF --rsource -j DROP