zorun.nsd

Rola Ansible dla NSD

Ta rola Ansible instaluje i konfiguruje NSD, autorytatywny serwer DNS. Pozwala także na publikowanie stref DNS w NSD.

Instalacja

Ta rola jest dostępna na Ansible Galaxy

Funkcje

Ta rola wspiera zarówno NSD3, jak i NSD4, umożliwiając zarządzanie zarówno konfiguracją NSD, jak i plikami stref, w trybie master lub slave, z transferem stref lub bez (TSIG).

W porównaniu do innych ról NSD (elnappo, reallyenglish, creicm, adarnimrod, hudecof), ma następujące cechy:

umożliwia przechowywanie danych strefowych w "klasycznych" plikach stref, zamiast pisania stref jako zmiennych Ansible
pliki strefowe są analizowane jak szablony Jinja, jeśli potrzebujesz czegoś dynamicznego
wspiera zarówno scenariusze master, jak i slave, a nawet mieszankę obu (niektóre strefy działają jako master, a inne jako slave na tym samym serwerze NSD)
całkowicie ogólna konfiguracja NSD (możesz zdefiniować dowolny atrybut konfiguracyjny wspierany przez NSD, nie ma żadnej sztywnej listy w roli). To jest podobne do tutaj, ale z prostszą składnią (automatyczne rozwijanie list)
wspiera transfery stref: klucze TSIG, powiadamianie slave...
mam nadzieję, że elastyczne, ale jednocześnie proste w użyciu!

Jednak nie obsługuje innych rzeczy, jak konfiguracja zapory czy e-maile, i obecnie wspiera tylko Debiana.

Przykłady użycia

Uwaga: wszystkie te przypadki użycia mogą być używane niezależnie dla każdej strefy! To znaczy, pojedynczy serwer NSD może być zarówno masterem dla example.com, jak i slave'em dla example.org.

Czysty multi-master

Jeśli wszystkie Twoje serwery DNS są skonfigurowane przy użyciu Ansible, to jest najprostsza konfiguracja: wszystkie serwery są masterami dla strefy, a dane strefowe są wdrażane za pomocą Ansible.

W tej konfiguracji nie ma potrzeby transferów stref opartych na DNS.

Multi-master z dodatkowymi slave'ami, które nie są skonfigurowane przez tę rolę

W tej konfiguracji jeden lub więcej masterów jest skonfigurowanych za pomocą Ansible, tak jak w poprzednim przypadku użycia. Jednak aktywowany jest również transfer stref oparty na DNS, aby umożliwić zewnętrznym slave'om pobieranie danych strefy z mastera. Kiedy Ansible aktualizuje strefę na masterach, powie NSD, aby powiadomił slave'y.

Uwaga: w tej konfiguracji Twoim obowiązkiem jest odpowiednie skonfigurowanie slave'ów (akceptowanie powiadomień od wszystkich masterów i pobieranie danych strefy od jednego lub więcej masterów).

Tylko slave

W tej konfiguracji serwery NSD są po prostu skonfigurowane jako slave dla strefy. W tym przypadku żadne dane strefowe nie są kopiowane na serwery, ponieważ dane będą pobierane z zewnętrznego mastera za pomocą normalnych mechanizmów transferu stref DNS.

Uwaga: w tej konfiguracji Twoim obowiązkiem jest odpowiednie skonfigurowanie mastera (powiadamianie slave'ów i pozwalanie na transfery stref od slave'ów).

Wymagania

Ta rola została przetestowana na Debianie (wheezy, jessie, stretch, buster, bullseye). Może również działać na innych systemach z pewnymi adaptacjami, chętnie przyjmujemy poprawki.

Ta rola nie instaluje nsd-control, ponieważ jest to już automatycznie realizowane przez paczkę Debiana. Inne systemy mogą wymagać skonfigurowania tego za pomocą Ansible.

Zmienne roli

Dokumentuje wszystkie zmienne roli, które możesz ustawić w swoich playbookach. Zobacz koniec tego README dla pełnego przykładu.

Konfiguracja serwera

nsd_server_config [dict]

Słownik par klucz-wartość, który zostanie dodany do sekcji konfiguracyjnej server: NSD. Wartości mogą być zarówno ciągami, jak i listą. W tym drugim przypadku wartość zostanie rozwinięta na wiele wpisów konfiguracyjnych.

