NS, Netzwerk und Verteilung …

Veröffentlicht am von

In den letzten Wochen habe ich für uns ein neues Nameserver Netzwerk geplant, entwickelt und umgesetzt (das war auch der Grund, warum ich die letzten Tage keine Zeit zum Bloggen hatte – ich musste schlicht und ergreifend hunderte Zonen migrieren, kontrollieren und auch bei den jeweiligen Registries die NS-Records aktualisieren). Die Herausforderung war gar nicht so klein, denn in den letzten Jahren hat sich so einiges angesammelt:

  • 7 Nameserver (verteilt auf 3 Zonen)
  • 2 Architekturen (PowerDNS und Bind)
  • 5 Datenformate (verteilt auf Flatfiles, MySQL4 und MySQL5)

Erschwerend kam natürlich hinzu, dass für die unterschiedlichen Nameserverarchitekturen auch unterschiedliche Verwaltungsoberflächen verwendet wurden (teils selbst entwickelt, teils fertige Codeschnippsel).

Folgende Eckdaten hatten wir uns in einem Technik-Meeting gesetzt:

  • Forward + Reverse DNS
  • IPv6-Support
  • Kein Master-Slave Setup – jedes Node muss ein Master sein
  • Erweiterbarkeit
  • Geringer RAM-Bedarf
  • Div. Schnittstellen (AXFR, CSV-Import und -Export, etc)
  • Simples Datenformat
  • Einfache Sicherungsmöglichkeit
  • Schnelles Recovery

Die Liste hat sich während dem Meeting irgendwie wie ein Geek-Wunschzettel an das Christkind angehört, hat aber das wiedergespiegelt, was wir dringend gebraucht haben. Aufgrund meiner Erfahrung mit Bind, kam für mich nur dieser in Frage. Versierte User wissen: Bind kann out of the box nichts mit einer MySQL-Tabelle anfangen (schade eigentlich). Hier bleibt also nur der Weg über die (eigentlich veralteten) Quellen von Bind DLZ. Nach einigen Tagen Code-Cleanup und Anpassung div. Bilbiotheks-Referenzen an aktuelle Gegegebeneheiten, lief Bind DLZ dann auch wie gewünscht. Das Tabellen-Layout, die Bind-Konfiguration und auch das Resolver-Setup waren von der Entwicklung also nur ein kleiner und einfacher Teil.

Damit es in späterer Folge ein zentrales Panel zur Verwaltung sämtlicher Zonen und Records geben kann, fehlten natürlich noch Dinge wie Zonen-Synchronisation zwischen den Nodes (da wir kein Master-Slave Setup haben, gibt es also auch keinen einfachen Zonen-Transfer) und natürlich ein Monitoring der einzelnen Nodes sowie der einzelnen Datenbestände (pro Node ein separater MySQL-Server). MySQL-Replikation wäre natürlich auch eine Möglichkeit gewesen, ist mir persönlich aber zu Fehleranfällig und zu unflexibel. Aus dem Grund haben wir insgesamt 5 Monitoring-Dämons die die Datenbestände synchron halten und Alarm schlagen, wenn etwas nicht stimmen sollte. Die einzelnen Nodes werden natürlich auch noch zusätzlich von unserem zentralen Monitoring überwacht.

Lange Rede, kurzer Sinn:

  • ns01.anexia.at (193.33.114.2)
  • ns02.anexia.at (78.47.133.21)
  • ns03.anexia.at (193.33.114.6)
  • ns04.anexia.at (85.131.190.41)
  • ns05.anexia.at (194.1.206.2)

Wie immer sind unsere Nameserver auch public Resolver – sollte also jemand sowas brauchen und unsere testen wollen – gerne ;).

9 Gedanken zu „NS, Netzwerk und Verteilung …“

  2. @Alex

    Tust den Jürgen ein bisschen kontrollieren…er macht gerne Vertipper und solche Sachen…

    Ich erinnere mich da, wo ich mal mitten in der Nacht ins Rechenzentrum fahren durfte, nur weil er ein “ vergessen hatte und dadurch nimmer aufn Server gekommen is. 😀 😀

  4. Wurscht….der, den ich meine, der wirds schon irgendwann lesen.. 😛

    Aber trotzdem…du hast damals Scheiße gebaut und ich habs wie immer ausbaden dürfen.. 😛

  7. Ähhhm, könnte mir einmal jemand erklären was zum Teufel ein „public Resolver“ ist? 😀
    Bin in Sachen DNS ein absoluter Anfänger 😛

    MfG Christian

  8. Nicht jeder Nameserver im Internet ist auch ein Resolver. Resolver bedeutet, dass du den Nameserver bei dir am Rechner eintragen kannst und dieser dann die Hostnamen, die du ansprechen willst, für dich auflöst. Das funktioniert nicht mit jeden Nameserver bzw manche Anbieter verwerfen jene Anfragen, die nicht aus ihrem eigenen Netz kommen.

    Unsere Nameserver kann jeder nutzen – das macht die Systeme für uns nur noch wichtiger und wir sehen, wie sich extreme Last (momentan bis zu 200.000 DNS-Request / Minute) auf unsere Systeme auswirkt.

Kommentare sind geschlossen.