哪些关键因素在影响互联网的性能和安全

哪些关键因素在影响互联网的性能和安全,第1张

7月12日,北京国家会议中心报告厅内,中国网络安全论坛正式举办。作为2017中国互联网大会的分论坛,中国网络安全论坛聚焦于“依法保障网络安全 为互联网+护航”主题。北京泰尔英福网络科技有限责任公司(Teleinfo)域名事业部总经理吕洪泽应邀出席论坛,并进行了题为“域名市场及应用安全状况报告”的演讲。


长期以来,我国对互联网域名产业的系统研究稍显薄弱,对这一重要基础资源的产业发展现状和趋势及其对互联网产业的影响缺少必要的数据统计和分析。此次论坛上,吕洪泽总经理旨在通过对全球及中国域名市场发展状况及特点的详细解析,解读域名产业的演变会对域名系统性能和安全带来哪些影响,同时通过对国内外域名设施建设及应用情况的对比,域名安全防护技术的剖析,让观众可以更加轻松、清晰地明了到当前影响和制约域名安全的关键因素。
域名行业演变及其对互联网安全的影响
域名是互联网的关键资源,域名系统的安全与稳定直接关系到互联网的安全与稳定。在投入使用至今的30余年中,互联网域名的种类与数量不断扩展,产业生态日趋成熟,管理体系逐步完善。尤其是2011年通过的新通用顶级域(gTLD)计划带来大量新进入者,行业生态活跃度大幅提高,推动顶级解析服务生态变化,市场竞争日趋激烈。
(1)大量新的非传统顶级域名服务主体涌入顶级域名服务,如谷歌、泰尔英福等。(2)原来顶级域运营管理机构自建自营的局面被打破,形成了新的竞争市场。传统顶级域运营机构(如CentralNic等)和有实力的新进入者在自建自营的同时开始向新进入者开放托管和运营业务。顶级解析服务竞争的引入,带动有实力的顶级域运营机构不断完善解析服务设施,提升对外服务的竞争力。CentralNic在除南极洲外的全球六大洲均部署了解析及镜像节点;谷歌利用原有网络基础建设了全球化的解析服务系统,在美洲、欧洲、亚洲的许多国家均部署了解析及镜像节点;域名全生命周期平台服务商Teleinfo,建成面向全球的多中心、多节点的服务平台,开发部署域名云注册局、数据托管、合规等服务,解析节点分布于欧、美及国内核心运营商。目前Teleinfo的国内解析服务设施主要分布在成都、北京等地,覆盖了我国主要运营商,同时也在英国伦敦、美国旧金山、荷兰阿姆斯特丹部署了解析节点。
这些域名生态上的变化,将大幅提升互联网基础设施的访问性能和安全冗余性: 一方面提高了DNS的安全冗余性,分流攻击流量,增强整体抗攻击能力,使得DNS整体架构更富有d性;另一方面,镜像服务器为部署地区用户提供就近的根解析服务能力,提升区域用户的根解析响应时间和解析成功率。


国内互联网行业与国际存在的显著差距
互联网新技术和新业务的不断涌现也对域名系统的发展提出新的要求,其效率与安全直接关系到互联网的健康稳定运行。如果要概括当前国际域名设施建设及应用的情况,可以用五句话来形容其特点:(1)根镜像全球分布式扩展,性能与安全冗余性大幅提升;(2)顶级解析服务竞争日趋激烈,设施快速增长完善;(3)权威解析服务TOP企业优势明显,GoDaddy一枝独秀;(4)递归解析应用价值突出;(5)域名解析安全成为互联网安全重要环节。
相较而言,国内的情况也可以用五点来描述:(1)我国根访问以国内引入镜像为主,根镜像数量仍显不足;(2)国际知名通用域设施引入较少,自主顶级域基础设施国内外布局逐步完善;(3)权威解析服务商跻身国际前列,行业关注度不断提升;(4)接入服务商递归解析占据主流,第三方市场百家争鸣;(5)域名解析性能不断提升,与国际先进水平仍有差距。
据统计,目前美国根服务器及镜像约占全球总量六分之一左右,我国只引入四个根(F、I、J、L)镜像节点,总数量位居全球第19位,不及美国十分之一。由于递归服务器对根服务器的访问策略采用“初始轮询,性能择优”的原则,目前我国根域名解析中,约六成可实现对国内已引入根镜像服务器的就近访问。
作为宽带网络通信的一环,我国固定宽带用户的域名解析性能低于发达国家,各基础电信运营企业之间的解析时延差异较大。据统计,2015年,我国固定宽带用户DNS解析时延的平均值为4677ms,比2014年欧盟30国平均DNS解析时延高出87%。
其中,我国访问引入镜像4个根平均解析性能为70 ms左右,远小于其它未引入镜像根平均解析性能190 ms。但由于受引入镜像数量、网络访问质量等因素影响,根镜像服务器访问性能与国际主流国家尚存在较大差距,解析时延约超过国际发达国家两倍左右。
域名解析安全成为互联网安全重要环节
域名解析故障是引起互联网安全问题的最频发原因之一。DNS是Internet的重要基础,包括Web访问、Email服务在内的众多网络服务都和DNS息息相关,DNS的安全直接关系到整个互联网应用能否正常使用。近年来,针对DNS的攻击越来越多,影响也越来越大,因此如何保护DNS系统的安全就成为了目前互联网安全的首要问题之一。
(1)针对域名系统的攻击已成为互联网最重大的威胁之一,拒绝服务(DDoS)攻击、域名劫持、缓存投毒等频发。据统计,DNS是全球受攻击最为严重的三大互联网业务之一,DNS是全球DDoS攻击的第二大目标。国内外域名安全事件层出不穷,影响范围广,破坏性强。(2)域名体系的桥梁作用被恶意利用,成为攻击互联网的手段。如反射放大攻击利用了DNS递归请求等特性,以较低的成本向网络发动巨大的流量攻击。
DNS安全防护主要面临如下威胁:(1)针对DNS的DDoS攻击;(2)DNS欺骗;(3)系统漏洞。
各国高度重视域名解析系统安全,提升域名系统的安全性已成为全球业界协作的发力点。目前,DNSSEC在根和顶级域的部署取得阶段性进展,根服务器已全部部署了DNSSEC验证服务,截至2015年底,已有803%的顶级域名服务器部署了DNSSEC。此外,在反垃圾邮件、治理钓鱼网站等方面的国际合作近年来继续加强。
此次论坛上还发布了《中国互联网站发展状况及其安全报告(2017)》,《报告》由中国互联网协会和国家互联网应急中心联合发布,获得了北京泰尔英福网络科技有限责任公司、中国电信集团等单位支持。


