关于 Designate，你不可不知的事儿

DNS 简介

在介绍 Designate 之前，我们需要对 DNS 以及其中的概念有一定的了解。

DNS 的全称是 Domain Name System，DNS 负责主机名字之间和互联网络地址之间的映射，在我们上网的时候，一般都会使用主机名而不是 IP 地址，因为主机名更容易记忆，但是对于计算机，使用数字（IP 地址）则更为方便。DNS 能够帮助我们将主机名转换成计算机更容易识别的 IP 地址。从而完成主机之前的通信。因此在进行主机名转换 IP 地址之前，首先需要知道 DNS 服务器的 IP 地址，常见的 DNS 服务器，比如114 DNS，这应该是用户数量数一数二的公共 DNS 了， IP 地址为 114.114.114.114，或 114.114.115.115； CNNIC SDNS，来自官方 CNNIC 的公共 DNS ，IP 地址为 1.2.4.8，或 210.2.4.8 没使用过也没敢用……Google DNS，曾经最火最热的一款公共 DNS 服务器，IP 地址为 8.8.8.8，或 8.8.4.4。

DNS 结构

DNS 是一个层级的分布式的数据库，以 C/S 架构工作，将域名和 IP 地址的对应关系记录下来，从而为客户端提供域名解析的服务。 DNS 数据库以层级的树状结构组织，最顶级的服务器被称为 “ 根 ”，以 . 表示，它是所有子树的根。根（root）将自己划分为多个子域（subdomain），这些子域包括 com，net，org，gov 等，这些子域被称为顶级域（Top Level Domain，TDL）。再进一步，各个顶级域名又可以将自己划分为多个子域，子域还可以在划分子域，最后树的叶子节点，就是某个域的主机名，整个结构图如下所示：

NS 服务器类型

主域名服务器：负责维护这个区域的所有域名信息，是特定的所有信息的权威信息源。也是说，主域名服务器内所存储的是该区域的正本数据，系统管理员可以对它进行修改。

辅助域名服务器：当主域名服务器出现故障、关闭或负载过重时，辅助域名服务器作为备份服务提供域名解析服务。辅助域名服务器中的区域文件内的数据是从另外一台域名服务器复制过来的，并不是直接输入的，也是说这个区域文件只是一份副本，这里的数据是无法修改的。

缓存域名服务器：可运行域名服务器软件但没有域名数据库。它从某个远程服务器取得每次域名服务器查询的回答，一旦获取一个答案，将它放在高速缓存中，以后查询相同的信息时用它予以回答。缓存域名服务器不是权威性服务器，因为提供的所有信息都是间接信息。

转发域名服务器：负责所有非本地域名的本地查询。转发域名服务器接到查询请求时，在其缓存中查找，如找不到把请求依次转发到指定的域名服务器，直到查询到结果为止，否则返回无法映射的结果。

DNS 资源记录类型

起始授权结构（SOA）: 用于一个区域的开始，SOA 记录后的所有信息均是用于控制这个区域的，每个区域数据库文件都必须包含一个 SOA 记录，并且必须是其中的第一个资源记录，用以标识 DNS 服务器管理的起始位置，SOA 说明能解析这个区域的 DNS 服务器中哪个是主服务器

别名（CNAME）：CNAME 记录，也是别名记录，用于定义A记录的别名。

邮件交换器（MX）：邮件交换器记录，用于告知邮件服务器进程将邮件发送到指定的另一台邮件服务器。（该服务器知道如何将邮件传送到最终目的地）。

名称服务器（NS）：NS记录，用于标识区域的DNS服务器，即是说负责此DNS区域的权威名称服务器，用哪一台DNS服务器来解析该区域。一个区域有可能有多条ns记录，例如zz.com有可能有一个主服务器和多个辅助服务器。

反向解析(PRT)：IP 地址到 DNS 名称的映射，用于反向解析。

常用的 DNS 客户端

在 Linux 下，dig 的基本使用格式为：

比如：

通过使用 +short 可以精简 dig 的输出，比如：

具体的使用方法本文不在赘述。

Designate 项目介绍

在 OpenStack 中，通过 Designate 提供 DNSaaS 功能，其目标就是要赋予 OpenStack 提供这种云域名系统的能力，云服务商可以使用 Designate 就能够很容易建造一个云域名管理系统来托管租户的公有域名。

Designate 整体架构

注：本文介绍的 Designate 基于 Mitaka 版。

Designate 的整体架构如下：

Designate API

Designate-api 提供了标准的 REST API 接口，接收 HTTP 请求，通过 Keystone 验证身份信息，通过 AMQP 将请求发送到 Designate Central。虽然 designate-api 拥有处理 HTTPS 请求的能力，但它需要在其他地方终结 HTTPS 请求，比如将 NGINX 放在 designate-api 之前，或者让外部的 Load Balancers 去终结 HTTPS 请求。

Designate Central

Designate-central 通过 MQ 接收来自 Designate-api 的 RPC 请求并操作存储的数据，数据通过插件的形式提供，典型的比如 SQLAlchemy，也可以是 MongoDB 等。

Designate MiniDNS

