基于“日志审计应用”的 DNS 日志洞察实践_云计算

作者：羿莉 (萧羿)

基础背景

dns(domain name system) [ 1] 是任何网络活动的基础。它将易于记忆的域名转换为机器能够理解的 ip 地址。监控 dns 服务可以帮助用户识别网络活动并保持系统安全。出于合规和安全性的考虑，公司通常要求对网络日志进行存储和分析。通过 dns 日志，可以清晰了解企业域名解析的使用情况，于发现配置错误和不必要的网络障碍，减少系统中断，在帮助企业对用户行为、网络行为进行审计的同时，及时发现潜在的安全问题。

dns 解析流程

dns 查询的结果通常会在本地域名服务器中进行缓存，如果本地域名服务器中有缓存的情况下，则会跳过如下 dns 查询步骤，很快返回解析结果。下面的示例则概述了本地域名服务器没有缓存的情况下，dns 查询所需的几个步骤：

dns 记录类型

dns（域名系统）中存在多种不同类型的记录，每种记录类型有特定的用途。以下是一些最常见的 dns 记录类型及其解释：

以上是一些基本的 dns 记录类型，每种类型在日常网络和域名的解析中扮演着重要角色。

日志审计

日志审计应用概况

日志审计服务 [ 2] 是阿里云日志服务 sls [ 3] 平台下的一款应用，它在继承了日志服务 sls 的全部功能以外，还有强大的多账号管理及跨地域采集阿里云各种云产品日志的功能，并且支持通过资源目录 [ 4] （resource directory）的方式有组织性地统一地管理和记录多账号下云产品实例的日志信息。

如何开通 dns 日志采集

登录 sls 产品控制台 [ 5] 。
在日志应用 栏选择审计与安全 页签，然后单击日志审计服务。

在全局配置 页面，将 dns 的日志审计开关打开并选择中心项目 project 所在区域 ，例如 cn-hangzhou；详细操作步骤参见开启日志采集功能 [ 6] 。

日志审计现已支持内网 dns 日志、公网 dns 解析日志、全局流量管理日志这三种日志类型，用户可以按需开启。

其他功能

此外，除了基础存储、查询、告警等 sls 功能外，还支持跨账号 [ 7] 采集、精细化采集策略 [ 8] 、terraform [ 9] 配置等功能。此处不详细展开，用户可以参考内网 dns 日志转存 sls [ 10] 进行配置使用。

dns 日志详情

具体的日志字段内容，及解释请参见附录。

内网请求应答示例

日志审计会自动开启用户满足采集策略的地域及 vpc 实例的流量分析功能，详情参见开启 dns 内网日志采集 [ 11] 。开启流量分析功能后，日志会自动转存投递到用户的日志审计 dns 专属库 dns_log 中，下面是具体日志内容及相应字段含义的解释介绍。

dns 请求日志

例如我们查询阿里云日志服务控制台 sls.console.aliyun.com 的 ip 地址。

dig sls.console.aliyun.com +short

在该请求日志内容中，可以看到会话请求 id 为 50999，该 id 会在后续模块应答日志中继续复用，直至得到完整请求应答日志, 请求域名服务器为内网 ecs 的 ip 地址172.16.0.184，响应地址为阿里云内置域名解析服务地址 100.100.2.136，响应端口为 53。

请求日志模块为 global，请求域名为完全限定域名 [1****2] sls.console.aliyun.com.，dns 记录类型为 a 类，请求发出的 ecs 所属的实例在 cn-hangzhou 地域，其 vpc id 为 vpc-bp9fj，ecs 主机 id 为 i-bp19d7，主机名为izbp********d7z，主机所属账号为 148**********782，dns 信息标志为 rd ad ，具体细节可参见附录日志字段说明。

模块应答日志

发出请求后，首先得到一条递归模块应答日志，从根域名服务器开启递归，得到sls.console.aliyun.com. 的 cname 记录为 sls-console-adns.console.aliyun.com.

然后继续查询 sls-console-adns.console.aliyun.com. 得到一条缓存模块应答日志，其对应的 cname 记录为 sls-console-adns.console.aliyun.com.gds.alibabadns.com.

继续查询 sls-console-adns.console.aliyun.com.gds.alibabadns.com. 得到对应的缓存模块应答日志，其 cname 记录为 tyjr-cn-hangzhou.aliyun.com.

继续查询 tyjr-cn-hangzhou.aliyun.com. 找到缓存应答模块对应的 cname 记录为 tyjr-cn-hangzhou.aliyun.com.vipgds.alibabadns.com.

追溯到域名 tyjr-cn-hangzhou.aliyun.com.vipgds.alibabadns.com. 后，得到对应的资源记录应答集合，并找到其真正的 a 记录地址例如 47.97.242.13。

全局应答日志

最后我们得到一条完整的全局应答日志，从而找到 sls.console.aliyun.com. 对应的 ip 地址。

公网解析日志示例

配置公网域名流量分析

首先用户需要进入 dns 控制台 [ 13] ，添加对应的域名，并打开相应域名下的 dns 流量分析功能。

查看公网权威解析日志

dig   y*****.online  @dns27.hichina.com

