解析服务提供商对非授权域名解析情况的评估

概要

在之前的文章中，我们披露了Specter僵尸网络序利用api[.]github.com等白域名提供C2服务，以此来逃避基于签名和威胁情报匹配的安全产品的检测。其具体原理经过分析之后，发现其利用了某些域名注册/托管商(cloudns)的权威DNS服务器在解析非其客户域名方面的漏洞。
我们对此现象，即域名注册/托管商，公有云提供商等能够提供域名注册和解析服务的供应商（以下统称为解析服务提供商）对非自己服务域名的DNS请求是否能够返回正确应答的情况，进行了系统的测量和评估。

这篇文章对此现象进行了分析。

数据选择及评估方法

被测域名

被测试域名：Alexa top500。选择他们作为被测域是因为：

这些域名都会使用自己专有的DNS服务器，他们并不会使用外部的解析服务提供商提供的解析服务。所以如果这些域名可以被外部的解析服务提供商的NS服务器解析，那么大概率是非授权的。
这些域名本身也因为其庞大而知名的业务，会被加入到各种白名单中。一些出于探测目的的人也更容易随手添加一些知名网站，而干坏事的人微了躲避检测黑名单检测，也愿意使用这些白域名。

其实使用DNS流量对域名进行排名更能精确的反应域名的流行度。360netlab的DNSMon系统可以按照域名在DNS流量中出现的时间跨度，频次，解析稳定性等多维度来计算域名在大网的流行程度，并按天更新排名。我们没有使用它作为被测域名也是出于大众对域名排名的认知。
其实如果要躲避的检测话，白名单域名中的CDN业务或者其他类似的后台功能自动出发的流行域名也是非常合适的选择。

测试服务器

测试的NS服务器：即解析提供商。从360netlab的passiveDNS库中提取，在最近半年活跃且为超过500个独立的二级域名提供解析服务的NS服务器，18469个。

测试方法

将被测域名逐个通过测试服务器尝试解析（UDP/53），如果测试服务器的DNS返回结果为NOERROR（无论是否有真实的RDATA的返回），则认为被测服务器提供了对被测域名的解析。

可能存在的误差

主要来自于数据误差，产生的原因是链路劫持。
为了覆盖最广泛的情况，我们采用udp/53的方式来收集测试数据。尽管我们已经采用了最大的努力来排除劫持的可能，考虑到较为复杂的链路环境，仍可能有少量的数据存在DNS解析结果被劫持的可能。
因为我们已经排除了最常见的劫持情况，所以即使可能有少量的劫持并不影响整体的结论。

评估结果

整体的解析情况

在18469个NS服务器中，能解析到地址的有18154个整体占比98.29%。在能解析到地址并且有有响应的服务器有17792个，占总数的96.33%。尽管筛选的是近半年有解析记录的NS服务器，在仍有3.67%的服务器在做测试的时候处在不活跃的状态，由此可以见NS服务提供商的基础设施处在不停的变动之中。
下文以这17792个NS的数据作为分析基础。

在解析数量方面，17792个NS服务器的响应率为70.12% ~（6237860/(17792*500)），也就是说30%的请求在服务器活跃的情况下丢失了，一般都是服务器超时导致的。
在所有的响应中，Rcode为Refuse的比例为75，NOERROR的比例大约为22%。具体分布如下图
在NS服务器方面，17792个NS服务器中，返回NOERROR记录的NS服务器有9544个，占比约为53.64%。
在NS服务器的二级域方面，17792个NS对应4149个二级域，其中有返回NOERROR记录的二级域有1687个，约占总数的40.66%左右。也就是说在我们选定的测试服务器中大概有40%的NS服务器会返回非自己客户的域名解析。

根据经验，如果这种解析记录是由用户个人添加的话，猜测排名越高的域名被添加和解析的可能性越大。所以我们对每一个返回NOERROR的被测服务器都统计了其Alexa Top100的解析占比以及全部的被测域名的解析（即Alexa Top500）占比。我们按照解析服务器对Alexa Top100域名的解析成功率进行排序。其统计曲线如下所示：

从图中可以明显的看到这9544个服务器可以分为4组，即

排名在1～2250的NS服务器对top100和top500的域名解析比例都在60%以上
排名在2250～3300的NS服务器对被测域名的解析离开快速的从60%下降到不足20%
排名在3300～6000的NS服务器解析比例从20%缓慢的下降到2%左右
排名在6000之后的NS服务器则偶有少量的解析，比例基本在1%左右。

另外从图中也可以看出来，被测域名处在Alexa Top100和Top500的比例没有显著的差异。这可能的原因是Alexa排名靠前的域名无论是100还是500对用户的感知差异不大。

解析结果的分析

另外一个对这个数据分析的角度是从其解析结果来看。这些NS服务器到底将这些流行域名解析到了哪里。
经过统计，在返回的结果中，大约有20.92%的数据在二级域上没有配置有效的DNS记录，但是返回为NOERROR，此种情况多数是针对被探测域名配置了对应的NS服务器，但是没有配置其他类型的记录所致。

解析出的IP的情况

在配置了解析记录的数据中，解析到的IP地理位置主要集中在美国，接下来是中国和俄罗斯。Top10的分布如下：

   4378 United_States
    579 China
    395 Russian_Federation
    350 United_Kingdom
    216 CLOUDFLARE.COM
    213 Netherlands
    212 Germany
    209 Japan
    195 Republic_of_Korea
    123 Singapore

值的一提的是，在众多的解析记录中，有大约3%做有的解析结果为保留地址或者私有地址，在众多的此类地址中，最让人喜爱的仍然是127.0.0.1。Top10的地址如下：

  33093 127.0.0.1
    856 10.10.34.35
    425 192.168.3.3
    154 10.10.10.10
     69 10.10.34.36
     52 10.152.68.117
     45 10.10.34.34
     42 192.168.1.1
     27 127.0.0.11
     22 0.0.0.0

记录添加人是谁？

如果解析服务商可以对目标域名提供解析，那么添加这种解析记录的人是谁？
从探测的数据中，我们发现大量的解析服务提供商对不同被测域名解析的结果是相同的。我们利用这个特点，统计了NS服务器和其解析结果rdata相同的情况下，能够映射到不同的域名的数量，如果此数量超过20，则认为是解析商自己添加的。
以此为标准，我们发现 2944 个解析器，占总解析器的16.55%。
如果将接这些解析器聚合到二级域，那么占总二级域的7%左右。

注：此处的添加人的角色判定过程是一个猜测。现在有很多注册商允许用户批量添加域名，那么在批量添加的情况下，上面计算过程使用的阈值就显得比较低了，猜测为注册商自己添加的结论也就不成立了。
我们此处假设整个添加过程仍然是个人测试性为主导，并没有使用解析商提供的批量功能。

解析结果的错误率

解析服务商对这些域名的解析可能是非授权的，不过也有可能存在解析结果和权威解析服务器返回相同结果的可能。我们对非授权的解析服务商解析的结果与正确的解析结果做了对比，发现80%的域名（即400个）的解析结果错误率在90%以上，最好情况的域名错误解析率也高达68%，这个比例高的有点让人吃惊。
不同域名解析错误率曲线如下：

域名角度

top500域名在多少个NS上有解析？占比分布怎么样
500个域名中，最少被解析的域名为express.dhl，有1483个NS服务器可以解析它，最多的则为yts.mx，有3114个NS服务器可以解析它。不过从他们解析的结果来看，不同的域名解析的rdata个数比较稳定，大多都在800左右。可见对流行域名来说，被添加到各种非授权的解析商是非常普遍但是让人非常吃惊的事情。具体分布如下图：

案例分析

为什么这么多流行域名会加入被非授权的NS服务器解析。从整体上无法深入细节来查看，我们以yts.mx 和mozilla.org为例来看看具体的情况。

yts.mx

选择yts.mx分析是因为它是我们本次测试中，解析NS服务器最多的一个域名。
yts.mx是通过p2p协议工具使用BitTorrents等工具下载电影的网站，在我们使用的Alexa数据中排名462。通过passiveDNS.cn来查看，其从2020年4月开始，一直使用cloudflare作为其解析商。

因为本次测试中，因为包含了cloudflare的NS服务器，而yts.mx的官方解析商也是cloudlfare，在排除掉cloudflare之后，仍有2886个非授权解析服务器可以解析yts.mx，这个数量仍然可以排在我们本次测试的TOP5。

在2886个非授权解析服务器中，仅有73个可以解析到正确的结果，错误解析率高达97.47%，这个比例是让人吃惊的。
从非授权解析服务器来看其涵盖的二级域名有383个，主要是域名注册商。头部的10个解析器的二级域名如下：

    846 hostgator.com
    520 gandi.net
    369 register.com
     83 orderbox-dns.com
     70 worldnic.com
     51 dan.hosting
     47 hostgator.mx
     33 ztomy.com
     30 cloudns.net
     16 zoneedit.com

