nsd

Ansible роль для NSD

Эта Ansible роль устанавливает и настраивает NSD, авторитетный DNS сервер. Она также позволяет публиковать DNS зоны в NSD.

Установка

Эта роль доступна на Ansible Galaxy.

Особенности

Эта роль поддерживает как NSD3, так и NSD4, позволяет управлять конфигурацией NSD и файловыми зонами, в мастер или слейв режиме, с или без трансфера зоны (TSIG).

Особенно стоит отметить, что по сравнению с другими ролями NSD (elnappo, reallyenglish, creicm, adarnimrod, hudecof), она имеет следующие особенности:

Позволяет хранить данные зоны в "классических" файловых зонах, вместо того чтобы писать зоны как переменные ansible, как здесь.
Файлы зон анализируются как шаблоны Jinja, если вам нужно что-то динамическое.
Поддерживает как мастер, так и слейв сценарии, или даже их сочетание (некоторые зоны работают как мастера, а некоторые как слейвы, на одном сервере NSD).
Полностью универсальная конфигурация NSD (вы можете определить любой конфигурационный атрибут, поддерживаемый NSD, нет жестко заданного списка в роли). Это похоже на здесь, но с более простой синтаксисом (автоматическое развертывание списков).
Поддерживает трансферы зоны: TSIG ключи, уведомления слейвам и пр...
Надеемся, гибкая и простая в использовании!

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

Сценарии использования

Примечание: все эти сценарии использования могут быть использованы независимо для каждой зоны! То есть, один сервер NSD может быть как мастером для example.com, так и слейвом для example.org.

Чистый многомастера

Если все ваши DNS серверы настроены с помощью Ansible, это самая простая настройка: все серверы являются мастерами для зоны, и данные зоны разворачиваются с помощью Ansible.

В этой настройке нет необходимости в трансфере зоны на основе DNS.

Многомастера с дополнительными слейвами, не настроенными этой ролью

В этой настройке один или несколько мастеров настраиваются с помощью Ansible, как в предыдущем примере. Однако также настраивается трансфер зоны на основе DNS, чтобы позволить внешним слейвам получать данные зоны от мастера. Каждый раз, когда Ansible обновляет зону на мастерах, он сообщает NSD уведомить слейвов.

Обратите внимание, что в этой настройке ваша ответственность — правильно настроить слейвы (принимать уведомления от всех мастеров и получать данные зоны от одного или нескольких мастеров).

Только слейв

В этой настройке серверы NSD просто настраиваются как слейвы для зоны. В этом случае данные зоны не копируются на серверы, так как данные будут получены от внешнего мастера с использованием обычных механизмов трансфера зоны DNS.

Обратите внимание, что в этой настройке ваша ответственность — правильно настроить мастера (уведомлять слейвов и разрешать трансферы зоны от слейвов).

Требования

Эта роль была протестирована на Debian (wheezy, jessie, stretch, buster, bullseye). Возможно, она будет работать и на других системах с некоторыми доработками, патчи приветствуются.

Эта роль не настраивает nsd-control, так как это уже сделано автоматически пакетом Debian. Другие системы могут потребовать настройки через Ansible.

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

Здесь описаны все переменные роли, которые вы можете установить в своих плейбуках. Смотрите в конце этого README для полного примера.

Конфигурация сервера

nsd_server_config [dict]

Словарь пар "ключ-значение", которые будут добавлены в секцию конфигурации server: NSD. Значение может быть либо строкой, либо списком. В последнем случае значение будет развернуто в несколько конфигурационных записей.

Вы можете добавлять любые конфигурационные опции в этот словарь, но убедитесь, что это опция конфигурации, понятная NSD! В качестве предосторожности, роль просит NSD проверить сгенерированную конфигурацию перед тем, как продолжить, но это не будет сделано при запуске ansible-playbook --check.

nsd_local_server_config [dict]

Та же синтаксис и семантика, как nsd_server_config. Эта вторая переменная предоставлена, чтобы упростить добавление специфической конфигурации для одной машины. Обычно вы определяете nsd_server_config в group_vars или в плейбуке, а nsd_local_server_config — в host_vars.

TSIG ключи

nsd_tsig_keys [list of dict]

Необязательный список TSIG ключей. Каждый TSIG ключ должен быть словарем с следующими атрибутами:

tsig_keyname: имя этого TSIG ключа. Обратите внимание, что в конфигурации DNS master/slave имя TSIG ключа должно быть одинаковым на мастере и слейвах! Это имя также используется для обращения к TSIG ключам из переменных роли nsd_primary_zones и nsd_secondary_zones. Обязательно.
tsig_secret: значение ключа, закодированное в base64. Обязательно.
tsig_algorithm: алгоритм, используемый ключом, например, hmac-md5. Обязательно.

