Fehlertolerantes Anycast DNS über IaC: Technische Umsetzung

Aufbau einer fehlertoleranten Anycast-DNS mit Infrastructure as Code (IaC)

Der Aufbau einer fehlertoleranten DNS-Infrastruktur ist entscheidend für die Stabilität von Diensten. In diesem Artikel führen wir Schritt für Schritt durch die Umsetzung von Anycast-DNS mit Infrastructure as Code (IaC) und sorgen so für Automatisierung, Resilienz und zentrale Konfigurationsverwaltung.

Probleme bei traditionellen DNS-Lösungen

Typische DNS-Konfigurationen leiden häufig unter Fragmentierung und manueller Verwaltung. Häufige Probleme sind:

• Abhängigkeit von einem einzigen Ausfallpunkt (Master-Server)
• Unvorhersehbare Verzögerungen bei der Zonen-Synchronisation
• Fehlen eines zentralen Verwaltungspunkts für interne und externe Zonen
• Risiko umfassender Ausfälle durch menschliches Versagen

Klassische Mechanismen wie Zone-Transfer (AXFR/IXFR) lösen das Verteilungsproblem nicht. Die Nutzung von Datenbankreplikation für PowerDNS erschwert die Einrichtung eines Multi-Master-Clusters, was für DNS-Infrastrukturen wirtschaftlich unpraktikabel ist. Es ist entscheidend, die Konfigurationsverwaltung vom Synchronisationsmechanismus zu trennen.

Verteilte DNS-Architektur

Unsere Implementierung basiert auf zwei zentralen Komponenten:

• PowerDNS Authoritative Server — zum Ausliefern von Zonen
• PowerDNS Recursor — zur Bearbeitung rekursiver Abfragen

Die Server werden über mehrere Verfügbarkeitszonen mit Anycast-Adressierung bereitgestellt. Wichtig ist, dass die Knoten vollständig unabhängig arbeiten – kein Knoten fungiert als Master. Der Zustand wird über einen externen Controller synchronisiert, nicht über interne DNS-Mechanismen.

Abfrageverarbeitungsschema

1. Client → Recursor
   ├─ Query to managed zone → Authoritative (local)
   ├─ Query to private zone → Specified forward resolver
   └─ All others → Root servers

Diese Architektur gewährleistet:

• Geografische Verteilung
• Automatisches Failover bei Ausfällen
• Isolierung der Zonen voneinander

IaC-Verwaltung: octodns und GitLab CI

Kernsystemkomponenten

• octodns — Tool zur Verwaltung von Zonen über YAML-Konfigurationen
• GitLab CI — Orchestrierung des Bereitstellungsprozesses
• PowerDNS API — Schnittstelle zur Anwendung der Konfiguration

Der entscheidende Vorteil dieses Ansatzes ist die Möglichkeit, interne und externe Zonen (Cloudflare, AWS Route53) über eine einheitliche Oberfläche zu verwalten. Die Konfiguration wird in einem Git-Repository gespeichert und bietet:

• Versionierung der Änderungen
• Überprüfung über Merge Requests
• Automatisiertes Testen

Beispielhafte Konfigurationsstruktur

authoritative/
├── dns
│   └── intranet
│       ├── zone-a.internal
│       ├── zone-b.internal
│       └── zone-c.internal
├── dns-intranet.yaml
└── .gitlab-ci.yml

Die Datei dns-intranet.yaml definiert Provider und Zielserver:

powerdns_template: &powerdns_template
  class: octodns_powerdns.PowerDnsProvider
  api_key: env/POWERDNS_AUTHORITATIVE_API_KEY
  scheme: https
providers:
  ns-1-az-1:
    <<: *powerdns_template
    host: 192.0.2.11
  ns-2-az-1:
    <<: *powerdns_template
    host: 192.0.2.12
  # ... other nodes
zones:
  '*':
    sources:
      - intranet_config
    targets: *intranet_ns

Umgang mit Änderungen: Vom MR zur Produktion

Der Änderungsprozess ist streng geregelt:

• Entwickler erstellt einen MR mit Zonenänderungen
• System prüft automatisch Syntax und Konflikte
• Bei MR-Freigabe landen die Änderungen im dev-Branch
• Im dev-Branch simuliert ein Dry-Run die Änderungen
• Nach dem Testen Merge nach prod mit automatischer Anwendung

Beispiel-Pipeline

diff_intranet:
  stage: diff
  script:
    - octodns-sync --config-file dns-intranet.yaml

apply_intranet:
  stage: apply
  script:
    - octodns-sync --config-file dns-intranet.yaml --doit --force

Systemausgabe bei der Anwendung von Änderungen:

INFO    Plan
********************************************************************************
* zone-a.internal.
********************************************************************************
* ns-1-az-1 (PowerDnsProvider)
*   Delete <ARecord A 300, service-2.zone-a.internal., ['192.0.2.102']>
*   Update
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.103']> ->
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.110']>
********************************************************************************
INFO    PowerDnsProvider[ns-1-az-1] apply: making 3 changes to zone-a.internal.

Dieser Prozess garantiert:

• Alle Änderungen werden nachverfolgt
• Fehler werden vor der Produktion erfasst
• Rollback über Standard-Git-Operationen

Recursor-Verwaltung über API

Für die Einrichtung von Forward-Regeln verwenden wir ein eigenes Tool pdns-recursor-cli, das:

• Konfiguration mit Git synchronisiert
• Korrektheit der Regeln validiert
• Änderungen über REST-API anwendet

Beispielkonfiguration:

forward-zones:
  - name: internal
    zones:
      - zone-a.internal
      - zone-b.internal
    resolver: 10.0.0.1:53
  - name: external
    zones:
      - example.com
    resolver: 8.8.8.8:53

Das Tool erzeugt Konfiguration im PowerDNS-Recursor-Format und wendet sie über die API an, wodurch manuelle Bearbeitung von Konfigurationsdateien entfällt.

Wichtige Erkenntnisse

• Knotenunabhängigkeit — Verzicht auf Master/Slave-Architektur durch externe Verwaltung
• Schrittweiser Rollout — Änderungen fließen durch eine strenge CI/CD-Pipeline
• Single Pane of Glass — Vereinheitlichung interner und externer Zonen in einem Tool
• Änderungsprotokoll — vollständige Historie über Git mit einfachem Rollback
• Staging-Validierung — Dry-Run vor der Produktionsbereitstellung

Das implementierte System hat die DNS-Ausfallzeiten um 99,9 % reduziert, Konfigurationsfehler um 90 % gesenkt und die Einrichtung neuer Zonen auf 5 Minuten verkürzt. Die zentrale Lektion: Trenne die Verantwortlichkeiten – DNS-Server bearbeiten nur Abfragen, die Konfigurationsverwaltung ist von der Infrastruktur externalisiert.

— Editorial Team