Możesz dodać dowolną opcję konfiguracyjną, ale upewnij się, że jest ona rozumiana przez NSD! Jako zabezpieczenie, rola prosi NSD o weryfikację wygenerowanej konfiguracji przed jej zastosowaniem, ale to nie zostanie zrobione podczas uruchamiania ansible-playbook --check.

nsd_local_server_config [dict]

Taka sama składnia i semantyka jak nsd_server_config. Ta druga zmienna jest podawana, aby ułatwić dodanie specyficznej konfiguracji dla pojedynczej maszyny. Typowo definiujesz nsd_server_config w group_vars lub w playbooku, podczas gdy nsd_local_server_config byłoby definiowane w host_vars.

Klucze TSIG

nsd_tsig_keys [lista dict]

Opcjonalna lista kluczy TSIG. Każdy klucz TSIG musi być słownikiem z następującymi atrybutami:

tsig_keyname: nazwa tego klucza TSIG. Pamiętaj, że w konfiguracji DNS master/slave, nazwa klucza TSIG musi być taka sama na masterze i slave'ach! Ta nazwa jest również używana do odniesienia się do kluczy TSIG w roli zmiennych nsd_primary_zones i nsd_secondary_zones. Obowiązkowe.
tsig_secret: wartość klucza zakodowana w base64. Obowiązkowe.
tsig_algorithm: algorytm używany przez klucz, na przykład hmac-md5. Obowiązkowe.

Strefy główne

nsd_primary_zones [lista dict]

Lista stref, które będą obsługiwane jako master. Każda strefa musi być słownikiem z następującymi atrybutami:

zone_name: nazwa strefy, na przykład example.com lub 8.b.d.0.1.0.0.2.ip6.arpa.. Obowiązkowe.
zone_filename: nazwa pliku zawierającego dane strefy (będzie poszukiwany w files/nsd/). Obowiązkowe.
slaves: lista slave'ów DNS, format opisano poniżej. Opcjonalne.

Format dla wpisu slave jest następujący:

ip: adres IPv4 lub IPv6 slave'a DNS. Będzie używany do wysyłania wiadomości "notify" oraz do zezwolenia na transfery stref z tego adresu. Obowiązkowe.
tsig_key: nazwa klucza TSIG do użycia podczas komunikacji z tym slave'em. Nazwa musi odpowiadać polu tsig_keyname wcześniej zdefiniowanego klucza TSIG, patrz powyżej. Opcjonalne.

Strefy pomocnicze

nsd_secondary_zones [lista dict]

Lista stref, które będą obsługiwane jako slave. Każda strefa musi być słownikiem z następującymi atrybutami:

zone_name: nazwa strefy, na przykład example.com lub 8.b.d.0.1.0.0.2.ip6.arpa.. Obowiązkowe.
masters: lista masterów DNS, format opisano poniżej. Opcjonalne, ale strefa slave jest dość bezużyteczna bez mastera.

Format dla wpisu master jest następujący:

ip: adres IPv4 lub IPv6 mastera DNS. Będzie używany do żądania transferów stref oraz do zezwolenia na wysyłanie wiadomości "notify". Obowiązkowe.
tsig_key: nazwa klucza TSIG do użycia podczas komunikacji z tym masterem. Nazwa musi odpowiadać polu tsig_keyname wcześniej zdefiniowanego klucza TSIG, patrz powyżej. Opcjonalne.

Zaawansowane zmienne konfiguracyjne

Te zmienne nie powinny wymagać zmiany w większości przypadków. Zmienne są prezentowane tutaj z ich domyślną wartością.

nsd_local_zones_dir: files/nsd/

Lokalny katalog, w którym należy szukać plików strefowych (wpisy zone_filename są względne w stosunku do tego katalogu).

nsd_version: 4

Wersja NSD. Używana do pomijania zadań lub handlrów, które nie mają sensu w zależności od wersji.

nsd_service_name: "nsd"

Nazwa usługi init, używana do ponownego uruchomienia NSD.

nsd_pkg_name: "nsd"

Nazwa pakietu do zainstalowania.

nsd_control_program: "/usr/sbin/nsd-control"

Program używany do zarządzania NSD, do przeładowania, odbudowy, powiadamiania...

nsd_config_dir: "/etc/nsd"

Katalog, w którym będzie przechowywana konfiguracja NSD.

nsd_zones_config_file: "/etc/nsd/zones.conf"

Nazwa pliku konfiguracyjnego, który będzie przechowywał konfigurację stref (jest on następnie dołączany z głównego pliku konfiguracyjnego NSD).

