《DNS技术研究与应用》结题汇报报告.ppt

《《DNS技术研究与应用》结题汇报报告.ppt》由会员分享，可在线阅读，更多相关《《DNS技术研究与应用》结题汇报报告.ppt（75页珍藏版）》请在三一文库上搜索。

1、中国移动集团级重点研发项目 结题汇报报告,2011年11月21日,项目名称：DNS技术研究与应用,一. 课题目标实现情况,目 录,二、主要研究成果（整合后）,1.1 研究背景：“4+1”战略推动全业务发展，全业务发展凸显DNS系统各类问题,已引入网站394家中可提供全网服务的只占42.4%,电信级DNS需求 亟需通过DNS技术研究、优化和应用，提升传统DNS走向电信级DNS并实现DNS增值,传统DNS缺失电信级能力 主流DNS是BIND软件，原为互联网设计 全网DNS未进行规范化，未进行电信级要求和提升,原因,应对方式,网内资源解析问题,2009.5.19，暴风影音事件造成电信大范围断网 20

2、10.1.12，百度域名被篡改导致无法访问 2011.8.18，新疆电信DDoS断网事件,特殊域名保障：新华网、政府网 CPU、解析成功数性能统计需求迫切 QPS等业务量统计需求 腾讯、新浪等重点域名分析 解析失败后域名纠错系统 各类系统有待梳理，建统一管理平台,DNS安全问题,电信级能力弱,深化运营问题,海量DNS请求QPS达5万，需要优化系统架构 应对大规模灾难性事故、故障等引起的域名解析问题，提升容灾备份能力,1.2 主要研究内容,立足现网 + 研究验证 + 推广应用,浙江公司,江苏公司,山东公司,北京公司,云南公司,需求分析,省公司 调研,各省回访,协调安全所封闭讨论,方案制定,规范制

3、定,计划、网络、数据部讨论,集团评审,入网测试,联合项目前期调研和研究,与集团各部门及安全所充分讨论,项目过程中进行了充分的调研和讨论,项目过程中进行了充分的测试和验证 完成分离架构及DNS重定位验证测试 已启动厂家入网测试 涉及厂商6家，用例达200余项,1.2 联合项目研究内容和整体性,江苏：统一域名服务系统技术研究与实践,北京：基于域名的增值业务运营体系研究及DNS规范制定,山东：智能纠错与应急解析备份,浙江：基于用户行为分析的DNS数据挖掘,研究院 “DNS技术研究与应用” 1）支撑全网CMNet DNS改造及新功能引入 2）制定CMNet DNS相关规范（架构、组网、功能等） 3）梳

4、理全网DNS关系，形成整体解决方案,传统DNS,DNS优化,DNS增值,云南：IPv6网络中的DNS研究,CMNet DNS,全网DNS,1.3 目标完成情况总结-成果输出,研究报告8册：DNS整体解决方案研究报告、DNS重定位现网改造方案研究、DNS项目中期评审报告、基于DNS日志挖掘的用户行为分析报告、统一域名服务系统技术研究报告、统一域名服务系统日志采集方案、 容灾容错系统研究报告、基于DNS解析的增值业务体系研究报告 企业标准2册：中国移动互联网DNS设备技术规范-已评审，中国移动DNS设备测试规范-征求意见 总计：完成研究报告8册，规范2册，专利5项，专利风险分析报告1册,DNS技术

5、研究与应用,项目成果在现网的应用与部署情况（浙江/江苏/山东/北京/云南/研究院/网络部/计划部）,计划部/网络部/研究院：关于IDC路由优化及DNS监控问题现网升级方案建议，指导全网100多台DNS服务器升级改造 研究院/网络部/计划部：DNS重定位现网改造方案研究 网络部/研究院：DNS系统数据挖掘需求分析 浙江公司：基于DNS日志挖掘的用户行为分析系统，系统已上线，测试研究报告1册 山东公司：容灾容错系统、智能纠错系统，两系统均已上线，测试报告2册 江苏公司：统一域名服务系统需求分析及软件开发，已完成验证测试，工程实施中 北京公司：XX现网试点，测试报告XX册，系统已上线 云南公司：支持

6、IPv6的域名解析系统试点，测试报告1册，系统部署中,成果总计：输出研究报告8本，规范2册，完成5个核心产品开发，完成产品试点5个，解决方案现网推广2项，正在进行入网测试（涉及6厂家，200余测试项），专利5个 完成了既定的项目目标，在解决方案现网推广/专利/企标方面超额完成目标。,1.3 目标完成情况总结-技术创新点,DNS系统加固,DNS业务支撑能力增强,业内首次制定DNS系统测试方法 在业界首先提出DNS服务器功能及性能测试方法，方法有望写入行业标准,DNS重定位方案 首次提出DNS重定位排序方案，明确了技术要求与设备支持情况，节省了网络升级成本,明确了DNS站点组网要求 明确了DNS服

