Rola Ansible BIND

To jest rola Ansible do konfiguracji ISC BIND jako tylko autorytatywnego serwera DNS dla wielu domen. Główne zadania tej roli to:

• instalacja BIND
• konfiguracja głównego pliku konfiguracyjnego (serwer primary/secondary/forwarder)
• konfiguracja stref wyszukiwania dla zapytań normalnych i odwrotnych

Ta rola wspiera wiele stref wyszukiwania, zarówno normalnych, jak i odwrotnych, w tym dla IPv6. Choć włączenie rekursji jest wspierane (choć mocno odradzane), rozważ użycie innej roli, jeśli chcesz skonfigurować serwer nazw z pamięcią podręczną lub przekierowaniem.

Jeśli lubisz/używasz tej roli, rozważ dodanie jej do ulubionych i ocenienie na stronie Ansible Galaxy roli. Dziękujemy!

Sprawdź dziennik zmian w celu zapoznania się z istotnymi zmianami między wersjami.

OSTRZEŻENIE: Jeśli używasz tej roli od przed v5.0.0, sprawdź dziennik zmian, aby uzyskać ważne informacje na temat zmian, które mogą powodować problemy. Starsze playbooki przestaną działać po aktualizacji do v5.0.0.

Wspierane platformy

Ta rola może być używana na różnych platformach, zobacz meta/main.yml po aktualną listę. Staramy się ustawić automatyczne testy dla każdej wspieranej platformy (zobacz .ci.yml), ale nie zawsze jest to możliwe.

Kilka uwag na temat wspieranych ról, które nie są zawarte w testach automatycznych:

• Arch Linux i FreeBSD powinny działać, ale obecnie nie można przetestować tej roli na tych dystrybucjach, ponieważ brak odpowiednich obrazów Dockera.
• CentOS 6 powinien działać, ale testy idempotencji nie przechodzą, nawet jeśli BIND jest poprawnie zainstalowany, a testy akceptacyjne się powiodły.

Wymagania

Pakiety python-netaddr (wymagane dla filtra ipaddr) oraz dnspython powinny być zainstalowane na węźle zarządzającym.

Zmienne roli

† Najlepszą praktyką dla autorytatywnego serwera nazw jest wyłączenie rekursji. Jednak w niektórych przypadkach może być konieczne włączenie rekursji.

Minimalne zmienne dla działającej strefy

Aby skonfigurować autorytatywny serwer nazw dostępny dla klientów, powinieneś przynajmniej zdefiniować poniższe zmienne:

Definicje domen

bind_zones:
  # Przykład strefy primary (hosts: i name_servers: są zdefiniowane)
  - name: mydomain.com           # Nazwa domeny
    create_reverse_zones: false  # Pomija tworzenie stref odwrotnych
    primaries:
      - 192.0.2.1                # Główne serwer(y) dla tej strefy
    name_servers:
      - pub01.mydomain.com.
      - pub02.mydomain.com.
    hosts:
      - name: pub01
        ip: 192.0.2.1
        ipv6: 2001:db8::1
        aliases:
          - ns1
      - name: pub02
        ip: 192.0.2.2
        ipv6: 2001:db8::2
        aliases:
          - ns2
      - name: '@'                # Umożliwia "http://mydomain.com/"
        ip:
          - 192.0.2.3            # Wiele adresów IP dla jednego hosta
          - 192.0.2.4            #   skutkuje round robin DNS
        sshfp:                   # Odcisk palca Secure Shell
          - "3 1 1262006f9a45bb36b1aa14f45f354b694b77d7c3"
          - "3 2 e5921564252fe10d2dbafeb243733ed8b1d165b8fa6d5a0e29198e5793f0623b"
        ipv6:
          - 2001:db8::2
          - 2001:db8::3
        aliases:
          - www
      - name: priv01             # Ten IP znajduje się w innej podsieci, skutkuje
        ip: 10.0.0.1             #   wieloma strefami odwrotnymi
      - name: mydomain.net.
        aliases:
          - name: sub01
            type: DNAME          # Przykład rekordu aliasu DNAME
    networks:
      - '192.0.2'
      - '10'
      - '172.16'
    delegate:
      - zone: foo
        dns: 192.0.2.1
    services:
      - name: _ldap._tcp
        weight: 100
        port: 88
        target: dc001
    naptr:                       # Rekord Name Authority Pointer, używany dla IP
      - name: "sip"              #   telefony
        order: 100
        pref: 10
        flags: "S"
        service: "SIP+D2T"
        regex: "!^.*$!sip:[email protected]!"
        replacement: "_sip._tcp.example.com."
  # Minimalny przykład strefy secondary
  - name: acme.com
    primaries:
      - 172.17.0.2
    networks:
      - "172.17"
  # Minimalny przykład strefy forward
  - name: acme.com
    forwarders:
      - 172.17.0.2
    networks:
      - "172.17"

