DNS中的“无效Rdata”
<!--kg-card-begin: markdown--><p>所谓Rdata是指在DNS记录中与类型相关的数据部分。比如对于DNS的A记录中的IPv4地址或者MX记录中的主机名及其优先级。</p>
<p>在分析DNS的数据过程中，常常能见到各种不同种类的怪异的Rdata。我们把不能有效反应域名和rdata的对应关系的数据称为“无效Rdata”。对这些无效Rdata进行分析是理解DNS数据的一个有趣的切入点。</p>
<p>另外，结合最近火爆的威胁情报，发现很多的数据源中，都包含了这些“无效的Rdata”，它们降低了这些威胁情报的质量。因此对这些无效rdata的过滤是提高威胁情报质量的一个重要手段。</p>
<p>尽管还有很多其他类型的无效的rdata，但是相比IP地址来说，其他种类的数据影响较小。因此本文主要讨论IP地址。</p>
<h1 id="dnssinkholeip">DNS Sinkhole的IP地址</h1>
<p>DNS Sinkhole是安全厂商为了研究恶意软件的行为，将恶意软件的网络流量进行接管的一种方式，具体参见<a href="https://en.wikipedia.org/wiki/DNS_sinkhole">wiki的定义</a>。</p>
<p>从PassiveDNS中的数据来看，sinkhole的域名主要集中在使用DGA技术产生随机域名的恶意软件上。比如<a href="__GHOST_URL__/conficker-domain-abuse/">上一篇blog</a>中提到的conficker，以及大名鼎鼎的GOZ等。现在来看，多数的DGA域名都已经被不同的安全机构做了sinkhole。</p>
<p>除了DGA域名之外，也有安全厂商对特定的恶意软件进行sinkhole，比如卡巴斯基就惯用这种手法对未知的恶意软件使用sinkhole对其网络行为进行研究。</p>
<p>因此如果你的情报数据中出现了sinkhole的IP地址。说明在安全行为分析上面是完善的，尤其是针对恶意域名的研究是完善的，可是这种分析可能不是最新的。它已经落后于其他的某些安全机构，如果在研究过程中和这些IP有过通信（多数情况都无法正常通信），那么你的某些研究行为也可能已经暴露在那些安全机构面前。</p>
<p>由于各家安全研究机构对自身的sinkhole的保密性，业界尚未有完整的sinkhole列表。但是一些安全研究机构也做了一些整理，比如abuse.ch的<a href="https://sinkdb.abuse.ch/">sinkdb</a>。</p>
<h1 id="nxdomainip">NXDomain引起的虚假IP地址</h1>
<p>NXDomain的含义是指对于不存在的域名，DNS系统能够返回确定的IP地址。但如果继续访问的话，这些IP地址呈现的内容往往和你想要的又完全不同。其实上一节的sinkhole也是这种情况当中的一种，只是sinkhole在安全研究方面比较特殊，我们把它单独列了出来。</p>
<p>造成NXdomain有确定IP映射的原因其实不尽相同，我们列举几种比较常见的情况。</p>
<h2 id="">运营商的问题</h2>
<p>运营商针对不存在的域名，返回自己控制的IP以达到导流的目的，这种现象我们司空见惯。并且这种行为并不仅仅发生在国内，在全世界各地都存在这种“劫持”行为。以至于Google的chrome浏览器（以及基于chrome内核的其他浏览器）在启动的时候要<a href="https://mikewest.org/2012/02/chrome-connects-to-three-random-domains-at-startup">发送随机DNS查询</a>对这种“劫持”行为进行探测以免干扰浏览器的正常工作。</p>
<p>在实际网络环境中，大量的恶意软件会产生无效域名请求，比如未被sinkhole或者sinkhole不完全的DGA域名等。另外各种扫描器以及形如散列前缀攻击的攻击行为都会产生大量的无效域名请求。</p>
<p>如果不加筛选将这种IP列入分析结果，输出为IP黑名单。尽管实际用户使用可能危害并不明显，但是准确度却打了折扣。尤其是在涉及到僵尸网络的C&amp;C分析的时候，会对分析结果造成很大的挑战。</p>
<h2 id="dnsresolver">DNS resolver的问题</h2>
<p>也许是为了避免被运营商劫持，大量用户开始使用公开的非运营商的open resolver作为自己的DNS服务器。而现在越来越多的DNS服务器提供安全服务，而这种安全服务从技术上来看，与运营商劫持的手法相同。即它们会将其认为存在安全隐患的域名返回为一个其控制的IP地址。页面内容一般是比较显著的安全提示信息。<br>
典型的例子是OpenDNS。其提供安全服务的一个IP地址为146.112.61.105。</p>
<p>同运营商的问题类似，将这类IP地址输出为IP黑名单，对实际用户并不会有太大的影响（其实会干扰这些DNS resolver的功能完整性），但是对所分析问题的准确度有影响。根据我们对PassiveDNS数据的分析，这类IP的数量不在少数。</p>
<h2 id="">注册商的问题</h2>
<p>如果说前两种情况发生在DNS查询过程中靠近用户这一侧，是对查询结果的劫持。那么由注册商引起的虚假应答就属于“官方作假”了。</p>
<p>从技术手段上来说，实现这种“官方作假”很简单，只需要把对应域名的<a href="https://en.wikipedia.org/wiki/Wildcard_DNS_record">泛解析</a>开启即可。</p>
<h3 id="tld">顶级域（TLD）级别</h3>
<p>在我们的印象中，TLD的管理应该是合规慎重的。因此第一次了解到泛解析开在TLD级别上还是有些吃惊。<br>
现在发现至少ws、sy、ph这几个ccTLD是开启泛解析的。因此如果在分析域名时，发现TLD为这几个后缀的域名，还请留意一下是否为泛解析的IP地址。一个典型的例子银行木马是<a href="http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/dyre-emerging-threat.pdf">dyre</a>的DGA域名有的是以ws作为TLD，显然它们都会有有效的解析地址，但并不是真正的C&amp;C地址。</p>
<p>随着ICANN开放TLD的注册，现在越来越多的TLD可供选择。也许为了利益的目的，在TLD上开放泛解析的行为也必然会越来越多。</p>
<h1 id="ip">特殊用途的IP</h1>
<h2 id="111122228888114114114114">形如1.1.1.1/2.2.2.2/8.8.8.8/114.114.114.114等</h2>
<p>如果在PassiveDNS中以类似如上IP进行查询，能够发现大量的域名与这些IP存在对应关系。尽管这些IP中有些并不可达，比如1.1.1.1，2.2.2.2；有些则完全另有他用，比如8.8.8.8, 114.114.114.114都是知名的DNS resolver。</p>
<p>造成这种对应关系的原因有多种：一种可能是管理员用于测试的配置，还有一种可能是某些DNS服务器在检测到攻击之后，对某些请求返回一些知名的地址。比如我们见到针对DNS的散列前缀攻击，有些DNS服务器对散列前缀的域名返回8.8.8.8以及8.8.4.4的情况。</p>
<p>要说明的是第二种情况是必须禁止的，某些情况下，错误的返回会导致返回地址遭到大流量的DDoS攻击。这种情况在真实环境中出现过。</p>
<h2 id="">保留地址</h2>
<p>最常见的保留地址就是我们熟悉的私网地址：10.0.0.0/8，172.16.0.0/12，192.168.0.0/16。它们在PassiveDNS中作为rdata并不罕见。显然这是内网数据泄漏的典型，将内网的网络拓扑一览无余的对外暴露了。</p>
<p>其他的保留地址也有出现，比如传统意义上的D类和E类地址，以及用于TEST-NET的保留地址等。<br>
完整的保留地址参见wiki的<a href="https://en.wikipedia.org/wiki/Reserved_IP_addresses">保留地址列表</a>。</p>
<p>同上一节的原因相同，造成这种问题的原因既有可能是配置错误，也有可能是一种安全防御手段。作为一种安全防御手段，尽管用保留地址在某种意义上来说比胡乱指向其它的有效IP更为保险，但是这种行为仍不建议。</p>
<h1 id="">结束语</h1>
<p>这篇文章简单的列举了几类无效rdata的情况。它们可能是造成黑名单不准确的一个因素。当然，还有很多其他的因素也有可能对rdata的准确度造成影响，比如国家防火墙造成的域名IP的映射混乱，比如虚拟主机提供商所造成数据准确度的偏差以及那些我们尚未认识到的原因造成的数据错误等等。这里我们无法对每种原因都进行详细的说明，但是在数据分析的过程中需要我们不断的对每种情况进行分析才有可能认清网络世界，同时才能够产生高质量的数据。</p>
<p>文中提到的这些数据，<a href="http://netlab.360.com/">360网络安全研究院</a>都有整理。任何想法都欢迎与我们交流。</p>
<!--kg-card-end: markdown-->
所谓Rdata是指在DNS记录中与类型相关的数据部分。比如对于DNS的A记录中的IPv4地址或者MX记录中的主机名及其优先级。