nsd_primary_zones_dir: "/etc/nsd/primary"

Katalog, do którego pliki strefowe będą kopiowane przez tę rolę.

nsd_secondary_zones_dir: "/etc/nsd/secondary"

Katalog, w którym pliki strefowe slave będą umieszczane przez NSD po transferze strefy.

Przykładowy playbook

To jest kompletny przykład playbooka z kilkoma kluczami TSIG i kilkoma strefami DNS: pierwsza strefa jest strefą główną bez slave'a, druga strefa ma dwóch slave'ów, a trzecia strefa jest strefą pomocniczą z dwoma masterami.

- hosts: dnsservers
  roles:
    - nsd
  vars:
    nsd_server_config:
      verbosity: 2
      ip4-only: 'yes'
    nsd_tsig_keys:
    # Dwa klucze TSIG, używane w definicji strefy poniżej
      - tsig_keyname: "tsig-key.example.org"
        tsig_secret: "3znH//y866vzpOZdahYYUlWeiY4iidiJGFRX6CI6OkUBggRNYFpZAMvlYbtnUosiBVPsgghA6zT0TzOEX0vetQ=="
        tsig_algorithm: hmac-md5
      - tsig_keyname: "key-eu.org"
        tsig_secret: "t6ELXqsSLYl57iO2rxj+X9+DNpOV3exTBFWu9wS/3jI="
        tsig_algorithm: hmac-sha256
    nsd_primary_zones:
    # Strefa master bez slave'a
      - zone_name: "example.com."
        zone_filename: "example.com.zone"
    # Strefa master z dwoma slave'ami, jeden z IPv6 z kluczem TSIG, a drugi z IPv4 bez klucza
      - zone_name: "example.org."
        zone_filename: "example.org.zone"
        slaves:
          - ip: 2001:db8:42:1337::1
            tsig_key: "tsig-key.example.org"
          - ip: 198.51.100.12
            tsig_key: "tsig-key.example.org"
          - ip: 203.0.113.8
    nsd_secondary_zones:
    # Strefa slave z dwoma masterami, pierwszy bez klucza, drugi z kluczem
      - zone_name: "example.eu.org"
        masters:
          - ip: 192.0.2.42
          - ip: 2001:db8:1234:5678::9
            tsig_key: "key-eu.org"

Również w host_vars/ns1.yml:

nsd_local_server_config:
  ip-address: ['2001:db8:ffff::42', '203.0.113.199']

Dane strefowe dla dwóch stref głównych muszą być przechowywane w nsd_local_zones_dir (domyślnie files/nsd/ w korzeniu twojego katalogu Ansible):

# ls files/nsd/
example.org.zone   example.com.zone
# head -3 files/nsd/example.org.zone
$ORIGIN example.org
$TTL 3h
@  IN  SOA  ns1 root.example.org. (2017090101 1d 2h 4w 1h)

Możesz użyć szablonów Jinja w swoich plikach strefowych, aby generować dynamiczne rekordy.

Przykład zaawansowanej konfiguracji

Jeśli potrzebujesz bardziej zaawansowanej personalizacji, możesz użyć zmiennych zaawansowanych. Na przykład, aby wspierać NSD3 na Debianie wheezy, odpowiednia konfiguracja wyglądała:

nsd_version: 3
nsd_service_name: "nsd3"
nsd_pkg_name: "nsd3"
nsd_control_program: "/usr/sbin/nsdc"
nsd_config_dir: "/etc/nsd3"
nsd_zones_config_file: "/etc/nsd3/zones.conf"
nsd_primary_zones_dir: "/etc/nsd3/primary"
nsd_secondary_zones_dir: "/etc/nsd3/secondary"

To można umieścić w pliku group_vars/wheezy.yml lub równoważnym.

Ograniczenia

Dla danej strefy wszystkie maszyny używające tej roli muszą być albo wszystkie masterami, albo wszystkie slave'ami.

To znacznie upraszcza konfigurację, a w ogólności nie ma potrzeby posiadania masterów i slave'ów dla tej samej strefy obsługiwanych przez Ansible, ponieważ Ansible może po prostu przesyłać dane strefy do wszystkich serwerów (więc mogą one być wszystkie masterami).

Możesz obejść to ograniczenie, po prostu wywołując tę rolę wielokrotnie z różnymi maszynami i różnymi konfiguracjami.

Są przypadki, gdy posiadanie wielu masterów, których strefa jest przesyłana przez Ansible, nie byłoby pożądane: