BenBE's humble thoughts Thoughts the world doesn't need yet …

Ich habe mir da einen neuen Server geholt und eine der Sachen war nun, dass abzusehen war, dass mehrere der zu installierenden Dienste sich ins Gehege kommen würden. Also grob gesagt: Es gab 3 Dienste, die liebend gerne auf Port 53 laufen wollen. Nun sind IPv4-Adressen knapp und der neue Hoster achtet etwas strenger drauf, wofür man die haben möchte. Da ich aber wenig Lust auf irgendwelche Sonderkonfigurationen hatte, um jeden Service auf einem andere Port zu betreiben und am Ende alles irgendwie zu verdrahten, habe ich mir also überlegt:

• Auf der Haupt-IP des Servers wird der gesamte Web-Krams, sowie Public-Services laufen. Hier läuft auch der erste der konfliktierenden Services: Ein offener DNS-Recursor, den jedermann als DNS-Server in seinem Router eintragen kann. Soweit unspannend also.
• Die erste spannende Geschichte läuft nun auf der ersten Zusatz-IP. Diese beherbergt (zur Zeit) einen autoritiven DNS-Server, der auf eine Reihe von meinen eigenen Zonen autoritiv antwortet, was u.a. meine Blacklist für Client-IPs betrifft, die über meinen Mailserver relayn wollten.
• Und bei der zweiten zusätzlichen IP schließlich laufen eine Reihe von VPN-Dienste, die in Kooperation mit dem Freifunk Chemnitz bereitgestellt werden.

Man geht also beim Provider in das Webinterface und bestellt über das verfügbare Interface die IPs. Als Teil dieser Prozedur wird dann auch bereits nach einer Begründung gefragt. Was aber noch nicht verraten wird, ist die Angabe, um welches der zahlreichen RIPE-Dokumente es sich bei den erwähnten Vergabe-Richtlinien handelt, anhand derer die Vergabe entschieden wird.

Für die erste Zusatz-IP fiel dann natürlich die Begründung ungefähr nach folgender Art aus:

IP für den Betrieb eines VPN-Dienstes zur Einwahl in das Firmen-VPN

Wer sich wundert: Ja, diese Angabe ist trotz der seltsamen Formulierung durchaus korrekt und vollkommen richtig. Dem Support war dies aber irgendwie trotzdem nicht ausreichend. Naja, dem Support vielleicht schon, dem RIPE-Dokument RIPE-509 aber offenbar nicht. Wer jetzt aber vermutet, dass man einen halbwegs aussagekräftigen Antwort-Text vom Support erhält, der irrt: Die Antwort bestand (Footer und Disclaimer außen vor) aus sagenhaften 5 Zeilen – Begrüßung und Grußformel mitgerechnet.

for VPN you can’t get an additional IP.
This purpose is not in accordance with RIPE guidelines.

Gut, aber andere betreiben doch auch VPN-Server. Haken wir doch mal kurz beim Telefon-Support nach. Angerufen, sofort auch jemanden an der Leitung, aber da die Frage für den frühen Morgen vielleicht etwas zu technisch wurde, an die Fachabteilung weiterverwiesen wurden. Dort bekam ich dann auch nach Schilderung meines Anliegens sofort den heißen Tipp: Schreiben Sie’s technischer und das sollte durchgehen.

Gründe für Zusatz-IP für VPN sind:

1. Administrative Trennung der Datenströme
2. Der auf der Haupt-IP laufende BIND, der sich mit einer Teilkomponente des VPN-Dienstes beißt.

Achievement unlocked: IP für VPN-Server 😉

Nun werden viele meinen, aber technisch notwendig ist das doch nicht, weil man den VPN-Server, bzw. die betroffene Komponente (einen IP-over-DNS-Tunnel-Server) auch auf einem andren Port betreiben könnte, um dann die relevanten Anfragen einfach zu proxien. Nunja: Warum bei einem Dienst, der eh bereits viel Aufwand für das Parsen der Datenströme hat unnötige Komponenten dazuwischen schalten? Es reicht schon, wenn man da ohne YetAnotherProxy dazwischen in dem Tunnel kaum mehr als als Modem-Speed schafft. Wenn man dann den VPN-Server noch zusätzlich auslastet, wird das garantiert nicht besser.

Bliebe also noch zu klären, wie die Trennung von Recursor und autoritivem DNSRBL-Server am einfachsten zu begründen geht. Hmmm, probieren wir den offensichtlichen Weg:

Auf dem Server läuft bereits ein DNS-Server als DNS-Cache und -Rekurser, während auf der anderen Zusatz-IP ein VPN-Dienst läuft, der den benötigten Port auch blockiert. Die Notwendigkeit liegt nun darin, dass der Betrieb von DNS-Rekursern und authoritiven Systemen auf getrennten IPs empfohlen wird.