7、务器三层组网方案，制定了组网要求，解决了原有四层交换机组网的性能瓶颈 联合北京公司，提出了递归DNS服务器的分离架构，并首次完成实验室验证测试，在一定程度上提高了DNS系统性能和可扩展性,业内首家制定DNS规范 业内首家制定DNS设备规范，明确了DNS相关功能、性能等要求,DNS网管监测 DNS系统各省独立部署与运维，集团无法对全网DNS进行集中监测。协助网络部首次明确DNS集中网管监测要求 首次开发多套DNS统一网管系统，实现对多套DNS系统的集中、统一管理,首次明确DNS安全要求 首次明确DDoS安全域划分，缓存投毒、DDoS等攻击防护要求，首次明确DNS安全配置要求,DNS数据挖掘系统开

8、发 首次开发部署DNS数据挖掘系统，实现了对热点业务的挖掘,DNS增值系统开发 首次进行DNS广告增值系统开发，制定了相关解决方案,DNS容灾备份系统开发 首次开发DNS容灾备份系统，实现对权威服务器数据的备份,IPv6 DNS系统部署与试点 首次进行IPv6网络DNS系统试点，实现了IPv6域名解析与访问,2010年底全国总经理会、2011年全国网络会部分省公司反馈网内资源解析至网外的问题，本项目采用DNS重定位方案缓解该问题，方案已在全国落实,暴风影音事件、百度域名攻击事件、新疆DNS DDOS攻击事件对用户造成了极大的影响，本项目对CMNet全网DNS系统提出了全面的DNS安全加固方案，

9、并在规范中进行了明确和落实,DNS安全加固,“4+1”战略推动全业务发展，全业务发展带来业务量猛增，DNS组网架构面临挑战，本项目优化了DNS组网架构 为应对大规模灾难性和故障事件等引起的域名解析问题，本项目在现网实现了DNS容灾备份方案,DNS电信级提升,为实现新华网等特殊域名保障、解析成功数性能统计、 、QPS等业务量统计需求、新浪等重点域名分析，本项目大力提升了DNS网管和统计支撑能力，在规范中进行了明确和落实 为解决用户域名解析失败后纠错系统，本项目在现网实现了解析失败后域名纠错系统 各类系统有待梳理，本项目在现网实现了统一管理平台,DNS深化运营,1）解决了7项公司在市场发展和生产运

10、营中存在的关键问题,1.3 目标完成情况总结,网内资源访问和DNS重定位,2）研究和提出了1项关键技术点的决策建议。,1.3 目标完成情况总结,决策点：IDC路由优化问题 决策内容：完成IDC路由优化功能技术方案研究，明确全网升级改造方案及要求 决策时间：2011年04月,3）申请了国内专利申请5项，其中，挖掘专利族5个（含专利20项），实现应用的专利1件，专利风险评估报告1份。,1.3 目标完成情况总结,4）输出企业标准1个。,企业标准：中国移动互联网DNS设备技术规范 评审时间：2011年10月31日 标准内容：规定了中国移动CMNet网络DNS系统的设备技术要求，具体包括：系统结构、服务

11、器功能要求、网管要求、数据分析及智能挖掘要求、可靠性及扩展性要求、安全要求、性能要求、接口要求、软硬件要求等内容,5）完成新技术试验6项,完成递归服务器合设与分离架构性能对比测试（研究院） 完成DNS重定位排序与筛选方案性能对比测试（研究院） 完成DNS挖掘系统功能验证测试（浙江） 完成容灾容错及智能纠错系统功能验证测试（山东） 完成统一域名服务系统验证测试（江苏） 完成支持IPv6的域名解析系统试点（云南） 正在进行DNS厂家入网测试,明确了设备对DNS重定位方案的支持情况，并进行了验证性测试 目前该方案已在现网100多台DNS设备上进行了升级，节约设备升级成本100万,降低建网成本,协助网

12、络部首次明确了DNS集中网管监测要求 首次开发面向多套DNS的统一网管系统，实现对多套DNS系统的集中、统一管理 预计节约运维成本30万,减少设备升级成本,降低运维成本,6）初步估计对企业绩效的贡献情况为,1.3 目标完成情况总结,明确DNS三层站点组网要求，解决了原有四层交换机组网的性能瓶颈 一台四层交换机成本约5万以上，而一台三层交换机成本约1万左右，能为每个DNS站点节约组网成本为4万左右 全网DNS共计64个站点，因此预计节约256万,项目对企业绩效贡献的量化路径图,1.4 项目企业绩效贡献和特征指标,1.4 项目企业绩效贡献和特征指标,项目特征指标的年度预期数值表,一. 课题目标实现