当前公网解析日志仅包含响应模块，在 sls 日志审计下可以得到如下的响应日志，其结果是一条 soa 记录，指定关于该区域的权威信息，如 dns 区域的主名称服务器，区域的管理员，ttl 等信息。

全局流量管理日志示例

配置全局流量管理模块

首先用户需要进入 dns 控制台，全局流量管理界面，购买全局流量管理实例，并创建接入域名。

查看全局流量管理日志

dig ti*****.g****.net +vc

其响应日志内容记录在日志审计中如下：

洞察 dns 日志

因为 dns 日志包含了丰富的信息，所以知道这些字段的具体解释，以及这些字段出现异常时，其内容所代表的特殊意义，对于我们在网络安全和网络性能中排查定位将会提供很大帮助。下面，本文大概总结了一些在监控 dns 日志时安全运营人员应该注意的信号，掌握这些信号就可以快速而轻松地发现问题。详情可参见附录中日志字段的详细介绍。

query_name 字段， 其内容为查询的完全限定域名 (fqdn [ 14] , fully qualified domain name），可以让用户知道每一次请求应答的具体查询内容。如果查询的 domain 出现在恶意域名列表上，那么该日志就可以作为安全威胁的证据。此外，过多重复的查询可能是恶意活动的一个指标，例如 dos 攻击，在这种攻击中，恶意行为者让目标域名的服务器不堪重负，发送异常超高量的 dns 查询。
query_type 字段， 包含请求的记录类型，当搜寻恶意活动时可以提供有用的上下文。例如，文本（txt） 记录经常被用于指挥和控制（c2）攻击以及 dns 隧道攻击。详细的记录类型可以参见前文背景介绍。
rt 字段， 其内容为请求应答时间，如果 query_type 为 global，则为全局应答 ，表示整个请求到应答的时延，否则模块日志 rt 仅表示在模块内部消耗的时延。如果 rt 值异常提升可能是网络连接问题的一个信号。例如，如果安全运维人员注意到与 dns 日志中 rt 值升高相关的超时错误激增，你可能会推断超时错误是在 dns 解析过程中发生的，这将表明用户的 dns 服务器可能存在问题。
rcode 字段， 即响应状态码，例如：0 表示 noerror，没有错误，查询域名成功；1 表示 formerr，格式错误，dns 无法解析该请求；2 表示 servfail，即 dns 服务器遇到内部错误或者超时引起的解析失败。rcode 为 2 是 dns 无法从权威名称服务器获取有效响应时常见的一种错误。记录这个值的日志可以帮助运维人员找出问题的根本原因。
answer_rrset 字段， 包含 dns 所请求的信息返回的 ip 地址集合，例如 [www.taobao.com 600 a 1.1.1.1]，这个字段的常见值 ip，可以帮助安全运维人员在本地网络上定位受损机器。在公共互联网上，这些 ip 地址可以与恶意行为者 ip 地址的数据库对照检查，例如可以发现是否存在 dns 劫持行为等。
dns_msg_flags 字段， 该字段中有许多请求标志（qr、rd、aa、tc 等），表明如查询是否是递归的、是否包含 dnssec 状态等。这些标志可以为 dns 请求提供重要的上下文，例如所请求的 dns 记录是否来自它的权威名称服务器、以及数据是否被修改。

下面我们通过几个具体的实践案例，深入体验如何洞察 dns 日志。

解析路径劫持

原理背景

通过对 dns 数据包"请求阶段"中的解析路径进行划分，我们将 dns 解析路径分为四类。

首先是正常的 dns 解析路径（normal resolution），用户的 dns 请求只到达指定的公共 dns 服务器；此时，权威服务器应当只看到一个来自公共服务器的请求。

以下三类均属于 dns 解析路径劫持：

请求转发 （request redirection），用户的 dns 请求将直接被重定向到劫持者的解析服务器，解析路径如下图红色路径所示；此时，权威服务器只收到来自这个服务器的请求，用户指定的公共 dns 服务器完全被排除在外。
请求复制 （request replication），用户的 dns 请求被网络中间设备复制，一份去往原来的目的地，一份去往劫持者使用的解析服务器，解析路径如下图橙色路径所示；此时，权威服务器将收到两个相同的查询。
直接应答 （direct responding），用户发出的请求同样被转发，但解析服务器并未进行后续查询而是直接返回一个响应，解析路径如图紫色路径所示；此时，权威服务器没有收到任何查询，但是客户端却收到解析结果。

环境模拟

下面我们将构造一个直接应答的解析路径劫持实验：

1）正常请求返回及日志审计 dns 日志记录如下：

dig aaa.y******.online

在 sls 日志审计的 dns_log 可以看到正常的权威解析的资源记录集 ["y******.online. 600 soa dns27.hichina.com. hostmaster.hichina.com. 2024060609 3600 1200 86400 600 "]，对应的权威 dns 解析服务器为 dns27.hichina.com，因为没有配置对应的 ip 记录，所以应答资源记录集为空。

2）自建 dns 服务器，并配置记录，更改 nameserver 配置

接下来，我们基于 bind [ 15] 自建一个 dns 解析服务器，其 ns 地址为 172.16.0.186，在该 dns 服务器的 zone 数据库文件（y*****.online.zone）下配置一条记录：

[aaa a 172.16.0.189]

3）然后我们修改本地 nameserver，将其地址指向我们自建的 dns 服务器

4）自建 dns 服务器直接应答，跳过前往权威 dns 服务器查询请求过程

此时 dig aaa.y******.online. 返回的 ip 地址为 172.16.0.189，即我们在自建 dns 解析服务器配置的 a 记录返回。没有经过权威解析服务器的请求流程，直接应答一个结果，从而将 aaa.y******.online 域名的访问劫持到我们指定的 ip 地址。

privatezone 域名转发

下面展示一个 private zone 域名转发 的日志洞察示例，比如由于某些业务场景安全需要，需要将某些服务的域名访问地址从公网方式（.xxx.com）切换到 vpc 内网方式（ -vpc-inner.region.xxx.com），而当前线上业务应用部署复杂，业务切换流依赖较多，直接进行业务代码切换的复杂性太大，很容易影响上下游业务，这个时候我们可以通过简单 privatezone 域名转发的案例进行域名切换，从而实现平滑业务流程，无损且快捷地切换到对应链路，而 dns 解析日志可以帮助我们验证域名转发是否配置正确，符合期望。

配置域名转发

验证域名转发

1）此时我们请求域名 ***.xxx.com.

2）经过 private zone 域名转发，经过权威普通模块，得到一个 cname 记录 ***-vpc-inner.cn-hangzhou.xxx.com.，以下为模块应答日志。

继续递归，得到 ***-vpc-inner.cn-hangzhou.xxx.com. 的 cname 记录 ***-vpc-inner.cn-hangzhou.xxx.com.yyy.zzz.com.

继续递归，得到 ***-vpc-inner.cn-hangzhou.xxx.com.yyy.zzz.com. 的 cname 记录 -vpc-inner.cn-hangzhou.xxx.com..com.

等走完全部递归查询，可以得到真正的 ip 地址为 100...35。

3）最终我们得到完整应答日志，得到 ***.xxx.com. 请求所对应的真正的解析地址 ip 记录。因为日志中有完整的 vpc、ecs id、ecs hostname 信息，后续出现问题，安全运维人员可以直接排查定位，判断 dns 解析路径是否符合期望。

解析失败、解析请求异常和解析 rt 异常

解析失败

rcode 是作为应答日志可以反映基本的解析状态，rcode 返回值 servfail（2） 或者 nxdomain （3）是两个较为典型且常见的解析失败场景，前者说明 dns 服务器遇到内部错误或者超时引起的解析失败，后者表示这个域名并未找到。此时我们结合具体的用户阿里云 uid 信息，和具体的 ecs 信息（内网场景）则可以更快捷地定位到此时出现问题的服务。下表是查找访问不存在的域名（rcode=3）的汇总统计记录。

rcode :3  and global | select distinct(query_name),  ecs_hostname, region_id, vpc_id, user_id

解析请求异常

前文已经提到，query_name 字段如果出现安全异常值（例如安全威胁库中已知的恶意地址），则可以作为一个非常直观的安全威胁的证据指标，另外某些 query_name 的解析量飙升，也可以作为判断 dos 攻击的依据，下面是一个 vpc 下，通过全局响应日志进行 query_name 统计的图表示例，如果从中发现了对某些已知恶意域名的访问，则可以进一步排查，找到安全威胁：

* and vpc_id: vpc-j6cd*****mgkrt6 and ( region_id : cn-hongkong ) and global  and ( region_id : cn-hongkong ) and rcode: 0 |select count(*) as total_req, query_name group by  query_name

正常情况下域名的解析请求量维持在一个可控平稳的范围（如下图），如果出现某个域名的请求量出现陡增，例如从 20 次/min 提升到了 1000 次/min，说明该域名可能遭受了攻击，可以通过创建告警分组评估 [ 16] ，分别监控需要特殊关注的域名目标，通知到响应的安全运维人员处。

* and vpc_id: vpc-j6cd*****mgkrt6 and ( region_id : cn-hongkong ) and global and rcode: 0 |select date_trunc('minute', __time__ )as t , query_name, count(*) as total_req group by t, query_name

解析请求 rt 异常

解析响应时间异常同样值得引发注意，这里我们仅用全局应答日志的 rt 进行统计分析，全局应答日志的 rt 是表示整个查询到应答的时延，解析路径的各个模块也包括在内，因为有 cache 模块的存在，正常情况下响应时延在一个可控范围。如果某个域名的 rt 突然提升，有可能是因为用户的 dns 服务器网络配置存在问题，或者是遭遇了网络攻击，此时的域名解析服务器已经不堪重负，因此 rt 的统计分析也是非常有价值的观测指标。

* and vpc_id: vpc-j6cd*****mgkrt6  and ( region_id : cn-hongkong ) and global  and rcode: 0 |select date_trunc('minute', __time__ )as t , query_name, avg(rt)
 as avg_rt where rt>=60 group by t, query_name

附录

dns 日志字段