<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>DNSPod Team Blog &#187; DNSSEC</title>
	<atom:link href="http://blog.dnspod.com/tag/dnssec/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.dnspod.com</link>
	<description>DNSPod.COM official Blog</description>
	<lastBuildDate>Wed, 01 Sep 2010 03:57:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>关于此次ICANN大规模部署DNSSEC</title>
		<link>http://blog.dnspod.com/2010/05/icann-deploy-dnssec/</link>
		<comments>http://blog.dnspod.com/2010/05/icann-deploy-dnssec/#comments</comments>
		<pubDate>Wed, 05 May 2010 10:07:29 +0000</pubDate>
		<dc:creator>Sam</dc:creator>
				<category><![CDATA[News]]></category>
		<category><![CDATA[DNSSEC]]></category>
		<category><![CDATA[ICANN]]></category>

		<guid isPermaLink="false">http://blog.dnspod.com/?p=275</guid>
		<description><![CDATA[根据DNSPOD的观察，ICANN已经成功的把DNSSEC部署到13台根DNS服务器上了。 此次部署之紧张，令人始料未及，ICANN事前没有足够的通知，或许背后会有更加深层次的原因。 根据了解，2003年以前生产的网络设备，有不少不支持DNSSEC，这意味着大量运营商都需要升级他们的网络设备。对于来不及升级网络设备的运营商来说，可能会造成他们的用户无法正常解析一个域名，甚至会因为无法解析域名而引起一些小规模的DNS请求风暴。所以未来几天内，可能会有部分地区用户所用的DNS不正常，会经常解析失败，甚至无法解析。但这情况会随着运营商升级他们的设备逐渐解决。 DNSPOD为了应对此次事件，增加了对DNSSEC的支持，但这并不意味着用户用DNSPOD就不会出现解析失败的情况。因为就算DNSPOD解析正常，也有可能因为运营商的设备不支持DNSSEC而导致解析失败。所以问题最终还是要靠运营商去解决。 根据ICANN的时间表，此次大规模部署上线的DNSSEC支持，所使用来加密的KEY只是用来测试，无法作为DNSSEC合法性验证的用途。也就是说，大家都是小白鼠。正式可以使用来加密的KEY，将会在7月份部署上线。 虽然DNSSEC部署上线，但离域名防劫持还有很长一段路要走。因为正式的KEY上线后，需要域名拥有者自己去生成属于自己域名的KEY，并且去DNS服务器上面部署，一般的域名拥有者是玩不来这么复杂的东西的。不过未来DNSPOD可能会帮大家把这些事情都做完。 未来DNSPOD将会继续对此事进行关注和跟进。 附：ICANN的DNSSEC部署时间表 December 1, 2009: Root zone signed for internal use by VeriSign and ICANN.  ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK. January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). [...]]]></description>
			<content:encoded><![CDATA[<p>根据DNSPOD的观察，ICANN已经成功的把DNSSEC部署到13台根DNS服务器上了。</p>
<p>此次部署之紧张，令人始料未及，ICANN事前没有足够的通知，或许背后会有更加深层次的原因。</p>
<p>根据了解，2003年以前生产的网络设备，有不少不支持DNSSEC，这意味着大量运营商都需要升级他们的网络设备。对于来不及升级网络设备的运营商来说，可能会造成他们的用户无法正常解析一个域名，甚至会因为无法解析域名而引起一些小规模的DNS请求风暴。所以未来几天内，可能会有部分地区用户所用的DNS不正常，会经常解析失败，甚至无法解析。但这情况会随着运营商升级他们的设备逐渐解决。</p>
<p>DNSPOD为了应对此次事件，增加了对DNSSEC的支持，但这并不意味着用户用DNSPOD就不会出现解析失败的情况。因为就算DNSPOD解析正常，也有可能因为运营商的设备不支持DNSSEC而导致解析失败。所以问题最终还是要靠运营商去解决。</p>
<p>根据ICANN的时间表，此次大规模部署上线的DNSSEC支持，所使用来加密的KEY只是用来测试，无法作为DNSSEC合法性验证的用途。也就是说，大家都是小白鼠。正式可以使用来加密的KEY，将会在7月份部署上线。</p>
<p>虽然DNSSEC部署上线，但离域名防劫持还有很长一段路要走。因为正式的KEY上线后，需要域名拥有者自己去生成属于自己域名的KEY，并且去DNS服务器上面部署，一般的域名拥有者是玩不来这么复杂的东西的。不过未来DNSPOD可能会帮大家把这些事情都做完。</p>
<p>未来DNSPOD将会继续对此事进行关注和跟进。</p>
<p>附：ICANN的DNSSEC部署时间表</p>
<ul>
<li>December 1, 2009: Root zone signed for internal use by VeriSign and ICANN.  ICANN and VeriSign exercise interaction protocols for signing the ZSK with the KSK.</li>
<li>January, 2010: The first root server begins serving the signed root in the form of the DURZ (deliberately unvalidatable root zone). The DURZ contains unusable keys in place of the root KSK and ZSK to prevent these keys being used for validation.</li>
<li>Early May, 2010: All root servers are now serving the DURZ.  The effects of the larger responses from the signed root, if any, would now be encountered.</li>
<li>May and June, 2010: The deployment results are studied and a final decision to deploy DNSSEC in the root zone is made.</li>
<li>July 1, 2010: ICANN publishes the root zone trust anchor and root operators begin to serve the signed root zone with actual keys – The signed root zone is available.</li>
</ul>]]></content:encoded>
			<wfw:commentRss>http://blog.dnspod.com/2010/05/icann-deploy-dnssec/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>DNS根服务器升级 可能造成部分用户无法解析域名</title>
		<link>http://blog.dnspod.com/2010/05/root-dns-upgrade-dnssec/</link>
		<comments>http://blog.dnspod.com/2010/05/root-dns-upgrade-dnssec/#comments</comments>
		<pubDate>Wed, 05 May 2010 09:36:14 +0000</pubDate>
		<dc:creator>Cat</dc:creator>
				<category><![CDATA[Announce]]></category>
		<category><![CDATA[News]]></category>
		<category><![CDATA[Tech]]></category>
		<category><![CDATA[DNSPod]]></category>
		<category><![CDATA[DNSSEC]]></category>
		<category><![CDATA[root]]></category>
		<category><![CDATA[upgrade]]></category>
		<category><![CDATA[故障]]></category>

		<guid isPermaLink="false">http://blog.dnspod.com/?p=271</guid>
		<description><![CDATA[今天下午﻿DNS根服务器升级，对于用户来说，最直接的影响就是有可能导致部分地区、线路的用户无法解析。 问题的原因是这些地区、线路运营商的网络设备过于陈旧，不支持根服务器升级可能带来的变化，导致经过这些设备的DNS查询被过滤，这与DNSPod解析的稳定性无关。 我们DNSPod为了上DNSSEC也是耗费了大量的CPU。 转发全文如下： 5月5日，由ICANN，美国政府和Verisign领导的全球13台根域名服务器将会迎来DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）升级，DNSSEC升级将会在反馈给互联网用户的DNS请求响应中插入数字签名，确保返回的域名地址是未经篡改的。 DNSSEC是为阻止中间人攻击而设计的，利用中间人攻击，黑客可以劫持DNS请求，并返回一个假地址给请求方，这种攻击手段类似于正常的DNS重定向，人们在不知不觉中被转到另一个URL。 据Melbourne IT首席战略官，ICANN董事Bruce Tonkin说，本次升级将会给那些毫无准备的网络管理员一个措手不及，响应标准DNS请求往往只有一个单一的数据包（UDP协议），大小一般不会超过 521字节，在某些较旧的网络设备中，比这个大的请求将会被出厂默认配置阻止掉，它会认为超过这个大小的数据包是异常的。 截至UTC 5月5日17:00点，所有发送给用户DNS解析器的DNSSEC签名的消息将会变大到2KB，是原来的4倍，但这么大的数据包可能会被许多网络设备拒绝接收，因此这个响应消息很可能会通过TCP分成多个数据包进行发送。 Tonkin有点担心，虽然DNSSEC已经提上日程有一段时间了，但许多IT和网络管理员还没有测试他们的旧路由器和防火墙，如果不能处理更大的DNS响应数据包就麻烦了。 他说：“企业网络中的设备可能会阻止比以往更大的DNS请求响应数据包”。 DNSSEC其实早在 2009年11月就在全球13台根服务器上准备好了，到目前为止，它只会导致许多旧网络设备载入网页略有延迟。 不是所有DNS根服务器都会响应每一个请求，用户机器上的DNS解析器会逐个请求这13台根服务器，直到返回一个满意的答复。当13台具有 DNSSEC签名功能的根服务器全部上线后，所有的响应不会抵达旧设备的企业网络，Tonkin希望大型ISP能解决这个问题，让家庭用户不受影响。 他说：“我不能保证所有ISP都准备好了，ISP会为你翻译DNS，但企业网络可能影响比较大，因为企业可能运行了自己的DNS服务器”。 从这个意义上来说，5月5日可与千年虫危机匹敌。Tonkin预计会有大量的组织遇到互联网接入问题，大量的网络管理员将会抓破头皮寻找问题的根源。 这个问题可能需要数天才能完全消除，晚上未关机的用户可能会访问到一些页面，那也仅仅是缓存中的内容。Tonkin建议网络管理员尽快运行一系列简单的测试，确保他们的网络可以处理更大的DNS响应包。 【51CTO.com译稿，合作站点转载请注明原文译者和出处。】 原文：Warning: Why your Internet might fail on May 5 作者：Brett Winterford]]></description>
			<content:encoded><![CDATA[<p><span style="color: #ff0000;">今天下午﻿DNS根服务器升级，对于用户来说，最直接的影响就是有可能导致部分地区、线路的用户无法解析。</span></p>
<p><span style="color: #ff0000;">问题的原因是这些地区、线路运营商的网络设备过于陈旧，不支持根服务器升级可能带来的变化，导致经过这些设备的DNS查询被过滤，这与DNSPod解析的稳定性无关。</span></p>
<p><span style="color: #ff0000;">我们DNSPod为了上DNSSEC也是耗费了大量的CPU。</span></p>
<p>转发全文如下：</p>
<p>5月5日，由ICANN，美国政府和Verisign领导的全球13台根域名服务器将会迎来DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）升级，DNSSEC升级将会在反馈给互联网用户的DNS请求响应中插入数字签名，确保返回的域名地址是未经篡改的。</p>
<p>DNSSEC是为阻止中间人攻击而设计的，利用中间人攻击，黑客可以劫持DNS请求，并返回一个假地址给请求方，这种攻击手段类似于正常的DNS重定向，人们在不知不觉中被转到另一个URL。</p>
<p>据Melbourne IT首席战略官，ICANN董事Bruce Tonkin说，本次升级将会给那些毫无准备的网络管理员一个措手不及，响应标准DNS请求往往只有一个单一的数据包（UDP协议），大小一般不会超过 521字节，在某些较旧的网络设备中，比这个大的请求将会被出厂默认配置阻止掉，它会认为超过这个大小的数据包是异常的。</p>
<p>截至UTC 5月5日17:00点，所有发送给用户DNS解析器的DNSSEC签名的消息将会变大到2KB，是原来的4倍，但这么大的数据包可能会被许多网络设备拒绝接收，因此这个响应消息很可能会通过TCP分成多个数据包进行发送。</p>
<p>Tonkin有点担心，虽然DNSSEC已经提上日程有一段时间了，但许多IT和网络管理员还没有测试他们的旧路由器和防火墙，如果不能处理更大的DNS响应数据包就麻烦了。</p>
<p>他说：“企业网络中的设备可能会阻止比以往更大的DNS请求响应数据包”。</p>
<p>DNSSEC其实早在 2009年11月就在全球13台根服务器上准备好了，到目前为止，它只会导致许多旧网络设备载入网页略有延迟。</p>
<p>不是所有DNS根服务器都会响应每一个请求，用户机器上的DNS解析器会逐个请求这13台根服务器，直到返回一个满意的答复。当13台具有 DNSSEC签名功能的根服务器全部上线后，所有的响应不会抵达旧设备的企业网络，Tonkin希望大型ISP能解决这个问题，让家庭用户不受影响。</p>
<p>他说：“我不能保证所有ISP都准备好了，ISP会为你翻译DNS，但企业网络可能影响比较大，因为企业可能运行了自己的DNS服务器”。</p>
<p>从这个意义上来说，5月5日可与千年虫危机匹敌。Tonkin预计会有大量的组织遇到互联网接入问题，大量的网络管理员将会抓破头皮寻找问题的根源。</p>
<p>这个问题可能需要数天才能完全消除，晚上未关机的用户可能会访问到一些页面，那也仅仅是缓存中的内容。Tonkin建议网络管理员尽快运行一系列简单的测试，确保他们的网络可以处理更大的DNS响应包。</p>
<p>【51CTO.com译稿，合作站点转载请注明原文译者和出处。】<br />
原文：Warning: Why your Internet might fail on May 5 作者：Brett Winterford</p>]]></content:encoded>
			<wfw:commentRss>http://blog.dnspod.com/2010/05/root-dns-upgrade-dnssec/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
