域名解析系统论文

2024-09-28

域名解析系统论文（共8篇）

域名解析系统论文篇1

0 引言

为了用户可以直接通过域名便利的浏览互联网中的网站, 在计算机网络中产生了将域名解析为IP地址的DNS服务。随着互联网爆炸式的发展, 网站的数量不断增多。现有的IPv4协议中的IP地址是有限的[1], 而一个IP地址唯一对应一台互联网计算机, 动态IP地址的出现有效的解决IP地址短缺的问题, 但如果想使用一台动态IP地址的计算机作为服务器, 其对应的DNS服务器的域名解析就遇到了域名与动态IP对应的问题, 动态域名解析系统 (DDNS) 根据动态IP地址的变化对域名解析表进行频繁且及时的修改, 有效的解决了这一问题。

本文根据DDNS原理[2], 结合现有的DNS服务器软件系统设计了能够完整的实现DDNS的功能的系统模型。系统共由客户端服务系统、服务端DDNS服务系统和基于WEB的数据服务系统三部分组成。用户在每次进行网络连接时, 客户端系统都会自动检测用户主机IP地址的变化。如果主机IP地址改变则把主机的新IP地址传送给DDNS的服务器系统。DDNS服务器程序捕获用户每次变化的IP地址, 并将其与原域名相对应, 以提供DNS服务并实现动态域名解析。基于WEB的数据服务系统作为用户主机和DNS服务器的数据交换中间层, 以可视化的方式让用户更方便的对数据库进行维护。

1 系统模型

本系统包括三个部分:客户端服务系统, 服务端DDNS服务系统以及基于WEB的数据服务系统。其模型如图1所示。

模型设计特点

(1) 自动运行

客户端和服务端软件都采用线程实现, 用户只需要在首次运行按提示配置相关信息, 系统就能在不需人为干涉的情况下自动运行, 实现动态域名解析[3], 自动化程度高。

(2) 及时可视化查看系统运行情况

在IP发生改变之后, 系统模型可以根据用户所配置的e-mail信息, 向用户发送邮件。用户可以通过WEB的数据服务系统查询域名绑定情况。

2 系统模型总体设计

DDNS服务系统是整个系统模型的核心, 主要负责DNS服务器上的数据更新和提醒邮件的发送, 需要遵照底层的网络协议。在服务系统中包含一个数据库, 用于存储用户信息以及域名相关的绑定记录。客户端服务系统运行在客户机上, 实时监控客户机的IP状况, 发现变动时及时通知服务器。数据服务系统, 设计为一个WEB服务程序, 将DNS服务器端复杂的数据库操作封装成简单易用的服务接口函数, 方便客户程序的调用。数据流图如图2。

2.1 客户端服务系统

客户端服务系统, 设计为两个子系统:一个为用户提供配置接口及注册验证信息的UI子系统;另一个提供IP监控的后台子系统。

用户运行客户端时先启动UI子系统, 在配置好信息后, 由UI子系统启动或刷新IP监控后台子系统。

根据图3所示, 客户端服务系统的具体流程如下:客户端通过UI为客户提供一个友好的操作界面。用户可以方便的通过系统在服务器上注册账号, 并自动进行账号身份的验证, 同时用户也可以自由地定制所需要的服务 (邮件服务、DNS动态绑定服务) 。

在客户机上首次运行客户端服务系统时, UI子系统会要求用户进行注册, 注册成功后, DDNS服务器端分配给客户机一个GUID的全局标识符, 系统把该GUID写入客户机注册表中。之后每次运行本系统时, 系统从注册表中读出该GUID, 通过它在服务器端验证身份并获取本机的相关信息 (如:邮箱地址、域名) 。将GUID写入注册表有以下优点:1.快速读写GUID, 缩短从服务器上获取本机信息的时间;2.一个操作系统只能对应一个的GUID, 可以将GUID作为某个操作系统的标识。

客户端服务系统中IP监控子系统是一个后台自动运行的监控系统[4]。能够实时地监测到客户机IP的变动情况。在本模型中, 该子系统设计为Windows后台系统服务。这样做是因为使该监控系统能随操作系统启动而运行, 独立于UI子系统, 不随用户界面的关闭而停止工作, 可以在操作系统中全程实行IP地址监控。

当IP监控子系统启动时, 将开辟两条线程, 一条用于检测操作系统所发出IP地址变动消息, 以对其进行反应;另一条使用定时器, 定时检测本机的IP地址栈, 发现IP地址发生变化时, 对其进行反应, 确保监控的实时性。

2.2 数据服务系统

数据服务系统是一个信息接口服务列表, 目的是为客户提供方便数据库读写操作的接口, 是一系列WEB服务函数的集合。数据服务系统在整个系统中起到连接客户端与服务端的管道作用。客户端的数据通过它流向服务器, 服务器的数据通过它反馈向客户端, 如图4所示。

由于对系统数据库的操作频繁。为了能够方便且有效的提供数据库操作功能, 模型中把数据库操作封装成WEB服务函数列表, 以方便客户端使用。安全高效地为客户端提供了数据服务, 并把客户端与后台的数据库隔离开, 客户端不用去关心后台数据库及服务器操作系统。如果后台服务器系统需要更换操作系统或者数据库软件, 服务器端只要满足提供的数据服务接口不变, 客户端程序便可以完全不需升级就能与新的数据库配合使用。

2.3 DDNS服务系统

DDNS服务系统是整个系统的核心[5], 运行在服务器端。它包含了三个子系统和一个数据库:IP域名绑定服务子系统、邮件服务子系统、网页查询服务系统及一个SQL Server2012的数据库。DDNS服务系统构造如图5:

数据库中存放所有用户注册的账号信息、邮箱地址以及域名和对应的IP地址。这些信息可供数据服务系统所查询和检索。

邮件服务子系统负责邮件发送, IP域名绑定子系统负责更新DNS服务器上的IP地址与域名绑定记录。这两个系统通过SQL Server的DLL扩展功能模块设计实现。并通过服务器脚本控制其运行, 当数据库中IP地址发生变化时, 立即调用邮件服务模块发送通知邮件, 同时调用IP域名绑定服务子系统更新域名绑定。作为SQL Server的扩展模块, 能够方便快速的响应数据库中的数据变化, 与SQL Server兼容好。网页查询服务系统以网页的形式向用户提供数据库中信息的查询。

3 系统模型集成运行

在客户机上运行客户端服务系统时, 系统首先查找注册表中GUID的相关位置是否存在, 如果不存在则提示用户进行注册, 否则弹出用户配置界面。用户通过配置界面配置完毕后, 系统将自动启动已注册为Windows系统服务的IP监控程序。当IP监控程序监控到IP发生变动时, 及时将数据通过数据服务系统传送到DDNS服务端。

