柴少的官方网站-DNS基本知识及搭建(一）

2017年06月05日 14:51:13

DNS基本知识及搭建(一）

DNS是什么大家已经很清楚了，就不多做累述了。

bind了解学习：https://www.isc.org/bind/

学习文档: https://bind9.readthedocs.io/en/latest/index.html

DNS的版本变更说明：https://kb.isc.org/docs/aa-01310

一、DNS和BIND了解(官网翻译了解可直接忽略)

1.1 DNS基本知识

DNS命名系统被组织为由多个级别组成的树结构，因此自然会创建分布式系统。给树上的每个节点都有一个标签，该标签定义其Authority(权威)的域area or zone。树上的最高节点是Root Domain(根域)。它在下一个级别上委派了域，该级别通常称为Top-Level Domains(顶级域)缩写为TLDS。他们反过来委派Second-Level Domains(第二级域)缩写为SLDS，依此类推。顶级域（TLDS）包括一个特殊的TLD组，称为 Country Code Top-Level Domains(国家代码顶级域)缩写为CCTLD，其中每个国家都被分配了ISO 3166的独特两字符国家代码作为其域名。

域名系统由ICANN（https://www.icann.org）控制（501C非营利实体）；他们目前的政策是，任何由三个或更多字符组成的新TLD都可以由任何一组商业赞助商提出，如果符合ICANN的标准，则将添加到TLD中。

delegation(委托)和authority(权威)的概念如下图DNS名称空间中的委托和权威所示，流向DNS tree (DNS层次结构）：

域是树中节点的标签。一个域名唯一地标识了DNS树中的任何节点，并通过组合所有域标签（每个域在其父母的区域或权威的域内都是唯一的），并用一个点分隔每个组件，直至根域。根有一个独特的标签“.”(dot），通常在将其写入域名时被省略，但是当它以完全合格的域名（FQDN）写入时，DOT必须存在。因此：

example.com     # domain name
example.com.    # FQDN

1.1.1 Authority and Delegation

每个域（节点）已从其母域中委派了权限。授权的权限包括特定的责任，以确保其代表的每个域名在其区域或权威域内都有一个唯一的名称或标签，并保留其授权域的权威列表。该职责进一步包括运营两个（或更多）名称服务器（可以签给第三方）的运营要求，该服务器将包含其在区域文件中其权限区域内所有域标签的权威数据。同样，树结构可确保DNS名称空间自然分布。

下图DNS名称空间中的权威名称服务器说明了每个级别和DNS名称空间中的每个域都存在权威的名称服务器：

Root Servers（根服务器）: 根服务器是DNS权威基础架构的关键部分。有13个根服务器（a.root-server.net to M.Root-servers.net）。数字13历史上是基于可以包装成512字节UDP消息的最大名称和IPv4数据的数量，而不是对某些文化视为不幸的数字的不良亲和力。 512字节UDP数据限制不再是限制因素，所有根服务器现在都支持IPv4和IPv6。此外，几乎所有的根服务器都使用Anycast，现在在全球范围内提供服务的300多个实例（请参阅https://www.root-servers.org）。根服务器是DNS中所有名称resolution的起点。

Name Resolution（named解析）：下图为权威名称服务器和Name Resolution的示意图

最终用户应用程序（例如浏览器(1))需要解析诸如www.example.com之类的名称时，将内部系统调用称为最小功能解析实体，称为stub Resolver(2）。存根解析器（使用存储的IP地址）联系resolver（缓存名称服务器或full-service resolver)(3），该解析器又与所有必要的权威名称服务器（4、5和6）contacts以提供answer,然后它返回给用户（2，1）。为了提高性能，所有resolvers（包括大多数stub resolvers）缓存（存储）的结果，以便从解析器的缓存中获取相同数据的请求，从而消除了重复名称resources流程并使用耗时资源的需要。the stub resolver,resolver,和authoritative name servers（权威名称服务器）之间的所有通信都使用DNS协议的查询和响应消息对。

DNS Protocol and Queries（DNS协议和查询）：

DNS查询使用保留端口53上的UDP协议（但是TCP和TLS都可以选择在网络的某些部分中使用）。上图显示了根据DNS查询和响应表示的名称解析的过程。stub resolver将递归查询消息（查询部分中的必需域名)(2)发送给resolver。recursive query(递归查询)只需要求解析器找到完整的答案即可。stub Resolver只会发送递归查询，并且始终需要返回一个解析。DNS层次结构始终从根服务器开始并working down。DNS层次结构中没有"UP"的概念。显然，如果解析器已经缓存了.com权威名称服务器的列表，并且用户的递归查询问题包含一个域名以.com结尾，则可以省略对根服务器的访问。但是，这仅仅是缓存的工件（在本例中是性能优势），并且不会改变DNS层次结构中自上而下的访问概念。

DNS Security Overview(DNS安全概述)：

DNS是一个通信协议。所有通信协议都可能容易受到颠覆和窃听的影响。对于用户而言，重要的是审核他们在运营环境中的各种威胁并实施适当的解决方案。 Bind 9是DNS协议的特定实现，提供了一组广泛的安全功能。从历史上看，DNS数据被认为是公共的，并且主要涉及确保DNS数据的完整性。 DNS数据隐私越来越被视为总体安全性的重要方面，尤其是TLS的DNS。下面显示了通用DNS网络，其次是文本说明。

以下注释是指上图中的编号元素：

1. 可以使用多种系统管理技术和方法来保护Bind 9的本地环境，包括文件权限，在jail(监狱)中运行9和使用访问控制列表。

2. 远程名称守护程序控制（RNDC）程序允许系统管理员控制名称服务器的操作。大多数BIND9软件包或端口都通过局部（环回地址）安全性预配置了预配置。如果从远程主机调用RNDC，则需要进一步的配置。 Nsupdate工具使用动态DNS（DDN）功能，并允许用户动态更改区域文件的内容。可以使用named.conf语句或使用TSIG或SIG（0）加密方法来控制NSUPDATE访问和安全性。显然，如果用于RNDC或DDN的远程主机完全位于用户控制下的网络中，则安全威胁可能被认为是不存在的。因此，任何实施要求都取决于网站的安全策略。

3. Zone从一个或多个二级权威名称服务器跨公共网络transfer会带来风险。可以使用named.conf语句，TSIG加密方法或TLS保护zone transfer。显然，如果次要权威名称服务器都完全位于用户控制下的网络中，则安全威胁可能被认为是不存在的。任何实施要求再次取决于网站的安全策略。

4. 如果权威名称服务器的操作员（primary or secondary）希望确保DNS对用户启动的有关他们负责的区域的响应仅来自其服务器，则用户收到的数据与发送的那样，non-existent names是真实的，那么DNSSEC是唯一的解决方案。 DNSSEC需要对权威名称服务器和任何访问这些服务器的解析器的配置和操作更改。

5. 典型的Internet连接最终用户设备（PC，笔记本电脑，甚至手机）具有stub resolver，或者通过DNS代理运行。 stub resolver需要区域或全方位服务解析器的服务来完全回答用户查询。大多数PC和笔记本电脑上的stub resolver通常具有提高性能的缓存能力。目前，没有实现DNSSEC的标准stub resolver或代理DNS工具。 BIND9可以配置为在支持的Linux或Unix平台上提供此类功能。可以将TLS上的DNS配置为验证stub resolver和区域（或全方位服务）解析器之间数据的完整性。但是，除非解析器和权威名称服务器实现DNSSEC，否则无法保证端到端完整性（从权威名称服务器到stub resolver）。

1.1.2 Resource Requirements（资源需求）

CPU要求：

BIND 9是完全多线程的，可以完全利用多处理器系统来进行需要的安装。CPU好点以处理许多动态更新和DNSSEC签名区域，每秒提供数千个查询。

内存要求：

服务器内存必须足以容纳缓存和从磁盘加载的区域。 Max-Cache-Size选项可以限制缓存使用的内存量，但要降低缓存命中率并引起更多的DNS流量。有足够的内存将所有区域和缓存数据加载到内存仍然是一个好习惯。

支持的平台：

在ISC知识库中可以找到跨不同平台的9个版本的当前支持状态：https://kb.isc.org/docs/supported-platforms

1.1.3 Named服务器的操作

管理工具：

named-checkconf：检查named.conf文件的语法。插一嘴,我们很多时候启动BIND可能是chroot模式,比如:named -u named -c /etc/named.conf -t /opt/soft/bind/chroot/,那么多所有的配置文件其实是在/opt/soft/bind/chroot/下面的,也就是named.conf其实是在/opt/soft/bind/chroot/etc/named.conf,这就带来一个问题,你在执行检查的时候会提示你：open: /etc/view/xxxx.conf: file not found,这种勤快正常的语法应该是：named-checkconf -t /opt/soft/bind/chroot

named-checkzone：检查zone文件

named-compilezone：该工具类似于named-checkzone，但始终将zone内容转储到指定的文件（通常以不同的格式）。

rndc:远程名称守护程序控制（RNDC）程序允许系统管理员控制名称服务器的操作。RNDC需要一个配置文件，因为与服务器的所有通信都使用依赖共享秘钥的数字签名进行身份验证，并且除了配置文件外，没有其他方法可以提供该秘钥。配置文件的格式类似于named.conf的格式，但仅限于四个语句： options, key, server, and include语句,示例最小配置文件如下：

key rndc_key {
     algorithm "hmac-sha256";
     secret
       "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";};options {
     default-server 127.0.0.1;
     default-key    rndc_key;};

该文件，如果已安装为/usr/local/etc/rndc.conf，则允许命令：rndc reload

要连接到127.0.0.1端口953并使名称服务器重新加载，如果本地计算机上的名称服务器正在运行以下控制语句：

controls {
    inet 127.0.0.1
        allow { localhost; } keys { rndc_key; };};

它具有rndc_key.的相同关键语句。运行rndc-confgen程序方便地创建rndc.conf文件，还显示添加到named.conf所需的相应控件语句。另外，可以运行rndc -confgen -a来设置一个rndc.key文件，而不修改naster.conf。

rndc的具体操作可以看http://blog.51niux.com/?id=125

信号：

某些UNIX信号导致名称服务器采取特定操作，如下表所述。这些信号可以使用Kill命令发送。

SIGHUP：导致服务器读取名称.conf并重新加载数据库。

SIGTERM：导致服务器清理并退出。

SIGINT：导致服务器清理并退出。

好吧我们如果平滑重启named怎么让其加载配置文件呢？service named reload=>其实就是执行rndc reload或者kill -HUP named进程号

关闭呢？service named stop =>其实就是执行rndc stop或者kill -TERM named进程号

插件：

插件是一种使用动态加载库的命名功能的机制。目前，仅支持“query plugins”；这些修改名称服务器查询逻辑。bind中当前包含的唯一插件是filter-aaaa.so。插件已配置为nuper.conf中的插件语句：

plugin query "library.so" {
    parameters};

可以指定多个插件语句，以加载同一插件的不同插件或多个实例。参数作为不透明字符串传递给插件的初始化例程。配置语法取决于模块的不同。

1.2 Configurations and Zone Files(配置与区域文件)

1.2.1 Introduction(介绍)

bind 9使用一个名为named.conf的单个配置文件。 named.conf通常位于/etc/nameb或/usr/local/etc/nameb中。如果RNDC在本地使用（在与BIND 9的同一主机上使用），则可能存在一个附加的文件RNDC.conf，尽管RNDC在没有此文件的情况下运行。如果RNDC是从远程主机运行的，则必须存在rndc.conf文件，因为它定义了链接特征和属性。

named.conf Base File：

该文件说明了用于named.conf的典型格式和布局样式。

options {
  //所有相对路径都将此目录用作基础 
  directory "/var";
  //如果不显示真实的版本
  version "not currently available";
};
logging {
  channel example_log {
    //使用相对路径名和目录语句扩展到/var/log/named/example.log,然后就是日志大于250k就轮询切割日志,保留3个版本的日志
    file "log/named/example.log" versions 3 size 250k;
    //仅记录登录信息和UP消息 - 所有其他丢弃
    severity info;
  };
  category default {
        example_log;
  };
};

example.com base zone file:

以下是域示例的完整区域文件，该文件说明了许多常见功能。

; base zone file for example.com 
$TTL 2d    ; default TTL for zone
$ORIGIN example.com. ; base domain-name
; 授权开始RR定义区域的关键特征（domain）
@         IN      SOA   ns1.example.com. hostmaster.example.com. ( 
                                2003080800 ; serial number 
                                12h        ; refresh                               
                                15m        ; update retry                             
                                3w         ; expiry                             
                                2h         ; minimum                           
                                )
; name server的RR的域名
          IN      NS      ns1.example.com.
;第二个名称服务器在此区域（域）外部
          IN      NS      ns2.example.net.    
;该区域（域）的邮件服务器RRS
       3w IN      MX  10  mail.example.com.         
;第二封邮件服务器位于区域（域）的外部
          IN      MX  20  mail.example.net.
;域主机包括上面定义的NS和MX记录，以及示例所需的任何其他记录。
ns1        IN      A       192.168.254.2
mail       IN      A       192.168.254.4
joe        IN      A       192.168.254.6
www        IN      A       192.168.254.7
;定义一个ftp的别名
ftp        IN      CNAME   ftp.example.net.

这种类型的区域文件通常称为forward-mapped的区域文件，因为它将域名映射到其他值，而reverse-mapped(反向映射)的区域文件将IP地址映射到域名。

1.2.2 Authoritative Name Servers(权威名称服务器)

这些为他们支持的区域提供了对用户查询的权威答案,权威的名称服务器可以支持主要和次要区域的任何组合。

术语primary and secondary并不意味着任何访问优先级。解析器（提供对用户查询的完整答案的名称服务器）不知道（也找不到）权威答案是否来自主名称服务器或辅助名称服务器。取而代之的是，解析器使用该区域的权威服务器列表（必须至少有两个），并维护往返时间（RTT） - 响应查询的时间 - 响应查询的时间 - 列表中的每个服务器。解析器使用最低值服务器（最快）作为该区域的首选服务器，并继续这样做，直到其RTT变得高于其列表中的下一个最慢的服务器，此时将成为首选服务器。出于向后兼容的原因，BIND 9视为 "primary” and “master”作为同义词，以及“secondary” and “slave.”

下图显示了主要名称服务器和次要名称服务器之间的关系。下面的文本详细说明了权威性主和次要名称服务器数据同步过程。

权威的主名服务器始终从（1）本地或网络文件中加载（或重新加载）其区域文件。
权威的辅助名称服务器始终通过区域传输操作从主体中加载其区域数据。区域传输可以使用AXFR（完整的区域传输）或IXFR（增量区域传输），但前提是主名和辅助服务器支持该服务。区域传输过程（AXFR或IXFR）如下：

a. 区域的次要名称服务器定期读取（3和4）SOA RR。间隔由权威开始（SOA）RR的刷新参数定义。
b. secondary比较了从primary区域数据的SOA RR中收到的SOA RR的序列号参数。
c. 如果接收到的序列号在算术上比当前的序列号更大（更高），则使用AXFR或IXFR（取决于主要和二级配置），使用TCP在端口53（6）上启动区域传输（5）。

3.SOA RR的通常推荐区域刷新时间（次级读取或轮询的时间间隔是SOA RR的主要时间）是减少traffic loads的小时倍数。因此，最差的区域变化传播可能需要延长。

4.optional NOTIFY 自动配置；每当主加载或重新加载区域时，它将通知消息发送给已配置的 secondary (or secondaries) ，并且可以选择配置，以使用另外的notify语句将通知消息发送到其他主机。通知消息简单地表明了次要的主体已加载或重新加载区域。收到通知消息后，次要响应表明它已收到通知并立即读取主要的SOA RR（如上第2 a节所述）。如果区域文件已更改，则实际上是立即传播的。

1.2.3 Resolver (Caching Name Servers)

解析器处理递归用户查询并提供完整的答案；也就是说，他们向DNS层次结构发出一个或多个迭代查询。在获得完整的答案（或错误）后，解析器将答案传递给了用户，并将其放置在缓存中。随后的用户请求将从解析器的缓存中回答相同的查询，直到缓存答案的TTL已过期，何时将其从缓存中冲洗；请求相同信息的下一个用户查询会导致DNS层次结构的一系列新查询。

解析器经常被各种各样的名称引用，包括caching name servers, recursive name servers, forwarding resolvers, area resolvers, and full-service resolvers(缓存名称服务器，递归名称服务器，转发解析器，区域解析器和全方位服务解析器)。

下图显示了Resolver and Forwarding Resolver如何在典型的网络环境中运行：

最终用户系统均以本地stub resolver作为标准功能分发。如今，大多数stub resolver还提供本地缓存服务，以加快用户响应时间。
当存根解析器从本地程序（例如浏览器）接收到名称的请求，并且答案不在其本地缓存中时，它将递归用户查询（1）发送到本地配置的解析器（5），可能在其缓存中可用答案。如果没有，它会向DNS层次结构发出迭代查询（2）以获取答案。
或者，可以将用户查询发送到转发解析器（4）。乍一看，转发解析器看起来毫无意义，因为它们似乎是一个简单的pass-though - 尽管像存根的解析器一样，需要提供全方位服务的解析器（5）。但是，由于以下原因，转发解析器可能是网络非常有力的补充：

a.成本和性能。 转发解析器（4）处的每个递归用户查询（1）会产生两条消息 - 查询及其答案。 解析器（5）可能必须发布三，四或更多查询对（2）才能获得所需的答案。 流量大大降低，增加性能或降低成本（如果链接征收）。 此外，由于通常在多个主机上共享转发解析器，因此其缓存更有可能包含答案，从而再次改善了用户性能。
b.网络维护。 可以使用转发解析器（4）来通过提供一个点来管理对远程名称服务器的更改，而不是必须更新所有主机来减轻本地管理的负担。 因此，可以将特定网络部分或区域中的所有主机配置为指向转发解析器，可以将其配置为根据需要流式DNS流量流，并随着时间的推移而更改。
c.Sanitizing Traffic。 尤其是在较大的专用网络中，使用转发解析器结构流式传输DNS流量可能是明智的。 例如，可以配置转发解析器（4），以处理所有域内流量（相对安全），并将所有外部流量转发到hardened resolver（5）。
d.Stealth Networks（隐形网络）。 转发解析器广泛用于隐身或拆分网络。

4.可以将转发解析器（4）配置为将所有流量转发到解析器（5），或者仅转发选择性流量（5），同时直接解决其他流量（3）。

1.2.4 Zone File

Resource Records(资源记录)：

域名标识DNS树名称空间中的节点。每个节点都有一组资源信息，可能是空的。与特定名称关联的一组资源信息集由单独的RR组成。集合中的RR顺序并不重要，不需要通过名称服务器，解析器或DNS的其他部分保留。但是，允许对多个RR进行排序以进行优化：例如，指定首先尝试特定的附近服务器。请参阅sort -list语句和RRSET排序。资源记录的组成部分是：

owner name：找到RR的域名。
type：编码的16-bit值指定资源记录的类型。
TTL：RR的时间。该字段是一个以秒为单位的32位整数，主要是解析器缓存RR时使用的。 TTL描述了RR在应丢弃之前可以缓存多长时间。
class: 编码的16-bit 值，标识协议家族或协议实例。
RDATA: 资源数据。数据的格式是类型，有时是类型的。
以下资源记录类别当前在DNS中有效：
IN:互联网。当今唯一使用的唯一广泛的类别。
CH: Chaosnet是1970年代中期在MIT创建的LAN协议。它很少用于其历史目的，但被重复用于BIND的内置服务器信息区域，例如version.bind。
HS: Hesiod，由麻省理工学院项目雅典娜（Athena）开发的信息服务。它用于共享有关各种系统数据库的信息，例如用户，组，打印机等。

TTL字段是可以将RR保存在缓存中的时间限制。如果预计会发生变化，则可以在更改之前减少TTL，然后在更改后增加到其以前的值。RRS的RDATA部分中的数据作为二进制字符串和域名的组合。域名经常用作DNS中其他数据的“pointers”。

Textual Expression of RRs(RRs的文本表述）

RR在DNS协议的数据包中以二进制形式表示，通常在name server or resolver中存储时以高度编码的形式表示。大多数RR都在单行上显示，尽管使用括号可以使用延续线。该行的开始赋予RR的所有者。如果一条线以空白开头，则假定所有者与以前的RR相同。空白行通常包括在内。

在所有者列出了RR的TTL，type和class。类和类型使用上面定义的助记符，而TTL是类型字段之前的整数。为了避免解析中的歧义，类型和类助记符是不相交的，TTL是整数，并且类型助记符始终是最后的。为了清楚起见，在class和TTL值中通常省略了示例。

RR的资源数据或RDATA部分使用数据的典型表示知识给出。

ISI.EDU.	MX	10 VENERA.ISI.EDU.
	MX	10 VAXA.ISI.EDU
VENERA.ISI.EDU	A	128.9.0.32
	A	10.1.0.52
VAXA.ISI.EDU	A	10.2.0.27
	A	128.9.0.33

MX RRS具有一个RDATA部分，该部分由16位编号组成，其次是域名。地址RRS使用标准IP地址格式包含32位Internet地址。上面的示例显示了六个RR，在三个域名中的每个名称中有两个RR。下面另一个可能的示例：

XX.LCS.MIT.EDU.	IN A	10.0.0.44
	CH A	MIT.EDU. 2420

这显示了xx.lcs.mit.edu的两个地址，不同的class。

Discussion of MX Records(MX记录的讨论)

MX记录用于控制电子邮件的传递。记录中指定的数据是优先级和域名。优先级控制着尝试发送电子邮件发送的顺序，首先是最低数字。如果两个优先级相同，则随机选择服务器。如果没有给定优先级的服务器响应，邮件传输代理将降回第二大优先级。优先数字没有任何绝对含义；它们仅与该域名的其他MX记录相关。给出的域名是邮件传递的机器。它必须具有关联的地址记录（A或AAAA）； CNAME还不够充分。

对于给定的域，如果同时存在CNAME记录和MX记录，则MX记录是错误的，并且被忽略。取而代之的是，将邮件传递到由CNAME指向的MX记录中指定的服务器。例如：

example.com.	IN	MX	10	mail.example.com.
	IN	MX	10	mail2.example.com.
	IN	MX	20	mail.backup.org.
mail.example.com.	IN	A	10.0.0.1
mail2.example.com.	IN	A	10.0.0.2

邮件交付尝试邮件邮件.example.com和mail2.example.com（中的任何一个）；如果这些成功都没有成功，则尝试将其交付给mail.backup.org。

Setting TTLs(设置TTLs）

RR字段的循环时间（TTL）是一个32位整数，以秒为单位表示，并且在解析器缓存RR时主要使用。 TTL描述了RR在应丢弃之前可以缓存多长时间。当前在区域文件中使用以下三种TTL。

SOA minimum：SOA中的最后一个字段是负缓存TTL。 这控制了其他服务器缓存多长时间的无类域（NXDOMAIN）响应。负缓存的最大时间为3小时（3H）。
$TTL：区域文件顶部的$TTL指令（在SOA之前）给出了每个RR的默认TTL，而没有特定的TTL设置。
RR TTLs：每个RR可以将TTL作为RR中的第二个字段，它控制其他服务器可以缓存多长时间。

所有这些TTL默认为秒的单位，尽管可以明确指定单位：例如，1h30m。

Inverse Mapping in IPv4（IPV4中的逆映射）

Reverse name resolution（即，从IP地址到name的翻译）是通过in-addr.arpa domain和PTR记录实现的。in-addr.arpa domain中的条目以最小的重要顺序进行，从左到右读取。这是与IP地址通常编写的方式相反的顺序。因此，IP地址为10.1.2.3的计算机将具有相应的in-addr.arpa名称为3.2.1.10.in-addr.arpa。此名称应具有PTR资源记录，其数据字段是计算机的名称，或者（如果计算机都有多个名称），则可以选择多个PTR记录。例如，在example.com域中：

$ORIGIN	2.1.10.in-addr.arpa
3	IN PTR foo.example.com.

在此示例中，$ORIGIN 行只是为了提供上下文；它不一定出现在实际用法中。它仅在这里用于指示该示例是相对于列出的原点。

Other Zone File Directives(其他区域文件指令)

主文件指令包含 $ORIGIN, $INCLUDE, and $TTL.

@ (at-sign)：When used in the label (or name) field, the asperand or at-sign (@) 代表当前原点。 在区域文件的开始时，它是<zone_name>，然后是尾随点(.)。
$ORIGIN原始指令：语法是$ORIGIN domain-name [comment]，$ORIGIN设置了附加到任何不合格记录的域名。 首先读取区域时，有一个隐式$ORIGIN <zone_name>.; 注意尾随点。 
$INCLUDE指令：语法是$INCLUDE filename [origin] [comment],这会读取和处理文件文件名，就好像此时包含在文件中一样。 文件名可以是绝对路径，也可以是相对路径。
$TTL指令：语法是$TTL default-ttl [comment]，这将设置使用未定义的TTL的后续记录的默认时间到live（TTL）。 有效的TTL为0-2147483647秒范围。

BIND Primary File Extension: the $GENERATE Directive(绑定主文件扩展名：$GENERATE指令)

语法：$GENERATE range lhs [ttl] [class] type rhs [comment]

$GENERATE用于创建一系列资源记录，这些记录仅由彼此不同迭代器使用。

$ORIGIN 0.0.192.IN-ADDR.ARPA.
$GENERATE 1-2 @ NS SERVER$.EXAMPLE.
$GENERATE 1-127 $ CNAME $.0

上面的配置等同于：

0.0.0.192.IN-ADDR.ARPA. NS SERVER1.EXAMPLE.
0.0.0.192.IN-ADDR.ARPA. NS SERVER2.EXAMPLE.
1.0.0.192.IN-ADDR.ARPA. CNAME 1.0.0.0.192.IN-ADDR.ARPA.
2.0.0.192.IN-ADDR.ARPA. CNAME 2.0.0.0.192.IN-ADDR.ARPA.
...
127.0.0.192.IN-ADDR.ARPA. CNAME 127.0.0.0.192.IN-ADDR.ARPA.

两者都生成一组A和MX记录。

$ORIGIN EXAMPLE.
$GENERATE 1-127 HOST-$ A 1.2.3.$
$GENERATE 1-127 HOST-$ MX "0 ."

上面的配置等同于：

HOST-1.EXAMPLE.   A  1.2.3.1
HOST-1.EXAMPLE.   MX 0 .
HOST-2.EXAMPLE.   A  1.2.3.2
HOST-2.EXAMPLE.   MX 0 .
HOST-3.EXAMPLE.   A  1.2.3.3
HOST-3.EXAMPLE.   MX 0 .
...
HOST-127.EXAMPLE. A  1.2.3.127
HOST-127.EXAMPLE. MX 0 .

下面是参数解释：

range：这可以是两种形式之一：start-stop or start-stop/step。 如果使用第一个形式，则将步骤设置为1。“start”, “stop”, and “step”必须是0到 (2^31)-1之间的正整数。 “start”不得比“stop”大。
owner: 这描述了要创建的资源记录的所有者名称
ttl：这指定了生成记录的time-to-live。 如果未指定，则使用normal TTL继承规则继承。class and ttl 可以按任一顺序输入。
class：这指定了生成的记录的类。 如果指定区域类，则必须匹配。
type: 这可以是任何有效类型。
rdata: 这是一个包含要创建资源记录的RDATA的字符串。 如果字符串中有空格，可能会引用。 引号未出现在生成的记录中。

$GENERATE指令是绑定扩展名，而不是标准区域文件格式的一部分。

Additional File Formats（附加文件格式）

除了标准文本格式外，BIND 9还支持以其他格式读取或转储到区域文件的能力。原始格式是区域数据的二进制表示，其方式与区域传输中使用的方式相似。由于它不需要解析文本，因此负载时间大大减少。对于主服务器，预计将通过named-compilezone命令从文本区域文件生成以RAW格式的区域文件。对于辅助服务器或动态区域，当命名命名时，将自动生成区域文件在区域传输之后或应用先前更新时，如果这些格式之一由MasterFile-Format选项指定。

如果以RAW格式的区域文件需要手动修改，则必须首先通过named-compilezone 命令将其转换为文本格式，然后在编辑后将其转换回。例如：

named-compilezone -f raw -F text -o zonefile.text <origin> zonefile.raw
[edit zonefile.text]
named-compilezone -f text -F raw -o zonefile.raw <origin> zonefile.text

1.3 Building BIND 9

要在UNIX或Linux系统上构建，请使用：

$ autoreconf -fi ### (only if building from the git repository)
$ ./configure
$ make

几个环境变量会影响汇编，并且可以在运行配置之前设置它们。最重要的是：

影响构建的其他环境变量在配置帮助文本的末尾列出，可以通过运行命令来获得：

$ ./configure --help

1.3.1 Required Libraries

要构建绑定9，必须安装以下软件包：

libcrypto, libssl，libuv，perl，pkg-config/pkgconfig/ pkgconf

要用GIT存储库构建BIND，还必须安装以下工具：

autoconf (includes autoreconf)，automake，libtool

1.3.2 Optional Features(可选功能)

要查看配置选项的完整列表，请运行配置--help。

为了提高性能，强烈建议使用jemalloc库（http://jemalloc.net/）。

为了支持HTTPS（DOH）的DNS，必须将服务器与libnghttp2（https://nghttp2.org/）链接。如果库不可用，则可以使用DISable-DOH来禁用DOH支持。

为了支持http统计通道，必须将服务器与以下至少一个库链接：libxml2（http://xmlsoft.org）或json-c（https://github.com/json-c/json-c）。如果这些安装在非标准位置，则：

对于libxml2，使用-with-with-libxml2 =/prefix指定前缀，
对于 json-c,调整PKG_Config_path。

为了支持HTTP统计通道上的压缩，必须针对zlib (https://zlib.net/)链接服务器。如果将其安装在非标准位置，请使用--with-zlib=/prefix。

为了支持LMDB数据库中运行时添加的区域的存储配置数据，必须将服务器与liblmdb（https://github.com/lmdb/lmdb）链接。如果将其安装在非标准位置，请使用--with-lmdb=/prefix。

为了支持MaxMind GeoIP2基于位置的ACL，必须将服务器与libmaxminddb（https://maxmind.github.io/libmaxminddb/）链接。如果找到库，默认情况下将打开。如果库是在非标准位置安装的，请使用--with-maxminddb=/prefix。 GEOIP2支持可以用 --disable-geoip关闭。

对于DNSTAP数据包记录，libfstrm（https://github.com/farsightsec/fstrm）和libprotobuf-c（https://develovelers.google.com/protococol-buffers必须安装，并且必须安装，并且必须配置为--enable-dnstap。

为了支持DIG中的国际化域名，必须安装libidn2 （https://www.gnu.org/software/libidn/#libidn2）。如果库是在非标准位置安装的，请使用--with-libidn2=/prefix，或调整PKG_CONFIG_PATH。

对于nsupdate和nslookup中的线路编辑，请读取线（https://tiswww.case.edu/php/chet/chet/readline/rltop.html）或libedit库 (https://www.thrysoee.dk/editline/) 必须安装。如果将它们安装在非标准位置，请调整PKG_Config_path。默认情况下使用readline，可以使用--with-readline=libedit。

某些编译常数和默认设置可以降低到更适合小型机器的值，例如OpenWRT boxes，通过指定configure命令行上的指定--with-tuning=small。这可以通过使用较小的结构来减少内存使用情况，但会降低性能。

在Linux上，使用libcap library (https://git.kernel.org/pub/scm/libs/libcap/libcap.git/)在用户空间中管理过程功能，可以通过linux系统在libcap上安装 -dev或libcap-devel软件包。也可以通过配置-disable-linux-caps来禁用过程能力支持。

在某些平台上，有必要明确要求大量文件支持以处理大于2GB的文件。这可以通过在configure命令行上使用--enable-largefile来完成。

可以通过指定configure命令行上的指定--enable-fixed-rrset or --disable-fixed-rrset来启用或禁用对“fixed” RRSET配置选项的支持。默认情况下，禁用固定的RRSET配置以减少内存footprint。

在处理每个查询时，在每个查询时命名为记录每个步骤的命名的--enable-singletrace选项。--enable-querytrace选项将打开相同的详细跟踪，但允许通过将其查询ID设置为0来单独追踪。这些选项仅在调试时才能启用，因为它们对查询性能有重大的负面影响。

使make install和各种BInd9库。默认情况下，安装已进入 /usr /local，但是在运行配置时可以使用--prefix选项更改。

可以指定选项--sysconfdir以设置配置文件（例如named.conf）by default; --localstatedir 局限制可用于设置 run/named.pid的默认父目录。 --sysconfdir默认为$prefix/etc and --localstatedir默认为$prefix/var。

关于上面提到的MX记录就是给邮件用的可以看：http://blog.51niux.com/?id=59 开头的关于域名的配置设置

二、DNS解析过程

2.1 DNS解析的顺序

linux进行DNS解析的顺序，先查找/etc/hosts文件，如果没有再通过配置/etc/resolv.conf里面设置的DNS服务器进行DNS解析。

Centos6的文件设置：

# cat /etc/nsswitch.conf |grep hosts #在Centos6里/etc/nsswitch.conf里面指定本地解析顺序的，这里只有两个files指本地的/etc/hosts文件，然后是/etc/resolv.conf里面定义的dns服务进行解析。

#hosts: db files nisplus nis dns
hosts: files dns
Centos7的文件设置：

# cat /etc/nsswitch.conf |grep hosts #在Centos7里/etc/nsswitch.conf里多了一个myhostname，就是多了一个本地主机名的解析，如果你的主机名是自定义的，你直接ping自己的主机名是可以通过。

#hosts: db files nisplus nis dns
hosts: files dns myhostname

2.2 /etc/resolv.conf里面的设置

首先介绍一下DNS解析的超时时间：

# cat /etc/resolv.conf

nameserver 114.114.114.114
nameserver 223.6.6.6

#我们一般都会设置两个DNS解析服务器，默认情况下当第一个解析出现问题的时候会让第二个DNS解析服务器负责解析。第一次默认是五秒。

图片.png

#由上图可以看出，就以三个DNS来解释一下公式，第一次都是5S按顺序尝试下次，然后第二次就是超时时间会增加到10秒,公式是10（这个是第二次是10秒）/3（这个DNS服务器设置的数量）=3(取整，后面的小数部分不要)。

然后就是5*3+3*3=24秒。两台DNS服务器设置就是5*2+5*2=20秒，一台就是5*1+10*1=15秒。这个可以将自己/etc/resolv.conf里面设置两个错误不能进行DNS解析的namserver，然后# time dig www.baidu.com测试一下。

然后就引出了options指令：

# cat /etc/resolv.conf #一般一个正常的DNS解析过程应该是在一秒之内，然后你可能觉得设置两个DNS解析服务器结果出问题了等待反馈的时间有点长，可以用options timeout:2将默认超时时间从5秒改为2秒。

nameserver 114.114.114.114
nameserver 223.5.5.5
options timeout:2

其他常用options指令介绍：

写的非常好：https://help.aliyun.com/document_detail/414219.html

attempts:n #失败的尝试次数,默认是2次,上限是5次

rotate：以Round Robin的形式轮询DNS服务器,而不是从默认的第一个开始使用。

single-request-reopen：开启该配置后，一旦需要处理同一Socket发送的两次请求时，解析端会在发送第一次请求后关闭Socket，并在发送第二次请求前打开新的socket。

#所以配置文件可以改成下面的：

options timeout:2 attempts:3 rotate single-request-reopen
nameserver 114.114.114.114
nameserver 223.5.5.5

2.3 域的划分

DQDN(完全合格域名)：根域+顶级域+二级域+子域+主机名，例如:www.baidu.com.，整个域名空间是一个倒置的树形结构。

根域：所有域的最顶端，管理者顶级域，现在全球有十三个根域。域名就是一个点号“.”。

顶级域：也称为一级域：.com（商业组织）、mil（军事部门）、.net（通常是提供网络基础设施的组织）、org（通常是非盈利组织）、.edu（教育）、.gov（政府）等常见的国际顶级域。还有国家顶级域：.cn、.ck等。

二级域或者次级域：网站使用者在顶级域中注册使用的域名，如baidu.com、sina.cn

子域：在二级域中可以授权多个子域并且可以设置多级子域，如:www.baidu.com这就是一级子域。如：web.mail.51niux.com，这就是一个二级子域，是mail.51niux.com的子域。（web就类似于主机名加上后面的mail.51niux.com域就是一个完整的域名，指向了此域名主机所在的位置。）

反向域：arpa，FQDN<--IP，通过IP反向解析出域名，这也算一个顶级域。

2.4 Zones

要正确操作名称服务器，重要的是要了解zone和domain之间的差异。

如前所述，区域是DNS tree中委派的点。一个zone由domain tree的那些连续部分组成，其名称服务器具有完整的信息，并且具有其权限。它包含从域树向下的某个点的所有域名，除了委派给其他zones的域名。委托点由父zone中的一个或多个NS记录标记，该记录应与委托zone根的等效NS记录相匹配。zone可以精确地映射到一个domain，但也只能包括一个domain的一部分，其余的可以委派给其他名称服务器。

2.5 DNS服务器解析过程

# dig +trace www.baidu.com #dig命令是我们经常用到的一个命令，这是追踪一个域名的解析过程

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.3 <<>> +trace   #dig的版本然后后面是跟的命令参数，追踪www.baidu.com的解析过程 
;; global options: +cmd   #下面可以看到第一列都是.，下面就是获得了13个根域的IP和主机名。
.            18113    IN    NS    e.root-servers.net.
.            18113    IN    NS    g.root-servers.net.
.            18113    IN    NS    m.root-servers.net.
.            18113    IN    NS    j.root-servers.net.
.            18113    IN    NS    l.root-servers.net.
.            18113    IN    NS    c.root-servers.net.
.            18113    IN    NS    b.root-servers.net.
.            18113    IN    NS    k.root-servers.net.
.            18113    IN    NS    a.root-servers.net.
.            18113    IN    NS    d.root-servers.net.
.            18113    IN    NS    h.root-servers.net.
.            18113    IN    NS    f.root-servers.net.
.            18113    IN    NS    i.root-servers.net.
;; Received 811 bytes from 114.114.114.114#53(114.114.114.114) in 39 ms  #114.114.114.114就是我们设置的DNS服务器，为我们返回来13个根域所在的位置。

com.            172800    IN    NS    a.gtld-servers.net. #这里就是向其中一台根域服务器发送www.baidu.com的解析请求，根域将.com顶级域的IP（未显示）和名称告诉了我们。
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20170618050000 20170605040000 14796 . GkB03B/beJHmV1RNk7C+cWtEK4kHex9DQ/yFdB+N0RRu1KdPL/fGCHon eeQInXxzSiF10WPv+w+BYIJXzN5zULaP8M6SieW+59aZbDcDVqxh7BNB Z1yBZRlvJHu5ILnkcfaZM8HrGj6tZRd3ozygjoR7M9lSFV55aNiYMWyR hfL2cMfN1w7+149wWjngFkNgSopOVCBvM6nUlxuDjw2GQktW8R8JThJQ RRN9VZ0WLeTAY9o0KzCXmoax2GSkb1PDLOYdS8G0nnaRs+Btrbk6u4cf oBXJdx770EckaxhIWA8goAMT/rmOyCAparYQwDmq1exU/vWFDfb1fiRn 4NXj+Q==
;; Received 865 bytes from 198.97.190.53#53(h.root-servers.net) in 291 ms   #h.root-servers.net这个主机为我们返回了上面的com.域的主机位置

baidu.com.        172800    IN    NS    dns.baidu.com. #第三步，向com.域的一台服务器请求www.baidu.com的解析，它为我们返回了百度的五台SOA域服务器，也就是百度自己的DNS服务器。
baidu.com.        172800    IN    NS    ns2.baidu.com.
baidu.com.        172800    IN    NS    ns3.baidu.com.
baidu.com.        172800    IN    NS    ns4.baidu.com.
baidu.com.        172800    IN    NS    ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20170610044750 20170603033750 27302 com. qtstB1qc43bHTc7TaTpoQf+0utzHITmvowD2CchY6qd546A00m3bnJf0 jof3C9kARs52DjVlJinbVbDL1eIa2UO/UVt0WOf9gyBkKbG3qRGWGu6N d6Y4GbgoSb/vRcyohpD15lqVcnFdhDPNVe9wsHBmFICe/lJG3d0RInbr RME=
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HQ01I3PFSK4TG3Q31LT3RIMHGBFQU42T NS DS RRSIG
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20170612044853 20170605033853 27302 com. iwBbO4jBbQE91G75HiBDuMChoQbYKugUF1SGTbRxmgUYdfm7GHyhhM7e 4MpiGF+3mXDrbg8AcyeIu8qE+OV5ir5ytKw7/r2gJj7E4s/780brQSLW owNK4jifzcbMFXyoMrR1xC6bnzCQyeEJ1nObglzLMA8R1Ime4gpyPCDh 4pw=
;; Received 697 bytes from 192.48.79.30#53(j.gtld-servers.net) in 301 ms  #j.gtld-servers.net这个com.域主机为我们返回了上面五个百度SOA域服务器所在的位置。

www.baidu.com.        1200    IN    CNAME   www.a.shifen.com. #向上面提供的域主机发起了www.baidu.com的解析请求，为我们返回了一个www的CNAME别名，别名是www.a.shifen.com。按照一般逻辑，当DNS请求到别名的时候查询会终止，而是重新发起查询别名的请求。 
a.shifen.com.        1200    IN    NS    ns2.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns4.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns5.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns3.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns1.a.shifen.com.
;; Received 239 bytes from 180.76.76.92#53(ns7.baidu.com) in 3 ms  #ns7.baidu.com域主机为我们提供了解析服务，为我们返回了上面6个域名解析记录。

#如果你搭建了本地的DNS解析服务器在跟踪解析过程的话，会发现当解析到www.baidu.com. 1200 IN CNAME www.a.shifen.com. 的时候，会向.com域再次对www.a.shifen.com.进行解析请求。

DNS轮询机制：如果你多对www.baidu.com进行dig查询的话，会发现并不是同一个IP,这就是一个名称对应多个IP，这是为了服务器不断地被轮询询问，防止一台主机接收访问量过大，从而做的负载均衡。

DNS查询分类：递归查询（一直问直到问出最终结果,DNS服务器做的事情）和迭代（反复）查询（只告诉你下一步怎么做或者是招那个域主机去询问，根域啊，com.域啊这些主机做的事情）。

博文来自：www.51niux.com

2.6 DNS名字服务器的类型

DNS规范定义了两种类型的名字服务器：primary master（主名字服务器）和secondary master（辅名字服务器）。当然除此之外还有扩展出缓存域名服务器和转发域名服务器。

主名字服务器：也称为主域名服务器,负责维护这个域名区域的所有域名信息，是特定的所有信息的权威信息源。可以对域名进行修改添加管理。从本机中加载数据的文件叫做数据文件。

辅名字服务器：从主名字服务器传送过来的区数据备份到本机的数据文件当中，数据是从另一台域服务器复制过来的，所以数据无法修改只是一个区域文件的副本。如果辅名字服务器被杀死再重启时，它会先读取备份的数据文件，然后检查它的取数据是否是最新的。如果主域名服务器出现故障，辅域名服务器再自杀前还可以提供一段时间的解析服务。

缓存域名服务器：运行域名服务器软件但是没有域名数据库，如果收到域名服务的查询操作，它从某个远程服务器获得域名服务器的查询结果，会放到缓存中，以后再有相同的查询会给予回答。所以缓存域名服务器不是权威性的服务器，因为提供的所有信息都是间接信息。在缓存名称服务器的缓存中保留记录的时间长度由与每个资源记录关联的Time-To-Live（TTL）字段控制。

转发域名服务器：负责所有非本地域名的本地查询。转发域名服务器接到查询请求时，在其缓存中查找，如果找不到请求的结果就以此转发到指定的域名服务器，直到查询到结果为止，否则返回无法映射的结果。名字服务器不能把数据永远的放到缓存中，这些域名的管理员为数据设定一个生存期简称TTL，生存期一过，名字服务器就必须丢弃缓存的数据，并从权威名字服务器上获取新的数据。对于否定缓存数据（也就是之前解析发现不存在的域名）也一样。

2.7 DNS按功能（角色）的分类

权威DNS：权威DNS是经过上一级授权对域名进行解析的服务器，同时它可以把解析授权转授给其他人，如com顶级服务器可以授权51niux.com这个域名的的权威服务器为ns.51niux.com，当然也可以指定别的域名权威服务器。平时我们解析域名的结果都源自权威DNS。比如51niux.com的权威DNS服务器就是万网的dns13.hichina.com和dns14.hichina.com。
递归DNS : 负责接受用户对任意域名查询，并返回结果给用户。递归DNS可以缓存结果以避免重复向上查询。我们平时使用最多的就是这类DNS，他对公众开放服务，一般由网络运营商提供，大家都自己可以架递归DNS提供服务。递归DNS一定要有可靠的互联网连接方可使用。比如谷歌的8.8.8.8和8.8.4.4以及114的114.114.114.114和114.114.115.115都属于这一类DNS。你本地电脑上设置的DNS就是这类DNS。
转发DNS : 负责接受用户查询，并返回结果给用户。但这个结果不是按标准的域名解析过程得到的，而是直接把递归DNS的结果转发给用户。它也具备缓存功能。他主要使用在没有直接的互联网连接，但可以连接到一个递归DNS那里，这时使用转发DNS就比较合适。其缺陷是：直接受递归DNS的影响，服务品质较差。比如我们用的路由器里面的DNS就是这一类，用路由器的朋友可以看下本地电脑的DNS一般都是192.168.1.1。

2.8 权威名称服务器

每个zone至少由一个权威名称服务器提供，其中包含该zone的完整数据。为了使DNS对服务器和网络故障的耐受性，大多数区域在不同的网络上都有两个或多个权威服务器。权威服务器的响应在响应数据包中设置了“权威答案”（AA）位。这使它们在使用DIG（诊断工具）等工具进行调试时，可以轻松识别DNS配置.

The Primary Server(主服务器）：维护zone数据的主要副本的权威服务器称为主服务器或者简称为主服务器。

Secondary Servers(辅助服务器)：其他权威服务器，辅助服务器（以前称为从服务器）使用称为zone传输的复制过程从另一台服务器加载zone内容。Periodically(定期),辅助服务器必须发送刷新查询，以确定zone内容是否已更新。这是通过向区域开始（SOA）记录的查询发送查询来完成的，这些刷新查询的时机由SOA刷新和重试字段控制，但可以通过max-refresh-time, min-refresh-time, max-retry-time, and min-retry-time选项来覆盖。如果在SOA到期选项指定的时间内无法更新区域数据（最多硬编码为24周），则次级区域到期，并且不再响应查询。

Stealth Servers(隐形服务器)：隐身服务器是一台对区域权威但没有在该区域的NS记录中列出的服务器。隐形服务器可用于保留区域的本地副本，以加快对区域记录的访问，或确保该区域可用，即使该区域的所有“官方”服务器都无法访问。主服务器本身是隐形服务器的配置通常称为“隐藏的主”配置。这种配置的一种用途是，当主是防火墙后面，因此无法直接与外界进行通信。

2.9 DNS常用记录类型

A记录：用来指定域名（或主机名）对应的IP地址记录。

CNAME记录：别名记录，允许将多个名字映射到同一台计算机。

MX记录：邮件交换记录，它指向一个邮件服务器，用于点子邮件系统发邮件时根据收件人的地址后缀来定位邮件服务器。

NS记录：域名服务器记录，用来指定该域名由哪个DNS服务器进行解析，指定负责此DNS区域的权威名称服务器。

PTR记录：指针记录，将一个IP地址映射到对应的域名，也可以看成是A记录的反向，IP地址的反向解析。PTR主要用于邮件服务器，对端的邮件服务器根据发件IP进行反向解析，如果解析结果对应发件人的域名称就接收这封邮件，否则拒绝接收这封邮件。

SOA记录：权威记录的起始，指定有关的DNS区域的权威性信息，包含主要名称服务器、域名管理员的邮箱地址、域名的流水式编号和几个有关刷新区域的定时器。

SPF记录：是为了防范垃圾邮件而提出来的一种DNS记录类型，它是一种TXT类型的记录，它用于登记某个域名拥有的用来外发邮件的所有IP地址。当你定义了你的domain name的SPF记录之后，接收邮件方会根据你的SPF记录来确定连接过来的IP地址是否被包含在SPF记录里面，如果在，则认为是一封正确的邮件，否则则认为是一封伪造的邮件。

TSIG记录：交易证书，用以认证动态更新（Dynamic DNS）是来自合法的客户端，或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。

TXT记录：文本记录。一般指某个主机名或域名的说明，TXT的应用之一，SPF（Sender Policy Framework）反垃圾邮件。

博文来自：www.51niux.com

三、DNS服务器搭建

3.1 DNS服务器基本搭建

第一步：安装相关件软件

# yum install bind bind-libs -y #dns服务软件安装。提供域名服务的主要程序及相关文件。

# yum install bind-utils -y #提供了对DNS服务器的测试工具（如nslookup,dig等）

第二步：修改位置文件

# vim /etc/named.conf #修改主配置文件，我们先做很小的修改让结果显示出来

options {
    //listen-on port 53 { 127.0.0.1; };  #我们将默认的127.0.0.1用//注释掉
    listen-on port 53 { 192.168.1.101; };  #这是新添加的一行，让其监听再192.168.1.101的53端口上面，注意每一行都要以;结尾。
    //listen-on-v6 port 53 { ::1; };   #我们将ipv6的注释掉如果不需要
    directory     "/var/named";        #这就是我们区数据文件的存放位置。
    dump-file     "/var/named/data/cache_dump.db"; #转储名称服务器数据库时存储文件的位置
    statistics-file "/var/named/data/named_stats.txt";  #转储其统计数据，存储文件的位置
    memstatistics-file "/var/named/data/named_mem_stats.txt";  
    //allow-query     { localhost; };  #将原来的只允许本地访问注释掉
    allow-query     { any; };   #新添加一行允许任何地址来访问
    /* 
     - If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
     - If you are building a RECURSIVE (caching) DNS server, you need to enable 
       recursion. 
     - If your recursive DNS server has a public IP address, you MUST enable access 
       control to limit queries to your legitimate users. Failing to do so will
       cause your server to become part of large scale DNS amplification 
       attacks. Implementing BCP38 within your network would greatly
       reduce such attack surface 
    */
    recursion yes; #默认是开启递归设置。如果是yes，并且一个DNS询问要求递归，那么服务器将会做所有能够回答查询请求的工作。如果recursion是off的，并且服务器不知道答案，它将会返回一个推荐（referral）响应。默认值是yes。注意把recursion设为no，不会阻止用户从服务器的缓存中得到数据，它仅仅阻止新数据作为查询的结果被缓存。服务器的内部操作还是可以影响本地的缓存内容，如NOTIFY地址查询。

    dnssec-enable yes; #是否支持DNSSEC开关,默认为yes。 (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制（可参考RFC2535）。它提供了一种来源鉴定和数据完整性的扩展，但不去保障可用性、加密性和证实域名不存在。DNSSEC是为解决DNS欺骗和缓存污染而设计的一种安全机制。 
    dnssec-validation yes;  # 是否进行DNSSEC确认开关。
    //dnssec-lookaside auto; #该选项的语法格式为：[ (dnssec-lookaside auto| no| domain trust-anchor daomain); ]，dnssec-lookside为验证器提供另外一个能在网络区域的顶层验证DNSKEY的方法。当使用dnssec-lookaside指定一个DNSKEY是等于或低于指定域时，正常DNSSEC验证已经忽略了不信任的密钥。如果它能够验证密钥，trust-anchor将被追加到密钥名和DLV记录被查看。如果DLV记录验证一个DNSKEY，这个DNSKEY RRset可以被视为可信任的。如果dnssec-lookside设置为auto，那么内置的默认值DLV域和信任锚定将被使用，随着一个内置的验证密钥。如果设置为no，那么不使用dnssec-lookside，将加载默认DLV密钥存储在文件bind.keys中。默认的DLV密钥存储在文件bind.keys中，如果dnssec-lookaside设置为auto，named在启动时将被加载。

    /* Path to ISC DLV key */
    bindkeys-file "/etc/named.iscdlv.key";   #内置信任的密钥文件。当dnssec-validation和dnssec-lookaside都被设为auto时，这个密钥文件生效。

    managed-keys-directory "/var/named/dynamic"; #指定目录中的文件存储，跟踪管理DNSSEC密钥。默认情况下，保存在/var/named/dynamic目录中。如果named配置不使用视图，然后在管理服务器中的密钥将被跟踪单个文件称为managed-keys.bind；否则将单独跟踪管理的密钥文件。

    pid-file "/run/named/named.pid";  #pid文件的位置
    session-keyfile "/run/named/session.key";  #写入由nsupdate -l使用的命名生成的TSIG会话密钥的文件的路径名。 如果未指定，则默认值为/var/run/named/session.key。
};

logging { #定义bind服务的日志
        channel default_debug {  #定义通道，default_debug只有当服务器的debug级别非0时，才产生输出
                file "data/named.run"; #默认日志保存位置
                severity dynamic;   #severity按照服务器当前的debug级别记录日志。everity语句用于指定消息的严重性等级。log_severity的取值为（按照严重性递减的顺序）：critical、error、warning、notice、info、debug [level]、dynamin。dynamic是一个特殊的值，系统会记录包括该级别以及比该级别更严重的级别的所有消息。比如定义级别为error，则会记录critical和error两个级别的消息。对于系统管理来说，一般记录到info级别就可以了。
        };
};

zone "." IN {   #这是定义了根域。zone用来定义一个区域。每个zone区域都是可选的（包括根域、回环域、反向域），具体根据实际需要而定，zone配置部分的IN关键子可以省略。
    type hint;  #指定区域类型为根域，可以设置的区域类型有“根域”、“主域”和“从域”3种类型，在配置文件中分别使用hint、master和slave表示这3种类型。
    file "named.ca";  #定义了根域数据库文件位置，默认是在/var/named/named.ca，设置区域地址数据库文件，该文件名由用户自行设置，只要实际的地址数据库文件名与其保持一致即可。
};

include "/etc/named.rfc1912.zones"; #这两个就是加载哪些文件
include "/etc/named.root.key";

第三步：修改/etc/named.rfc1912.zones区域文件,此文件里面原来的内容可以全删除掉，那就相当于例子供你参考。

zone "51niux.in" IN {  #定义了一个51niux.in的域
     type master;      #类型为主域
     file "51niux.in.zone";   #文件是51niux.in.zone，默认是在/vat/named/目录下面
};
zone "1.168.192.in-addr.arpa" IN {  #定义了一个反向域，这个你要从右向左来看，arpa.addr-in.192.168.1
     type master;    #类型为主域
     file "1.168.192.zone";  #文件位置
};

第四步：添加51niux.in.zone域文件并修改

# cat /var/named/51niux.in.zone

$TTL 86400      //设置地址解析记录的默认存储时间，单位是秒。当然也可以用3h（3小时）或者1D（一天）来表示，大小写没影响不过一般用大写。H(时)、M（分）、S（秒）、W（周）、D（天）
@ IN SOA ns1.51niux.in. csp ( //定义了一条SOA记录，现在是一种缩写，@代表51niux.in.，这是很常见的一种写法。这里定义了SOA标记、SOA域名是ns1.51niux.com,域管理邮箱是csp@51niux.in（也可以写成csp.51niux.in.，这里第一个.就相当于@）
                  2017060616    //更新序列号，10位以内的证书，用于标记地址数据库的变化，这里是以2017年6月6日16时来定义的序列号。
                  3H          //刷新时间，从域名服务器更新该地址数据库文件的间隔时间
                  1H          //重试延时，从域命服务器更新地址数据库失败以后，等待多长时间再次尝试
                  1W          //失效时间，超过该时间仍无法更新地址数据库，则不再尝试并且杀死自己。
                  1H )        //设置无效地址解析记录（该数据库中不存在的地址也就是域名）的默认缓存时间
@ IN NS ns1.51niux.in.        //域名服务器记录，用于设置当前域的DNS服务器的域名地址
@ IN NS ns2.51niux.in.

@          IN MX 5 mail.51niux.in. //设置邮件服务器的MX记录，前面的@就表示51niux.in.
@                    IN  MX  10 mail2.51niux.in. //这里设置了两个MX记录。优先级越高的邮件交换器的优先级值就小，如果上面的MX出问题了，才会解析到现在这台机器。
ns1 IN  A  192.168.1.101           //这些就是A记录了
ns2 IN  A  192.168.1.102                      //因为是缩写了，所以ns2.51niux.in.可以直接缩写成ns2
www IN  A  192.168.1.103
mail IN A  192.168.1.104                     
mail2 IN  A    192.168.1.105              
pop3 IN  CNAME mail.51niux.in.     //这些就是CNAME记录了
imap IN  CNAME mail.51niux.in.

第五步：1.168.192.zone反向域文件的添加并修改

$TTL 86400
@ IN SOA ns1.51niux.in. csp (
                  2017060616
                  3H
                  1H
                  1W
                  1H )
@ IN NS ns1.51niux.in.
@ IN NS ns2.51niux.in.
104 IN PTR mail.51niux.in.  //这是也缩写，标准格式是104.1.168.192.in-addr.arpa，指定了192.168.1.104的反向域名是mail.51niux.in

第六步：重启DNS服务

# named-checkconf /etc/named.conf #可以检测下配置文件，没输出就说明没问题

# named-checkzone 51niux.in /var/named/51niux.in.zone #检查下zone文件，

zone 51niux.in/IN: loaded serial 2017060616
OK

# service named restart #重启bind服务，也可以查看日志是否报错# tail -f /var/log/messages
# netstat -lntup|grep :53 #查看53端口已经启动
tcp 0 0 192.168.1.101:53 0.0.0.0:* LISTEN 124313/named
udp 0 0 192.168.1.101:53 0.0.0.0:* 124313/named

第七步：测试

# cat /etc/resolv.conf #找一台机器将dns服务器设置成我们的测试DNS服务器
nameserver 192.168.1.101

# ping www.51niux.in #ping检测一下
图片.png
# nslookup www.baidu.com #抓下外网

图片.png

# dig -x 192.168.1.104 @192.168.1.101 #指定通过192.168.1.101去查看192.168.1.104的反向解析。

图片.png

#经过测试我们设置的域名可以解析，外网也可以解析，反向解析也是可以的。

第八步：解决ipv6相关报错

通过上面的配置启用后虽然可以正常使用，不过在/var/log/message 和 /var/named/data/named.run 日志中会出现相关报错。

Jun  6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:500:3::42#53
Jun  6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:7fe::53#53
Jun  6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:dc3::35#53
Jun  6 18:05:56 agent3 named[3218]: error (network unreachable) resolving './DNSKEY/IN': 2001:500:2f::f#53

该报错是由于启用了ipv6的原因导致的，虽然我们在/etc/named.conf中将listen项的IPv6配置已禁用，但是在named.ca配置中还有13台根域的ipv6配置。所以还需要如下两种方法中的任一种来关闭ipv6的使用。
方法1：修改/etc/sysconfig/named配置
直接编辑配置文件/etc/sysconfig/named：

OPTIONS="whatever" 改为  OPTIONS="-4"
# 注意OPTIONS选项的值可以是：whatever、-4、-6中的一个

方法2：完全禁用IPv6

配置文件/etc/sysconfig/network，然后将NETWORKING_IPV6=YES改为NETWORKING=no；

关闭ip6tables这个服务；向/etc/modprobe.conf文件中，添加如下内容：

alias ipv6 off
alias net-pf-10 off

博文来自：www.51niux.com

四、DNS主辅同步部署

增量区传送（IXFR）：区很大的话，区传送需要一定的时间，IXFR是为了解决这个问题，它允许辅名字服务器告诉主名字服务器当前使用的区的版本，并仅仅请求传送它使用的版本和当前版本之间改动过的部分。这样就大大减少了区传送的大小和所需的时间。但是存在的问题比较多，如果最大限度的利用IXFR，最好动态更新修改区而不是手工编辑区数据文件。

全量区传送（AXFR）：默认的是这种形式，进行整个区传送的查询类型。

4.1 dns主服务器端（192.168.1.101）的设置

# cat /etc/named.rfc1912.zones

zone "51niux.in" IN {
     type master;
     file "51niux.in.zone"; 
     allow-transfer { 192.168.1.104;}; //辅助DNS的地址，也就是只允许此服务复制51niux.in.zone的信息的信息
     allow-update { none;};            //设置允许动态更新的客户端地址（none为禁止）
     also-notify { 192.168.1.104;};    //当zone信息发送改变时，主DNS会主动给辅助DNS发送信息通知自己更新了
};
zone "1.168.192.in-addr.arpa" IN {
     type master;
     file "1.168.192.zone";
     allow-transfer { 192.168.1.104;};
     allow-update { none;};
     also-notify { 192.168.1.104;};  //BIND8和BIND9是不允许关掉服务器对服务器的NOTIFY声明的，所以notify yes;加不加都行，默认就是开启的。

};

notify: 默认为yes,当服务器的一个域授权发生改变,将发送DNS NOTIFY信息给域NS记录的服务器列表,和一些列在also-notify选项中的服务器.如果选master-only,信息只发给主域,如果是explicit,通知只发给also-notify的列表,no不发通知.这里需要注意：如果我们also-notify没有进行设定的话，那么会造成当主dns记录发生改变后，辅dns并没有同步更改相应的记录。也许有人会说我们可以更改SOA中的Refresh值，把它改小点也一样，这样说到也是可以的，但问题是我们的主DNS修改完重启服务后，它是会主动发送一个notify值，如果辅助DNS服务器没有收到才参考Refresh，Refresh 不成功,则参考Retry ，Retry 一直不成功,则参考 Expire，如果Expire也不成功，则选择放弃zone transfer的过程。所以为了主辅更好的同步，建议大家在这里设置also-notify。

# service named restart #重启主DNS的服务

4.2 dns从服务器端（192.168.1.104）的设置

# cat /etc/named.conf #只改变一出，上面讲述了这里设置个IP的形式，改成下面的形式就是监听0.0.0.0，主从这样设置的话，主从的named.conf就都不用更改了保持一致了。
listen-on port 53 { any; };

# cat /etc/named.rfc1912.zones

zone "51niux.in" IN {
     type slave;  //类型是不一样，指定自己的DNS类型是slave也就是指定自己是辅助DNS服务器
     file "slaves/51niux.in.zone";
     masters{   //这里指定从哪个master服务器同步zone文件
            192.168.1.101;  //192.168.1.101从这个主服务器同步zone数据
     };
};
zone "1.168.192.in-addr.arpa" IN {
     type slave;
     file "slaves/1.168.192.zone";
     masters{
            192.168.1.101;
     };
};

# service named restart #重启辅助DNS服务器的服务。

# chmod 700 /var/named/slaves

# tail -f /var/log/messages #当你上面进行重启的时候，查看日志已经有数据同步过来了，如果设置是成功的话。

Jun  6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: Transfer started.
Jun  6 18:17:13 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: connected using 192.168.1.104#21228
Jun  6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: transferred serial 2017060619  #注意我们设置的这个ID号等会同步的时候就知道它的重要性了。
Jun  6 18:17:13 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 17 records, 391 bytes, 0.001 secs (391000 bytes/sec)
Jun  6 18:17:13 agent3 named[3399]: zone 51niux.in/IN: sending notifies (serial 2017060619)
Jun  6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: Transfer started.
Jun  6 18:17:13 agent3 named[3399]: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.101#53: connected using 192.168.1.104#10660
Jun  6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: transferred serial 2017060616
Jun  6 18:17:13 agent3 named[3399]: transfer of '1.168.192.in-addr.arpa/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 5 records, 184 bytes, 0.003 secs (61333 bytes/sec)
Jun  6 18:17:13 agent3 named[3399]: zone 1.168.192.in-addr.arpa/IN: sending notifies (serial 2017060616)

图片.png

4.3 进行测试

主DNS上面的操作：

现在我们在192.168.1.101上面添加一条DNS，并且查看日志：

# vim /var/named/51niux.in.zone #添加下面一条记录
dnstest IN A 192.168.1.101

# service named reload #不可能总是重启服务，让named重新加载一下配置文件

# tail -f /var/log/messages #下面是最后的信息

Jun  6 18:22:30 master named[125967]: reloading zones succeeded
Jun  6 18:22:30 master named[125967]: zone 51niux.in/IN: zone serial (2017060619) unchanged. zone may fail to transfer to slaves.  #区序（2017060619）不变。区域可能无法转移到salves服务器。
Jun  6 18:22:30 master named[125967]: zone 51niux.in/IN: loaded serial 2017060619
Jun  6 18:22:30 master named[125967]: zone 51niux.in/IN: sending notifies (serial 2017060619)  #发送通知（系列2017060619）,说明已经通知出去，通知slaves来更新了。

图片.png

#客户端本地测试已经生效了。

辅助DNS上面进行的操作：

# tail -f /var/log/messages #下面是最后的信息

Jun  6 18:22:31 agent3 named[3399]: client 192.168.1.101#43642: received notify for zone '51niux.in'  #客户端收到了通知51niux.in的更新
Jun  6 18:22:31 agent3 named[3399]: zone 51niux.in/IN: notify from 192.168.1.101#43642: zone is up to date  #从192.168.1.101去更新最新的51nux.in的zone文件

图片.png

注意：

差就差在了主DNS服务器再更改zone文件的时候，serial号没有进行更改。每次更改zone文件，serial号都要进行更改可以按天加或者按小时加，要增大，一定要比辅助DNS的serial号大，这样辅助DNS一查看自己的serial号变小了，就会同步数据了。

如现在我们将主DNS上面的号加大一下再重新加载配置文件：

图片.png

再查看辅助DNS上面的日志：

# tail -f /var/log/messages

Jun  6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: Transfer started.  #zone 51niux.in转移开始
Jun  6 18:35:09 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: connected using 192.168.1.104#36323  #192.168.1.104连接上来了
Jun  6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: transferred serial 2017060620  #发现号已经发生了变化已经不是2017060619了。
Jun  6 18:35:09 agent3 named[3399]: transfer of '51niux.in/IN' from 192.168.1.101#53: Transfer completed: 1 messages, 18 records, 415 bytes, 0.001 secs (415000 bytes/sec)  #从192.168.1.101传送51niux.in完成，1条信息，18条记录，415字节，0.001秒。
Jun  6 18:35:09 agent3 named[3399]: zone 51niux.in/IN: sending notifies (serial 2017060620)

图片.png

博文来自：www.51niux.com