一、DNS相关简介

DNS(Domain Name System)是Internet的重要组成部分，它的核心是为IP地址提供一个更易记住的名字。Internet上的大部分服务都会用到DNS，例如：访问网站，发送邮件，登录软件系统，玩游戏，网络聊天等。浏览器通过域名访问网站的实际过程如下图所示：

DNS从1985年开始被使用。但是为IP地址提供一个更易记住的名字可以追溯到ARPANET（Internet前身）时代。最早的ARPANET网络通过一个hosts.txt文件管理地址和hostname的关系，用户需要DNS服务，就从一个ftp下载host.txt文件到本地。最开始的网络中也就几百台计算机，这种方法没什么问题。但是随着网络的增加，文件存储的方式不能满足规模的要求。为了适应日益增长的网络规模，DNS被提出。不过host.txt文件被保留下来了，这就是我们日常熟悉的hosts文件，Linux在/etc/hosts，Windows在 C:/Windows/System32/Drivers/etc/hosts。在现代的计算机中，当请求Domain name（域名）解析时，还是先查找计算机的hosts文件，如果hosts文件没有相应的记录，才会触发DNS请求。
作为host.txt的改进方案，DNS本质上是一个Internet上的域名和IP地址相互映射的分布式数据库。数据库以树形结构存在，如下图所示：

树中每个节点都有自己的标签，根节点有个特殊的标签“.”。树结构中一条路径中所有节点的标签构成了DNS域名。这与Unix文件系统路径类似，区别在于Unix文件系统路径将根节点放在前面，而DNS域名反过来了，将根节点放在了最后。例如，图中host完整的域名是：“eos.cs.berkeley.edu.”，越靠近根节点ROOT的标签在右，越靠近服务器的标签在左。注意，一个完整的域名，是以根节点标签“.”结束。

1.1 DNS zone子树

Zone是DNS树中的子树。Zone本身可以划分成更小的Zone。前面说过DNS的结构与Unix文件系统类似，相应的Zone与Unix文件系统中的磁盘分区类似。我们无法从DNS域名看出当前域名在哪个Zone，就像很难根据Unix文件路径，看出当前目录在哪个磁盘分区一样。在DNS树形结构中，Zone可以用下图来描述。

DNS Zone通常由一个或者多个DNS server管理，一个DNS server也可以管理多个Zone。如下图所示：

DNS与传统的hosts.txt方式的区别在于，通过Zone的划分，将庞大的DNS记录划分成了一个个小块，从而解决数据庞大，不易管理的问题。所以DNS Zone本质上是DNS记录的集合。DNS记录被称为Resource Record（RR）。RR有很多种类型。常见的有以下几种：

• A：域名与IPv4地址的对应
• AAAA：域名与IPv6地址的对应
• PTR：域名与IP地址的对应，区别是A或者AAAA是通过域名获得IP地址，PTR可以通过IP地址获得域名
• CNAME：记录一个域名与另一个域名的对应关系
• NS：为当前Zone指定一个DNS server
• SOA：包含Zone的一些信息，例如首要的DNS server，管理员邮箱地址，更新时间等

1.2 DNS工作过程

这部分介绍DNS工作过程，首先看一下日常中经常接触的DNS server。DNS server大体上可以分为两类。
* 一类是管理DNS zone的DNS server，称为Authoritative DNS server。这些DNS Server只掌握了一个或者多个DNS zone的信息，不能为我们提供整个互联网的DNS信息。
* 另一类是Cache DNS server。这类DNS server不管理DNS zone，但是连接Authoritative DNS server，并且缓存从Authoritative DNS Server获取的信息。最典型的就是谷歌的8.8.8.8。
假设我的电脑配置的DNS server是8.8.8.8，我需要访问www.zhihu.com，首先我的电脑要获取www.zhihu.com的IP地址，需要经过下面所示的步骤：

1.  向8.8.8.8请求获取www.zhihu.com的IP地址。如果8.8.8.8包含了www.zhihu.com的IP地址记录，则直接跳到步骤8。
2.  8.8.8.8所在的Cache DNS server并没有www.zhihu.com的记录，所以它向Authoritative DNS server请求数据。首先发往Root DNS server，这是全球共有的13个逻辑服务器，每一个是由一个集群构成。
3.  Root DNS server实际上没有www.zhihu.com的记录，也不可能有，因为全球的DNS记录不可能集中在一起，这在性能上是不能接受的，并且这样就跟之前的hosts.txt文件也没有区别了。不过由于需要解析的是www.zhihu.com，Root DNS server知道如何到达“.com”的DNS Server，也就是TLD（Top-Level Domain）DNS server。因此将TLD DNS server的信息也就是“.com”的DNS server地址发送给8.8.8.8。
4.  8.8.8.8收到了TLD DNS server的地址之后，继续向“.com” 的DNS server请求数据。
5.  TLD DNS server 仍然没有www.zhihu.com的信息，但是TLD DNS Server知道zhihu.com的DNS server，于是TLD DNS Server将zhihu.com的DNS server地址发送给8.8.8.8。
6.  8.8.8.8收到了DNS server地址之后，继续向zhihu.com的DNS server请求数据。
7.  管理zhihu.com的Authoritative DNS server有www.zhihu.com的记录，于是将对应的IP地址发送给8.8.8.8。
8.  8.8.8.8拿到了www.zhihu.com对应的IP地址，首先记录在本地缓存，这样下次不用再走一遍234567，接着将IP地址发送给请求主机。
9.  主机拿到IP地址之后，向IP地址所在的Server发送实际的HTTP请求。

这里的1-8实际上就是第一幅图中的步骤1，2的详细版。
好了，DNS的工作过程大概如此，接下来看一下，如何为OpenStack中的虚机提供DNS服务。OpenStack中的虚机DNS服务，可以分为两个部分：一个是Internal DNS service，另一个是External DNS service。Internal DNS service由Neutron DHCP Service完成，External DNS service由OpenStack Designate项目实现。

1.3 OpenStack Neutron DHCP服务

Neutron DHCP Service默认是由dnsmasq进程实现，dnsmasq同时提供了DNS服务和DHCP服务。它的DHCP服务在OpenStack Neutron中应用广泛，相应的，其提供的DNS服务知名度不那么高。OpenStack Neutron DHCP service是以tenant network为单位提供服务的，也就是说每个tenant network都有独立的DHCP service，独立的dnsmasq进程。那么相应的，Neutron DHCP service提供的DNS service也只能在tenant network范围内。默认情况下，DHCP service会通过DHCP协议，将dnsmasq的管理端口地址（也就是DHCP Server地址）作为虚机的DNS Server写入虚机。在每个dnsmasq的配置文件中（存放于state_path中），会静态的记录虚机的hostname与IP地址的对应。这样，当虚机请求DNS解析的时候，dnsmasq可以从静态的配置文件中获取对应的解析记录，并回送给虚机。

相应的配置项有：