数据服务系统充当数据通道的角色, 当用户进行注册时, 注册的信息通过其从客户端流向服务端并记录在数据库中, 服务端处理后, 将GUID通过数据通道传送回客户端。当IP地址变动时, 数据服务系统将数据传送到服务端, 记录在用户对应的信息表中。

服务端通发现IP变动时, 立即调用邮件通知系统向用户发送一封邮件通知, 同时使用Windows AP向DNS服务器提出域名修改请求[6], 当DNS服务器返回成功时, 表示动态域名绑定成功。

4 结语

模型由于采用windows平台的数据库和操作系统。客户端服务系统, 数据服务系统和DDNS服务系统都可以使用C#语言进行编程, 服务器端则需要安装IIS5.0以上和Microsoft SQL Server。系统模型具有能快速自动准确的进行域名绑定和更新的功能。用户只需首次启动时配置完整的信息, 系统模型即可自动完成所有工作。

参考文献

[1]何智勇, 沈苏彬, 毛燕琴.DHCP协议优化方案研究[J].计算机技术与发展, 2010, 20 (9) :5-9.

[2]曾宪章, 李潇等.动态域名解析服务系统及相关问题讨论[J].微电子学与计算机, 2005 (12) :81-84.

[3]张建臣, 张谷省.基于ADSL虚拟拨号的动态域名解析的研究与实现[J].德州学院学报, 2007 (4) .54-56

[4]王莉军.域名解析文件自动生成技术研究[J].计算机技术与发展, 2013 (3) .

[5]鄢萍, 易润忠等.基于DDNS和NAT的服务器内外网动态映射[J].计算机工程, 2008 (20) :136-137.

[6]刘晓霞, 孙海骏.域名解析系统的实现[J].计算机应用, 2001, 21 (7) :48-50.

域名解析系统论文篇2

IP，让人们通过注册的域名可以方便地访问到网站一种服务。域名解析也叫域名指向、服务器设置、域名配置以及反向IP登记等等。说得简单点就是将好记的域名解析成IP，服务由DNS服务器完成，是把域名解析到一个IP地址，然后在此IP地址的主机上将一个子目录与域名绑定。

接下来我们先来了解一下什么是IP反向解析。我们经常使用到得DNS服务器里面有两个区域，即“正向查找区域”和“反向查找区域”，正向查找区域就是我们通常所说的域名解析，反向查找区域即是这里所说的IP反向解析，它的作用就是通过查询IP地址的PTR记录来得到该IP地址指向的域名，当然，要成功得到域名就必需要有该IP地址的PTR记录。PTR记录是邮件交换记录的一种，邮件交换记录中有A记录和PTR记录，A记录解析名字到地址，而 PTR记录解析地址到名字。地址是指一个客户端的IP地址，名字是指一个客户的完全合格域名。通过对PTR记录的查询，达到反查的目的。

反向域名解析系统(Reverse DNS)的功能确保适当的邮件交换记录是生效的。这是一个最常见的问题(尤其是国外的邮件系统更是如此)。更多的电子邮件提供商是使用反向域名解析系统查找来确认信息是从哪里来的。由于这种方式的使用变得更广泛，那些没有正确地发布反向域名解析系统信息的域可能更常发生邮件的退回。所以，当正向域名解析完成后还应当向您的线路接入商(ISP)申请做反向地址解析，特别是涉外邮件之类，以减少被国外机构退信的可能性。

反向解析验证其实是对方服务器在进行的，如果我们没有做反向解析，那么对方服务器的反向解析验证就会失败，这样对方服务器就会以我们是不明发送方而拒收我们发往的邮件，这也就是我们排除其它原因后(如被对方列入黑名单、没有MX记录、使用的是动态IP地址等等)在没做反向解析时无法向邮件服务器发信的原因。

域名解析系统论文篇3

关键词：域名解析，BIND9，动态DNS

中图分类号：TP393 文献标识码：A 文章编号：1006-8937（2015）17-0065-01

1 DNS与BIND

随着互联网的快速发展，为了使用户们能够通过便于记忆的主机名来访问网络中的计算机，域名解析系统应运而生。在类UNIX操作系统中，可以使用HOST表，NIS和DNS三种方式实现主机名与IP地址之间的转换。由于前两种方式繁琐且效率较低，使用分层分布式数据库技术的DNS域名服务被广泛使用。DNS域名空间结构如图1所示。

BIND是DNS的一个实现版本，约占所有DNS服务器的90%。BIND最早由加州大学伯克里分校开发，互联网系统协会（Internet Systems Consortium，ISC）已发布了BIND 9的最新版本BIND 9.10.0rc2，该版本增加了prefetch选项，可提高递归解析服务器的性能。

BIND程序属于C/S架构，其客户端称为转换程序（resolver），负责产生域名信息的查询，将这类信息发给服务器端。BIND服务器端程序是守护进程named，负责回答转换程序的查询。通过修改named配置文件，可以根据IP来源，给出不同的域名解析结果，合理利用局域网内的资源，从而达到提高网络速度、控制出口带宽的目的。

2 BIND关键配置文件

BIND的关键文件有以下几个：

①named.conf用于设置DNS全局参数，指定区域文件名称及其保存路径。

②named.ca指向根域名服务器，用于高速缓存服务器的初始配置。

③正向区域数据文件及反向区域文件，由用户自己创建，为自己局域网内的主机提供域名映射。

3 设置根据外网ip来源动态解析

如果局域网接入了两个不同的运营商，以教育网和网通为例，局域网内www服务器配置教育网网段ip，导致部分外网网通及电信用户反映局域网内www服务器速度较慢。可以采用BIND提供的view视图功能，对DNS实现动态分割，即：根据访问www服务器的ip来源，分别指向www服务器的不同ip。

①首先编辑教育网ip地址列表，放到cernet.acl中。

②在name.conf文件中，使用view进行zone文件区分，示例如下：

a⑤编辑in.aaa.cn.zone和out.aaa.cn.zone两个区域文件，将www服务器分别指向不同的ip。并编辑相应的反向解析文件。

设置完成后，重启named服务，即可生效。

4 劫持局域网内对外网的访问

局域网内用户由于业务需要，经常大量访问一台位于公网的服务器，因出口带宽限制，访问速度较慢。该服务提供商愿意在内网搭建一台提供相同业务的服务器，但域名仍旧希望采用原有的learn.bbb.org，与局域网的aaa.cn属于不同顶级域。同时bbb.org域名下的www，mail等服务器仍指向原有ip。

实现方法如下：

①在named.conf文件中添加bbb.org区域，将该域名指向bbb.org.zone文件：

设置完成后，重启named服务，配置生效。内网用户在浏览器地址栏输入learn.bbb.org，DNS将自动指向对应的内网ip。