Hosty

Nazwy hostów, które ten serwer DNS powinien rozwiązywać, można określić w bind_zones.hosts jako listę mapowań z kluczami name:, ip:, aliases: i sshfp:. Aliasami mogą być rekordy CNAME (domyślnie) lub DNAME.

Aby umożliwić przejście do http://example.com/, ustaw nazwę hosta swojego serwera WWW na '@' (musi być w cudzysłowie!). W składni BIND, @ oznacza samą nazwę domeny.

Jeśli chcesz określić wiele adresów IP dla hosta, dodaj wpisy do bind_zones.hosts z taką samą nazwą (np. priv01 w powyższym kodzie). Skutkuje to wieloma rekordami A/AAAA dla tego hosta i umożliwia DNS round robin, prostą technikę równoważenia obciążenia. Kolejność, w jakiej zwracane są adresy IP, można skonfigurować przy użyciu zmiennej roli bind_rrset_order.

Sieci

Jak widać, nie wszystkie hosty znajdują się w tej samej podsieci. Ta rola wygeneruje odpowiednie odwrotne strefy wyszukiwania dla każdej podsieci. Wszystkie podsieci powinny być określone w bind_zones.networks, w przeciwnym razie host nie otrzyma rekordu PTR do odwrotnego wyszukiwania.

Zauważ, że należy określać tylko część sieci! Przy określaniu adresu IP klasy B (np. "172.16") w pliku zmiennej musi być on w cudzysłowie, w przeciwnym razie parser Yaml zinterpretuje go jako liczbę zmiennoprzecinkową.

Na podstawie pomysłów i przykładów szczegółowych na stronie https://linuxmonk.ch/wordpress/index.php/2016/managing-dns-zones-with-ansible/ dla pakietu gdnsd, pliki stref są w pełni idempotentne, więc aktualizowane są tylko w przypadku rzeczywistych zmian zawartości.

Typy stref i automatyczna detekcja typów stref

Typ strefy type jest opcjonalnym parametrem, który definiuje, czy typ strefy powinien być primary, secondary czy forward. Gdy parametr type jest pominięty, typ strefy jest wykrywany automatycznie na podstawie zbioru adresów IP hostów i rekordu primaries przy konfigurowaniu strefy primary lub secondary. Gdy primaries nie jest zdefiniowane, a forwarders jest zdefiniowane, typ strefy zostanie ustawiony na forward.

Funkcjonalność automatycznego wykrywania typów stref jest szczególnie przydatna podczas wdrażania infrastruktury DNS w wielu lokalizacjach. Wygodne jest posiadanie "wspólnych" definicji bind_zones w jednym pliku inwentarza dla wszystkich serwerów DNS (np. group_vars\dns.yml). Takie podejście pozwala na przełączanie ról głównych i drugorzędnych serwerów poprzez aktualizację rekordu primaries i ponowne uruchomienie playbooka. Można to przetestować w scenariuszach "shared_inventory" przy uruchomieniu: molecule test --scenario-name shared_inventory.

UWAGA

• BIND nie obsługuje automatycznej konfiguracji multi-master i lista primaries powinna mieć tylko jeden wpis.
• Gdy rekord primaries jest aktualizowany, aby przełączyć rolę serwera głównego na rolę drugorzędnego, strefy zostaną usunięte i odtworzone z szablonu, ponieważ jeszcze nie wspieramy dynamicznych aktualizacji dla istniejących stref.

Typy stref mogą być również określone jawnie w inwentarzu per host, aby pominąć automatyczne wykrywanie:

# Serwer primary
bind_zones:
  - name: mydomain.com
    type: primary
    primaries:
      - 192.0.2.1