Основные зоны

nsd_primary_zones [list of dict]

Список зон, которые будут обслуживаться как мастер. Каждая зона должна быть словарем со следующими атрибутами:

zone_name: имя зоны, например, example.com или 8.b.d.0.1.0.0.2.ip6.arpa.. Обязательно.
zone_filename: имя файла, содержащего данные зоны (будет искаться в files/nsd/). Обязательно.
slaves: список DNS слейвов, формат описан ниже. Необязательно.

Формат для записи слейва следующий:

ip: IPv4 или IPv6 адрес DNS слейва. Будет использоваться для отправки "уведомлений" и для разрешения трансферов зоны с этого IP. Обязательно.
tsig_key: имя TSIG ключа, который будет использоваться при взаимодействии с этим слейвом. Имя должно совпадать с полем tsig_keyname ранее определённого TSIG ключа, см. выше. Необязательно.

Вторичные зоны

nsd_secondary_zones [list of dict]

Список зон, которые будут обслуживаться как слейв. Каждая зона должна быть словарем со следующими атрибутами:

zone_name: имя зоны, например, example.com или 8.b.d.0.1.0.0.2.ip6.arpa.. Обязательно.
masters: список DNS мастеров, формат описан ниже. Необязательно, но слейв зона довольно бесполезна без мастера.

Формат для записи мастера следующий:

ip: IPv4 или IPv6 адрес DNS мастера. Будет использоваться для запроса трансферов зоны и для разрешения уведомлений. Обязательно.
tsig_key: имя TSIG ключа, который будет использоваться при взаимодействии с этим мастером. Имя должно совпадать с полем tsig_keyname ранее определённого TSIG ключа, см. выше. Необязательно.

Переменные для продвинутой конфигурации

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

nsd_local_zones_dir: files/nsd/

Локальный каталог, в котором следует искать файлы зон (записи zone_filename относительны к этому каталогу).

nsd_version: 4

Версия NSD. Используется для пропуска задач или обработчиков, которые не имеют смысла в зависимости от версии.

nsd_service_name: "nsd"

Имя сервиса инициализации, используемого для перезапуска NSD.

nsd_pkg_name: "nsd"

Имя пакета для установки.

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

Программа, используемая для управления NSD, для перезагрузки, перестройки, уведомления и пр.

nsd_config_dir: "/etc/nsd"

Каталог, в котором будет храниться конфигурация NSD.

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

Имя конфигурационного файла, который будет хранить конфигурацию зон (он затем включается из основного файла конфигурации NSD).

nsd_primary_zones_dir: "/etc/nsd/primary"

Каталог, в который файлы зон будут копироваться этой ролью.

nsd_secondary_zones_dir: "/etc/nsd/secondary"

Каталог, в который файлы слейв зон будут помещены NSD после трансфера зоны.

Пример плейбука

Это полный пример плейбука с несколькими TSIG ключами и несколькими DNS зонами: первая зона является основной зоной без слейва, вторая зона имеет двух слейвов, а третья зона является вторичной зоной с двумя мастерами.

- hosts: dnsservers
  roles:
    - nsd
  vars:
    nsd_server_config:
      verbosity: 2
      ip4-only: 'yes'
    nsd_tsig_keys:
    # Два TSIG ключа, используемых в определении зон ниже
      - 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:
    # Основная зона без слейва
      - zone_name: "example.com."
        zone_filename: "example.com.zone"
    # Основная зона с двумя слейвами, один с двойной стеком с TSIG ключом, и один с одиночным стеком без ключа
      - 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:
    # Слейв зона с двумя мастерами, первый без ключа, второй с ключом
      - zone_name: "example.eu.org"
        masters:
          - ip: 192.0.2.42
          - ip: 2001:db8:1234:5678::9
            tsig_key: "key-eu.org"

Также в host_vars/ns1.yml:

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

Данные зоны для двух основных зон должны храниться в nsd_local_zones_dir (по умолчанию это files/nsd/ в корне вашей директории 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)

Вы можете использовать шаблоны Jinja в ваших файловых зонах для генерации динамических записей.

Пример продвинутой конфигурации

Если вам нужна более продвинутая настройка, вы можете использовать продвинутые переменные. Например, для поддержки NSD3 на Debian wheezy, подходящая конфигурация была:

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"

Это можно разместить в group_vars/wheezy.yml или эквивалентном файле.

Ограничения

Для заданной зоны все машины, использующие эту роль, должны быть либо все мастерами, либо все слейвами.

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

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

Существуют случаи, когда иметь несколько мастеров, чья зона подконтрольна Ansible, возможно, не будет желательно: