Ansible роль BIND

Роль Ansible для настройки ISC BIND как только авторитетного DNS сервера для нескольких доменов. Конкретные задачи этой роли:

• Установка BIND
• Настройка основного конфигурационного файла (основной/вторичный/пересылающий сервер)
• Настройка файлов зон для прямого и обратного поиска

Эта роль поддерживает несколько зон для прямого и обратного поиска, включая IPv6. Хотя включение рекурсии поддерживается (но категорически не рекомендуется), подумайте о том, чтобы использовать другую роль, если хотите настроить сервер имен с кешированием или пересылкой.

Если вам нравится/вы используете эту роль, пожалуйста, рассмотрите возможность поставить звезду и оценить ее на странице Ansible Galaxy роли. Спасибо!

Смотрите журнал изменений для заметных изменений между версиями.

ПРЕДУПРЕЖДЕНИЕ: Если вы использовали эту роль до v5.0.0, пожалуйста, ознакомьтесь с журналом изменений для важной информации о кардинальных изменениях. Старые плейбуки будут работать с ошибками, если вы обновитесь до v5.0.0.

Поддерживаемые платформы

Эта роль может быть использована на нескольких платформах, смотрите meta/main.yml для обновленного списка. Мы стремимся установить автоматические тесты для каждой поддерживаемой платформы (см. .ci.yml), но это не всегда возможно.

Несколько замечаний о поддерживаемых ролях, которые не включены в автоматические тесты

• Arch Linux и FreeBSD должны работать, но в настоящее время невозможно протестировать роль на этих дистрибутивах, так как нет подходящих Docker-образов.
• CentOS 6 должен работать, но тесты идемпотентности не проходят, даже если BIND установлен успешно, и тесты акцептирования проходят.

Требования

Пакеты python-netaddr (необходим для фильтра ipaddr) и dnspython должны быть установлены на управляющем узле.

Переменные роли

† Лучшей практикой для авторитетного сервера имен является отключение рекурсии. Однако, в некоторых случаях может быть необходимо включить рекурсию.

Минимальные переменные для работающей зоны

Чтобы настроить авторитетный сервер имен, доступный клиентам, необходимо определить как минимум следующие переменные:

Определения доменов

bind_zones:
  # Пример основной зоны (hosts: и name_servers: определены)
  - name: mydomain.com           # Имя домена
    create_reverse_zones: false  # Пропустить создание обратных зон
    primaries:
      - 192.0.2.1                # Основной сервер(ы) для этой зоны
    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: '@'                # Позволяет "http://mydomain.com/"
        ip:
          - 192.0.2.3            # Несколько IP адресов для одного хоста
          - 192.0.2.4            #   приводит к DNS round robin
        sshfp:                   # Secure shell fingerprint
          - "3 1 1262006f9a45bb36b1aa14f45f354b694b77d7c3"
          - "3 2 e5921564252fe10d2dbafeb243733ed8b1d165b8fa6d5a0e29198e5793f0623b"
        ipv6:
          - 2001:db8::2
          - 2001:db8::3
        aliases:
          - www
      - name: priv01             # Этот IP находится в другой подсети, приведет к
        ip: 10.0.0.1             #   множественным обратным зонам
      - name: mydomain.net.
        aliases:
          - name: sub01
            type: DNAME          # Пример 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:                       # Запись указателя имени, используемая для IP
      - name: "sip"              #   телефония
        order: 100
        pref: 10
        flags: "S"
        service: "SIP+D2T"
        regex: "!^.*$!sip:[email protected]!"
        replacement: "_sip._tcp.example.com."
  # Минимальный пример вторичной зоны
  - name: acme.com
    primaries:
      - 172.17.0.2
    networks:
      - "172.17"
  # Минимальный пример зоны пересылки
  - name: acme.com
    forwarders:
      - 172.17.0.2
    networks:
      - "172.17"

Хосты

Имена хостов, которые этот DNS сервер должен разрешать, можно указать в bind_zones.hosts в виде списка сопоставлений с ключами name:, ip:, aliases: и sshfp:. Псевдонимы могут быть записями CNAME (по умолчанию) или DNAME.

Чтобы разрешить переход на http://example.com/, установите имя хоста вашего веб-сервера на '@' (должно быть в кавычках!). В синтаксисе BIND, @ указывает на имя самого домена.

Если вы хотите указать несколько IP адресов для хоста, добавьте записи в bind_zones.hosts с тем же именем (например, priv01 в приведенном фрагменте кода). Это приведет к множественным записям A/AAAA для этого хоста и позволит использовать DNS round robin, простую технику балансировки нагрузки. Порядок, в котором возвращаются IP адреса, можно настроить с помощью переменной роли bind_rrset_order.