在分析DNS的数据过程中，常常能见到各种不同种类的怪异的Rdata。我们把不能有效反应域名和rdata的对应关系的数据称为“无效Rdata”。对这些无效Rdata进行分析是理解DNS数据的一个有趣的切入点。


另外，结合最近火爆的威胁情报，发现很多的数据源中，都包含了这些“无效的Rdata”，它们降低了这些威胁情报的质量。因此对这些无效rdata的过滤是提高威胁情报质量的一个重要手段。


尽管还有很多其他类型的无效的rdata，但是相比IP地址来说，其他种类的数据影响较小。因此本文主要讨论IP地址。



DNS Sinkhole的IP地址


DNS Sinkhole是安全厂商为了研究恶意软件的行为，将恶意软件的网络流量进行接管的一种方式，具体参见wiki的定义。


从PassiveDNS中的数据来看，sinkhole的域名主要集中在使用DGA技术产生随机域名的恶意软件上。比如上一篇blog中提到的conficker，以及大名鼎鼎的GOZ等。现在来看，多数的DGA域名都已经被不同的安全机构做了sinkhole。


除了DGA域名之外，也有安全厂商对特定的恶意软件进行sinkhole，比如卡巴斯基就惯用这种手法对未知的恶意软件使用sinkhole对其网络行为进行研究。


因此如果你的情报数据中出现了sinkhole的IP地址。说明在安全行为分析上面是完善的，尤其是针对恶意域名的研究是完善的，可是这种分析可能不是最新的。它已经落后于其他的某些安全机构，如果在研究过程中和这些IP有过通信（多数情况都无法正常通信），那么你的某些研究行为也可能已经暴露在那些安全机构面前。


由于各家安全研究机构对自身的sinkhole的保密性，业界尚未有完整的sinkhole列表。但是一些安全研究机构也做了一些整理，比如abuse.ch的sinkdb。



NXDomain引起的虚假IP地址


NXDomain的含义是指对于不存在的域名，DNS系统能够返回确定的IP地址。但如果继续访问的话，这些IP地址呈现的内容往往和你想要的又完全不同。其实上一节的sinkhole也是这种情况当中的一种，只是sinkhole在安全研究方面比较特殊，我们把它单独列了出来。


造成NXdomain有确定IP映射的原因其实不尽相同，我们列举几种比较常见的情况。



运营商的问题


运营商针对不存在的域名，返回自己控制的IP以达到导流的目的，这种现象我们司空见惯。并且这种行为并不仅仅发生在国内，在全世界各地都存在这种“劫持”行为。以至于Google的chrome浏览器（以及基于chrome内核的其他浏览器）在启动的时候要发送随机DNS查询对这种“劫持”行为进行探测以免干扰浏览器的正常工作。


在实际网络环境中，大量的恶意软件会产生无效域名请求，比如未被sinkhole或者sinkhole不完全的DGA域名等。另外各种扫描器以及形如散列前缀攻击的攻击行为都会产生大量的无效域名请求。


如果不加筛选将这种IP列入分析结果，输出为IP黑名单。尽管实际用户使用可能危害并不明显，但是准确度却打了折扣。尤其是在涉及到僵尸网络的C&C分析的时候，会对分析结果造成很大的挑战。



DNS resolver的问题


也许是为了避免被运营商劫持，大量用户开始使用公开的非运营商的open resolver作为自己的DNS服务器。而现在越来越多的DNS服务器提供安全服务，而这种安全服务从技术上来看，与运营商劫持的手法相同。即它们会将其认为存在安全隐患的域名返回为一个其控制的IP地址。页面内容一般是比较显著的安全提示信息。

典型的例子是OpenDNS。其提供安全服务的一个IP地址为146.112.61.105。


同运营商的问题类似，将这类IP地址输出为IP黑名单，对实际用户并不会有太大的影响（其实会干扰这些DNS resolver的功能完整性），但是对所分析问题的准确度有影响。根据我们对PassiveDNS数据的分析，这类IP的数量不在少数。



注册商的问题


如果说前两种情况发生在DNS查询过程中靠近用户这一侧，是对查询结果的劫持。那么由注册商引起的虚假应答就属于“官方作假”了。


从技术手段上来说，实现这种“官方作假”很简单，只需要把对应域名的泛解析开启即可。



顶级域（TLD）级别


在我们的印象中，TLD的管理应该是合规慎重的。因此第一次了解到泛解析开在TLD级别上还是有些吃惊。

现在发现至少ws、sy、ph这几个ccTLD是开启泛解析的。因此如果在分析域名时，发现TLD为这几个后缀的域名，还请留意一下是否为泛解析的IP地址。一个典型的例子银行木马是dyre的DGA域名有的是以ws作为TLD，显然它们都会有有效的解析地址，但并不是真正的C&C地址。


随着ICANN开放TLD的注册，现在越来越多的TLD可供选择。也许为了利益的目的，在TLD上开放泛解析的行为也必然会越来越多。



特殊用途的IP



形如1.1.1.1/2.2.2.2/8.8.8.8/114.114.114.114等


如果在PassiveDNS中以类似如上IP进行查询，能够发现大量的域名与这些IP存在对应关系。尽管这些IP中有些并不可达，比如1.1.1.1，2.2.2.2；有些则完全另有他用，比如8.8.8.8, 114.114.114.114都是知名的DNS resolver。


造成这种对应关系的原因有多种：一种可能是管理员用于测试的配置，还有一种可能是某些DNS服务器在检测到攻击之后，对某些请求返回一些知名的地址。比如我们见到针对DNS的散列前缀攻击，有些DNS服务器对散列前缀的域名返回8.8.8.8以及8.8.4.4的情况。


要说明的是第二种情况是必须禁止的，某些情况下，错误的返回会导致返回地址遭到大流量的DDoS攻击。这种情况在真实环境中出现过。



保留地址


最常见的保留地址就是我们熟悉的私网地址：10.0.0.0/8，172.16.0.0/12，192.168.0.0/16。它们在PassiveDNS中作为rdata并不罕见。显然这是内网数据泄漏的典型，将内网的网络拓扑一览无余的对外暴露了。


其他的保留地址也有出现，比如传统意义上的D类和E类地址，以及用于TEST-NET的保留地址等。

完整的保留地址参见wiki的保留地址列表。


同上一节的原因相同，造成这种问题的原因既有可能是配置错误，也有可能是一种安全防御手段。作为一种安全防御手段，尽管用保留地址在某种意义上来说比胡乱指向其它的有效IP更为保险，但是这种行为仍不建议。



结束语


这篇文章简单的列举了几类无效rdata的情况。它们可能是造成黑名单不准确的一个因素。当然，还有很多其他的因素也有可能对rdata的准确度造成影响，比如国家防火墙造成的域名IP的映射混乱，比如虚拟主机提供商所造成数据准确度的偏差以及那些我们尚未认识到的原因造成的数据错误等等。这里我们无法对每种原因都进行详细的说明，但是在数据分析的过程中需要我们不断的对每种情况进行分析才有可能认清网络世界，同时才能够产生高质量的数据。


文中提到的这些数据，360网络安全研究院都有整理。任何想法都欢迎与我们交流。