Designate-mdns 服务发送 DNS 通告以及回答 AXFR（在 RFC 5936 中有关于 AXFR 的详细说明） 请求。通过这样的设计，可以很好的将任意支持标准通信的 DNS 服务器联合起来一起工作。Designate-mdns 也会封装各种符合 DNS 协议的报文进行传输，比如，SOA 的发送。

Designate Pool Manager

Designate-pool-manager 管理 DNS 服务器的状态，通过它可以知道 Designate 管理的后端（包括 PowerDNS、BIND9 等等）。通过 pool manager 也可以将这些服务器划分成不同的 “ pools ”，这样一来，Designate 里的 zones 可以被不同的后端 DNS 服务器解析。当然，Pool manager 也需要将后端 DNS 服务器和 Designate 数据库保持同步。

Designate Sink

Designate-sink 是可选服务，它用来监听来自 Nova 或者 Neutron 事件，比如虚拟机的创建等。这些事件可以触发 DNS 记录的增加或者删除。

DNS Backend

DNS 服务器的后端实现，Designate 支持多种后端实现，比如 PowerDNS，BIND，NSD，DynECT 等。类似于在 DHCP Agent 中的 Dnsmasq。

安装 BIND

这次 Designate 使用的后端 DNS 服务器是 BIND，因此在安装 Designate 之前，需要首先安装 BIND。

BIND 软件包在 bind-utils 中，通过 yum 安装完成后，进行 BIND 的配置。首先在 /etc/named.conf 中的 options 中添加如下内容：

allow-new-zones yes 允许在 BIND 运行期间创建 zone

request-ixfr no 域维护方式为全量传输。DNS中有两种域维护手段，一种是全量传输AXFR(full zone transfer)，另一种是增量传输IXFR(incremental zone transfer)。全量传输时，从域名服务器从主域名服务器上请求zone文件，poll的时间间隔由SOA记录中的refresh标签定义。传递非常大的zone文件是非常耗资源的（时间、带宽等），尤其是只有zone中的一个记录改变的时候，没有必要传递整个zone文件，增量传输是允许主域名服务器和从域名服务器之间只传输那些改变的记录。

listen-on port 53 { 127.0.0.1; }; 服务监听的 IP 地址和端口，需要注意的是 IP 地址后面需要 ； 结尾。

recursion no : 不允许递归查询

allow-query : 只允许来自本地的 DNS 查询。

接下来配置 RNDC。

在计算节点上需要配置 rndc，rndc（Remote Name Domain Controllerr）是一个远程管理 bind 的工具，通过这个工具可以在本地或者远程了解当前服务器的运行状况，也可以对服务器进行关闭、重载、刷新缓存、增加删除 zone 等操作。 使用 rndc 可以在不停止 DNS 服务器工作的情况进行数据的更新，使修改后的配置文件生效。在实际情况下，DNS 服务器是非常繁忙的，任何短时间的停顿都会给用户的使用带来影响。因此，使用rndc工具可以使 DNS 服务器更好地为用户提供服务。在使用 rndc 管理 bind 前需要使用rndc生成一对密钥文件，一半保存于 rndc 的配置文件中，另一半保存于 bind 主配置文件中。rndc 的配置文件为/etc/rndc.conf，在 CentOS 或者 RHEL 中，rndc 的密钥保存在 /etc/rndc.key 文件中。rndc 默认监听在 953 号端口（TCP），其实在 bind9 中 rndc 默认就是可以使用，不需要配置密钥文件。

rndc 与 DNS 服务器实行连接时，需要通过数字证书进行认证，而不是传统的用户名/密码方式。在当前版本下，rndc 和 named 都只支持 HMAC-MD5 认证算法，在通信两端使用预共享密钥。在当前版本的 rndc 和 named 中，唯一支持的认证算法是 HMAC-MD5，在连接的两端使用共享密钥。它为命令请求和名字服务器的响应提供 TSIG类型的认证。所有经由通道发送的命令都必须被一个服务器所知道的 key_id 签名。为了生成双方都认可的密钥，可以使用rndc-confgen命令产生密钥和相应的配置，再把这些配置分别放入 named.conf 和 rndc 的配置文件 rndc.conf 中。

创建 rndc 密钥文件：

将该密钥文件添加到 named.conf 中：

在本地也需配置 rndc ( /etc/rndc.conf )：

配置完成后，通过如下命令检查 named.conf 中是否有语法错误：

确认无误后，重启 named 服务，完成 BIND 服务器的安装与配置。

Designate 安装安装 designate 软件包

初始化数据库

配置 Designate

首先在 designate.conf 中配置认证相关选项：

接下来配置 keystone 相关：

enable worker 模式：

配置数据库连接选项：

完成数据库的建表初始化：

启动 designate-api 服务以及设置开机启动

在 api 启动无误后，启动其余的 designate 服务，包括 designate-mdns、designate-pool-manger、designate-central 即可。

验证 Designate 是否正常工作创建 DNS server

创建 DNS domain

创建 DNS record

通过 dig 验证

以上就是关于 Designate 的安装、配置和验证的全部过程。总的来说，由于在 Designate 的配置过程中使用到了很多关于 DNS 的基础知识以及相关概念，对于没有接触过 DNS 的管理员来说，配置和 troubleshooting Designate 存在着一些难度。