Сети

Как вы можете видеть, не все хосты находятся в одной подсети. Эта роль сгенерирует подходящие зоны обратного поиска для каждой подсети. Все подсети должны быть указаны в bind_zones.networks, иначе хост не получит PTR запись для обратного поиска.

Заметьте, что здесь следует указывать только часть сети! При указании IP адреса класса B (например, "172.16") в файле переменных его нужно взять в кавычки. В противном случае парсер Yaml интерпретирует его как число с плавающей точкой.

Согласно идее и примерам, изложенным на https://linuxmonk.ch/wordpress/index.php/2016/managing-dns-zones-with-ansible/ для пакета gdnsd, файлы зон полностью идемпотентны, и, следовательно, обновляются только в случае изменения "реального" содержимого.

Типы зон и автоопределение типа зон

Параметр type зоны является необязательным параметром зоны, который определяет, должен ли тип зоны быть primary, secondary или forward. Когда параметр type опущен, тип зоны будет автоопределен на основе пересечения IP адресов хостов и записи primaries при настройке основной или вторичной зоны. Когда primaries не определен, а forwarders определен, тип зоны будет установлен на forward.

Функциональность автоопределения зон особенно полезна при развертывании многосайтовой DNS инфраструктуры. Удобно иметь "общие" определения bind_zones в одном файле инвентаря для всех DNS серверов (например, group_vars\dns.yml). Такой подход позволяет переключаться между ролями основных и вторичных серверов, просто обновляя запись primaries и повторно выполняя плейбук. Функция автоопределения типа зоны может быть протестирована с помощью сценария "shared_inventory", запустив: molecule test --scenario-name shared_inventory

ПРИМЕЧАНИЕ

• bind не поддерживает автоматизированную мульти-мастерную конфигурацию и в списке primaries должно быть только одно значение.
• Когда запись primaries обновляется для переключения ролей основного на вторичный сервер, зоны будут удалены и воссозданы из шаблона, так как мы пока не поддерживаем динамические обновления для существующих зон.

Типы зон также могут быть явно определены в инвентаре на уровне хоста, чтобы избежать автоопределения:

# Основной сервер
bind_zones:
  - name: mydomain.com
    type: primary
    primaries:
      - 192.0.2.1
...
# Вторичный сервер
bind_zones:
  - name: mydomain.com
      type: secondary
      primaries:
        - 192.0.2.1
...
# Сервер пересылки
bind_zones:
  - name: anotherdomain.com
      type: forward
      forwarders:
        - 192.0.3.1

Делегирование зоны

Чтобы делегировать зону на DNS сервер, достаточно создать запись NS (под делегирование), что эквивалентно:

foo IN NS 192.0.2.1

Записи служб

Записи служб (SRV) могут быть добавлены с помощью секции services. Это должен быть список сопоставлений с обязательными ключами name: (имя службы), target: (хост, предоставляющий услугу), port: (TCP/UDP порт службы) и необязательными ключами priority: (по умолчанию = 0) и weight: (по умолчанию = 0).

ACL

ACL можно определить следующим образом:

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

Имена ACL будут добавлены в клаузулу allow-transfer в глобальных опциях.

Ключи привязки

Ключи привязки можно определить так:

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

Совет: Дополнительный включаемый файл должен быть установлен как переменная ansible, так как файл зависит от ОС

Это будет установлено в файле "{{ bind_auth_file }} (например, /etc/bind/auth_transfer.conf для Debian), который также нужно добавить в список переменной bind_extra_include_files.

Использование TSIG для авторизации передачи зоны (XFR)

Чтобы авторизовать передачу зоны между основными и вторичными серверами на основе ключа TSIG, установите сопоставление в переменной bind_key_mapping:

bind_key_mapping:
  primary_ip: TSIG-keyname

Каждый основной сервер может иметь только один ключ (на одно представление).

Будет выполнена проверка на наличие ключа в сопоставлении bind_dns_keys. Это добавит оператор сервера для a в bind_auth_file на вторичном сервере, содержащем указанный ключ.

Зависимости

Нет зависимостей.

Примеры плейбуков

Смотрите тестовые плейбуки и инвентарь для подробного примера, который демонстрирует большинство функций.

Стандартный инвентарь

• Переменные, общие для всех серверов, определены в all.yml
• Переменная bind_zone определена на уровне каждого хоста (основной, вторичный и пересылающий)

❯ tree --dirsfirst molecule/default
molecule/default
├── group_vars
│   └── all.yml
├── host_vars
│   ├── ns1.yml    # Основной
│   ├── ns2.yml    # Вторичный
│   └── ns3.yml    # Пересылающий
├── converge.yml
...

Общий инвентарь