5 结语

通过对BIND的配置，能够根据内外网不同来源ip的访问需求，进行动态域名解析，提高了用户的访问速度，节省了出口带宽资源，实现了局域网内的智能DNS。

参考文献：

[1] 李静梅，吴鹏，智能DNS系统的设计与实现[J].计算机工程与应用，2007，（11）.

[2] 蔡昭权.策略路由和动态DNS在校园网中的应用[J].计算机工程与设计，2005，（5）.

区域域名系统建设与管理篇4

DNS是Internet/Intranet中最重要的一项基本服务, 实现域名和IP地址之间的双向转换服务, 它采用服务器/客户机模型, 是一种分布式层次结构系统。所有的DNS主机都被写入称之为名字树或域名空间的结构中。在DNS域层次结构的顶部是根域, 有一组被称为根服务器的DNS服务器 (Name Server) 为它服务, 直接在根域下的是顶层域, 顶层域往下是各个不同层次的子域, 每个子域都包含了DNS服务器和客户机。当DNS客户机需要和其他主机进行连接时, 先向本地的DNS服务器发出主机名解析请求, 本地DNS服务器如果认为查询目标是在自己管辖的域内, 则直接返回解析结果, 否则把查询请求转寄给自己的顶层域继续查询, 最终将查询结果返回给客户机。DNS服务器还负责及时地将新主机的信息网络中传播, 因而给网络访问、维护带来了极大的方便。

DNS的查询可以在客户机和DNS服务器或两个DNS服务器之间进行, 有递归和迭代两种查询方法。递归查询由DNS服务器直接做出查询成功或失败的响应, 如果需要的话, DNS服务器还与其他的DNS服务器通讯, 包括转到根DNS服务器查询。迭代查询过程中, DNS服务器只是根据本地的区域文件或cache文件, 提供最新、相对权威的信息, 比如接近客户机所查询名称的其他DNS服务器地址, 目前DNS查询多采用两者交互的方式。

但任何系统都存在宕机或失败的可能。DNS系统也一样, 出现无法查询的故障时, 网络访问将受到影响。由DNS查询原理可知, 出现无法查询的结果可能由两方面原因所致:一是本地DNS服务器宕机, 导致本地和非本地域名均无法完成查询;二是上行线路中断, 导致非本地域名无法查询。汇总起来, 当本地DNS服务器无法完成查询或无法连接上级域名服务器时, 查询将可能失败。本文研究和要解决的就是如何避免上述问题出现。为了解决这个问题, 笔者研究了备份域名系统, 并提出通过改进网络拓扑结构的办法使域名查询的可靠性得到改进。

2. 解决问题思路

2.1 加固域名服务器系统提高本身的可靠性

解决本地域名系统本身的可靠性问题, RFC822提出了备份域名服务系统的概念。为提高本地域名系统的可靠性, 可以在本地同时建立两个域名服务器, 其中一个叫做主master服务器, 另一个叫做从 (或辅助) slave服务器。一般情况下主服务器工作, 从服务器处于监听状态, 但他们之间数据是自动同步的。一旦主服务器宕机, 则从服务器自动接管全部解析业务, 直到主服务器恢复正常, 从服务器又自动退回到监听状态。这种机制在现有DNS服务器系统机制内可解决, 关键是在DNS服务器的基本配置文件named.conf里分别指定primary和slave关键字、在本地域内分别指定primary和slave关键字即可。

笔者提出的提高域名服务器系统本身可靠性的另一种办法是建立集群。双机热备是一种简单的集群方式, 双机之间不存在primary和slave之分, 但存在主从, 同样使用监听机制, 但两者配置文件一样。为了使得数据保持一致, 需要在后台设立集中存储。

两种办法相比前者代价小, 可部署于异地, 特别适合地域分布较广的单位;后者优点是更加可靠, 但缺点是物质代价较大, 不宜异地部署。

2.2 改进网络拓扑结构提高通讯的可靠性

通常含DNS的网络系统拓扑抽象如图1。但上行链路也可能出现故障, 为了提高通讯可靠性, 需要建立备用冗余链路, 改进后的拓扑如图2。这样域名服务器除可以在正常情况下上行达根服务器外, 还可在主线路故障情况下通过备份线路访问Internet以达根服务器, 确保链路畅通。

由于有了备份线路, 则主、从域名服务器可部署于异地。这样本地域名服务器就可以在主干线路断开的情况下仍然可以访问外部的上级DNS服务器, 以更新它本身的数据, 为客户提供准确可靠的服务。在正常情况下, 本地DNS服务器若要到外部服务器上获取数据, 则可直接访问外部DNS服务器;一旦网络上行主线路因某种故障与外部断开, 则可查询备份域名服务器, 并根据备份服务器本身拥有的数据对用户查询进行可靠的应答。

系统利用静态路由实现把查询转发给备份域名服务器。通过设置具有不同优先级的静态路由, 使高优先级的静态路由在网络连通的时候把查询请求路由直接路由到外部域名服务器, 使低优先级的静态路由在网络断开时可以把查询请求路由到备份域名服务器。这样低优先级的路由在网络连通的时候无效, 保证了备份域名服务器只在网络出故障的时候被访问。

因为这里使用的是RFC文档规定的异地主从域名服务器模式, 而不是本地集群模式, 主、从之间的速数据是时刻同步的, 因此不存在不一致的情况, 因而备份域名服务器上数据是有的。而且, 备份线路在主线路故障时畅通, 备份域名服务器利用一条独立线路连接到Internet继续更新, 所以它所获得的信息应比主服务器较为新。在主线路故障时, 主、备服务器之间仍然畅通, 这样备份服务器还可以访问主DNS服务器来获得有效的数据, 以此完善了备份域名服务器上的数据, 保证系统建立的服务器拥有准确可靠的数据。

3. 总结

本文综合利用了DNS系统主辅服务器系统相互备份和集群及硬件线路冗余的优点, 通过分析本地网在无法正常接入Internet时, DNS域名解析遇到的故障, 描述了如何建立备份域名系统和建立线路备份的办法来解决问题的思路, 并对此系统的应用问题进行了讨论。系统的实现是对现有DNS很好的扩展应用, 典型的可运用于现在院校合并后各校区之间相互访问的在实践中。

摘要：域名系统已在RFC822和RFC823中清楚叙述, 本文针对现行域名系统运行, 为增强系统可靠性而提出备份解决方案, 包括服务器本身的备份和线路冗余备份, 探讨了关键技术, 分析了应用价值。

关键词：DNS,备份,集群

参考文献

[1].王波, FreeBSD使用大全 (第2版) , 机械工业出版社, 2002-06-01