13、情况,目 录,二、主要研究成果（整合后）,主要研究成果,2.1 CMNet DNS优化方案研究,2.1.3 基于域名的增值业务运营体系研究,2.1.2 基于用户行为分析的DNS数据挖掘,2.1.1 DNS总体优化方案研究,2.1.4 DNS容灾备份系统研究,2.1.5 IPv6网络中的DNS研究,2.2.2 统一域名服务系统技术研究与实践,2.2.1 与其他系统DNS关系梳理,CMNet DNS存在问题及应对措施,部分省公司的权威及递归服务器合设，存在安全隐患 站点内组网缺乏统一规范，目前组网五花八门,DNS服务器攻击防范能力差 部分省份，仅设一台DNS服务器，难以进行容灾备份,目前缺乏对全网

14、DNS运行指标的网管监测能力 目前缺乏数据分析手段，无法获取用户热点业务 其他关键问题,制定并优化全网DNS系统架构、逻辑架构 全网统一组网结构要求,开展DNS安全研究 分阶段逐步落实安全要求,制定DNS网管监测指标上报要求 制定业务统计指标 制定DNS关键问题的技术要求,应对措施,DNS系统架构与组网优化,现网问题：缺乏统一管理要求和规范,安全和可靠性问题,DNS系统的业务支撑能力有待提升,现网DNS缺乏重定位能力 已引入域名存在出网现象,制定DNS重定位要求 全网部署DNS重定位功能,DNS重定位和IDC资源访问,我公司DNS由集团及各省共32个DNS节点组成，其中 权威服务器由集团和省网

15、两级架构组成 递归服务器为扁平化架构，集团节点主要用作各省节点的应急备份节点 各DNS节点遵循“双节点双路由”原则，通过异地备份的方式实现互备,CMNet DNS全国逻辑组网,DNS安全,业务支撑,架构与组网,CMNet DNS全国物理组网,DNS安全,业务支撑,架构与组网,CMNet DNS系统架构,DNS安全,业务支撑,架构与组网,关键问题分析： 一是站点问题 二是缓存和迭代分离问题,关键问题一：DNS系统的站点组网优化,DNS系统现网主要采用四层组网方案，随着DNS系统业务量逐渐增大，四层组网的性能瓶颈将会凸显 建议全网DNS系统在业务量大的情况下采用三层组网方案 三层组网技术要求： C

16、MNet DNS分为权威服务器、递归服务器，业务量大时递归服务器可考虑进一步分为缓存和迭代服务器 站点内部采用L3等价路由方式实现负载均衡 站点内部通过VLAN隔离服务器，站点内应成对部署防火墙,四层组网方案,三层组网方案,DNS安全,业务支撑,架构与组网,关键问题二：递归服务器是否分离是DNS架构分析中最主要的问题,权威和递归分离：出于安全考虑，目前集团已要求全网DNS系统的权威服务器与递归服务器进行分离 迭代和缓存分离：对于是否需要进一步把递归服务器分离成迭代和缓存，需要进行详细的分析,DNS安全,业务支撑,架构与组网,（1）可扩展性,从可扩展性方面看，由于迭代服务器上需要升级的功能较少，

17、且升级改造需要的工作量不大，因此两级架构对于可扩展性有一定好处,基本功能,安全功能,新增功能,迭代服务器功能,DNS拦截（用于应急）,TTL修改,DDos防攻击,缓存投毒防护,缓存查询功能,迭代查询功能,缓存服务器功能,缓存查询功能,DDos防攻击,缓存投毒防护,迭代查询功能,仅需修改配置,需修改代码，代码量较少,仅需修改配置,仅需修改配置,改造难度,Cutlist,Sortlist,筛选需修改代码 排序仅需修改配置,优先级,外网探测,解析结果监控,需修改代码,需修改代码,DNS安全,业务支撑,架构与组网,从上述分析来看，分离架构在安全方面能起到一定的防护作用 建议省公司根据实际的长远需求和业

18、务发展、实施成本，可选支持和部署,当出现DDoS攻击时，由于递归功能的集中，有可能出现迭代服务器先瘫痪，缓存服务器尚可工作 但分析表明缓存服务器在短时间内也会瘫痪： 缓存服务器正常工作的时间与TTL值的长短，以及攻击强度密切相关 当攻击强度大时，缓存服务器瞬时也将瘫痪 分离架构下，攻击者也可以通过自己构造一个权威服务器来直接获得后端迭代服务器的地址，因此也无法完全隐藏后端的迭代服务器 对于缓存投毒等其他类型的攻击，分离架构与合设架构没有差别 在部署了DNSSEC后，加重了对递归服务器的DDoS攻击（1.攻击难度降低：原来正常的查询请求量即可形成攻击；2.受攻击概率上升）的可能性，缓存和递归分离

