DNS实时监控系统的设计与实现

文/李欣琪

目前，复旦大学共有5台DNS服务器分布于四校区，其中两台作为复旦域名名称服务器（Name Server），同时提供其他域名的递归解析服务。因此，DNS服务直接关系到两方面内容：1.公众访问复旦大学相关站点的质量；2.校园网用户的网络访问质量。DNS的性能指标和统计分析，成为信息化建设的一个关注点。建立一个功能全面完善的DNS监控系统，提供DNS服务关键信息的统计和分析，帮助排查网络故障，进行安全预警，具有重要的意义。

以使用最为广泛的DNS软件ISC BIND为例，对于BIND服务的监控和统计，可以采取执行命令或使用第三方程序如DNSTOP的方式获取BIND进程的CPU、内存和网络等资源消耗情况，并通过编写脚本来统计BIND产生的日志，获取相应的查询记录。但当DNS服务处于高负载的条件下，这种方式无法及时处理迅速增长的日志，同时频繁的日志读取很快会带来I/O上的瓶颈，甚至影响到DNS服务的质量。

因此，本文提出了一种分布式架构的DNS实时监控系统的设计方案，利用流式数据存储和分布式计算实时处理DNS性能数据，改变了传统通过人工排查DNS故障的方式，提高了DNS服务关键信息统计和分析的效率，提升了系统的稳定性和安全性。

图1 DNS运行流程

DNS运行流程与性能指标

根据服务类型，DNS可以分为递归和迭代两种。如图1所示，当用户要访问目标域名时，首先查询本地DNS缓存，如果没有该域名的解析记录，则向本地DNS服务器提交查询请求，由本地DNS服务器代为解析，这一过程称为递归。其中，本地DNS服务器接收到请求后，首先判断本地缓存中是否有该域名解析记录。如果有则直接返回相应的IP地址；如果没有则向十三台根域名服务器提交查询请求，并以迭代方式轮询，直到获知该域名的解析结果。

上述过程中产生了大量的数据交互，为了了解DNS的运行服务状况，我们需要对DNS的各项指标进行实时监控。除了常规的CPU、内存、I/O、网络和进程状态之外，还需要针对DNS的各类请求进行更细粒度的监控和分析。

首先，需要对DNS实时请求数、A类地址查询数、CNAME类地址查询数、MX邮件交换查询数、AAAA IPv6地址查询数等不同类型的DNS查询进行分析和统计，计算各类型的数量及比例，帮助管理员在总体上掌握网络概况。

其次，分析和统计不同域名的请求次数和频率，可以了解各业务系统的访问状态，以及互联网访问的集中区域。

再次，通过统计和分析DNS请求的IP来源也可以从宏观上掌握整个校园网的网络请求来源分布和热点区域；特别对于对外提供访问服务的站点，可以获知来访者在地区上的分布情况。通过以上信息，我们可以实时获取DNS的运行状态，以及电子邮件、网站等访问情况。根据校园网用户的DNS请求IP来源统计，我们还可以判断出校园网热点区域，这些信息可以辅助我们判断网络状况。假如某个区域在一段时间内的DNS请求数相比最近的一段时间，出现急剧下降的情况，很可能是该区域的网络连接出现了故障，如果出现急剧上升的情况，很可能是该区域存在恶意访问行为。这些信息都可以帮助管理员在第一时间内追踪问题根源。同时，通过监测来自互联网的DNS请求，分析和统计其IP来源、请求对象和频率，可以发现包括DNS放大攻击在内的恶意请求，也可以有针对性地对爬虫的请求进行过滤和屏蔽。

最后，从用户体验的角度进行响应时间及DNS服务可用性监测。用户的网络访问首先要通过DNS解析获取所要访问域名的IP地址，因此DNS的服务质量直接关系到网页加载和页面打开的速度，影响用户对网络质量的整体感受。为了更深层次地了解DNS的服务质量，还需要模拟用户向DNS发出请求的过程，对DNS响应结果和响应时间进行检测。

图2 监控系统架构

系统架构与设计

根据上述需求，对DNS实时监控系统的架构进行设计，如图2所示。监控系统包括控制中心、数据传输、数据清洗、索引、分布式存储、检索、统计分析和可视化等部分。

通过控制中心向DNS集群下达数据传输任务，DNS集群将各类性能数据和日志文件通过数据传输模块发往指定的存储区域进行集中化存储。由于原始数据的类型和格式各异，所以需要根据数据源分别对各类数据进行数据清洗，去除格式异常的无效数据，并将其转换为预定义的逻辑结构。接下来数据将会以流的形式发送给索引模块，索引模块为数据建立索引，并将其存储至HBase节点上。对于前端用户发起的查询请求，检索模块通过HBase集群的读写接口进行并行处理，并将结果返回给用户。同时，可视化模块负责提供数据的多样化展示。

数据传输

DNS服务器时刻都在响应用户的请求，大量的数据在会话中产生。这其中量最大的就是刻画服务性能的相关数据。例如，服务器实时的CPU、内存使用率，网络带宽的使用情况，并发请求数等等。另外，通过配置，DNS能够以对服务器的性能指标进行统一管理，需要将这些数据统一传输到监控系统的后端存储上进行集中处理。数据传输任务由控制中心向各DNS服务器下发，可使用FTP、SCP等多种传输方式。

数据清洗

对于传输到监控系统后端存储上的数据，由于其格式各不相同，并且可能包含一些无效的数据，所以在进行索引和分析之前，需要对数据进行统一的清洗。数据清洗主要通过Fluentd来实现。Fluentd是一款开源的数据流收集系统，它的特点在于其输入输出部分均是可定制化的，用户可以通过简单的配置，将数据流以指定格式输出到目标位置。例如，一条典型的DNS查询请求格式如下所示：