[2].计算机群集技术概述, http://windows.chinaitlab.com/other/380892.html

[3].P.Mockapetris.DOMAIN NAMES-CONCEPTS AND FACILITIES, Nov.1987, RFC1034

统一域名服务系统设计方案篇5

1 需求分析

根据应用级灾备工作的规划, 新建DNS系统应包括:

1.1 功能需求

域名服务系统目前已经成为某公司绝大多数信息系统应用的实际寻址方式, 应用访问方式都基于域名系统进行。

随着应用级灾备建设的开展, 对于应用系统基于域名技术的多种应用以实现应用切换, 将是完成应用级灾备建设的重要保障。

根据灾备建设的需求, 将在目前域名服务系统的整体架构上, 进行适应性调整建设, 以期确保在信息系统应用切换时, 可以提供支撑服务, 减少切换时间, 保障客户对业务应用系统安全、稳定、高效的访问。

1.2 可靠性需求

目前某公司根域名服务系统和二级域名服务系统基本为主从架构, 物理部署在同一生产机房内, 仅仅具备本地的高可用性。在面对极端灾害情况下, 区域节点如总部、省市公司一旦发生域名服务系统中断, 将会导致客户无法正常访问信息系统。

在应急或者演练情况下, 客户需要访问切换到灾备 (数据) 中心的业务系统, 在省市公司生产中心域名解析系统中断服务时, 客户将无法通过第二网络汇聚点对灾备 (数据) 中心业务访问请求。

为确保客户在任何情况下对于信息系统访问的不中断, 需要完善域名服务系统的部署架构, 提升可靠性, 以保障为客户提供不间断的域名服务能力。

1.3 运行管理需求

目前总部、各分部和各省市公司均已建设了域名服务系统, 并和总部的根域进行了级联。对于域名地址的变更管理采用分布式管理, 由于开源软件命令行操作的不便捷性, 所有操作均需要命令行操作, 操作过程中无错误检测功能, 容易发生人为错误, 对于各个节点运维人员有较高要求.

对于Qps监控、审计、访问统计等域名服务运行状态, 无分析和预警措施, 缺乏域名服务应用的监测机制, 无法对运维人员实时展现。

按公司信息系统建设和运行工作的集约化发展要求, 结合未来三地集中式数据中心对于域名服务的需求, 需要对域名服务系统进行统一的整体管理。

1.4 安全需求

随着网络技术的发展, 域名系统面临的安全威胁和风险不断加大, 不论是2009年暴风影音的5.19事件, 还是2010年百度的DNS域名记录被劫持事件, 均导致大范围网络故障, 使得高达数省的用户无法进行网络访问。由于对DNS服务器的安全性问题不够重视, 致使类似安全事件时有发生。

某公司的大量客户端机器中安装了诸如暴风影音等视频播放软件, 此类软件会定时、频繁的发送大量无效解析请求, 加重了域名系统的解析压力。

域名服务系统是某公司网络的一项核心服务、中枢神经系统, 事关网络的安全与稳定。域名系统的故障会导致信息系统应用的访问中断。针对网络攻击、域名劫持等威胁, 需要加强域名系统安全防护, 建立完善域名安全技术手段, 确保域名解析正常, 域名系统的安全运行。

2 架构设计

统一域名项目的整体架构如下图1所示。

2.1 内网部署

1) 本方案中根域名服务系统同时负责管理配置解析顶级域abcd.com.cn和各网省授权子域。三地灾备 (数据) 中心DNS服务器将作为内网的权威DNS服务器, 提供公司的所有的域名地址解析服务。

2) 省市公司、直属单位的原有域名服务器更改为forward工作模式, 仅作为缓存服务器使用, 物理设备继续使用原有服务器设备。

3) 根域名服务系统物理设备部署在A、B、C三地灾备 (数据) 中心, 采用主辅架构。三地灾备 (数据) 中心权威DNS服务器之间实现信息实时同步, 当单一灾备 (数据) 中心停止域名解析服务时, 其他灾备 (数据) 中心权威DNS服务器可以继续为全网用户提供不间断服务, 提升域名解析系统的高可靠性。

4) 用户可以通过配置所属灾备 (数据) 中心权威DNS服务器为自己的备选DNS服务器, 以保障在所属生产中心主汇聚点网络不通的情形下, 可以通过第二网络汇聚点访问业务。

2.2 内网解析流程

内网用户请求域名地址解析时, 首先向用户本地的DNS缓存服务器提出域名解析申请, 本地缓存DNS首先在自己的缓存区进行查找, 查看是否有相关域名的A记录, 如果有直接将域名地址解析给用户。如果没有将向三地灾备 (数据) 中心权威DNS服务器发送请求, 请求相关的域名地址解析, 权威DNS服务器应答请求, 将解析结果通知给用户本地缓存DNS, 用户本地缓存DNS将解析结果通知给用户。

首次解析记录结果将会被存放在缓存DNS服务器的缓存内, 记录在缓存内存的持续时间是由权威DNS服务器设置的TTL值来决定的, 当持续时间到达了规定的TTL时间后, 本地缓存DNS服务器会自动的将此记录删除, 并且不会主动的发起新的请求, 只有当再等到用户请求此记录相对的域名地址解析时, 本地缓存DNS服务器才会重新发起请求。

2.3 外网部署

1) 在A灾备 (数据) 中心部署两台DNS服务器, 用来替换原有外网权威DNS服务器, 负责解析权威域, 同时也负责解析授权子域。

2) 向中国互联网络信息中心 (CNNIC) 再申请一条NS记录, 并将相应的DNS服务器部署在B灾备 (数据) 中心, 和原有部署在A灾备 (数据) 中心的两台外网权威服务器组成一个分布式部署的异地高可用。

3) 省市公司、直属单位原有外网DNS服务器维持原状。

2.4 外网解析流程

外网用户请求域名地址解析时, 首先用户请求会提交到本地ISP供应商提供的DNS中, 如果DNS有相关记录时, 直接返回结果, 如果没有, ISP供应商提供的DNS会直接向中国互联网络信息中心 (CNNIC) 提供的根域DNS服务器提出申请, 根域DNS服务器会将abcd.com.cn的四条NS记录信息随机选择一条传递给ISP供应商的DNS, ISP供应商的DNS根据NS记录找到相应的公司外网权威DNS服务器, 由公司权威DNS服务器进行域名地址解析并将解析结果通知给ISP供应商的DNS, 后者将解析结果通知给用户, 完成解析过程。

由于目前互联网对于域名解析系统缺乏统一的标准和规范, ISP供应商的DNS设置也各不相同, 可能在解析过程中返回给客户端的缓存时间并不遵循公司外网权威DNS服务器的TTL值设定, 无法控制域名解析记录的缓存时间。

3 系统设计