19、的架构有助于缓解DDoS攻击的影响,2）安全性分析-DDoS攻击,DNS安全,业务支撑,架构与组网,VS.,（3）性能分析：,对比分析分离架构与合设架构的性能差异，关键是考虑DNS服务器数量相同，且CPU同负载的情况下，分离架构能比合设架构多处理多少QPS,DNS安全,业务支撑,架构与组网,根据测试结果，未增加任何智能策略时，分离架构缓存服务器命中率与迭代服务器命中率差别越小，分离架构与合设架构的性能差异越小 根据测试结果，服务器上增加智能策略（如TTL修改和DNS重定位功能）时，对性能影响非常小，可以忽略 现网调研发现，目前无法获取缓存服务器命中率与迭代服务器命中率,分离结构下，迭代服务器缓

20、存命中率80%，缓存服务器缓存命中率75% 合设架构下，递归服务器缓存命中率 75%,测试 场景一,分离结构下，迭代服务器缓存命中率80%，缓存服务器缓存命中率80% 合设架构下，递归服务器缓存命中率 80%,测试 场景二,（4）成本分析,根据对现网主要的6个DNS厂家的调研，DNS新增软件功能模块定价模式有以下三种： 按软件模块卖：只收一个软件开发费，没有任何license限制。 代表厂家是亚信、中网和润通 缓存按qps卖、迭代按软件模块卖：迭代服务器新增功能模块一般只收软件开发费，而缓存服务器上的新增模块会首license的qps限制。 代表厂家是泰策和牙木 按服务器台数卖：代表厂家是中太

21、,根据调研，新增DNS功能时，厂家多数是按照软件模块或者QPS请求量进行收费的，与服务器的数量并不直接相关，因此分离架构中集中建设迭代服务器并部署相关策略，并不能节省软件开发的费用,DNS安全,业务支撑,架构与组网,调研涉及的厂商,考虑可扩展性、安全、性能、成本多方面因素，分离架构在业务量大情况下能够提高设备性能，但对于可扩展性、安全效果、节省成本并不明显；业务量小的情况下效果均不明显，因此不建议全网强制要求分离架构 可扩展性：需要升级的功能较少，且升级改造工作量不大，因此两级架构对于可扩展性有一定好处 安全：缓存迭代隔离方案在安全方面能起到一定的防护作用，但效果不明显 性能：在DNS服务器数

22、量大于6台时，分离架构的性能将明显优于合设架构 成本：厂家多数是按照软件模块或者QPS请求量进行收费，与服务器的数量并不直接相关，因此分离架构中集中建设迭代服务器并部署相关策略，并不能节省软件开发的费用 建议后续进一步落实缓存命中率的现网参考数据，同时规范明确要求递归服务器数量大于6台时，建议采用分离架构,缓存与迭代是否分离的结论,迭代缓存是否分离,集中建设与现有维护机制不匹配，暂不建议集中建设迭代服务器,是否集中建设迭代服务器,多层次、有重点严格划分不同的安全域： 纵向划分为核心服务域、内部支撑系统域、管理域、集团或省公司互联区及互联网（CMNet）接入域、DMZ域； 横向划分为权威域、递归

23、域。,缓存投毒防护： 支持查询源端口支持16位随机性 根据国家的要求逐步部署DNSSEC 可选支持0X20 DDoS攻击防护： 递归服务器要具备一定的策略，过滤或终止异常请求进程 采用自动入侵防护系统（检测与清洗联动） 系统边界处部署安全设备，并加强对系统的访问控制和安全审计。,明确服务器软件配置安全要求： 隐藏BIND的版本号 避免透露服务器信息 建立访问控制列表（ACL） ,DNS系统无安全域划分，访问边界混乱。,DNS系统安全性差，易受到各种攻击。 缓存投毒 暴风影响事件DDoS攻击 其他类型的安全威胁,DNS服务器软件配置不当，导致安全威胁。,DNS安全防护,DNS安全问题,DNS系统

24、安全性提升,DNS安全,业务支撑,架构与组网,1）安全域划分,明确安全域划分的原则，对DNS系统进行区域划分，进行层次化、有重点的保护，形成清晰、简洁、稳定的DNS组网架构 实现DNS系统之间严格访问控制的安全互连，更好的解决DNS系统的安全问题。,集团公司和省公司两个层面的安全域 管理域、接入域、DMZ域、核心服务域、支撑域严格划分,纵向划分,外网解析安全域、内网解析安全域 权威DNS域、递归DNS域,横向划分,DNS安全,业务支撑,架构与组网,2）安全攻击防护-DDoS攻击防护,1,攻击者发起大量不存在或伪造域名的递归请求,迭代查询,2,新疆事件,业务支撑,架构与组网,暴风影音事件,4,本

