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

发表评论 取消回复

电子邮件地址不会被公开。 必填项已用*标注