北京泰尔英福网络科技有限责任公司(Teleinfo)依托“信息”顶级域,自建了面向全球的域名全生命周期服务平台,是完全覆盖域名实/命名验证、解析托管、云注册局、监测服务等环节的域名全生命周期服务商。Teleinfo负责运营托管的新顶级域已然超过10个,包括“信息”、“在线”、“中文网”等。泰尔英福是中文域名应用创新的坚定推动者,致力于实现更广范围的互联互通,更优质的网络在线服务和用户体验。

DNS服务器分为两种,权威服务器和缓存服务器(也叫递归服务器)。
权威服务器提供权威的数据,缓存服务器从权威服务器获取数据转发给查询的客户端。
TTL值是在权威服务器设置的,缓存服务器从权威服务器获取数据时得到TTL,这个TTL值会随时间变小,变为0时数据失效,需要从权威服务器重新获取数据。
刚才查了下,googlecom的TTL是300秒,baiducom的TTL是7200秒。
dig googlecom a +trace
dig baicucom a +trace
(googlecom和>域名系统DNS(Domain Name System)是因特网使用的命名系统,用来把便于人们使用的机器名字转换成为IP地址。域名系统其实就是名字系统。为什么不叫“名字”而叫“域名”呢?这是因为在这种因特网的命名系统中使用了许多的“域(domain)”,因此就出现了“域名”这个名词。“域名系统”明确地指明这种系统是应用在因特网中。
那么DNS如何解析呢,其解析过程有哪些呢?下面让我们举一个例子演示整个解析过程:
假定域名为mxyzcom的主机想知道另一个主机yabccom的IP地址。例如,主机mxyzcom打算发送邮件给yabccom。这时就必须知道主机yabccom的IP地址。下面是上a的几个查询步骤:
1、主机mabccom先向本地服务器dnsxyzcom进行递归查询。
2、本地服务器采用迭代查询。它先向一个根域名服务器查询。
3、根域名服务器告诉本地服务器,下一次应查询的顶级域名服务器dnscom的IP地址。
4、本地域名服务器向顶级域名服务器dnscom进行查询。
5、顶级域名服务器dnscom告诉本地域名服务器,下一步应查询的权限服务器dnsabccom的IP地址。
6、本地域名服务器向权限域名服务器dnsabccom进行查询。
7、权限域名服务器dnsabccom告诉本地域名服务器,所查询的主机的IP地址。
8、本地域名服务器最后把查询结果告诉mxyzcom。
为了提高DNS查询效率,并减轻服务器的负荷和减少因特网上的DNS查询报文数量,在域名服务器中广泛使用了高速缓存,用来存放最近查询过的域名以及从何处获得域名映射信息的记录。
例如,在上面的解析过程中,如果在mxyzcom的主机上不久前已经有用户查询过yabccom的IP地址,那么本地域名服务器就不必向根域名服务器重新查询yabccom的IP地址,而是直接把告诉缓存中存放的上次查询结果(即yabccom的IP地址)告诉用户。
由于名字到地址的绑定并不经常改变,为保持高速缓存中的内容正确,域名服务器应为每项内容设置计时器并处理超过合理时间的项。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息,就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时,在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销,而减少此时间值可提高域名解析的正确性。

我们在使用PHP递归时,会遇到各种各样的问题,其中比较令人苦恼的是有关PHP递归返回值时出现的问题。其实细细想想这是一个很简单的问题。可就是这个简单的问题困扰了半个下午。问题出在递归函数的返回值上。
这是开始写的:
代码如下:
<php   
function test($i)   
{   
$i -= 4;   
if($i < 3)   
{   
return $i;   
}   
else    
{   
test($i);   
}   
}   
echo test(30);   

这段代码看起来没有问题,其实有else里面是有问题的。在这里执行的test没有返回值。所以虽然满足条件$i < 3时 return $i整个函数还是不会返回值的。对上面的PHP递归返回值函数做如下修改:
代码如下:
< php   
function test($i)   
{   
$i -= 4;   
if($i < 3)   
{   
return $i;   
}   
else    
{   
return test($i); //增加return, 让函数返回值   
}   
}   
echo test(30);   
>
以上代码示例就是PHP递归返回值出现问题时的具体解决方法。

由于CNAME记录具有排他性,dns查找过程中碰到CNAME会递归重启查询。
因而当TXT和CNAME同时存在时,若先被查询到的记录是CNAME,那么这条TXT记录就不能被查询到了。
这个是有标准规范的,如下:
CNAME 记录是 DNS 里的一种特殊的记录类型,一般理解为“别名”记录。之所以说其 特殊,请看下面的例子。假设为 DNS 域 demoonly 注册了下面的两条记录:
下面是在递归服务器(不能使用该域的授权服务器)上 dig 查询的结果(省略了部分 不重要的信息):
可以看到 MX 记录查询的结果为其 CNAME 记录值所配置的 MX 记录。 但如果在递归服务器的 CNAME 记录 TTL 过期后再来做查询,只是把查询的顺序颠倒, (即先查询 MX 记录,再查询 CNAME 记录)则有可能得到正确的结果。
在上面的测试过程中授权服务器和递归服务器都是有着大量用户的知名 DNS 服务提 供商,因此,程序出现 bug 的可能性可以忽略。那么,怎么解释这种现象呢?
权威的说明则请参考相关的 RFC 文档。部分原文摘抄如下:
中文说明如下:
递归 DNS 服务器在查询某个常规域名记录(非 CNAME 记录)时,如果在本地 cache 中已有该域名有对应的 CNAME 记录,则会开始用该别名记录来重启查询。 上文中第一次 dig 查询 MX 记录即对应于这种情况。如果直接在授权服务器上查询, 则总是能得到预期的结果。或者简单的理解为 CNAME 的优先级更高。
已经注册了 CNAME 类型的域名记录不能再注册除 DNSSEC 相关类型记录 (RRSIG, NSEC 等)之外的其他类型记录,包括(MX, A, NS 等记录)。
这就是本文最开始 dig 查询 MX 记录拿不到预期结果的原因。从用户的角度来说, 对任何记录(尤其是 @ 记录,因为该记录用到 MX 的可能性非常大)的配置如果 用到了 CNAME,则需要知道该域名不可再配置 MX 等其他记录。从 DNS 服务提供 商的角度来说,需要显示的告知用户这样配置的风险,警示和教育用户。

递归是用户只向本地DNS服务器发出请求,然后等待肯定或否定答案。
迭代是本地服务器向根DNS服务器发出请求,而根DNS服务器只是给出下一级DNS服务器的地址,然后本地DNS服务器再向下一级DNS发送查询请求直至得到最终答案。
DNS是以树状目录分阶层的方式来处理主机名,树状结构的好处就是,父节点只关注他的子节点的内容,而不关注他的孙子节点的内容,这样就在很大程度上实现了分治,根节点只需要管理它的子节点。因此,迭代更为常用一点。

1、工作方式上的区别

递归查询是域名服务器将代替提出请求的客户机(下级DNS服务器)进行域名查询,若域名服务器不能直接回答,则域名服务器会在域各树中的各分支的上下进行递归查询,最终将返回查询结果给客户机。

迭代查询是能够使其他服务器返回一个最佳的查询点提示或主机地址,若此最佳的查询点中包含需要查询的主机地址,则返回主机 地址信息,若此时服务器不能够直接查询到主机地址,则是按照提示的指引依次查询。

2、使用上的区别

一般由DNS工作站提出的查询请求便属于递归查询。一般发生在客户端与服务器间,也有特殊情况是dns服务器与dns服务器之间。

根域名服务器总应该使用迭代查询,而不应该使用递归查询。一般的,每次指引都会更靠近根服务器(向上),查寻到根域名服务器后,则会再次根据提示向下查找。

3、查询状态上的区别

递归查询,在域名服务器查询期间,客户机将完全处于等待状态。

迭代查询是直到服务器给出的提示中包含所需要查询的主机地址为止。

参考资料来源:百度百科-递归查询

参考资料来源:百度百科-迭代查询


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/10631940.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-10
下一篇 2023-05-10

发表评论

登录后才能评论

评论列表(0条)

保存