25、地 DNS 服务器 缓存+迭代,迭代查询,询问 . com,根（.）,询问 ,迭代查询,迭代查询,授权响应,暴风托管的解析服务器受攻击，IP被封,1,缓存过期，用户客户端递归查询暴风失败,2,大量计算机暴风影音客户端不断发起查询请求,3,递归查询 ,172.16.64.11,大量的暴风影音用户持续发送域名解析请求，导致递归解析服务器的资源耗尽，形成拒绝服务攻击； 用户无法获得DNS解析服务，导致网络应用瘫痪,攻击者通过假冒源IP地址发起大量的不存在（AAAA类型的域名请求）或伪造（随机生成的以结尾的三级域名）的域名解析请求； DNS服务器资源耗尽，用户无法获得DNS解析服务，导致网络应用瘫痪,

26、DNS安全,业务支撑,架构与组网,.com,针对DDoS攻击，目前还没有成熟的方案来防范。可以通过提高设备性能、事前流量监控、事后攻击行为分析来防范。 在部署DNSSEC之后，由于递归时间变长、性能消耗大，针对递归服务器的DDoS攻击会更加严重。, ,针对DDoS攻击，目前还没有成熟的方案来防范。可以通过提高设备性能、事前流量监控、事后攻击行为分析来防范 在部署DNSSEC之后，由于递归时间变长、性能消耗大，针对递归服务器的DDoS攻击会更加严重,2）安全攻击防护-DDoS攻击防护,大量的暴风影音用户持续发送域名解析请求，导致递归解析服务器的资源耗尽，形成拒绝服务攻击； 用户无法获得DNS解析

27、服务，导致网络应用瘫痪。,暴风影音事件,1,攻击者发起大量不存在或伪造域名的递归请求,迭代查询,2,新疆事件,攻击者通过假冒源IP地址发起大量的不存在（AAAA类型的域名请求）或伪造（随机生成的以结尾的三级域名）的域名解析请求； DNS服务器资源耗尽，用户无法获得DNS解析服务，导致网络应用瘫痪。,DNS安全,业务支撑,架构与组网,2）安全攻击防护-缓存投毒防护,2008 年7 月9 日以来，微软、ISC 等互联网域名解析服务软件厂商纷纷发布了安全公告，称其DNS 软件存在高危漏洞，攻击者可以通过猜测DNS 解析过程中的报文序列号来伪造DNS权威服务器的应答，从而达到“污染”高速缓存中记录的目

28、的。,缓存投毒攻击防护 查询源端口支持16随机性 在发现异常访问后清理缓存 支持DNSSEC功能 支持0x20属性(可选) 定期递归服务器反向查询（可选） 维护知名网站IP地址列表，进行IP地址验证（可选） 被动监听检测应答报文数量（可选）,DNS安全,业务支撑,架构与组网,DNSSEC防范缓存投毒 在DNSSEC 中，所有的应答报文都经过数字签名。客户端(解析程序)通过验证消息中的数字签名判断收到的信息来源是否安全可靠，从而防止缓存投毒。 DNSSEC 的主要功能： 来源验证：通过数字签名，验证数据是否来自正确的授权服务器。 完整性验证：通过Hash校验数据在传输的过程中是否被更改。 否定存

29、在验证：对否定应答报文提供验证信息，确认授权服务器上不存在所查询的资源记录。,缓存投毒防护部署DNSSEC,DNSSEC部署建议 DNSSEC机制对DNS系统性能有较高要求。建议部署DNSSEC时明确要求服务器的性能指标要求，并对硬件设备和带宽进行相应的升级和扩容 。 DNSSEC无法防护拒绝服务攻击，在一定程度上加重了拒绝服务攻击。开启和部署DNSSEC后，相应的安全防护手段仍需不断加强。,DNS安全,业务支撑,架构与组网,DNS与IDC访问控制,DNS安全,业务支撑,架构与组网,网间结算费用高 用户体验差,上述访问问题造成的后果,在TOP1000已引入的394家网站，约有42%的子域名需要

30、出网访问 在所有已引入的流量中，出网访问的流量占比约为14%,IDC网站访问存在的问题,该问题的解决方案,方案一：升级我公司DNS具备域名重定位能力(主动式) 方案二：通过域名拦截方式将已引入网内的域名拦截至网内(主动式) 方案三：要求网站具备DNS智能解析能力（被动式）,DNS重定位方案,对运营商侧DNS进行功能改造，对CP授权DNS的解析结果进行IP地址比对、把本网的解析地址排序在前，结果上能实现网内用户优先访问所有网内网站,方案简介,DNS重定位方案比较,方案对比分析,DNS安全,业务支撑,架构与组网,DNS重定位两种方案测试对比,实验室排序方式与筛选方式性能对比测试,现网调研升级排序方

