Rola Ansible: manage-bind 2.0

Ta rola została stworzona jako warstwa abstrakcji do konfigurowania BIND i tworzenia stref DNS za pomocą składni YAML.

• Zainstaluj i zarządzaj swoim serwerem bind9 na serwerach Debian/Ubuntu.
• Użyj składni/pliku YAML do konfigurowania opcji, stref itp.

Wymagania

Ansible 2.4+

Uwaga: ta rola wymaga dostępu root do serwera bind

playbook.yml:

- hosts: dnsserver
  roles:
    - role: aalaesar.manage-bind
      become: yes

Zmienne roli

# konfiguracja hosta
bind_user:  bind
bind_group: bind
host_dns_srv: self
# katalog logów
bind_log_dir: /var/log/bind
# Konfiguracja instalacji
bind_pkg_state: present
bind_pkgs: ['bind9', 'dnsutils']
bind_service_state: started
bind_service_enabled: yes
# Konfiguracje
bind_configs_dir: /etc/bind
bind_config_master_zones: []
bind_config_default_zones: 'yes'
RFC1918: no
# Pliki stref
bind_zones_dir: /var/lib/bind
# Domyślna konfiguracja stref
zones_config_ttl: 38400 #10h45m
zones_config_refresh: 10800 #3h
zones_config_retry: 3600 #1h
zones_config_expire: 604800 #1w
zones_config_minimum: 38400 #10h45m

# usuwanie niezarządzanych plików w celu utrzymania porządku na serwerze
remove_unmanaged_files: true
# inicjalizacja listy zarządzanych plików stref:
list_zone_files: []

Konfigurowanie BIND

Wprowadzenie do konfiguracji BIND

BIND korzysta z mechanizmu dziedziczenia instrukcji klauzul do precyzyjnej konfiguracji.

• klauzula to klasa z własnym zbiorem instrukcji.
  • Mogą mieć szczególne lub wspólne instrukcje.
  • Klauzula zdefiniowana wewnątrz innej klauzuli automatycznie dziedziczy wspólne instrukcje swojej "matki".
• instrukcja to właściwość klauzuli.
  • Opisuje zachowanie serwera na temat jak wykonać zadanie, kiedy, itd.
  • Może być zdefiniowana jawnie lub niejawnie.
• Niektóre zasady dziedziczenia:
• Opcje są klauzulą najwyższą, która zawiera wszystkie inne.
• strefa jest klauzulą najniższą. Nie może mieć żadnych dzieci. Zawiera również rekordy strefy.
• klauzula może nadpisywać instrukcję swojego rodzica i przekazywać nową wartość do swoich dzieci, jawnie redefiniując tę instrukcję.

  Oto przykład w ASCII tych zasad:

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          Opcje                              |
|=============================================================|
|                       statement1=foo                        |
|                      statement2=koala                       |
|#############################################################|
Ostateczny wynik:
Zgodnie z tym, że instrukcja1 i instrukcja2 są wspólne dla wszystkich klauzul
zone1: statement1=john, statement2=kangaroo
zone2: statement1=foo, statement2=kangaroo
zone3: statement1=bar, statement2=koala
zone4: statement1=foo, statement2=koala

manage-bind obsługuje następujące klauzule:

• opcje
• strefa
• klucz

Lista obsługiwanych instrukcji: Zobacz ./vars/main.yml

TODO: widoki

Ostrzeżenie podczas definiowania instrukcji !

• niektóre instrukcje są definiowane za pomocą złożonych mapowań, podczas gdy inne wymagają tylko prostej wartości. Na wszelki wypadek, każda instrukcja ma swój własny dokumentujący szablon.
• manage-bind używa narzędzi BIND named-checkconf i named-checkzone do weryfikacji konfiguracji i stref. Jednak te narzędzia są ograniczone do składni i lekkiej spójności. Ta rola nie zapewnia zaawansowanych metod weryfikacji.
• Użyj cudzysłowów do ucieczki specjalnych znaków, takich jak @
• Niektóre instrukcje wymagają wartości łańcuchowych "yes|no": użyj cudzysłowów do ucieczki yes i no, ponieważ Ansible ocenia je jako typ logiczny.

Klauzula Opcji

Uwaga: Rola zawiera pewne domyślne opcje.

Definiowanie instrukcji opcji

Podczas wywoływania manage-bind, możesz przekazać instrukcje opcji:

• w zewnętrznym pliku YAML zadeklarowanym za pomocą options_file.
  • Musi zawierać mapowanie instrukcji nazwane options.
• w mapowaniu nazwanemu options wewnątrz swojego playbooka.

Uwaga: Pierwsza metoda wyklucza drugą: rola załadowuje tylko instrukcje z pliku, jeśli zadeklarujesz go w swoim playbooku.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      options_file: ./files/options.yml # rola załaduje tylko te opcje
      options: # następne linie są zbędne w tym przypadku
        statement1: ...
        statement2: ...

./files/options.yml:

---
options:
  statement1: ...
  statement2: ...

Lista wszystkich dostępnych instrukcji dla opcji znajduje się w ./tests/bind_options.yml

Zmiana domyślnych opcji roli:

Są zdefiniowane w ./defaults/default_options.yml

Możesz użyć tego pliku, aby podzielić wspólną politykę w swojej infrastrukturze i łatwo nadpisywać konkretne opcje.

Klauzule stref