...
# Serwer secondary
bind_zones:
  - name: mydomain.com
      type: secondary
      primaries:
        - 192.0.2.1
...
# Serwer forwarder
bind_zones:
  - name: anotherdomain.com
      type: forward
      forwarders:
        - 192.0.3.1

Delegacja strefy

Aby delegować strefę do serwera DNS, wystarczy utworzyć rekord NS (w sekcji delegate), który jest równoważny z:

foo IN NS 192.0.2.1

Rekordy usług

Rekordy usług (SRV) można dodać z usługami. Powinna to być lista mapowań z obowiązkowymi kluczami name: (nazwa usługi), target: (host świadczący usługę), port: (port TCP/UDP usługi) oraz opcjonalnymi kluczami priority: (domyślnie = 0) i weight: (domyślnie = 0).

ACL

ACL można zdefiniować w ten sposób:

bind_acls:
  - name: acl1
    match_list:
      - 192.0.2.0/24
      - 10.0.0.0/8

Nazwy ACL będą dodane do klauzuli allow-transfer w globalnych opcjach.

Klucze do związku

Klucze do związku można zdefiniować w ten sposób:

bind_dns_keys:
  - name: primary_key
    algorithm: hmac-sha256
    secret: "azertyAZERTY123456"
bind_extra_include_files:
  - "{{ bind_auth_file }}"

wskazówka: Dodatkowy plik do dołączenia musi być ustawiony jako zmienna ansible, ponieważ plik jest zależny od systemu operacyjnego.

To zostanie ustawione w pliku "{{ bind_auth_file }} (np. /etc/bind/auth_transfer.conf dla Debiana), który musi być dodany do listy zmiennych bind_extra_include_files.

Używanie TSIG do autoryzacji transferu strefy (XFR)

Aby autoryzować transfer strefy między serwerami primary i secondary na podstawie klucza TSIG, ustawić mapowanie w zmiennej bind_key_mapping:

bind_key_mapping:
  primary_ip: TSIG-keyname

Każdy serwer główny może mieć tylko jeden klucz (na widok).

Sprawdzany będzie klucz w mapowaniu bind_dns_keys, aby upewnić się, że klucz jest rzeczywiście obecny. To doda deklarację serwera dla a w bind_auth_file na serwerze secondary, zawierającym określony klucz.

Zależności

Brak zależności.

Przykłady playbooków

Zobacz playbooki testowe i inwentarz dla szczegółowego przykładu, który pokazuje większość funkcji.

Standardowy inwentarz

• Zmienne wspólne dla wszystkich serwerów zdefiniowane w all.yml
• Zmienna bind_zone definiowana na poziomie pojedynczego hosta (primary, secondary i forwarder)

❯ tree --dirsfirst molecule/default
molecule/default
├── group_vars
│   └── all.yml
├── host_vars
│   ├── ns1.yml    # Primary
│   ├── ns2.yml    # Secondary
│   └── ns3.yml    # Forwarder
├── converge.yml
...

Wspólny inwentarz

Zmienne wspólne między głównym i drugorzędnym serwerami zdefiniowane w all.yml

❯ tree --dirsfirst molecule/shared_inventory
molecule/shared_inventory
├── group_vars
│   └── all.yml
├── converge.yml
...

Testowanie

Ta rola jest testowana przy użyciu Ansible Molecule. Testy są uruchamiane automatycznie na Github Actions po każdym commitcie i PR.

Konfiguracja Molecule zrobi:

• Uruchomi Yamllint i Ansible Lint
• Utworzy trzy kontenery Docker, jeden serwer primary (ns1), jeden serwer secondary (ns2) i forwarder(ns3) - default scenariusz molekuł
• Uruchomi sprawdzanie składni
• Zastosuje rolę z testowego playbooka i sprawdzi idempotencję
• Przeprowadzi testy akceptacyjne z playbooka weryfikacyjnego
• Utworzy dwa dodatkowe kontenery Docker, jeden primary(ns4) i jeden secondary (ns5) i uruchomi scenariusz shared_inventory

Ten proces powtarzany jest dla wszystkich wspieranych dystrybucji Linuxa.

Lokalna środowisko testowe