31、式前后性能对比,根据实验室对比测试结果，在相同硬件情况下，sortlist与cutlist的性能差异不大 根据现网对各省升级sortlist前后性能对比情况看， sortlist对服务器的性能影响几乎可忽略 综上，由于sortlist功能升级简单，网络改造小，成本低，建议优选排序方式,迭代查询,用户请求,仪表（模拟用户）,仪表（模拟权威服务器）,测试拓扑,递归服务器,CPU利用率不超过30%,模拟权威服务器,注：Recursor是厂家自行开发的DNS软件，同时支持sortlist和cutlist,测试结果,DNS安全,业务支撑,架构与组网,山东公司DNS设备性能调研,总量（亿条）,峰值(QPS

32、),云南公司DNS设备性能调研,浙江公司DNS设备性能调研,升级前,升级后,DNS拦截方案,DNS拦截方案：指对于网内已引入网站，直接在我公司DNS上进行域名拦截，由我公司DNS进行域名解析、直接返回解析结果给用户，用户不再到权威DNS进行域名解析,建议DNS拦截方案作为全网的应急方案（必选） 由于风险较大，DNS拦截方案不建议用于常态下大规模的域名解析方案 在通过相应手段能完全避免潜在的法律风险和用户投诉风险的前提下，允许对少量域名进行域名拦截,DNS拦截方案的意义：对于那些已经引入移动的IDC但是不支持智能DNS解析的CP域名进行拦截（部署DNS拦截方案最大能解决约14%出网访问业务量的解

33、析问题，有一定的部署意义，但是空间并不大） DNS拦截方案存在的问题： 问题一：一旦CP更新了IP地址，而我公司DNS未及时更新，将存在很大的用户投诉风险 问题二：需要部署探测服务器或者增加探测模块，否则将存在投诉风险 问题三：需要和CP签署相关的协议，否则会存在法律风险 问题四：当有域名更新需要进行拦截时，我公司需频繁修改DNS拦截服务器上的配置，每次配置生效需重启该设备，影响网络稳定性；我公司DNS要进行改造，具备配置我公司网站和IP地址对应关系能力及相关配置管理接口,1、发起解析请求 ,移动DNS,2、进行地址比对，直接用移动IP构造DNS响应包 11.11.11.1(移动),移动节点

34、域名= IP地址=11.11.11.1,3、直接解析至移动网内,CMNet网内,CP授权DNS,网内用户,电信联通节点,DNS安全,业务支撑,架构与组网,DNS网管和日志,网管：DNS系统通过数据网管系统进行管理，能够支持对设备运行指标及业务相关指标的实时监控 日志：建议设置独立的日志服务器，在解析请求到达DNS服务器之前通过分光方式对DNS流量进行旁路,DNS安全,业务支撑,架构与组网,DNS与NTP同步,在集团北京节点和集团广州节点分别设置NTP主备服务器，启动NTP服务 各省DNS节点划分为南区和北区，分别同北京/广州主备节点进行同步,时间同步 必要性,对DNS数据进行数据挖掘、业务分析

35、时，需要关联全网DNS系统进行分析，因此DNS系统应有一致的时钟。 DNS系统内部各服务器需要有一致的时钟，以便于统一管理。,北京,广州,DNS安全,业务支撑,架构与组网,TTL修改,RFC2181指出：TTL是RR记录的最大生存周期，但并非强制。其取值可为02147483647（合24855天） Bind软件对TTL配置没有要求，根据调研，部分根服务器TTL设置达3000000（合34.7天）,TTL改大：能够大大减轻DNS性能压力，对现网意义较大。但当网站割接，易造成用户无法访问的风险 TTL改小：易造成DNS频繁的出网学习，给DNS服务器造成性能压力。且用户无法直接从缓存获取DNS响应，

36、造成体验降低,根据现网调研，目前DNS服务器性能压力不大，不建议出于降低DNS服务器性能压力，全网要求支持TTL修改 由于部分省公司反馈有些CP解析不稳定（互联互通出口拥塞造成丢包），因此现网曾进行TTL修改。建议规范明确要求设备能够支持对TTL进行修改。 但由于各省公司情况不一，因此规范里要求设备应支持TTL修改功能，但不指定具体值。,DNS安全,业务支撑,架构与组网,TC位修改,TC位=0，表示DNS响应报文总长度未超过512 字节，报文未被截断 TC位=1，表示DNS响应报文总长度超过512 字节，报文已被截断。此时用户需要重新发起TCP查询，重新获取DNS响应报文,TC位基本原理,TC

