给DNS划重点：分析ISC BIND必知必会

0×01

最近一直在分析dns协议的漏洞，分析过程中明显感到对所分析协议的理解程度不到位。尤其对于dns而言，本科期间也上过《计算机网络》这门课，可是当中对dns的讲解其实非常浅，考试而言通常也就两个考点：1.阐述递归查询，迭代查询的概念及区别2.区分各种资源记录类型。本文有感而发，主要谈谈dns协议知识中在我分析漏洞时碰到的重难点，以及最近分析的漏洞中涉及到的额外的背景知识。

0×02

一些在rfc里有的或者讲的很清楚的，我这里就不再赘述了。只挑几个点来讲一下。

namespace

随着互联网扩展，主机数量增加，导致域名数量增加，面对这一现象，如何才能使域名易于记忆，又如何管理域名数据呢？

解决办法就是树状的namespace，其特点是名字和文件夹一样，由大到小，由整体到局部；通过某种机制划分管理区块。

域（domain）和区（zone）

我们知道树是可以无限伸展的，将树种同一根下的连续域名组成一个区，由某一个机构管理，该机构又将自己树的一个子树交给另一个机构，这样逐层授权，就可以将namespace划分成易于管理的区块。

存储有关域名空间信息name space的程序称为name server. Name server通常具有关于name space的某些部分（称为一个zone）的完整信息，它们是从文件加载的。Name server被认为具有该zone的权限。

我们倾向于认为domain就是DNS，它让我们的生活变得轻松，但在处理为我们的domains（name servers）保存数据的DNS服务器时，我们需要引入zone这个专业术语，因为它是必不可少的。

domain和zone之间的区别很重要，但很微妙。我们使用下图的例子进行理解。COM domain分为多个zone，包括hp.com zone，sun.com，it.com。在domain的顶部，还有一个com zone。

我们要知道一个zone存在于domain里面。 name server加载zone file，而不是domain。Zone files包含有关其负责的domain部分的信息,可能是整个domain（sun.com，it.com）或只是其中的一部分（hp.com + pr.hp.com）。

在我们的示例中，hp.com domain有两个子domain，即support.hp.com和pr.hp.com。 第一个是support.hp.com，它由自己的name server控制，因为它有自己的zone，称为support.hp.com zone。 第二个，pr.hp.com由负责hp.com zone的同一个name server控制。

hp.com zone只有少量support.hp.com zone的信息，它只是知道support.hp.com自己下面。 如果有人需要有关support.hp.com的更多信息，则会要求联系该子domain的权威服务器（authoritative name servsers），它是这个zone的name server。

所以你看到即使support.hp.com是一个子domain，就像pr.hp.com一样，但是它的设置和控制方式与pr.hp.com不同。

另一方面，Sun.com domain有一个zone（sun.com zone），包含并控制整个domain，这个zone由权威服务器（authoritative name servsers）加载。

Emmm,上面的话比较绕，不过这应该是目前最简单的解释了，读理解几遍就明白了。

从上面我们知道，zone file由权威服务器加载，客户通过dns协议查询域名对应的ip地址。如果每次查询都从这儿开始查询，权威服务器是无法实现的，那么这时候怎么提高dns系统的性能呢？答案是递归服务器。递归服务器的主要功能是帮助用户做递归查询；缓存上次查询的结果，当相同的查询时直接返回结果；通过某种机制使得缓存过期，保证权威服务器更新的数据能被用户查询到。当然，递归功能和缓存功能并非必须同时拥有。事实上，我们在主机上配置的dns地址就是递归服务器的地址。

结合以上知识点，我们已经知道了dns系统的构成部分：

1.name space

2.authoritative name servsers加载zone file,使用域名可以被查询

3.客户端使用递归服务器查询相关域名

资源记录（RR）

我们知道dns提供全球分布式的数据库，提供从域名到ip地址的映射关系。而记录域名到信息的映射，我们称之为资源记录。

Dns通用的记录格式是这样子的：

分别指的是域名，生存周期，网络/协议类型，资源记录类型，资源记录数据

我们对应一条例子进行解释

www.xxx.com 600 IN A 111.111.111.111

这里600指定递归服务器会缓存该RR的时间；IN代表internet，是目前DNS系统主要支持的协议；A是指A记录，即用来将 DNS 域名映射到网络上的主机 IP 地址的资源记录；111.111.111.111指的是域名关联的信息数据

这里需要注意的是，一个域名可以有多种资源记录，每种资源记录可以有多条。

一个域名，多个相同类型的资源记录的集合称为资源记录集（RRset），RRset是dns传输的基本单元，意思是说查询一个域名对应的信息时，dns系统不会返回RR,而是返回RRset。

主/从服务器（master server/slave server）

首先要明确一点，主服务器和从服务器都可以给出权威应答。为什么会出现从服务器呢？假设我们将一个zone交给一个name server解析时，如果唯一的name server出现故障，则Internet上的用户无法取得属于这个zone的记录。为了避免出现这个问题，就出现了辅服务器。我们将zone交个多个name server解析，一个zone一般是一台主服务器，从服务器则定期从主服务器同步zone file。主服务器和从服务器对外表现为平等接收查询，所以可以起到负载均衡和容灾备份的作用。