Gut, klingt erstmal seltsam und leider konnte ich da auf die Schnelle nicht das passende IETF-issued Document for Veriification™ finden. Also sollte das doch erstmal reichen: Manchmal funktioniert das mit dem Beweis durch Autorität ja.

In diesem Fall jedoch nicht. Also zumindest der RIPE-Beauftragte war da etwas hartnäckiger, als gedacht:

unser RIPE Beauftragter möchte noch wissen:

…und aus technischer Sicht anzuraten, den autoritiven Teil des Nameservers auf einer getrennten IP zu betreiben.

Warum wird das technisch angeraten?

Weil ich das so sage? Ne, kommt glaube nicht so gut. Auch wenn ich mich jedes Mall angesprochen fühle, wenn jemand „Gott sei Dank!“ sagt, aber wir haben hier einen durchaus interessierten Menschen; ihm soll auf seine Frage eine angemessene Antwort gegeben werden!

Ihre letzte offene Frage möchte ich gerne beantworten:

unser RIPE Beauftragter möchte noch wissen:

…und aus technischer sicht anzuraten, den auhoritiven Teil des Nameservers auf einer getrennten IP zu betreiben.

Warum wird das technisch angeraten?

Beim Betrieb eines Recursors entsteht in Abhängigkeit der Anfragen eine recht hohe Last, da die Antworten auf Anfragen für einen Recursor im Zweifelsfall nicht aus einem Cache geholt werden können. Somit benötigt die Beantwortung von Recursor-Anfragen im Vergleich zu autoritiven Antworten mehr Resourcen. Aus diesem Grund ist es ratsam zum Begrenzen der Resourcen ein Rate Limitting durchzuführen, bei dem die Anzahl von (offenen) Anfragen bereits im Vorhinein begrenzt wird (z.B. durch Verwerfen von Anfragen, die das Last-Limit übersteigen). Wird dies jedoch auf einer IP gemacht, auf der sowohl rekursive wie auch autoritive Anfragen eintreffen, so muss erst der Paket-Inhalt analysiert werden, bevor über das Rate Limitting entschieden werden kann. Trennt man die IPs für rekursive und autoritive Anfragen, kann man bereits ohne Betrachtung des Paket-Inhaltes das Rate Limitting vornehmen und bereits mit Mitteln des Betriebssystems lastspezifische, unterschiedliche Limits erreichen, ohne eine unnötige Verschlechterung der Erreichbarkeit der autoritiven Zone zu riskieren oder übermäßig Resourcen zum Lesen der Paketinhalte aufzuwenden.

Achievement unlocked: IP für DNS-RBL-Server 😉

Okay, ich fasse zusammen: Man muss seinen DNS-Server nur mit statischem Load-Balancing und Vermeidung von DPI begründen, dann klappt’s auch mit der IP. Die oben genannte Begründung ist zwar an sich richtig, aber der springende Punkt ist der Grund nun wiederum auch nicht: Statisches Load Balancing egal ob mit oder ohne Rate Limitting funktioniert nur in begrenztem Umfang. Solange man also die Last auf die einzelnen Systeme abschätzen kann, mag es gehen; sobald aber ein Public DNS-Server ins Spiel kommt, ist die Last ungefähr so gut vorhersehbar wie die Lottozahlen von nächster Woche. Technisch mag das also durchaus stimmen; rein es würde hoffentlich keiner real so machen.

Genauso wie beim VPN-Dienst steckt hinter der Trennung auch hier wieder ein im Wesentlichen administrativer Gedanke: Nicht nur möchte ich den Public DNS getrennt von nem autoritiven DNS haben, der die Erreichbarkeit der darüber angebotenen Zonen zu gewährleisten hat, sondern möchte ich ferner auch erreichen, dass beim Abfragen von autoritiven Zonen unter meiner Kontrolle nicht gleich jedes Webmaster-Tool rummeckert, dass da auch ein Public Resolver läuft.

Nunja. Bliebe noch zu erwähnen:
Achievement unlocked: Mit kreativen, technisch wenig zielführenden Begründungen IPs bekommen 😉

Während das VPN bereits funzt, brauch das mit dem DNS noch etwas. Naja, BIND scheint die gewünschte Konfiguration irgendwie nicht ganz zu verstehen. Aber ich denk, mit etwas Einsatz der richtigen Black Magic wird das auch noch ^^

P.S.: Das zusätzliche IPv6-/64-Subnetz war mit einem Klick und der Bestätigung der Datenübermittlung an die SchufaRIPE erledigt. Keine Begründung, nix.