3.1 域名功能

域名服务系统集中部署在灾备 (数据) 中心的内外网权威服务器具备以下功能:

1) 能够处理来自某公司内部网络和外部互联网的任何客户端的查询请求;

2) 权威服务器主辅之间实现安全的区数据传输;

3) 支持DNS安全协议扩展 (DNSSEC) ;

4) 同时具有IPv4和IPv6两个协议栈, 可以处理来自IPv4和IPv6网络中的客户端域名查询请求。

域名服务系统中部署在省市公司、直属单位和地市公司的缓存服务器具备以下功能:

4) 能够处理来自某公司区域内部网络和外部互联网的任何客户端的查询请求;

6) 正确执行递归查询过程;

5) 能够按照权威服务器返回的信息生存期 (TTL) 时间进行域名数据缓存。

3.2 域名管理

域名服务器集中部署在三地灾备 (数据) 中心, 对于域名记录的管理能够由三地灾备 (数据) 中心统一管理, 也可针对单位建立角色账号, 分级分权管理域名记录信息。不同区域的管理员通过自己的用户名登录实现只管理自己的区域的记录, 并实现增、添、改功能, 并且不会对其他区域的内容造成影响。超级用户admin可以管理所有区域的配置, 管理者 (admin) 可以对附属权限的域进行增删改操作, 超级管理员 (administrator) 可以对全局域进行管理。

3.3 安全防护

域名服务器的安全风险主要有DOS (Denial Of Service) 攻击、域名劫持、域名欺骗、区传输泄密等方面, 针对风险主要采取以下几方面手段来进行安全防护。

4 加强安全防护体系

1) 技术:更新和完善安全工具、软硬件设备、管理平台、监控系统。主要包括安全扫描、评估分析、入侵检测、入侵取证、陷阱网络、备份恢复、病毒防治等。

2) 管理:完善安全技术规范、管理制度、高水平的安全技术人才和高度的工作责任心。建立定期检查制度, 建立网络安全专人负责制度, 建立安全事故及时上报制度, 建立定期备份制度, 限定口令定期修改制度等。

3) 规划:对新的技术和产品及时了解, 深入调研国内外信息网络安全的状况, 了解黑客技术的进展, 在广泛融合的基础上作出前瞻性规划。

5 技术手段保护

域名服务器可以根据对解析流量来源、目的地或端口的监控, 使用分组过滤、建立访问控制列表等手段来限制或拒绝用户对域名服务器的访问。安全加固DNS的运行环境, 内核安全优化, 升级到最新的补丁程序, 关闭无关的进程和端口, 配置防病毒模块等。防火墙划分不同区域, 设置严格的访问策略, 配置ACL、ACL longing, 启动Do S、DDo S功能。

6 安全协议

针对权威服务器的主服务器和从服务器的之间的同步信息的完整性和可靠性安全可以通过事务签名 (Transaction Signature) 协议来保障, 对于缓存服务器从权威服务器获取的查询结果的完整性和可靠性可以由域名系统安全扩展 (DNS Security) 来保障。

7 域名信息同步

为确保三地灾备 (数据) 中心在对同一解析请求时, 返回相同的结果, 保障域名服务器提供稳定可靠的服务, 域名服务器之间必须具有对域名文件和策略文件安全的信息同步机制。

部署在三地灾备 (数据) 中心的域名服务器相互之间的域名记录信息能够采用自动同步模式, 使得三地灾备 (数据) 中心的域名服务器都拥有全网的域名信息记录, 能够实现三地灾备 (数据) 中心域名解析服务的平台化、同步化。

三地灾备 (数据) 中心的权威域名服务器之间在建立同步关系时, 必须设置为同一组, 组内所有域名服务器实时校验域名文件和策略文件的时间戳, 任一域名服务器中一旦有文件时间变更, 则能自动启动同步机制, 将信息同步至其他权威域名服务器。权威域名服务器组能够和某公司统一时间源进行同步。

8 结束语

目前公司的权威域名服务器TTL值设置为24小时, 意味着如果应用业务是基于域名方式访问的, 当应用业务地址发生变化时, 客户端最坏情况下需要48小时才会访问到正确的地址。

如现阶段集中部署后的某A业务平台对于RTO要求为30分钟, B业务系统的RTO要求为4小时, 域名服务系统对于A业务平台的域名记录, 缓存时间TTL值需要设置在15分钟以内才可以满足RTO要求, 而对于B业务系统, 缓存时间TTL值则需要设置为2小时才能满足其RTO要求。

基于IPv6的域名系统篇6

域名系统(Domain Name System,简称:DNS)的主要功能是通过域名和IP地址之间的相互对应关系,来精确定位网络资源。IPv6协议是用来取代IPv4的互联网协议。首先,它提供了巨大的地址空间,这实际上是推广IPv6的最大动力。其次,IPv6的地址结构和地址分配采用严格的层次结构,以便于进行地址聚合,从而大大减小了路由器中路由表的规模。再次,IPv6协议支持网络节点的地址自动配置,可以实现即插即用功能。而且,IPv6协议对主机移动性有较好的支持,适合于越来越多的互联网移动应用。另外,IPv6协议在安全性、对多媒体流的支持性等方面都具有超过IPv4的优势。

2 IPV6域名的结构

IPv6网络中的DNS与IPv4的DNS在体系结构上是一致的,都采用树型结构的域名空间。IPv4协议与IPv6协议的不同并不意味着需要单独两套IPv4 DNS体系和IPv6 DNS体系,相反的是,DNS的体系和域名空间必须是一致的,即,IPv4和IPv6共同拥有统一的域名空间。

DNS树形结构中唯一的一个根(Root),用点号“.”表示。根的下一级称为顶级域(Top Level Domain,简称:TLD),也称一级域。顶级域的下级就是二级域(Second Level Domain,简称:SLD),二级域的下级就是三级域,依次类推。每个域都是其上级域的子域(Sub Domain),比如“.net.cn”是”.cn”的子域,而“cnnic.net.cn”既是”net.cn”的子域,同时也是”.cn”的子域。

DNS树上的每一个节点都有一个标识(Label),根节点的标识是“空”(即长度为0),其它节点的标识的长度在1到63字节之间。一个节点的域名是由从这个节点到根节点的路径上的所有标识从左到右顺序排列组成的,标识之间用“.”分隔。例如www.cnnic.net.cn。

3 IPv6地址及其表示方法

IPv6地址长度为128比特,地址按照其传输类型分为3种:

单播地址(Unicast Address):用来标识单一网络接口。目标地址是单播地址的数据包将发送给以这个地址标识的网络接口。

任播地址(Anycast Address):用来标识一组网络接口(通常属于不同的节点)。目标地址是任播地址的数据包将发送给其中路由意义上最近的一个网络接口。