Aby uruchomić testy akceptacyjne dla tej roli lokalnie, możesz zainstalować niezbędne narzędzia na swoim komputerze lub skorzystać z tego powtarzalnego zestawu w maszynie wirtualnej VirtualBox (ustawionej za pomocą Vagranta): https://github.com/bertvv/ansible-testenv.

Kroki ręcznej instalacji narzędzi:

1. Docker powinien być zainstalowany na twoim komputerze
2. Zgodnie z zaleceniem Molecule, stwórz środowisko wirtualne Pythona
3. Zainstaluj niezbędne narzędzia python3 -m pip install molecule molecule-docker docker netaddr dnspython yamllint ansible-lint
4. Przejdź do katalogu głównego katalogu roli i uruchom molecule test

Molecule automatycznie usuwa kontenery po teście. Jeśli chcesz samodzielnie sprawdzić kontenery, uruchom molecule converge, a następnie molecule login --host HOSTNAME.

Kontenery Docker są oparte na obrazach stworzonych przez Jeffa Geerlinga, specjalnie do testowania Ansible (szukaj obrazów nazwanych geerlingguy/docker-DISTRO-ansible). Możesz używać dowolnych jego obrazów, ale obsługiwane są tylko dystrybucje wymienione w meta/main.yml.

Domyślna konfiguracja uruchomi trzy kontenery CentOS 8 (główna wspierana platforma w tym czasie). Wybierz inną dystrybucję ustawiając zmienną MOLECULE_DISTRO za pomocą polecenia, np.:

MOLECULE_DISTRO=debian9 molecule test

lub

MOLECULE_DISTRO=debian9 molecule converge

Możesz uruchomić testy akceptacyjne na wszystkich serwerach za pomocą molecule verify.

Testy weryfikacyjne przeprowadzane są przy użyciu modułu "dig" poprzez zapytanie rekordów dns i walidację odpowiedzi. Wymaga to bezpośredniej komunikacji sieciowej między węzłem kontrolera Ansible (twoim komputerem działającym na Ansible) a docelowym kontenerem dockerowym.

UWAGA

Testy weryfikacyjne molecule będą nieudane, jeśli docker działa na MacOS, ponieważ MacOS nie może uzyskać dostępu do adresu IP kontenera bezpośrednio. To jest znany problem. Zobacz #2670.

Obejście:

1. Uruchom linter molekuł: molecule lint
2. Przygotuj kontenery: molecule converge
3. Połącz się z kontenerem: molecule login --host ns1
4. Przejdź do katalogu roli: cd /etc/ansible/roles/bertvv.bind
5. Uruchom playbook weryfikacyjny:

ansible-playbook -c local -i "`hostname`," -i molecule/default/inventory.ini molecule/default/verify.yml

6. Powtórz kroki 2-4 dla ns2 i ns3

Licencja

BSD

Współtwórcy

Ta rola mogła być zrealizowana tylko dzięki wkładom wielu osób. Jeśli masz pomysł na dalsze usprawnienia, nie wahaj się zwrócić się o pomoc!

Problemy, prośby o funkcje, pomysły, sugestie itp. można zgłaszać w sekcji Problemy.

Prośby o zlecenie również są mile widziane. Utwórz gałąź tematyczną dla proponowanych zmian. W przeciwnym razie spowoduje to konflikty w twoim forku po scaleniu. Nie wahaj się dodać siebie do listy współtwórców poniżej w swoim PR!

Utrzymujący:

• Bert Van Vreckem
• Gregory Shulov
• Stuart Knight

Współtwórcy:

• Aido
• Angel Barrera
• B. Verschueren
• Boris Momčilović
• Brad Durrow
• Christopher Hicks
• David J. Haines
• Fabio Rocha
• Fazle Arefin
• flora-five
• Greg Cockburn
• Guillaume Darmont
• itbane
• jadjay
• Jascha Sticher
• Joanna Delaporte
• Jörg Eichhorn
• Jose Taas
• Lennart Weller
• Loic Dachary
• Mario Ciccarelli
• Miroslav Hudec
• Otto Sabart
• Paulius Mazeika
• Paulo E. Castro
• Peter Janes
• psa
• Rafael Bodill
• Rayford Johnson
• Robin Ophalvens
• Romuald
• roumano
• Shawn Wilsher
• Tom Meinlschmidt
• Jascha Sticher
• Zephyr82