{"version":"0.3.1","markups":[],"atoms":[],"cards":[["markdown",{"cardName":"card-markdown","markdown":"所谓Rdata是指在DNS记录中与类型相关的数据部分。比如对于DNS的A记录中的IPv4地址或者MX记录中的主机名及其优先级。\n\n在分析DNS的数据过程中，常常能见到各种不同种类的怪异的Rdata。我们把不能有效反应域名和rdata的对应关系的数据称为“无效Rdata”。对这些无效Rdata进行分析是理解DNS数据的一个有趣的切入点。\n\n另外，结合最近火爆的威胁情报，发现很多的数据源中，都包含了这些“无效的Rdata”，它们降低了这些威胁情报的质量。因此对这些无效rdata的过滤是提高威胁情报质量的一个重要手段。\n\n尽管还有很多其他类型的无效的rdata，但是相比IP地址来说，其他种类的数据影响较小。因此本文主要讨论IP地址。\n\n#DNS Sinkhole的IP地址\nDNS Sinkhole是安全厂商为了研究恶意软件的行为，将恶意软件的网络流量进行接管的一种方式，具体参见[wiki的定义](https://en.wikipedia.org/wiki/DNS_sinkhole)。\n\n从PassiveDNS中的数据来看，sinkhole的域名主要集中在使用DGA技术产生随机域名的恶意软件上。比如[上一篇blog](__GHOST_URL__/conficker-domain-abuse/)中提到的conficker，以及大名鼎鼎的GOZ等。现在来看，多数的DGA域名都已经被不同的安全机构做了sinkhole。\n\n除了DGA域名之外，也有安全厂商对特定的恶意软件进行sinkhole，比如卡巴斯基就惯用这种手法对未知的恶意软件使用sinkhole对其网络行为进行研究。\n\n因此如果你的情报数据中出现了sinkhole的IP地址。说明在安全行为分析上面是完善的，尤其是针对恶意域名的研究是完善的，可是这种分析可能不是最新的。它已经落后于其他的某些安全机构，如果在研究过程中和这些IP有过通信（多数情况都无法正常通信），那么你的某些研究行为也可能已经暴露在那些安全机构面前。\n\n由于各家安全研究机构对自身的sinkhole的保密性，业界尚未有完整的sinkhole列表。但是一些安全研究机构也做了一些整理，比如abuse.ch的[sinkdb](https://sinkdb.abuse.ch/)。 \n\n#NXDomain引起的虚假IP地址\nNXDomain的含义是指对于不存在的域名，DNS系统能够返回确定的IP地址。但如果继续访问的话，这些IP地址呈现的内容往往和你想要的又完全不同。其实上一节的sinkhole也是这种情况当中的一种，只是sinkhole在安全研究方面比较特殊，我们把它单独列了出来。\n\n造成NXdomain有确定IP映射的原因其实不尽相同，我们列举几种比较常见的情况。\n##运营商的问题\n运营商针对不存在的域名，返回自己控制的IP以达到导流的目的，这种现象我们司空见惯。并且这种行为并不仅仅发生在国内，在全世界各地都存在这种“劫持”行为。以至于Google的chrome浏览器（以及基于chrome内核的其他浏览器）在启动的时候要[发送随机DNS查询](https://mikewest.org/2012/02/chrome-connects-to-three-random-domains-at-startup)对这种“劫持”行为进行探测以免干扰浏览器的正常工作。\n\n在实际网络环境中，大量的恶意软件会产生无效域名请求，比如未被sinkhole或者sinkhole不完全的DGA域名等。另外各种扫描器以及形如散列前缀攻击的攻击行为都会产生大量的无效域名请求。\n\n如果不加筛选将这种IP列入分析结果，输出为IP黑名单。尽管实际用户使用可能危害并不明显，但是准确度却打了折扣。尤其是在涉及到僵尸网络的C&C分析的时候，会对分析结果造成很大的挑战。\n##DNS resolver的问题\n也许是为了避免被运营商劫持，大量用户开始使用公开的非运营商的open resolver作为自己的DNS服务器。而现在越来越多的DNS服务器提供安全服务，而这种安全服务从技术上来看，与运营商劫持的手法相同。即它们会将其认为存在安全隐患的域名返回为一个其控制的IP地址。页面内容一般是比较显著的安全提示信息。\n典型的例子是OpenDNS。其提供安全服务的一个IP地址为146.112.61.105。\n\n同运营商的问题类似，将这类IP地址输出为IP黑名单，对实际用户并不会有太大的影响（其实会干扰这些DNS resolver的功能完整性），但是对所分析问题的准确度有影响。根据我们对PassiveDNS数据的分析，这类IP的数量不在少数。\n\n##注册商的问题\n如果说前两种情况发生在DNS查询过程中靠近用户这一侧，是对查询结果的劫持。那么由注册商引起的虚假应答就属于“官方作假”了。\n\n从技术手段上来说，实现这种“官方作假”很简单，只需要把对应域名的[泛解析](https://en.wikipedia.org/wiki/Wildcard_DNS_record)开启即可。\n###顶级域（TLD）级别\n在我们的印象中，TLD的管理应该是合规慎重的。因此第一次了解到泛解析开在TLD级别上还是有些吃惊。\n现在发现至少ws、sy、ph这几个ccTLD是开启泛解析的。因此如果在分析域名时，发现TLD为这几个后缀的域名，还请留意一下是否为泛解析的IP地址。一个典型的例子银行木马是[dyre](http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/dyre-emerging-threat.pdf)的DGA域名有的是以ws作为TLD，显然它们都会有有效的解析地址，但并不是真正的C&C地址。\n\n随着ICANN开放TLD的注册，现在越来越多的TLD可供选择。也许为了利益的目的，在TLD上开放泛解析的行为也必然会越来越多。\n#特殊用途的IP\n##形如1.1.1.1/2.2.2.2/8.8.8.8/114.114.114.114等\n如果在PassiveDNS中以类似如上IP进行查询，能够发现大量的域名与这些IP存在对应关系。尽管这些IP中有些并不可达，比如1.1.1.1，2.2.2.2；有些则完全另有他用，比如8.8.8.8, 114.114.114.114都是知名的DNS resolver。\n\n造成这种对应关系的原因有多种：一种可能是管理员用于测试的配置，还有一种可能是某些DNS服务器在检测到攻击之后，对某些请求返回一些知名的地址。比如我们见到针对DNS的散列前缀攻击，有些DNS服务器对散列前缀的域名返回8.8.8.8以及8.8.4.4的情况。\n\n要说明的是第二种情况是必须禁止的，某些情况下，错误的返回会导致返回地址遭到大流量的DDoS攻击。这种情况在真实环境中出现过。\n##保留地址\n最常见的保留地址就是我们熟悉的私网地址：10.0.0.0/8，172.16.0.0/12，192.168.0.0/16。它们在PassiveDNS中作为rdata并不罕见。显然这是内网数据泄漏的典型，将内网的网络拓扑一览无余的对外暴露了。\n\n其他的保留地址也有出现，比如传统意义上的D类和E类地址，以及用于TEST-NET的保留地址等。\n完整的保留地址参见wiki的[保留地址列表](https://en.wikipedia.org/wiki/Reserved_IP_addresses)。\n\n同上一节的原因相同，造成这种问题的原因既有可能是配置错误，也有可能是一种安全防御手段。作为一种安全防御手段，尽管用保留地址在某种意义上来说比胡乱指向其它的有效IP更为保险，但是这种行为仍不建议。\n\n#结束语\n这篇文章简单的列举了几类无效rdata的情况。它们可能是造成黑名单不准确的一个因素。当然，还有很多其他的因素也有可能对rdata的准确度造成影响，比如国家防火墙造成的域名IP的映射混乱，比如虚拟主机提供商所造成数据准确度的偏差以及那些我们尚未认识到的原因造成的数据错误等等。这里我们无法对每种原因都进行详细的说明，但是在数据分析的过程中需要我们不断的对每种情况进行分析才有可能认清网络世界，同时才能够产生高质量的数据。\n\n文中提到的这些数据，[360网络安全研究院](http://netlab.360.com/)都有整理。任何想法都欢迎与我们交流。\n"}]],"sections":[[10,0]],"ghostVersion":"3.0"}