多播地址(Multicast Address):用来标识一组网络接口的标识(通常属于不同的节点)。发送到多播地址的数据包发送给本组中所有的网络接口。在IPv6中没有广播地址(Broadcast Address),用多播地址取代。

其中,单播地址按照地址的传输范围分为可聚合全局单播地址(Aggregatable GlobalUnicast Addresses)、NSAP地址、IPX层次地址、站点本地地址(Site-Local address)和链路本地地址(link-Local address)等。所有的网络接口至少要有一个链路本地地址,同时还可以拥有多个地址(包括单播地址,任播地址和多播地址)。

IPv6的地址在表示和书写时,用冒号将128比特其分割成8个16比特的部分,每个部分包括4位的16进制数字。例如:

1080:0000:0000:0000:0008:0800:200C:123A

4 DNS对IPv6地址层次性的支持

IPv6可聚合全局单播地址是在全局范围内使用的地址,必须进行层次划分及地址聚合。IPv6全局单播地址的分配方式如下:顶级地址聚合机构TLA(即大的ISP或地址管理机构)获得大块地址,负责给次级地址聚合机构NLA(中小规模ISP)分配地址,NLA给站点级地址聚合机构SLA(子网)和网络用户分配地址。IPv6地址的层次性在DNS中通过地址链技术可以得到很好的支持。下面从DNS正向地址解析和反向地址解析两方面进行分析。

4.1 正向解析

首先,“A6”记录方式根据TLA、NLA和SLA的分配层次把128位的IPv6的地址分解成为若干级的地址前缀和地址后缀,构成了一个地址链。每个地址前缀和地址后缀都是地址链上的一环,一个完整的地址链就组成一个IPv6地址。这种思想符合IPv6地址的层次结构,从而支持地址聚合。

其次,用户在改变ISP时,要随ISP改变而改变其拥有的IPv6地址。如果手工修改用户子网中所有在DNS中注册的地址,是一件非常繁琐的事情。而在用“A6”记录表示的地址链中,只要改变地址前缀对应的ISP名字即可,可以大大减少DNS中资源记录的修改。并且在地址分配层次中越靠近底层,所需要改动的越少。

4.2 反向解析

IPv6反向解析的记录和IPv4一样,是“PTR”,但地址表示形式有两种。一种是用“.”分隔的半字节16进制数字格式(Nibble Format),低位地址在前,高位地址在后,域后缀是“IP6.INT.”。另一种是二进制串(Bit-string)格式,以“[”开头,16进制地址(无分隔符,高位在前,低位在后)居中,地址后加“]”,域后缀是“IP6.ARPA.”。

总之,以地址链形式表示的IPv6地址体现了地址的层次性,支持地址聚合和地址更改。但由于一次完整的地址解析分成多个步骤进行,需要按照地址的分配层次关系到不同的DNS服务器进行查询。所有的查询都成功才能得到完整的解析结果。这势必会延长解析时间,出错的机会也增加。因此进一步改进DNS地址链功能,提高域名解析的速度才能为用户提供理想的服务。

随着Internet技术的不断发展,DNS不再是仅仅提供传统意义上的简单资源定位,一方面提供类似IPv4 DNS的基础功能,另一方面结合IPv6的新特性,和其它协议有机的结合在一起,提供新的功能,使网络的配置、维护、使用变的更简单更方便。

参考文献

[1]蒋亮,郭健.下一代网络移动IPv6技术[M].北京:机械工业出版社,2005.8.

域名解析系统论文篇7

2014年以来,在美国政府有条件放弃对IANA监管权政策的推动下,全球根管理格局和根技术架构都经历了微妙变化,并逐步成为全球聚焦热点。在我国,中央领导高度重视当前争取根自主管理的机遇和挑战,把掌握根服务器和根区文件管控权上升到保障国家网络空间安全的战略高度。因此,从根管理政策、服务器部署技术和镜像部署3方面,深入探讨全球根域名系统布局环境及发展趋势,是支撑相关部门理清全球根系统发展脉络,把握转型机遇,推动实现多方共享根系统管理的前提和保证。

1根域名系统及其管理模式的演进

1.1根服务器分布的历史沿革

在互联网最初发展阶段,每台主机通过配置定期更新的Hosts文件实现全网解析。为应对互联网规模扩张,20世纪80年代IETF发布了RFC1034和RFC1035标准,成为构建分布式、层次化DNS系统的技术基础。

根域名系统正是在此基础上发展起来的。到1997年全球共部署13个根服务器,受到DNS报文长度限制无法继续扩展。为突破根节点数量限制,提供快速、稳定、安全的根解析服务,2002年以来多个根广泛采用Anycast技术大规模扩张根镜像节点,目前达到400余根节点,初步形成覆盖全球各大洲的大规模、分布式根域名解析网络(见表1)。

数据来源:root-servers.org

1.2根管理模式分析及影响因素

根系统管理由“服务器管理”和“根区文件管理”两部分构成。“服务器管理”是由13个运营机构开展网络、服务器等硬件和解析系统、安全保障等软件环境的维护。“根区文件管理”是对加载在根服务器上的顶级域寻址文件的控制,是转移互联网管理权,变革全球“根管理格局”和“互联网治理格局”的核心(见图1)。

全球根管理基本格局是美国政府主导的2份合同确定: 第一,美国电信和信息管理局NTIA与ICANN签订合同,授权ICANN履行IANA职能;第二,NTIA与Verisign签订合同,授权Verisign开展根区文件运营维护。通过上述2份合同,任何对于根区文件的增加、修改和删除操作,都要经过3个步骤:

1)ICANN审核相关申请是否符合相关域名政策,若无误则提交NTIA。

2)NTIA审核ICANN是否正确完成工作,授权后将请求提交Verisign。

3)Verisign检查该请求的技术正确性(如域名服务器是否在线等),将相关条目注入根区数据库并向13个根服务器分发。

在法律关系的限制下,美国政府对根区文件运营者ICANN和维护商Verisign都具有话语权,实现了美国政府对根系统的单边控制权。三主体及其相互制约关系共同形成了当前根区管理模式,也是推动根区管理去美国政府化的重要切入点。

1.3变更根管理权的机遇与挑战

由于美国政府掌握修订根区文件的最终审批权,世界各国都面临美国删除、篡改和劫持本国顶级域的风险,国际社会对美国垄断根管理权普遍不满,要求改变美国控制全球互联网最终解释权的呼声越来越高。多方压力下,2014年初美国商务部宣布2015年9月将有条件放弃对IANA的监管权。