这个列表中大多都是提供域名注册，web服务托管，主机服务等IT基础服务提供商。不出所料我们上一篇文章中提到的cloudns在列。

从解析错误的IP来看，2886个非授权解析服务器，共解析到750个IP地址，聚合到了149个网段。其中top10的网段及这些网段的用途分析如下：

mozilla.org

选择mozilla.org是因为mozilla.org是火狐浏览器的官方网站，在我们使用的Alexa 排名182，为大众所熟知。mozilla.org的权威NS服务器通过passiveDNS.cn 来查看，其从2014年开始就一直使用akamai作为其解析商没有变过。

其解析结果随着时间有变动，但是2020年11月之前使用自己的服务，之后则非常稳定的使用amazon的服务。

但是在实际网络中，能够解析mozilla.org的NS服务器多达2624个，解析的IP地址有735个。
头部的10个解析器的二级域名如下：

    831 hostgator.com
    633 cloudflare.com
    366 register.com
     79 orderbox-dns.com
     75 akam.net
     50 hostgator.mx
     45 dan.hosting
     33 cloudns.net
     14 hostgator.co
     13 zoneedit.com

和yts.mx类似，这个列表中大多都是提供域名注册，web服务托管，主机服务等IT基础服务提供商。同样不出所料我们上一篇文章中提到的cloudns也在列。

另一个值得关注的点是 akam.net 自身也有75个服务器提供对mozilla.org的解析，不过所有的服务器解析结果是相同且正确的。也就是说akamai提供的权威解析器可以交叉解析其托管域名。

除此之外，cloudflare的解析看起来可能也是对的。为什么是可能？因为我们发现从passiveDNS数据来看从2016年4月份开始，一直到2021年11月份，www.mozilla.org 使用了cloudflare的CDN服务，其CNAME记录是cloudflare.net，从2021年11月开始逐步切换到了amazon。不过 mozilla.org的ns服务器从未使用过cloudlfare的解析器。

从解析结果来看，除掉akam.net以及cloudflare.com之外，仅有62个解析器可以正确的将解析结果返回。也就是说70%的非授权解析器解析结果是错误的，这个比例也同样让人吃惊。

在解析的错误IP方面，730个错误IP（有5个IP是正确的解析结果），聚合到了153个CIDR/24网段，其中top10网段占总错误解析量的75.9%。我们详细分析了错误解析的Top10的CIDR/24网段，发现主要是域名注册/解析商注册，最终解析目的IP是用于域名停靠、重定向以及域名出售等目的，基本都是域名注册商的赚钱的基本手段。具体结果见下图：

从以上两个案例来看，目前提供这种非授权解析服务的主要是域名注册/解析商注册，最终解析目的IP是用于域名停靠、重定向以及域名出售等目的，基本都是域名注册商的赚钱的基本手段。

安全检测

首先这种现象为什么没有引起关注？需要说明的是尽管它广泛存在，但是流量整体比较少，整体流量少是因为入口流量少，大多数的DNS流量走的公共DNS服务器，所以除非在特定网络环境下，否则此种现象很难被注意到。

其次解析服务提供商对非授权域名的解析在安全方面带来了不少的挑战。新的DNS安全检测角度，需要扩展，既要看域名，也要看域名使用的DNS服务器，同时还要看解析结果是否和真实的解析结果一致。

NS服务器角度

在传统的检测方法中，一般对DNS服务器一般会忽略。在APT组织海莲花的攻击行为中，就曾经出现过特定域名只有特定的NS服务器才可以解析的情况。
因此小众的DNS是很值得关注的。这里说的小众就是指其请求客户端少，请求域名数量少。尤其是在网络等级较高的环境中，客户端直接和小众的DNS服务器通信的情况就值得做进一步的分析了。

流量侧角度

从流量中筛选出小众的DNS服务器
筛选出网络内DNS服务器与客户端
针对客户端与小众DNS服务器的流量进行检查
检查结果和大众解析结果进行比对
如果存在差异，需要结合其他维度的数据做进一步分析

结论

组织内网要规范使用DNS服务器，对于组织内的非递归服务器之外的其他DNS请求的目标地址要做严格的检查和筛选
域名解析提供商广泛的解析非自己客户的域名
提供这种业务的主力是域名注册商，目的（猜测）是为了拉拢客户或者提升流量
业界没有统一的标准来规范此类解析行为
已经出现恶意程序使用这种方式逃避检测
对基于签名和威胁情报简单匹配的安全产品存在较大的挑战