Klauzule stref są definiowane z instrukcją i rekordami strefy.

Deklaracja strefy

Każda strefa jest zadeklarowana jako element listy nazwanej zones.

'zones' musi być zdefiniowana w playbooku i jest wymagana.

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      zones:
        "strefa 1":
          statements ...
        "strefa 2":
          statements ...

Definiowanie instrukcji strefy

Strefa to mapowanie, w którym nazwa strefy jest głównym kluczem, a jej instrukcje to klucze:wartości

• [instruction]:value
• type to obowiązkowe instrukcje
• force_file [boolean]: informuje ansible, aby przepisał plik bazy rekordów. Przydatne, jeśli Twoja strefa jest dynamicznie wypełniana przez DNS. - false dla stref podrzędnych - true dla pozostałych
• Niektóre typy stref mają swoje własne obowiązkowe instrukcje.

playbook.yml:

zones:
  example.com: # nazwa domeny
    type: master # obowiązkowe. Typ strefy : master|slave|forward|stub
    recursion: "no" # instrukcja nadpisująca globalną opcję "recursion" dla tej strefy.
    ... # itp

Lista wszystkich dostępnych instrukcji strefy znajduje się w ./tests/zone_statements.md

Definiowanie rekordów strefy

rekordy strefy są definiowane w mapowaniu nazwanym 'records'

To mapowanie 'records' można zadeklarować:

• w pliku YAML określonym w kluczu yamlfile.
• jako mapowanie wewnątrz mapowania strefy.

Uwaga: zawartość plików YAML jest łączona z konfiguracją strefy: więc w przypadku zduplikowanych rekordów, zawartość pliku będzie miała pierwszeństwo.

playbook.yml:

zones:
  example.com:
    records:
      SOA: ...
      NS: ...
      ... # itp
    ... # itp
  test.tld:
    yamlfile: "./files/test.tld.yml"
    records:
      SOA: ...
      NS: ...
      A:
       localhost: 127.0.0.1
       test1: 9.8.7.6 # będzie nadpisany przez yamlfile
    ... # itp

W pliku yaml, records musi być mapowaniem na najwyższym poziomie:

./files/test.tld.yml:

---
records:
  SOA: ...
  NS: ...
  A:
   test1: 1.2.3.4
   test2: 5.6.7.8
  ... # itp

Dodawanie rekordów w strefie

Rekordy strefy mają różne typy, są zadeklarowane według typu wewnątrz records.

każdy typ rekordu jest inny i ma swoją własną strukturę YAML.

Manage-bind obsługuje następujące rekordy:

• SOA
• NS
• A
• AAAA
• MX
• SRV
• PTR
• CNAME
• DNAME
• TXT
• ttl można zadeklarować wzdłuż rekordów strefowych

Zależności

Brak.

Przykłady playbooków

Przykład konfiguracji:

• Posiadasz strefy example.tld, example.com i example.org
• Masz 2 serwery nazw: dnserver1 (11.22.33.44) i dnserver2 (55.66.77.88)
• dnserver1 jest masterem example.tld i slave'em example.com.
• dnserver2 jest masterem example.com i slave'em example.tld
• example.tld jest dynamicznie uzupełniany przez serwer DHCP

Playbook dnserver1:

---
- hosts: dnserver1
  roles:
    - role: aalaesar.manage-bind
      options:
        allow_recursion: '55.66.77.88'
        allow_transfer: '55.66.77.88'
      zones:
        example.tld:
          type: master
          force_file: no
          notify: '55.66.77.88'
          allow_update:
            - key dhcp_updater
          records:
            - SOA:
                serial: 2016080401
                ns: dnserver1.example.tld.
                email: admin.example.tld.
            - NS:
              - dnserver1.example.tld.
              - dnserver2.example.tld.
            - A:
                dnserver1: 11.22.33.44
                dnserver2: 55.66.77.88
        example.com:
          type: slave
          masters: '55.66.77.88'
      keys:
      - name: dhcp_updater
        algorithm: "hmac-md5"
        secret: "{{myvault_dhcp_key}}"

Playbook dnserver2:

---
- hosts: dnserver2
  roles:
    - role: aalaesar.manage-bind
      options:
        allow_recursion: '11.22.33.44'
        allow_transfer: '11.22.33.44'
      zones:
        example.com:
          type: slave
          notify: '11.22.33.44'
        example.tld:
         type: slave
         masters: '11.22.33.44'
         ymlfile: example.com.yml

Plik YAML dla example.com.yml na dnserver2

---
records:
  ttl: 3d
  SOA:
    serial: 2016080401
    ns: dnserver2.example.com.
    email: admin.example.com.
  NS:
    - srvdns01.example.com.
  A:
    127.0.0.1:
      - '@'
      - dnserver2.example.com.
    host1: 12.34.56.78
    mailsrv: 98.76.54.32
    'ftp.domain.tld.': 95.38.94.196
  MX:
    '@':
      - target: backup.fqdn.
        priority: 20
  CNAME:
    host1: ftp
    '@':
      - www
      - webmail
  TXT:
    - text: '"v=spf1 mx -all"'
    - text: '( "v=DKIM1; k=rsa; t=s; n=core; p=someverylongstringbecausethisisakeyformailsecurity" )  ; ----- DKIM key mail for example.com'
      label: mail._domainkey

Więcej przykładów jest dostępnych w folderze testowym.

Licencja

BSD