在具体操作层面,成立了IANA职能管理权移交协调工作组(ICG),从兼容性、互操作性方面评估域名、IP地址和协议参数3个社群所提出的移交方案,整合后递交NTIA审议。其中,域名职能跨社群工作组(CWG)方案与转移根管理权密切相关。若移交进程顺利开展,将在一定程度上改变美国单边治理局面,但是移交面临巨大不确定性风险:

第一,CWG方案尚未解决关键问题,影响ICG整体方案进度,预计9月前难以顺利完成方案整合、公众评议、NTIA评议等诸多流程。

第二,确定ICANN问责机制是与IANA管理权移交相互关联的进程,但进展缓慢影响了整体协调推进。

第三,凭借NTIA提出的4项原则及美国互联网产业强大实力,移交过程完全由美国主导完成,存在诸多不可控因素。

综上,预计移交方案难以按时完成(见图2)并获得各利益相关方及美国政府的一致认可。考虑到IANA职能合同到期后还可续签2次(每次2年),未来2~4年面临根管理方案从NTIA单边向全球多方共治过渡的重要机遇。

2根域名系统部署技术的发展

2.1根服务器部署技术面临变革需求

RFC1034和RFC1035奠定了包含根服务器在内的域名系统技术基础。默认情况下,DNS协议基于UDP报文传输, 且报文尺寸限制在512 byte以内,当大于512 byte时采用TCP传输。出于安全稳定运行的考虑,512 byte的DNS UDP响应消息中最多能容纳13个根服务器,为实现根服务器广泛分布,保证系统安全稳定运行,采用Anycast技术面向全球部署镜像节点。

随着互联网新技术和新业务的不断发展演进,根服务器部署技术面临变革需求,相关技术也在不断推进实施中。第一,IPv6地址尺寸是IPv4地址的4倍,只要增加2个根的IPv6地址信息,DNS响应报文尺寸将超过上限,若记录13个根IPv6地址,响应报文将增加到811 byte,远超出512 byte的限制。第二,DNSSEC大幅增加DNS响应报文尺寸,仅采用一种签名算法生成RRSIG资源记录,DNSSEC响应报文尺寸将增加到7~10倍。第三,随着物联网蓬勃发展,摆脱当前根解析系统,构筑安全自主的物联网标识解析体系也逐渐成为全球关注的热点。

2.2根体系架构变革思路分析

为应对技术和业务不断发展的诉求,以及共享根管理权的呼声,业内不断提出多项调整根系统架构的技术方案,在拓展DNS报文尺寸、重构解析系统等方面都有所进展,其中部分方案已在具体部署中得到实施,成为变革根系统架构的基础。

1)拓展DNS报文长度

IETF提出了EDNS0机制,通过在DNS消息中增加字段, 允许DNS请求者公布其UDP数据包大小,通知服务器自己可接收的UDP数据报文的最大数据容量,避免采用TCP重传带来的效率下降或通信失败。

2)重构解析系统

构建物联网终端标识解析体系引起全球关注,除利用DNS协议或者基于现有DNS系统部署物联网解析系统外,也涌现出构建全新的根解析架构,例如Handle系统在全球部署4个根,根间独立、平等、协同运行,每个根可自主实施本国根区管理,通过根间合作完成跨国寻址。

3)改良根解析系统

在根服务器可扩展和根区文件安全传输等技术基础上, 2014年全球产业各方(包括我国CNNIC、ZDNS、BII等)密集提出多项关于拓展全球根系统的建议,其中不乏革命性变革的技术方案,虽然各项技术的可行性尚未形成定论,但充分体现出全球调整根体系架构的强烈意愿及发展方向。例如: Google提出递归服务器缓存全部根区文件,是对当前根镜像架构的极大拓展,使传统意义上根镜像服务器及其管理权向递归层面延伸;方滨兴院士提出借鉴自治域间路由对等扩散的思路,建立国家级顶级域名联盟,采用“域名对等扩散”方法通过可信通道交换TLD信息,增强我国自治根域名解析系统健壮性。

3我国根镜像服务器建设和服务水平分析

3.1我国根解析性能和镜像部署水平的国际对比

2003年以来,我国已陆续引入4个根的多镜像节点,其中两个F根镜像服务器分别接入中国电信和CNNIC网络,J根镜像服务器接入联通网络,I根和L根接入CNNIC网络。然而,我国根镜像部署进程缓慢,在引入规模、解析质量和辐射范围等方面落后于国际水平。解析性能对比分析详见表2。

数据来源:TEAM CYMRU

第一,全球根及其镜像节点的全球分布极不均衡,美国镜像节点数量是中国的15倍,巴西、德国、日本、法国、澳大利亚、加拿大等国的根镜像节点数量是中国的2~3倍。

第二,节点密集程度直接影响解析性能,根据TEAM CYMRU监测结果,各国对不同根解析的时延差异极大。我国平均根解析性能远低于发达国家,其中未引入根的访问性能远低于发达国家水平,已引入根的性能也普遍低于发达国家水平。

第三,各国部署根/镜像节点定位和国际辐射范围存在显著差异。以F根为例,日本、北美和欧洲交换中心F根镜像节点服务范围非常广泛(如图3所示)。在中国、印度和澳大利亚互联网物理连接故障时,新加坡为3国提供J根解析的冗余保障。我国引入的镜像仅服务于国内特定网络范围,与我国互联网在东南亚地区甚至全球的影响力极不相称。

数据来源:RIPE Atlas

图3中,编号4,6,10,17,23,30,33,36,41,44,45,52, 53,56,58为欧洲节点;编号5,29,32,37,40,42,49,59,60为北美节点;编号9,19,46,57为南美节点;编号11,12,20,24, 25,27,35,43,47,48,51,55为亚洲节点;编号22,34为非洲节点。

3.2我国根镜像国内服务水平分析

我国访问各根的解析时延取决于所访问根节点的地理位置和网络位置。国内的F、J和L镜像支持电信、联通、鹏博士用户访问,移动/铁通访问香港交换中心的F和I根镜像以及北美的J和L镜像。而我国主导运营商主要访问日本、香港、台湾的I根镜像,国内I镜像服务少量用户。由于我国访问的F、I、J、L节点主要分布于亚洲地区,且网间互通带宽较高,因此4个根服务性能明显优于其他海外节点,相对而言, 访问欧美根节点的性能较差,美国根解析时延在200 ms以上,见表3。

从国内性能解析分布来看,根解析性能与根节点接入网络和部署地点密切相关。以联通L根镜像覆盖和服务情况 (见图4)为例,移动/铁通访问美国节点的解析性能较差,达200 ms以上,电信和鹏博士3月访问法国节点,解析性能远差于9月访问国内节点。

数据来源:中国信息通信研究院互联网监测平台

3.3镜像网络覆盖能力的深度分析

