Odporny na awarie Anycast DNS przez IaC: realizacja techniczna

# Budowa odpornej na awarie infrastruktury Anycast DNS z Infrastructure as Code (IaC)

Tworzenie odpornej na awarie infrastruktury DNS jest kluczowe dla stabilności usług. W tym artykule omówimy, jak zaimplementować Anycast DNS z użyciem Infrastructure as Code (IaC), zapewniając automatyzację, odporność na awarie i scentralizowane zarządzanie konfiguracją.

Problemy tradycyjnych rozwiązań DNS

Typowe infrastruktury DNS często cierpią na fragmentację i ręczne zarządzanie. Najczęstsze problemy to:

• Zależność od pojedynczego punktu awarii (serwera master)
• Nieprzewidywalne opóźnienia synchronizacji stref
• Brak centralnego punktu zarządzania dla stref wewnętrznych i zewnętrznych
• Ryzyko masowych awarii spowodowanych błędem ludzkim

Klasyczne mechanizmy takie jak zone transfer (AXFR/IXFR) nie rozwiązują problemu rozproszoności. Przy użyciu replikacji baz danych dla PowerDNS pojawia się złożoność konfiguracji klastrów multi-master, co jest nieopłacalne ekonomicznie dla infrastruktury DNS. Kluczowe jest oddzielenie zarządzania konfiguracją od mechanizmu synchronizacji.

Architektura rozproszonego DNS

Nasza implementacja opiera się na dwóch kluczowych komponentach:

• PowerDNS Authoritative Server — do obsługi stref
• PowerDNS Recursor — do przetwarzania zapytań rekurencyjnych

Serwery są wdrażane w kilku strefach dostępności z adresacją Anycast. Ważne, że węzły działają całkowicie niezależnie — żaden nie jest master. Stan jest synchronizowany przez zewnętrzny kontroler, a nie wewnętrzne mechanizmy DNS.

Schemat przetwarzania zapytań

1. Klient → Recursor
   ├─ Zapytanie do zarządzanej strefy → Authoritative (lokalny)
   ├─ Zapytanie do prywatnej strefy → Określony forward-rozwiązujący
   └─ Wszystkie pozostałe → Serwery główne

Ta architektura zapewnia:

• Rozproszenie geograficzne
• Automatyczne przełączanie w przypadku awarii
• Izolację stref od siebie nawzajem

Zarządzanie przez IaC: octodns i GitLab CI

Główne komponenty systemu

• octodns — narzędzie do zarządzania strefami przez konfiguracje YAML
• GitLab CI — orkiestracja procesu wdrażania
• PowerDNS API — interfejs do stosowania konfiguracji

Kluczową zaletą podejścia jest możliwość zarządzania zarówno strefami wewnętrznymi, jak i zewnętrznymi (Cloudflare, AWS Route53) przez jeden interfejs. Konfiguracja jest przechowywana w repozytorium Git, co zapewnia:

• Wersjonowanie zmian
• Recenzję przez merge requests
• Automatyzowane testowanie

Przykładowa struktura konfiguracji

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

Plik dns-intranet.yaml określa dostawców i serwery docelowe:

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
  # ... pozostałe węzły
zones:
  '*':
    sources:
      - intranet_config
    targets: *intranet_ns

Przetwarzanie zmian: od MR do produkcji

Proces wprowadzania zmian jest ściśle uregulowany:

• Deweloper tworzy MR ze zmianami w strefach
• System automatycznie sprawdza składnię i konflikty
• Po zatwierdzeniu MR zmiany trafiają do gałęzi dev
• W gałęzi dev wykonywana jest symulacja dry-run zmian
• Po testach — merge do prod z automatycznym zastosowaniem

Przykładowy 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

Wynik systemu przy stosowaniu zmian:

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.

Ten proces gwarantuje, że:

• Wszystkie zmiany są śledzone
• Błędy są wykrywane przed trafieniem do produkcji
• Rollback odbywa się przez standardowe operacje Git

Zarządzanie Recursor przez API

Do konfiguracji reguł forward użyto niestandardowego narzędzia pdns-recursor-cli, które:

• Synchronizuje konfigurację z Git
• Sprawdza poprawność reguł
• Stosuje zmiany przez REST API

Przykładowa konfiguracja:

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

Narzędzie generuje konfigurację w formacie PowerDNS Recursor i stosuje ją przez API, co eliminuje ręczne edytowanie plików konfiguracyjnych.

Co jest ważne

• Niezależność węzłów — rezygnacja z architektury master/slave przez zewnętrzne zarządzanie
• Stopniowe stosowanie — zmiany przechodzą przez rygorystyczny pipeline CI/CD
• Centralny punkt zarządzania — połączenie stref wewnętrznych i zewnętrznych w jednym narzędziu
• Audyt zmian — pełna historia przez Git z możliwością roll backu
• Testowanie w stagingu — dry-run przed zastosowaniem w produkcji

Zaimplementowany system zmniejszył czas przestoju DNS o 99,9%, zredukował błędy konfiguracji o 90% i uprościł dodawanie nowych stref do 5 minut. Kluczowa lekcja — rozdzielność odpowiedzialności: serwery DNS powinny tylko przetwarzać zapytania, a zarządzanie konfiguracją jest wyodrębnione poza infrastrukturę.

— Editorial Team