Stub resolver:

是主机上的dns软件库，主要功能是方便应用程序使用dns系统，为应用程序开发者提供统一的编程接口，它能够直接将查询转发给递归服务器。

0×03

漏洞分析中碰到的额外的背景知识：

Cve-2002-0029:

1）udns:stub DNS resolver library ,DNS库udns实现了线程安全存根DNS解析器功能，它可以与传统的同步方式和异步方式一起使用，也可以与应用程序提供的事件循环一起使用。

Cve-2007-0494:

1）DNSSec：Domain Name System Security Extensions (DNSSEC)DNS安全扩展，是由IETF提供的一系列DNS安全认证的机制（可参考RFC2535）。它提供了一种来源鉴定和数据完整性的扩展，但不去保障可用性、加密性和证实域名不存在。

2）RRset：多个相同类型的资源记录的集合称为资源记录集RRset，RRset是dns传输的基本单元，也就是说查询一个域名对应的某种信息。Dns系统不会返回一条RR，而是返回一个RRset。

Cve-2009-0696:

1）Dynamic update和prerequisite section:动态更新使DNS客户端计算机能够在发生更改时使用DNS服务器注册并动态更新其资源记录。 …先决条件资源记录包含一组资源记录先决条件，在权威DNS服务接收到更新消息时必须满足这些先决条件

Cve-2011-1910:

1）负缓存：否定缓存，也叫负缓存，是指对查询失败的域名进行缓存

2）RRsets：DNS记录集（RRsets）是一组具有相同记录类型的记录，例如，所有DNS A记录都是一个RRset。

要为每个zone level签名，还会引入一些其他记录类型：

资源记录签名（RRSig） – RRset的签名

DNSKey – 包含用于验证RRSig的公钥

委派签名者（DS） – 在子区域中引用DNSKey并添加到域名注册商

Cve-2014-8500

1)dns lookup 可以查找IP地址并对任何URL执行深度DNS查找，提供有关常见记录类型（如A，MX，NS，SOA和TXT）的详细信息。

2)Named:isc bind服务器的守护进程

3)Name server:域名服务器，每个域名服务器所负责管辖的范围叫做区（zone）

4)Delegation:当 com服务器被要求找到区域example.com的权限时，他们经常将这项工作委托给不同的名称服务器

Cve-2016-1285

1)rndc

BIND分发包含的远程名称守护程序控制（rndc）程序提供了一个control channel来执行BIND 9 DNS服务器操作。 rndc命令提供执行这些操作的访问权限

2) DNAME记录

rfc2672描述了DNAME,rfc的标题是”Non-Terminal DNS Name Redirection”, 与CNAME的意思类似, 但他并不是别名了单独的一个名字, 而是别名了整个域名.当发现DNAME时, 并没结束, 而是计算出一个新的名字并且解析它

DNAME

作用是, 整个owner标识的整个子树被映射到目标域名上. 这是为了创建一种机制, 以帮助当网络重新规划后, 域名方便的重新命名, 包括原来的和新添加的域名.

Cve-2016-2088

1)DNS cookie:DNS Cookie是一种轻量级的DNS事务安全机制，可为DNS服务器和客户端提供有限的保护，防止off-apth攻击者造成的各种日益普遍的拒绝服务和放大攻击/伪造攻击或缓存中毒攻击。 DNS Cookie可以兼容NAT，NAT-PT（网络地址转换 – 协议转换）和任播，并且可以逐步部署。 （由于DNS Cookie仅返回到最初收到它们的IP地址，因此它们不能用于跟踪Internet用户。）

Cve-2016-9147

1）NSEC Record:

NSEC记录链接到区域中的下一个记录的名称（在DNSSEC排序顺序中），并列出记录名称的记录类型。

解析器作为DNSSEC验证的一部分，可以使用这些记录来验证记录名称和类型是否不存在。

NSEC记录具有以下数据元素：

下一个域名：区域中的下一个记录名称（DNSSEC排序顺序）

记录类型：此NSEC记录名称的DNS记录类型。

2）Authoritative Section:

可以查询任何 DNS服务器来回答发送的查询。不过，该服务器可以选择从缓存中回答查询。但是，如果想确保得到一个权威的响应，应该询问authoritative section中的服务器

参考链接：

1.https://www.isc.org/git/bind_developer/

2.https://tools.ietf.org/html/rfc4035

3.https://www.ripe.net/support/training/learn-online/videos/dnssec/dns-glossary/stub-resolver

4.www.firewall.cx/linux-knowledgebase-tutorials/system-and-network-services/829-linux-bind-introduction.html

5.https://docs.oracle.com/cd/E19455-01/806-1387/6jam692f3/index.html

*本文作者：Yale1024，转载来自FreeBuf