37、位=1的规避方式,升级改造DNS软件，将TC位置1的强制置0 RFC2671定义了EDNS0实现方式：服务器可将包长大于512字节的DNS报文发送用户,由于易造成DNS受到TCP攻击，现网多数已在四层交换机上将TCP查询请求关闭 根据北京现网调研，目前TCP查询占比约0.0935%，用户影响面不大 随着DNSSec部署，未来出现大于512字节的DNS响应报文可能性增多；由于EDNS0方式需要客户端配合，难以控制；因此建议逐步打开TCP查询的限制，且不进行对DNS服务器TC位修改的升级,递归DNS,网内用户,需要修改递归服务器,需要客户端配合,DNS安全,业务支撑,架构与组网,主要研究成果,2.

38、1 CMNet DNS优化方案研究,2.1.3 基于域名的增值业务运营体系研究,2.1.2 基于用户行为分析的DNS数据挖掘,2.1.1 DNS总体解决方案研究,2.1.4 DNS容灾备份系统研究,2.1.5 IPv6网络中的DNS研究,2.2.2 统一域名服务系统技术研究与实践,2.2.1 与其他系统DNS关系梳理,DNS日志挖掘-研究目标,DNS系统记录了全省所有用户的域名解析请求，包含用户普遍行为，通过对域名解析请求的聚合分析，可实现网内用户关注热点提取、协助业务排障，支撑宽带业务发展,用户行为分析是配合业务发展重要分析手段 采取何种技术进行用户行为分析，需要结合现网部署综合考虑,互联网

39、业务发展需求,IDC资源引入需求：需要分析网内用户聚合行为，提取关注热点 已引入资源效能评估：对已引入资源是否提供正确服务，提供资源服务评估,DPI系统能力有限,DPI系统分析能力有限：无法按业务需求提供分析报表，设备镜像口带宽有限，开发周期长 DPI系统能力有限：海量数据分析需要大量硬件平台支撑，目前系统无法提供,研究目标,解决方案,实施成效,DNS日志挖掘的用户行为方法,DNS日志挖掘组网图,解析日志入库,单独设置解析日志留存服务器。通过交换机端口镜像，采集DNS系统上下行流量，通过DPI设备提取DNS解析与应答，形成日志 日志采集服务器从解析日志留存服务器提取日志，按照设计的数据库表，进

40、行入库操作,数据表设计,基础信息表：记录运营商IP地址信息；地市级别IP地址列表；用户类型IP地址信息 业务表：解析日志表，每日一张，分4个存储随机存放,行为聚合分析,全网用户TOPN域名 按有线宽带、WLAN、企业用户提取TOPN域名 按区域提取局部用户集中关注域名 按解析结果范围提取TOPN域名，如解析到电信/联通、到地市电信/联通的TOPN域名,网站资源分析,IDC引入站点评估：建立资源引入深度、考虑用户点击量的资源引入深度、服务全省率等三个指标 网站与域名关联分析，提取基于某站点的用户最关注的域名，实施优先引入,协助投诉处理,协助GPRS用户无下行DNS数据故障处理，提取解析日志，明确

41、原因 处理用户网站打不开投诉，统计某时段某域名的解析情况，明确产生投诉原因,研究目标,解决方案,实施成效,实施成效1,1,非著名域名挖掘,基于域名解析请求量的分析，可以挖掘非著名域名。G,等非著名域名，却在TOP100榜上有名。,2,基于一级域名的域名关联分析,对TOPN的网站域名进行细分，按解析量提取子域名，输出用户关注更多的子域名清单，按业务部分需求，提供过qqqvoduusee等子域名清单,3,用户关注首页与用户关注站点有所不同,用户关注的TOP15首页和用户关于的TOP15站点有较大差异，这和用户安装的软件有极大的关系，引入360毒霸搜狗PPSTREAM站点同样意义非凡,研究目标,解决

42、方案,实施成效,实施成效2,4,浙江IDC已引入站点评估,引入深度,对浙江已引入的TOP200及TOP1000站点进行分析，完全引入的仅占7%,5,考察本地智能DNS功能升级的必要性,对浙江省网DNS域名解析的TOP30000域名进行解析结果分析，其中同时包含移动地址和非移动地址的域名量仅占总量的0.64%。可讲本地智能DNS排序功能升级的效果不会太好。虽然浙江分析到了该数据，但本地DNS仍然按集团的要求进行了排序。,监测用户域名解析请求量，及时发现异常行为,6,浙江省网DNS域名解析请求量从3月份的每日2亿条，现已上涨为每日12亿条。但单用户的域名解析请求量应该在一个合理范围。而用户异常的请

