Ansible ロール: manage-bind 2.0

このロールは、YAML構文を使用してbindを構成し、DNSゾーンを作成するための抽象化レイヤーとして構築されています。

• Debian/Ubuntuサーバーでbind9サーバーをインストールし、管理します。
• YAML構文/ファイルを使用して、Bindのオプションやゾーンなどを構成します。

要件

Ansible 2.4+

注: このロールはbindサーバーへのルートアクセスを必要とします。

playbook.yml:

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

ロール変数

# ホスト設定
bind_user:  bind
bind_group: bind
host_dns_srv: self
# ログディレクトリ
bind_log_dir: /var/log/bind
# インストール設定
bind_pkg_state: present
bind_pkgs: ['bind9', 'dnsutils']
bind_service_state: started
bind_service_enabled: yes
# 設定
bind_configs_dir: /etc/bind
bind_config_master_zones: []
bind_config_default_zones: 'yes'
RFC1918: no
# ゾーンファイル
bind_zones_dir: /var/lib/bind
# ゾーンのデフォルト設定
zones_config_ttl: 38400 #10時間45分
zones_config_refresh: 10800 #3時間
zones_config_retry: 3600 #1時間
zones_config_expire: 604800 #1週間
zones_config_minimum: 38400 #10時間45分

# 管理されていないファイルを削除してサーバーをクリーンに保つ
remove_unmanaged_files: true
# 管理されているゾーンファイルのリストを初期化します：
list_zone_files: []

Bindの構成

Bindの設定について

Bindは節のステートメントの継承メカニズムを使用して、正確な構成を可能にします。

• 節は独自のステートメントセットを持つクラスです。
  • 特定のステートメントや共通ステートメントを持つことができます。
  • 別の節内に定義された節は、その親の共通ステートメントを暗黙的に継承します。
• **ステートメント**は節の属性です。
  • サーバーの動作を説明し、タスクを実行する方法や時期などを示します。
  • 明示的または暗黙的に定義されることがあります。
• いくつかの継承ルール:
• Optionsは最上位の節で、他のすべてを含みます。
• zoneは最下位の節です。子を持てません。また、ゾーンレコードを含みます。
• 節は親のステートメントをオーバーライドし、新しい値を子(や孫)に引き継ぐことができます。

  ここにこのルールのASCII例があります：

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          Options                            |
|=============================================================|
|                       statement1=foo                        |
|                      statement2=koala                       |
|#############################################################|
最終結果:
statement1とstatement2はすべての節に共通
zone1: statement1=john, statement2=kangaroo
zone2: statement1=foo, statement2=kangaroo
zone3: statement1=bar, statement2=koala
zone4: statement1=foo, statement2=koala

manage-bindは以下の節をサポートしています：

• options
• zone
• key

サポートされているステートメントのリスト: ./vars/main.ymlを参照してください。

TODO: views

ステートメントを定義する際の注意点！

• 一部のステートメントは複雑なマッピングで定義されており、他は単純な値を必要とします。 各ステートメントには自己文書化されたテンプレートがあります。
• manage-bindはbindのツールnamed-checkconfおよびnamed-checkzoneを使用して構成とゾーンの検証を行います。 ただし、これらのツールは構文および軽微な整合性の検証に限られています。 このロールは高度な検証方法を提供しません。
• 特殊文字（例: @）は引用符でエスケープします。
• 一部のステートメントは「yes|no」文字列値を必要とします：Ansibleがそれをブーリアンとして評価するため、yesとnoは引用符でエスケープしてください。

オプション節

注: このロールにはいくつかのデフォルトオプションが含まれています。

オプションのステートメントを定義する

manage-bindを呼び出すとき、オプションのステートメントを渡すことができます：

• options_fileで宣言された外部YAMLファイルに。
  • ステートメントマッピングoptionsを含む必要があります。
• プレイブック内のoptionsというマッピング。

注: 最初の方法は2つ目を排除します: プレイブックで宣言した場合、ロールはファイル内のステートメントのみを読み込みます。

playbook.yml:

- hosts: dnsserver
  become: yes
  roles:
    - role: aalaesar.manage-bind
      options_file: ./files/options.yml # ロールはこれらのオプションのみを読み込みます
      options: # この場合、次の行は不要です
        statement1: ...
        statement2: ...

./files/options.yml:

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

オプションのステートメントのリストは**./tests/bind_options.yml**にあります。

ロールのデフォルトオプションを変更する：

それは**./defaults/default_options.yml**に定義されています。

このファイルを使用してインフラ全体に共通のポリシーを共有し、特定のオプションを簡単にオーバーライドできます。

ゾーン節

ゾーン節はステートメント および ゾーンレコードで定義されます。

ゾーン宣言

各ゾーンは、zonesというリストの要素として宣言されます。

**'zones'**はプレイブックで定義する必要があり、_必須_です。

playbook.yml:

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

ゾーンのステートメントを定義する

ゾーンは、ゾーン名がメインキーであり、そのステートメントがキー:値のマッピングです。

• [ステートメント]:値
• typeは必須ステートメントです。
• force_file [ブーリアン]: Ansibleにレコードデータベースファイルを上書きさせます。ゾーンがDNSによって動的に生成される場合に便利です。 - スレーブゾーンの場合はfalse - それ以外の場合はtrue
• 一部のゾーンタイプには独自の必須ステートメントがあります。

playbook.yml:

zones:
  example.com: # ドメイン名
    type: master # 必須。 ゾーンの種類: master|slave|forward|stub
    recursion: "no" # このゾーンのグローバルオプション「recursion」をオーバーライドするステートメントです。
    ... # 等

ゾーンのステートメントのリストは**./tests/zone_statements.md**にあります。

ゾーンのレコードを定義する

ゾーンのレコードは、**'records'**というマッピングで定義されます。

このマッピング**'records'**は次の方法で宣言できます：

• **yamlfile**キーで指定されたYAMLファイル内で。
• ゾーンのマッピング内のマッピングとして。

注: YAMLファイルの内容はゾーン構成と組み合わされます: したがって、重複するレコードがある場合、ファイルの内容が優先されます.

playbook.yml:

zones:
  example.com:
    records:
      SOA: ...
      NS: ...
      ... # 等
    ... # 等
  test.tld:
    yamlfile: "./files/test.tld.yml"
    records:
      SOA: ...
      NS: ...
      A:
       localhost: 127.0.0.1
       test1: 9.8.7.6 # yamlfileによって上書きされます
    ... # 等

YAMLファイル内で、recordsはトップレベルのマッピングでなければなりません：

./files/test.tld.yml:

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

ゾーンにレコードを追加する

ゾーンレコードには異なるタイプがあり、records内でタイプによって宣言されます。

各レコードタイプは異なり、独自のYAML構造に従います。

manage-bindは以下のレコードをサポートしています。

• SOA
• NS
• A
• AAAA
• MX
• SRV
• PTR
• CNAME
• DNAME
• TXT
• TTLはゾーンのレコードに沿って宣言できます。

依存関係

なし。

例プレイブック

例の設定:

• あなたはexample.tld、example.com、example.orgゾーンを所有しています。
• 2つのネームサーバーがあります: dnserver1 (11.22.33.44) と dnserver2 (55.66.77.88)
• dnserver1はexample.tldのマスターで、example.comのスレーブです。
• dnserver2はexample.comのマスターで、example.tldのスレーブです。
• example.tldはDHCPサーバーによって動的に生成されています。

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}}"

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

dnserver2のexample.com.yml用のYAMLファイル:

---
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

テストフォルダに他の例もあります。

ライセンス

BSD