Переменные, общие для основных и вторичных серверов, определены в all.yml

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

Тестирование

Эта роль тестируется с использованием Ansible Molecule. Тесты запускаются автоматически на Github Actions после каждого коммита и PR.

Эта конфигурация Molecule будет:

• Запустить Yamllint и Ansible Lint
• Создать три контейнера Docker: один основной (ns1), один вторичный (ns2) DNS сервер и пересылающий (ns3) - сценарий молекулы по умолчанию
• Выполнить проверку синтаксиса
• Применить роль с помощью тестового плейбука и проверить идемпотентность
• Запустить тесты акцептирования с плейбуком проверки
• Создать два дополнительных контейнера Docker: один основной(ns4) и один вторичный (ns5), и выполнить сценарий shared_inventory

Этот процесс повторяется для всех поддерживаемых дистрибутивов Linux.

Локальная тестовая среда

Чтобы выполнить тесты акцептирования для этой роли локально, вы можете установить необходимые инструменты на своем компьютере или использовать эту воспроизводимую настройку в VirtualBox VM (настроенная с Vagrant): https://github.com/bertvv/ansible-testenv.

Шаги для установки инструментов вручную:

1. Docker должен быть установлен на вашем компьютере
2. Рекомендуется для Molecule создать виртуальную среду python
3. Установите программное обеспечение python3 -m pip install molecule molecule-docker docker netaddr dnspython yamllint ansible-lint
4. Перейдите в корень директории роли и выполните molecule test

Molecule автоматически удаляет контейнеры после теста. Если вы хотите проверить контейнеры самостоятельно, выполните molecule converge, затем molecule login --host HOSTNAME.

Контейнеры Docker основаны на образах, созданных Джеффом Гирлингом, специально для тестирования Ansible (ищите образы с именами geerlingguy/docker-DISTRO-ansible). Вы можете использовать любой из его образов, но поддерживаются только дистрибутивы, указанные в meta/main.yml.

Конфигурация по умолчанию запустит три контейнера Centos 8 (основная поддерживаемая платформа в настоящее время). Выберите другой дистрибутив, установив переменную MOLECULE_DISTRO с командой, например:

MOLECULE_DISTRO=debian9 molecule test

или

MOLECULE_DISTRO=debian9 molecule converge

Вы можете запустить тесты акцептирования на всех серверах с помощью molecule verify.

Тесты проверки выполняются с использованием модуля "dig" для запроса DNS записей и валидации ответов. Это требует прямой сетевой связи между узлом контроллера Ansible (вашим компьютером, на котором выполняется Ansible) и целевым контейнером Docker.

ПРИМЕЧАНИЕ

Тесты верификации Molecule будут неудачны, если Docker работает на MacOS, так как MacOS не может получить доступ к IP контейнера напрямую. Это известная проблема. См. #2670.

Обходной путь:

1. Выполните линтер молекулы: molecule lint
2. Проведите инициализацию контейнеров: molecule converge
3. Подключитесь к контейнеру: molecule login --host ns1
4. Перейдите в директорию роли: cd /etc/ansible/roles/bertvv.bind
5. Выполните плейбук проверки:

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

6. Повторите шаги 2-4 для ns2 и ns3

Лицензия

BSD

Участники

Эта роль могла быть реализована только благодаря вкладу многих. Если у вас есть идея, как улучшить ее еще больше, не стесняйтесь участвовать!

Проблемы, запросы функций, идеи, предложения и т. д. могут быть размещены в разделе Issues.

Запросы на извлечение также очень приветствуются. Пожалуйста, создайте ветку темы для ваших предлагаемых изменений. Если вы этого не сделаете, это создаст конфликты в вашем форке после слияния. Не стесняйтесь добавлять себя в список участников ниже в своем PR!

Сопредседатели:

• Берт Ван Врекем
• Грегори Шулов
• Стюарт Найт

Участники:

• Aido
• Angel Barrera
• B. Verschueren
• Борис Момчилович
• Брэд Дурроу
• Кристофер Хикс
• Дэвид Дж. Хейнс
• Фабио Роша
• Фазле Арефин
• flora-five
• Грег Кокберн
• Гийом Дормон
• itbane
• jadjay
• Ясча Стихер
• Жоанна Делапорт
• Йорг Эйххорн
• Хосе Таас
• Леннарт Уэллер
• Лоик Дачари
• Марио Чиккарелли
• Мирослав Худек
• Отто Сабарт
• Паулиус Мазейка
• Пауло Э. Кастро
• Питер Джанес
• psa
• Рафаэль Бодил
• Рейфорд Джонсон
• Робин Офалвенс
• Ромоальд
• roumano
• Шон Уилшер
• Том Майншмидт
• Ясча Стихер
• Zephyr82