18-Aug-2012 15:05:19.975 info: client 175.186.6.136#56377:view internal: query: www.hao123.com IN A +

各字段分别记录了请求日期、时间、请求来源和端口，以及请求对象和请求类型。为了从中提取对数据统计和分析有价值的信息，可以通过构造正则表达式定义如下的Fluentd数据格式配置来对该条数据进行整理：

format /^(?) (?) [^ ]＊ [^ ]＊ (?)[^ ]＊ [^ ]＊[^ ]＊[^ ]＊(?) .＊$/

整理后的数据为Key-Value的形式，非常适合做进一步地处理。

索引与分布式存储

为了提高数据检索的速度，需要将清洗后的数据做进一步的处理而不是直接进行存储。首先将数据通过全文索引工具Lucene进行处理，由于是文本文件，Lucene使用Text File Parser对数据进行解析，提取出索引项和相关频率等信息。接下来Lucene对数据构建反向索引并进行存储，其中反向索引包含搜索关键词所对应的所有文档，通过这种方式来提高对文档关键词的检索速度。但随着处理数据量的增加，索引的规模也在迅速膨胀，直接基于文件系统存储索引会使检索性能明显下降。本文通过将Lucene索引存储到专为海量数据处理而设计的HBase之上，能够很好地利用HBase高可靠性、高性能、可伸缩的分布式存储特点，即使在索引规模较大的情况下也能够实现实时的查询。

控制中心

对于监控系统的数据传输、数据清洗、索引和存储等任务，都需要由控制中心来统一下发命令和进行任务调度。在数据传输过程中，控制中心需要实时检测传输是否中断，传输完成之后还要再次检查线上数据和监控系统后端存储数据是否一致。如果两份数据不一致，控制中心需要通知数据传输模块进行重传。对于成功传输的数据，控制中心会通知传输模块将其从DNS线上服务器删除。同样，数据处理的其他各阶段，也需要控制中心来监控处理过程，对于出现异常的任务需要重新启动，只有顺利完成的任务才能够进入下一个阶段进行进一步的数据处理。

检索

经过索引后的数据，可以通过监控系统的前端提交查询请求。查询请求的格式支持Lucene的查询语法，同时支持多条件、多字段的综合查询。例如，需要查询2013年07月03日所有查询fudan.edu.cn域名的请求情况，可以输入以下语句进行查询：

Date:”2013-07-03” AND domain:”fudan.edu.cn”

检索模块将通过HBase查询接口对索引数据进行查询，并返回所有的结果。

可视化

对于DNS的各项监控指标，单纯从记录查询和数据统计上可能无法对DNS的整体运行状况有全局性的了解。因此对监控数据进行可视化展示和对比能够让管理员对DNS运行状态一目了然。本文设计的监控系统通过横向和纵向对比各监控指标所占的比例和趋势，提供柱状、饼状和热力图等可视化方式，使管理员全面掌握DNS以及网络的运行情况。

图3 DNS监控系统数据检索页面

图4 DNS各类查询比例

图5 DNS每日统计报表

图6 DNS请求来源

效果与分析

以最流行的DNS软件BIND为例，使用本文设计的监控系统进行实时监控。BIND配置文件的语法允许使用logging关键字定义不同的channel，每个channel指定存放日志信息的文件名、文件个数及大小、消息等级，并指定日志内容是否包括时间和消息的类别。通过配置可以将DNS运行时产生的一些关键信息以文本形式保存在磁盘上，关键配置如下所示：

Logging {

channel security_log {

File "/home/dns/log/dns-sec.log" size 10240m;

Severity info;

Print-severity yes;

Print-timeyes;

};

channel query_log {

File "/home/dns/log/dns-query.log" size 10240m;

Severity info;

Print-severity yes;

Print-timeyes;

};

channel default_log {

File "/home/dns/log/dns-default.log" size 10240m;

Print-category yes;

Print-time yes;

Severity info;

};

category security { security_log; };

category queries { query_log; };

category default { default_log; };

};

5台DNS使用同样的日志配置，并以logrotate的方式每15分钟进行轮转。控制中心控制数据传输模块将生成的数据实时发送到监控系统的后端存储上进行数据清洗。经过索引后的数据可以接受来前端的实时检索。通过监控系统前台检索某天某段时间内的DNS查询请求效果如图3所示。

对于各类DNS监控指标的实时可视化效果如图4所示。当DNS流量或并发请求出现异常时，为了进一步排查，需要对请求来源做统计分析，请求来源可视化可以为解决此类问题提供帮助。如图5所示，通过某天的DNS流量统计报表发现其中一台DNS流量同比有大幅上涨，通过图6所示的DNS请求来源统计可以迅速定位可疑IP地址，并通过监控系统的前台检索该IP请求内容，进一步确认该IP是否存在恶意访问行为。

同时，DNS监控系统对请求来源实时绘制热力图，根据其IP来源映射到所属的地理位置，并以标注点的明亮程度代表请求的数量多少。热力图支持通过正则表达式过滤IP来源和查询历史。

本文设计和实现了一种DNS实时监控系统，能够实时分析和统计DNS的各类请求及来源分布，并通过统计报表及可视化的手段帮助管理员从全局把握DNS和网络的运行状况。在实际应用中，该实时监控系统能够帮助管理员及时发现网络中潜在的问题和风险，进行预警和告警，还可以帮助管理员进行细粒度的问题排查，具备处理高效、监控精准、响应实时、统计分析全面的特点。