目前,我国已引入根镜像节点并未实现对境内各运营商以及周边地区的广泛服务,存在不同程度的访问盲区现象。这主要是根运营管理机构和根引入机构调整路由通告策略所致,限制了根节点的服务范围。

数据来源:中国信息通信研究院互联网监测平台

1)根管理机构的路由策略

根节点分为Global和Local两类,Global节点配置高,能承担全球全部解析请求负载,Local节点配置低,用于承担一定地理范围内的解析请求。根管理机构通过配置差异化路由策略,以适应两类节点不同的处理能力。F根为例,Global节点向全网通告根服务器地址前缀/23,Local节点仅向对等方通告带有no-export属性的根地址前缀/24。

2)运营商的路由策略

根镜像引入企业也可能有针对性地选择通告根地址前缀的网络范围,例如,考虑到需向主导运营商支付流量结算费用,引入根镜像的中小运营企业可能不向主导运营商通告。接入香港交换中心的运营商能够得到部分根的优质服务,移动和铁通优先选择香港节点。

4推进我国构建自主根系统的策略思考

伴随美国移交IANA监管权,我国面临争取根自主的历史机遇。在此背景下,加强我国根发展策略的顶层设计,坚持“根管理权积极竞争”和“根镜像科学部署”两条主线并重,以提升我国根解析性能和逐步掌握互联网控制权为总体发展目标,推动我国以多样化方式访问、部署根镜像服务器,增强我国在全球互联网治理领域的国际话语权。

第一,加强根部署技术和管理模式的创新研究,并提出可行方案,积极应对全球根域名系统变革。转型期在共享根管理权和拓展根数量方面存在很多机会,鼓励科研单位、企业加强关键技术和管理权转移方案的研究,以协会、联盟等模式推动各方形成合力,提出可行方案。

第二,充分利用IETF、ICANN等渠道和平台,加强国际合作交流,增强我国在互联网治理领域的影响力和话语权。融入国际根架构调整、根管理、根运行维护、支撑资助等机构发起的多层次活动,并展开深度沟通合作,争取在相关国际机构发出我国的声音,先参与、再发声,逐步形成我国的影响力。积极向IETF提交并参与讨论根架构调整相关技术草案, 根管理政策制定方面积极参与到RSSAC咨询委员会,充分参与根移交方案制定过程,在新方案关于根区内容管理、政治监管、根运行维护等方面充分体现我国利益。

域名解析系统论文篇8

DNS(域名系统)是一个将域名和IP地址相互映射的分布式数据库,一般通过在服务器上安装BIND(伯克利互联网域名保护协议)来实现域名解析功能,采用anycas(任播)方式,见图1。

除安全防护缓存系统的专业网管可对DNS服务器实现管理外，在日常维护中还可以利用Linux操作系统强大的功能实现各种个性化维护需求。

2利用Cacti实现BIND统计功能

这里用到大家熟悉的一套开源的PHP (超文本预处理器)程序Cacti,我们之前用它来采集城域网设备的流量、CPU(中央处理器).BAS(宽带接入服务器)在线用户数，并利用其方便的

edef功能实现人均带宽、地址池利用率等计算采集。现在我们把它同样用在bind主机的性能采集上。

在BIND主机使用命令mnde stats可以产生一个重要统计文件named.stats,在这个文件里存放了实时的DNS请求回应等诸多信息,将这个文件导入pl模板后,就可以使用图形化界面看到实时的BIND各种请求连接数如A记录,MX记录响应时延解析成功1失败次数等。

3利用syslog的实时异地备份及呈现

DNS中有数十台BIND主机，主机的日志是日常维护重点查看的文件之一,将各台主机的日志远程保存Linux数据库中，既有利于日志查看,也可避免可能的主机被入侵后历史日志恶意删除的情况。

远程发送日志这里不再详述，主要利用了Linux上的sys-logd进程。

在Cacti上呈现日志使用了Cacti自有插件syslog，该插件实现IP网各种设备syslog的集中存储与查询功能，支持根据IP、日志等级、日志信息、时间等纬度进行查询、导出功能。

在日常维护中,使用此系统可根据日志等级,优先查看高等级、严重级别的日志，如err日志,过滤海量的info类信息,有效减轻维护人员信息检索量,提

高维护效率

1)多亮点功能:

2)日志以my ysqI维度的日志检索;数据库存放,

3) log关键字提取与筛选,减轻维护人员信息检索量;

4)host栏目可以IP形式、主机名

4Cacti在的形式呈现,便于查找。

DNS维护上的扩展应用Cacti还有多款插件,比如th old,可以提醒有超过1低于阀值的流量在监控端口上。除了传统的静态阀值,还可以设置动态阈值，当前采集值与前5 min相比,超过1低于某个百分比发送告警;mo nitor，对有告警的设备调用音频文件做提醒功能。结合thold和monitor后，告警产生会有声音提示。既可把告警信息发送至指定邮箱，也可将网管服务器与短信平台做接口,发送短信至包机人员的通信终端上面.

5域名对应IP篡改的实时预警通知

在日常维护中碰到网站被黑或者域名注册商数据库异常,导致用户域名对应Ip地址被篡改,如果能及时发现,可通过代理应答等预处理手段将用户损失降到最低.

如果现阶段没有条件和短信平台做接口直接发送短信,那么可以在Linux上利用shell脚本与发送邮件的mutt程序,再结合电信189邮箱的邮件短信提醒功能。比如jsinfo.net域名对应IP为202.102.29.38,每5 min解析一次,当发现解析出的地址非202.102.29.38,即发送邮件。

同时手机收到短信提醒。

从收到提示到维护人员响应处理,全程不超过10 min,用户网站访问问题迅速解决,大幅提高用户的满意度。

6异常告警的自动化脚本检查

Linux强大的脚本功能在检查告警原因时也是可圈可点。比如在维护中,碰到这样一个告警,每天凌晨4:30左右会提示系统CPU利用率高,20 min后会自动恢复。

使用ps aux命令可以看到当前设备上正在运行的程序使用者、程序进程号、CPU利用率等信息,如图2,其中第三列为CPU利用率。

第一步:将ps aux命令与Linux的sort排序程序结合,使用sort以第三列CPU利用率进行降

第二步:将排序显示的内容存入文件,从4:00点到4:59,每.5 min执行一次,文件名以当前时间命名以示区别。

第三部:将所有文件合成为一一个文件后,使用head程序提取CPU值最高的topN项。

找到了导致CPU瞬时高的进程后,进行优化,问

7DNS重要配置题得以解决。

文件的自动备份DNS中一些重要的文件比如授权服务器的na med.conf文件以及named文件夹,缓存服务器的ospfd.con f配置文件,相关路由器的配置文件等,根据工信部对域名系统的安全要求,

都需要每日备份。备份的方法有很多,