Ansible 角色: manage-bind 2.0

此角色被构建为一个抽象层，用于使用 YAML 语法配置 Bind 和创建 DNS 区域。

• 在 Debian/Ubuntu 服务器上安装和管理你的 bind9 服务器。
• 使用 YAML 语法/文件配置 Bind 选项、区域等。

要求

Ansible 2.4+

注意: 此角色需要对 Bind 服务器的 root 访问权限。

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 使用 子句声明继承机制以允许精确配置。

• 子句 是一个具有自己 声明 集合的类。
  • 它们可以有特定或公共的声明。
  • 定义在另一个子句内的子句将隐式继承其母类的公共声明。
• 声明 是子句的属性。
  • 它描述了服务器在如何执行某个任务时的行为，例如，何时、如何等。
  • 它可以显式或隐式定义。
• 一些继承规则：
• 选项 是包含所有其他选项的 顶层 子句。
• 区域 是 最低 子句。它不能有任何子类。它也包含 区域记录。
• 子句可以通过显式重新定义声明来覆盖其父类的声明，并将新值传递给其子类。

下面是这些规则的 ASCII 示例：

|##########|  
|  zone1   |  |#########|
|==========|  |  zone2  |
|statement1|  |=========|
|  =john   |  |         |
|##########|  |#########|
     /\            /\
     ||            ||
|#######################|   |##############|   |##############|
|         view1         |   |   zone3      |   |    zone4     |
|=======================|   |==============|   |              |
|  statement2=kangaroo  |   |statement1=bar|   |##############|
|#######################|   |##############|          /\
           /\                     /\                  ||
           ||                     ||                  ||
|#############################################################|
|                          选项                              |
|=============================================================|
|                       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

待办事项: views

定义声明时的_注意事项_ !

• 一些声明定义了复杂的映射，而其他声明只需要简单的值。为了以防万一，每个声明都有自己的模板进行自我文档化。
• manage-bind 使用 bind 的工具 named-checkconf 和 named-checkzone 来进行配置和区域验证。然而，这些工具仅限于 语法 和 轻微一致性 验证。此角色不提供高级验证方法。
• 通过引号转义特殊字符，例如 @。
• 一些声明要求使用 "yes|no" 字符串值：用引号转义 yes 和 no，因为 Ansible 将它们视为布尔值。

选项子句

注意: 该角色带有一些默认选项。

定义选项声明

调用 manage-bind 时，可以传递选项声明：

• 在外部 YAML 文件中声明 options_file。
  • 它必须包含名为 options 的声明映射。
• 在你的 playbook 中的名为 options 的映射内部。

注意: 第一种方法排除了第二种方法：如果你在 playbook 中声明了文件，角色将仅加载文件中的声明。

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 中定义并 _是强制性的_。

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 可以在区域记录中声明。

依赖项

无。

示例 Playbook

示例配置：

• 你拥有示例域 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 的 playbook：

---
- 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 的 playbook：

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