43、求也是导致请求量大量上涨的原因。从监控中曾发现缓存系统、专线用户的异常请求请求。,研究目标,解决方案,实施成效,主要研究成果,2.1 CMNet DNS优化方案研究,2.1.4 DNS容灾备份系统研究,2.1.2 基于用户行为分析的DNS数据挖掘,2.1.1 DNS总体解决方案研究,2.1.3 基于域名的增值业务运营体系研究,2.1.5 IPv6网络中的DNS研究,2.2.2 统一域名服务系统技术研究与实践,2.2.1 与其他系统DNS关系梳理,基于域名的增值业务运营体系研究-研究目标,研究目标,解决方案,实施成效,目标1：现网DNS解析结果中有10%的错误域名解析，有效利用这部分访问流量来开

44、展增值业务,目标2：进一步提高DNS系统的智能功能,有效利用铁通及直连的IDC资源； 提高解析时延； 进一步优化0X20功能；,解决方案1-利用Nxdomain开展增值业务,研究目标,解决方案,实施成效,BMCC CMNET,北京智能DNS系统,internet,根域DNSsever,授权DNSsever,1,2,3,4,5,1,2,用户请求“”域名的IP地址；,通过迭代查询查找域名对应的IP地址，查找失败，反馈报文中通过Nxdomain字段标示该域名不存在；,3,智能DNS将Nxdomain域名封装广告网站的IP地址；,4,将重新封装后的结果反馈给用户；,5,用户访问广告网站；,Nxdoma

45、in时弹出页面,业务流程,解决方案2提升DNS系统智能性,控制缓存服务器缓存DNS记录的时间，在缓存DNS到期之前进行预缓存，获得最新的数据，如下图所示在，TTL=590秒时进行迭代查询；,当SDNS检测到伪装响应包时（比如TXID不对，或回复域名的大小写与递归请求中域名的大小写不能完全对应），则产生告警，抛弃回复包，同时对该域名发出第二次TCP请求，避免缓存中毒；,基于IP地址的多级匹配功能开发及实现,IP地址匹配的扩展应用,缓存结果的提前迭代功能,“0x20+”功能的实现,研究目标,解决方案,实施成效,实施效果1,研究目标,解决方案,实施成效,1、DNS增值业务系统已在北京公司立项实施,2

46、、智能DNS系统新增功能的实现,缓存结果的提前迭代功能（已完成开发）,“0x20+”功能的实现（已完成开发),域名增值网站功能： 网址预测，根据用户输入的域名，如果有类似的常见域名，则从其中推荐最常见的一个域名，置于首行显示； 后台统计，可统计整个导航页面的UV、PV，并可针对具体导航链接进行统计； 终端适配，根据终端是手机还是电脑，返回相应的WAP/WEB页面，并做好相应的页面适配； 运营能力，页面中的样式、板块、各元素均可动态调整。支持广告等商务操作；,实施效果2,定义A和B两个IP地址段，解析结果先于A匹配，命中就直接封装报文；未命中，再与B匹配，命中后直接封装； A= 192.168.

47、1.0/24;192.168.33.4;192.168.34.0/24; B=60.28.14.190;192.168.2.0/24;192.168.3.0/24;,多级匹配策略应用后命中60.28.14.190,策略实施前解析结果,基于IP地址的多级匹配功能（已完成开发）,研究目标,解决方案,实施成效,主要研究成果,2.1 CMNet DNS优化方案研究,2.1.3 DNS容灾备份系统研究,2.1.2 基于用户行为分析的DNS数据挖掘,2.1.1 DNS总体解决方案研究,2.1.4 基于域名的增值业务运营体系研究,2.1.5 IPv6网络中的DNS研究,2.2.2 统一域名服务系统技术研究与

48、实践,2.2.1 与其他系统DNS关系梳理,研究目标,研究目标,解决方案,实施成效,研究目标：提升DNS系统容灾容错能力,解决方案,研究目标,解决方案,实施成效,容灾容错系统运行机制 容灾容错数据采集：用户发起DNS域名查询请求，Cache服务器收到请求后递归查询该域名，收到域名查询返回数据后将结果。同时，缓存服务器部署数据采集agent模块，采集数据去重、比对更新后写入容错数据库。 容灾容错数据读取：缓存服务器部署解析数据异常探测器，当监测到某域名递归解析出现异常时，触发容灾容错功能，缓存服务器转向容灾容错Portal服务器进行查询，容灾容错Portal服务器作为加速器从容灾容错数据数据库提取数据并返回结果给缓存服务器。,实施效果,研究目标,解决方案,实施成效,显示系统当前容错的状态，包括问题域名列表，更多信息界面，可以看到哪个域名在具体dns服务器上的状态。,主要研究成果,2.1 CMNet DNS优化方案研究,2.1.3 DNS容灾备份系统研究,2.1.2 基于用户行为分析的DNS数据挖掘,2.1.1 DNS总体解决方案研究,2.1.4 基于域名的增值业务运营体系研究,2.1.5 IPv6网络中的DNS研究,2.2.2 统一域名服务系统技术研