<?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>ICANN Blog &#187; L-Root</title>
	<atom:link href="http://blog.icann.org/category/dns/l-root-dns/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.icann.org</link>
	<description>Internet Corporation for Assigned Names and Numbers</description>
	<lastBuildDate>Fri, 10 May 2013 21:09:11 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
		<item>
		<title>IPv6 All the Way Down</title>
		<link>http://blog.icann.org/2012/06/ipv6-all-the-way-down/</link>
		<comments>http://blog.icann.org/2012/06/ipv6-all-the-way-down/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:32:49 +0000</pubDate>
		<dc:creator>Leo Vegoda</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[English]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4067</guid>
		<description><![CDATA[In the past we&#8217;ve talked about how the Internet&#8217;s key infrastructure has been getting ready for IPv6. In 2004, the first IPv6 glue was added to the root DNS zone for .JP and .KR but when you look at a part of the root zone today &#8211; the part related to ccTLDs derived from the [...]]]></description>
				<content:encoded><![CDATA[<p>In the past we&#8217;ve talked about how the Internet&#8217;s key infrastructure has been getting ready for IPv6. In 2004, the first IPv6 glue was added to the root DNS zone for .JP and .KR but when you look at a part of the root zone today &ndash; the part related to ccTLDs derived from the ISO-3166-1 list &ndash; you can see that a huge proportion of TLD operators are ready for IPv6.</p>
<div style="margin-bottom: 1em;"> <a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"> <img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>In 2008 another big step was taken, when IPv6 glue was added for six of the root DNS servers. Today, in 2012, nine have IPv6 glue and as the map below shows, IPv6 access to root DNS servers is widely spread around the world. While all L-root nodes are IPv6 capable, some are attached to networks that do not yet run IPv6, so only 68 of the 112 nodes deployed today are accessed over IPv6.</p>
<div style="margin-bottom: 1em;"> <a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"> <img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"></a></div>
<p>Beyond the DNS, major network backbones and IXPs have been IPv6 ready for years, too. Currently, 95% of Euro-IX&#8217;s 63 members have IPv6 peering LANs ate the exchanges they operate. This means that ISPs, the IXPs&#8217; customers have been keen to make sure their peering platforms are ready for IPv6.</p>
<p>These are all major deliverables on the critical path to smooth IPv6 deployment. Now they&#8217;re done it&#8217;s time for content and access providers to offer content and access over IPv6. As the measurements make very clear, <a href="http://www.worldipv6launch.org/measurements/">World IPv6 Launch</a> delivered lots of content over IPv6 and a lot of large ISPs have been enabling their subscribers, with millions more to follow before the year end.</p>
<p>But those subscribers need IPv6 capable routers and modems in their homes so that they can access the Internet over IPv6. <a href="http://www.worldipv6launch.org/participants/?q=3">Five manufacturers</a> are now offering home networking equipment that&#8217;s IPv6 enabled by default and available at low and medium price points. This is on top of the <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">17 IPv6 ready cable modem products</a> available today.</p>
<p>All the jigsaw pieces are now available for successful IPv6 deployment to consumer Internet users.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/ipv6-all-the-way-down/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv6 一路向前</title>
		<link>http://blog.icann.org/2012/06/ipv6-%e4%b8%80%e8%b7%af%e5%90%91%e5%89%8d/</link>
		<comments>http://blog.icann.org/2012/06/ipv6-%e4%b8%80%e8%b7%af%e5%90%91%e5%89%8d/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:31:41 +0000</pubDate>
		<dc:creator>ICANN Blog</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>
		<category><![CDATA[中文]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4481</guid>
		<description><![CDATA[此前，我们谈到了互联网的关键基础架构已经做好了部署 IPv6 的准备。2004 年，.JP 和 .KR 域名的根 DNS 域添加了第一个 IPv6 粘附，而在当今的根区域中，从与 ISO-3166-1 名单衍生的 ccTLD 相关的部分看，我们可以发现，有极大部分的 TLD 运营商已经准备好迎接 IPv6。 2008 年，IPv6 进程又迈出了一大步，又有六台根 DNS 服务器添加了 IPv6 粘附。时至今日，已有九台根 DNS 服务器上有 IPv6 粘附，具体如下图所示。世界各地已经广泛分布了能访问根 DNS 服务器的 IPv6 接口。虽然所有的 L-根节点都支持 IPv6，某些节点仍然隶属于未部署 IPv6 的网络，因此，目前已部署的 112 个节点中仅有 68 个能够接入 IPv6 网络。 除了 DNS 以外，主要的骨干网络和 IXP 都已经在数年前做好了部署 IPv6 的准备。目前，Euro-IX 的 63 个成员中 95% 已经在自己运行的交换服务器上测试了 [...]]]></description>
				<content:encoded><![CDATA[<p>此前，我们谈到了互联网的关键基础架构已经做好了部署 IPv6 的准备。2004 年，.JP 和 .KR 域名的根 DNS 域添加了第一个 IPv6 粘附，而在当今的根区域中，从与 ISO-3166-1 名单衍生的 ccTLD 相关的部分看，我们可以发现，有极大部分的 TLD 运营商已经准备好迎接 IPv6。</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"><img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>2008 年，IPv6 进程又迈出了一大步，又有六台根 DNS 服务器添加了 IPv6 粘附。时至今日，已有九台根 DNS 服务器上有 IPv6 粘附，具体如下图所示。世界各地已经广泛分布了能访问根 DNS 服务器的 IPv6 接口。虽然所有的 L-根节点都支持 IPv6，某些节点仍然隶属于未部署 IPv6 的网络，因此，目前已部署的 112 个节点中仅有 68 个能够接入 IPv6 网络。</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"><img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"></a></div>
<p>除了 DNS 以外，主要的骨干网络和 IXP 都已经在数年前做好了部署 IPv6 的准备。目前，Euro-IX 的 63 个成员中 95% 已经在自己运行的交换服务器上测试了 IPv6 局域网。这表明各 ISP（IXP 的客户）都热衷于确保其试验平台能够部署 IPv6。</p>
<p>这些都是顺利部署 IPv6 的关键进程中取得的重大成果。鉴于这些已取得的成果，现在正是让内容和接入供应商在 IPv6 网络上提供内容和接入服务的时机。测量结果清楚地表明，<a href="http://www.worldipv6launch.org/measurements/">World IPv6 Launch</a>（世界 IPv6 启动）已成功在 IPv6 上发送了许多的内容，而许多大型 ISP 也已经为用户开放了 IPv6 服务，并且在今年结束之前将再有数百万用户接入 IPv6 网络。</p>
<p>但这些用户须在家中自备支持 IPv6 的路由器和调制解调器，才能通过 IPv6 访问互联网。目前有<a href="http://www.worldipv6launch.org/participants/?q=3">五家制造商</a>正在供应默认支持 IPv6 的家庭网络连接设备，并且价格适中。这些产品在目前在售的 <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">17 种支持 IPv6 的有线调制解调器产品</a>中位于前列。</p>
<p>目前所有已具备的条件表明，IPv6 可以成功部署，供商业型互联网用户使用。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/ipv6-%e4%b8%80%e8%b7%af%e5%90%91%e5%89%8d/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Полное развертывание IPv6</title>
		<link>http://blog.icann.org/2012/06/%d0%bf%d0%be%d0%bb%d0%bd%d0%be%d0%b5-%d1%80%d0%b0%d0%b7%d0%b2%d0%b5%d1%80%d1%82%d1%8b%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-ipv6/</link>
		<comments>http://blog.icann.org/2012/06/%d0%bf%d0%be%d0%bb%d0%bd%d0%be%d0%b5-%d1%80%d0%b0%d0%b7%d0%b2%d0%b5%d1%80%d1%82%d1%8b%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-ipv6/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:29:47 +0000</pubDate>
		<dc:creator>ICANN Blog</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>
		<category><![CDATA[Русский]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4487</guid>
		<description><![CDATA[В прошлом мы говорили о процессе подготовки критически важной инфраструктуры Интернета к использованию IPv6. В 2004 году первые связующие элементы IPv6 были добавлены в корневую зону DNS для доменов .JP и .KR, однако если в наши дни взглянуть на часть корневой зоны &#8211; ту часть, которая относится к нДВУ из списка ISO-3166-1, &#8211; можно увидеть, [...]]]></description>
				<content:encoded><![CDATA[<p>В прошлом мы говорили о процессе подготовки критически важной инфраструктуры Интернета к использованию IPv6. В 2004 году первые связующие элементы IPv6 были добавлены в корневую зону DNS для доменов .JP и .KR, однако если в наши дни взглянуть на часть корневой зоны &ndash; ту часть, которая относится к нДВУ из списка ISO-3166-1, &ndash; можно увидеть, что очень большая часть операторов ДВУ готова к использованию IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"><img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>В 2008 году был сделан еще один большой шаг, когда были добавлены связующие элементы IPv6 для шести корневых серверов DNS. На сегодняшний день, в 2012 году, девять из них имеют связующие элементы IPv6 и, как показано на карте ниже, доступ по протоколу IPv6 к корневым серверам DNS широко распространен по всему миру. Хотя все корневые узлы сервера &laquo;L&raquo; совместимы с IPv6, некоторые из них подключены к сетям, еще не использующим IPv6, поэтому доступ по протоколу IPv6 возможен только к 68 из 112 развернутых в настоящее время узлов.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"><img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg" /></a></div>
<p>Помимо DNS, главные сетевые магистрали и точки обмена трафиком (IXP) уже в течение многих лет готовы к переходу на IPv6. В настоящее время 95% из 63 членов Euro-IX имеют одноранговые локальные сети IPv6 для обмена трафиком, находящимся под их управлением. Это означает, что поставщики услуг Интернета, клиенты IXP стремятся обеспечить готовность своих одноранговых платформ к использованию IPv6.</p>
<p>Все это &mdash; крупные результаты на важном пути развертывания IPv6, позволяющие обеспечить плавность развертывания. Теперь, когда они достигнуты, для поставщиков контента и доступа настало время предлагать информационное содержание и доступ по протоколу IPv6. Как совершенно точно показывают результаты измерений, инициатива <a href="http://www.worldipv6launch.org/measurements/">World IPv6 Launch (Всемирный запуск IPv6)</a> привела к передаче большого объема контента по IPv6, и многие крупные поставщики услуг Интернета позволяют своим абонентам использовать этот протокол, ожидая появления миллионов новых пользователей данного протокола до конца этого года.</p>
<p>Однако для получения возможности доступа к Интернету по протоколу IPv6 этим абонентам необходимо установить у себя дома совместимые с IPv6 маршрутизаторы и модемы. <a href="http://www.worldipv6launch.org/participants/?q=3">Пять производителей</a> предлагают в настоящее время домашнее сетевое оборудование, совместимое с IPv6 по умолчанию и относящееся к низкой и средней ценовой категории. Эти продукты лидируют среди доступных сегодня <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">17 кабельных модемов, готовых к использованию IPv6</a>.</p>
<p>Теперь имеются все компоненты, позволяющие осуществить успешное развертывание IPv6 для потребителей, использующих Интернет.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/%d0%bf%d0%be%d0%bb%d0%bd%d0%be%d0%b5-%d1%80%d0%b0%d0%b7%d0%b2%d0%b5%d1%80%d1%82%d1%8b%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5-ipv6/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv6, le chemin parcouru</title>
		<link>http://blog.icann.org/2012/06/ipv6-le-chemin-parcouru/</link>
		<comments>http://blog.icann.org/2012/06/ipv6-le-chemin-parcouru/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:28:49 +0000</pubDate>
		<dc:creator>Leo Vegoda</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[Français]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4495</guid>
		<description><![CDATA[Dans le passé, nous avons parlé sur la manière dont l&#8217;infrastructure clé d&#8217;Internet se préparait pour IPv6. En 2004, la première liaison IPv6 (IPv6 glue) a été ajoutée à la zone racine du DNS pour .JP et .KR ; mais si aujourd&#8217;hui vous regardez une partie de la zone racine &#8211; la zone liée aux [...]]]></description>
				<content:encoded><![CDATA[<p>Dans le passé, nous avons parlé sur la manière dont l&#8217;infrastructure clé d&#8217;Internet se préparait pour IPv6. En 2004, la première liaison IPv6 (<em>IPv6 glue</em>) a été ajoutée à la zone racine du DNS pour .JP et .KR ; mais si aujourd&#8217;hui vous regardez une partie de la zone racine &ndash; la zone liée aux ccTLD qui dérivent de la liste ISO-3166-1 &ndash; vous verrez que la plupart des opérateurs TLD sont prêts pour IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"><img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>Un grand progrès a été réalisé lorsqu&#8217;en 2008 la liaison IPv6 a été ajoutée dans six des serveurs racine du DNS. À ce jour, en 2012, il y en a neuf ayant la liaison IPv6. La carte ci-dessous montre que l&#8217;accès IPv6 aux serveurs racine du DNS est largement répandu dans le monde entier. Alors que les nœuds de la racine L sont capables de supporter IPv6, quelques-uns sont rattachés à des réseaux qui n&#8217;opèrent pas encore avec IPv6, de sorte qu&#8217;à ce jour, on ne peut accéder qu&#8217;à 68 des 112 nœuds déployés sur IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"><img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"></a></div>
<p>Au-delà du DNS, les plus grands réseaux fédérateurs et les IXP ont aussi été prêts pour IPv6 pendant des années. À ce jour, 95 % des 63 membres d&#8217;Euro-IX ont des réseaux locaux (LAN) d&#8217;appairage IPv6 pour leurs échanges. Cela signifie que les ISP, les clients d&#8217;IXP ont été motivés pour s&#8217;assurer que leurs plateformes d&#8217;appairage soient prêtes pour IPv6.</p>
<p>Voici les objectifs majeurs de l&#8217;étape critique pour assurer le déploiement d&#8217;IPv6. Maintenant que cela est fait, il est temps pour que les fournisseurs offrent l&#8217;accès et les contenus sur IPv6. Il est clair d&#8217;après les mesures, que le <a href="http://www.worldipv6launch.org/measurements/">World IPv6 Launch</a> a livré un bon nombre de contenus sur IPv6, qu&#8217;une grande partie des ISP ont rendu possible l&#8217;accès à leurs abonnés, et que des millions vont les suivre avant la fin de l&#8217;année.</p>
<p>Mais, pour pouvoir accéder à l&#8217;Internet sur IPv6, ces abonnées ont besoin d&#8217;avoir des routeurs et des modems adaptés dans leurs foyers. <a href="http://www.worldipv6launch.org/participants/?q=3">Five manufacturers</a> offrent à ce jour des équipements de réseau domestiques supportant IPv6 par défaut et qui sont disponibles sur le marché à des prix raisonnables. Ce sont les principaux <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">17 IPv6 ready cable modem products</a> disponibles aujourd&#8217;hui.</p>
<p>Toutes les pièces du puzzle sont maintenant disponibles pour le déploiement réussi d&#8217;IPv6 en faveur des utilisateurs d&#8217;Internet.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/ipv6-le-chemin-parcouru/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>IPv6 a montones</title>
		<link>http://blog.icann.org/2012/06/ipv6-a-montones/</link>
		<comments>http://blog.icann.org/2012/06/ipv6-a-montones/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:27:38 +0000</pubDate>
		<dc:creator>Leo Vegoda</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[Español]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4503</guid>
		<description><![CDATA[En el pasado hemos hablado sobre cómo la infraestructura de claves de Internet se ha estado preparando para el IPv6. En el año 2004, el primer registro de interconexión (glue) del IPv6 fue agregado a la zona raíz del DNS para los dominios .JP y .KR, pero si en la actualidad se observa una parte [...]]]></description>
				<content:encoded><![CDATA[<p>En el pasado hemos hablado sobre cómo la infraestructura de claves de Internet se ha estado preparando para el IPv6. En el año 2004, el primer registro de interconexión (glue) del IPv6 fue agregado a la zona raíz del DNS para los dominios .JP y .KR, pero si en la actualidad se observa una parte de la zona raíz, aquella que se encuentra relacionada a ccTLDs derivados de la lista del ISO-3166-1, podrá ver que una enorme cantidad de los operadores de TLD ya están listos para el IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"><img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>En el año 2008 se dio otro importante paso cuando el registro de interconexión (glue) del IPv6 fue agregado a seis de los servidores raíz del DNS. Actualmente, en el año 2012, nueve servidores tienen registros de interconexión (glue) del IPv6 y, tal como lo muestra el mapa a continuación, el acceso IPv6 a servidores raíz del DNS se encuentra ampliamente difundido en todo el mundo. Si bien todos los nodos de los servidores de raíz &#8220;L&#8221; tienen la capacidad necesaria para el IPv6, algunos se encuentran adjuntados a redes que aún no funcionan con IPv6. Por lo tanto, sólo 68 de los 112 nodos que se encuentran desplegados en la actualidad son accedidos mediante el IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"><img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"></a></div>
<p>Además del DNS, los ejes de las redes más importantes y los Puntos de Intercambio de Internet (IXPs) también han estado preparados para el IPv6 hace varios años. Actualmente, el 95% de los 63 miembros de la Asociación de Intercambio de Internet Europeo (Euro-IX&#8217;s) tienen IPv6 interconectados con Redes de Área Local (LANs) en los intercambios que operan. Esto significa que los Proveedores de Servicios de Internet (ISPs), los clientes de los IXPs, han tenido el interés en asegurar que sus plataformas de interconexión estuviesen preparados para el IPv6.</p>
<p>Estos son los principales productos que se encuentran en el camino principal hacia un despliegue sin complicaciones del IPv6. Ahora que están listos, es hora de que los proveedores de contenido y acceso ofrezcan contenido y acceso mediante el IPv6. Tal como lo aclaran las mediciones, <a href="http://www.worldipv6launch.org/measurements/">el Lanzamiento Mundial del IPv6</a> brindó mucho contenido a través del IPv6 y varios importantes Proveedores de Servicios de Internet (ISPs) han estado habilitando a sus suscriptores con el uso de este protocolo. Se seguirán habilitando millones más antes del final del año.</p>
<p>Pero esos suscriptores necesitan enrutadores y módems en sus hogares que tengan la capacidad necesaria para el IPv6 para poder tener acceso a Internet a través de este protocolo. <a href="http://www.worldipv6launch.org/participants/?q=3">Cinco fabricantes</a> están ofreciendo equipos de red para el hogar que permiten el uso del IPv6 de forma predeterminada. Los mismos están disponibles a precios bajos y medianos. Estos ocupan un lugar importante entre los <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">17 productos de cable módem, listos para el uso del IPv6</a> que se encuentran disponibles en la actualidad.</p>
<p>Todas las piezas del rompecabezas están disponibles para un despliegue exitoso del IPv6 para los usuarios de Internet.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/ipv6-a-montones/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>IPv6 معطل تمامًا</title>
		<link>http://blog.icann.org/2012/06/ipv6-%d9%85%d8%b9%d8%b7%d9%84-%d8%aa%d9%85%d8%a7%d9%85%d9%8b%d8%a7/</link>
		<comments>http://blog.icann.org/2012/06/ipv6-%d9%85%d8%b9%d8%b7%d9%84-%d8%aa%d9%85%d8%a7%d9%85%d9%8b%d8%a7/#comments</comments>
		<pubDate>Mon, 11 Jun 2012 22:26:39 +0000</pubDate>
		<dc:creator>Leo Vegoda</dc:creator>
				<category><![CDATA[ccTLDs]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[IPv6]]></category>
		<category><![CDATA[Issues]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[العربية]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4509</guid>
		<description><![CDATA[تكلمنا في الماضي عن كيفية استعداد البنية التحتية الأساسية للإنترنت للعمل ببروتوكول IPv6. في عام 2004، تمت إضافة أول لصق لبروتوكول IPv6 إلى منطقة جزر DNS لكل من .JP و .KR ولكن عندما تنظر إلى جزء من منطقة الجزر اليوم &#8211; أي الجزء المرتبط بنطاقات ccTLD المشتقة من القائمة ISO-3166-1 &#8211; يمكنك أن ترى بأن [...]]]></description>
				<content:encoded><![CDATA[<div style="direction:rtl;">
<p>تكلمنا في الماضي عن كيفية استعداد البنية التحتية الأساسية للإنترنت للعمل ببروتوكول IPv6. في عام 2004، تمت إضافة أول لصق لبروتوكول IPv6 إلى منطقة جزر DNS لكل من <span dir="ltr">.JP</span> و <span dir="ltr">.KR</span> ولكن عندما تنظر إلى جزء من منطقة الجزر اليوم &ndash; أي الجزء المرتبط بنطاقات ccTLD المشتقة من القائمة ISO-3166-1 &ndash; يمكنك أن ترى بأن حصة كبيرة من مشغلي نطاقات TLD جاهزة للعمل باستخدام IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"><img style="width: 485px; height: 270px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-cctld-diversity-1000x557-11jun12.jpg"></a></div>
<p>وفي عام 2008، تم اتخاذ خطوة أخرى كبيرة، وذلك عندما تمت إضافة لصق بروتوكول IPv6 لخوادم DNS الجذر الستة. واليوم في عام 2012، تحتوي تسعة خوادم على لصق IPv6 كما توضح الخريطة أدناه، فقد انتشر الوصول إلى خوادم DNS الجذر بشكل واسع حول العالم. ففي حين أن كافة عقد جذر L قادرة على التشغيل بنظام IPv6، فإن البعض منها مرتبط بشبكات لا تعمل حتى الآن بنظام IPv6، لذا فإن 68 عقدة فقط من بين 112 عقدة مستخدمة اليوم يمكن الوصول إليها من خلال بروتوكول IPv6.</p>
<div style="margin-bottom: 1em;"><a href="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"><img style="width: 485px; height: 274px; border: 0;" src="/wp-content/uploads/2012/06/ipv6-root-dns-servers-1000x564-11jun12.jpg"></a></div>
<p>وبخلاف DNS، فإن الركائز الأساسية للشبكات بالإضافة إلى نقاط تبادل الإنترنت (IXP) كانت هي الأخرى جاهزة للعمل بنظام IPv6 لعدة أعوام. وفي الوقت الحالي، فإن نسبة 95 % من أعضاء نقاط تبادل الإنترنت الأوروبية البالغ عددهم 63 لديهم شبكات واسعة تعمل بنظام IPv6 قد استوعبت التبادلات التي تشغلها. وهذا يعني أن مشغلي خدمة الإنترنت، وعملاء نقاط تبادل الإنترنت كانت لديهم الرغبة في التأكد من أن المنصات الموازية التي تعمل لديهم جاهزة لاستخدام نظام IPv6.</p>
<p>وكانت هذه جميعها مواد التسليم الأساسية في الطريق الحرج للحصول على نشر واستخدام سلس لنظام IPv6. وبما أن ذلك قد تم الآن، فقد حان الوقت لموفي المحتوى والوصول لعرض المحتوى والوصول من خلال IPv6. وحيث أن عمليات القياس تؤدي إلى مزيد من التوضيح, فقد قدم <a href="http://www.worldipv6launch.org/measurements/">تشغيل IPv6 العالمي</a> العديد من المحتويات عن طريق IPv6 والعديد من كبار موفر خدمة إنترنت كانوا يقومون بتمكين المشتركين لديهم، بالإضافة إلى الملايين للمتابعة قبل نهاية العام.</p>
<p>إلا أن هؤلاء المشتركين بحاجة إلى أجهزة توجيه وأجهزة مودم قادرة على استخدام IPv6 في منازلهم بحيث يمكنك الوصول إلى الإنترنت عبر استخدام IPv6. <a href="http://www.worldipv6launch.org/participants/?q=3">هناك خمس شركات مصنعة</a> تعرض الآن أجهزة شبكات منزلية لها القدرة على استخدام IPv6 بشكل افتراضي وتتوافر بأسعار منخفضة ومتوسطة. ويأتي ذلك زائدًا عن <a href="http://mydeviceinfo.comcast.net/?s=i&#038;so=1&#038;e=0&#038;d3=0&#038;tier=-1&#038;sc=310">منتجات مودم الكابل القادرة على استخدام IPv6 وعددها 17</a> المتوفرة حاليًا.</p>
<p>وتتوافر الآن جميع الأجزاء اللازمة لنجاح استخدام IPv6 لدى مستخدمي إنترنت العملاء.</p>
</div>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/06/ipv6-%d9%85%d8%b9%d8%b7%d9%84-%d8%aa%d9%85%d8%a7%d9%85%d9%8b%d8%a7/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Ten Million DNS Resolvers on the Internet</title>
		<link>http://blog.icann.org/2012/03/ten-million-dns-resolvers-on-the-internet/</link>
		<comments>http://blog.icann.org/2012/03/ten-million-dns-resolvers-on-the-internet/#comments</comments>
		<pubDate>Thu, 22 Mar 2012 16:08:12 +0000</pubDate>
		<dc:creator>Joe Abley</dc:creator>
				<category><![CDATA[DNS]]></category>
		<category><![CDATA[English]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=3455</guid>
		<description><![CDATA[Resolvers are servers on the Internet which use the Domain Name System (DNS) protocol [TXT, 120 KB] to retrieve information from authoritative servers and return answers to end-user applications. They&#8217;re often found in enterprise and ISP networks, and there are a number of public resolver services provided by people like Google and OpenDNS. It&#8217;s also [...]]]></description>
				<content:encoded><![CDATA[<p>Resolvers are servers on the Internet which use the <a href="http://www.ietf.org/rfc/rfc1035.txt">Domain Name System (DNS) protocol</a> [TXT, 120 KB] to retrieve information from authoritative servers and return answers to end-user applications. They&#8217;re often found in enterprise and ISP networks, and there are a number of public resolver services provided by people like <a href="http://code.google.com/speed/public-dns/">Google</a> and <a href="http://www.opendns.com/">OpenDNS</a>. It&#8217;s also possible to configure your own computer to be a resolver, or to deploy your own in your own network using free software like <a href="http://www.isc.org/software/bind">ISC BIND9</a> and <a href="http://www.nlnetlabs.nl/projects/unbound/">NLNet Labs&#8217; unbound</a>.</p>
<p>So, all in all, how many resolvers are there? Given that anybody can run one, it seems like a difficult thing to measure. It turns out, however, that all resolvers that talk directly to authoritative servers on the Internet leave a trail, and with a little data crunching we can come up with a number.</p>
<p><span id="more-3455"></span></p>
<p>Back in 2010, ICANN, VeriSign and NTIA concluded a <a href="http://www.root-dnssec.org/">successful collaboration</a> to deploy <a href="http://www.ietf.org/rfc/rfc4033.txt">DNSSEC</a> [TXT, 52 KB] in the root zone of the DNS. As part of that project, <a href="http://www.root-servers.org/">Root Server Operators</a> collected DNS requests that were delivered to their individual Root Server infrastructure, and deposited the resulting data with <a href="http://www.dns-oarc.net/">DNS-OARC</a> for analysis.</p>
<p>The goal of this data collection exercise was to try and identify any potential problems for DNS clients due to DNSSEC deployment. The by-product of this exercise, however, is a data set which provides insight into DNS traffic between a highly-representative set of DNS resolvers and DNS authority servers (almost all resolvers talk to a root server every once in a while).</p>
<p>One of the data collection exercises carried out had a particularly long time-base. The collection is referred to as &quot;LTQC&quot; (Long-Term Query Collection) and it concerned itself just with priming queries, that is, the initial query that every resolver sends to a root server when it starts up in order to obtain an up-to-date set of DNS root server names.11 of the 13 root servers contributed data to this collection, including L-Root, the root server operated by ICANN. Data was collected between November 2009 and July 2010. </p>
<p>So, here&#8217;s our methodology: we look at every request contained in the LTQC packet-capture, and count the number of unique IPv4 and IPv6 source addresses.</p>
<p>During the collection period, we saw 9,945,017 unique source addresses, of which 59,489 (0.60%) were IPv6 and  and 9,885,528 (99.40%) were IPv4.</p>
<p>So which resolvers won&#8217;t we see?</p>
<p>We won&#8217;t see internal resolvers that don&#8217;t send queries to authoritative servers on the Internet directly, but instead send them via other intermediate resolvers. Included in this class of resolver are any that are hidden behind <a href="http://en.wikipedia.org/wiki/Middlebox">middleboxes</a> that redirect DNS queries to a central cache, or otherwise change normal priming behaviour.</p>
<p>We won&#8217;t necessarily see internal resolvers that are deployed behind a <a href="http://en.wikipedia.org/wiki/Network_address_translation">Network Address Translator (NAT)</a> &mdash; at least, in such a situation we might see only some of them.</p>
<p>We won&#8217;t see resolvers that started (and primed) before the data collection period started, and then never primed again before the end of that period.</p>
<p>We obviously won&#8217;t see any resolvers that were brought live after the collection period ended, and we assume that the number of resolvers is probably increasing due to the general growth of the Internet.</p>
<p>Any resolver that was renumbered during the collection period (and primed before and after the renumbering event) would be counted twice. Intuitively, this seems like a minor effect; we think most resolvers are renumbered fairly infrequently, since they are generally referred to by address rather than name.</p>
<p>Given the expected errors in the number we measured due to the effects described above, it seems appropriate to round the answer to a single significant figure; this at least gives us an order of magnitude for a lower bound.</p>
<p>What we are left with? That there are at least 10 million DNS resolvers on the Internet today.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/03/ten-million-dns-resolvers-on-the-internet/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>互联网上的千万个 DNS 解析器</title>
		<link>http://blog.icann.org/2012/03/%e4%ba%92%e8%81%94%e7%bd%91%e4%b8%8a%e7%9a%84%e5%8d%83%e4%b8%87%e4%b8%aa-dns-%e8%a7%a3%e6%9e%90%e5%99%a8/</link>
		<comments>http://blog.icann.org/2012/03/%e4%ba%92%e8%81%94%e7%bd%91%e4%b8%8a%e7%9a%84%e5%8d%83%e4%b8%87%e4%b8%aa-dns-%e8%a7%a3%e6%9e%90%e5%99%a8/#comments</comments>
		<pubDate>Thu, 22 Mar 2012 16:07:57 +0000</pubDate>
		<dc:creator>Joe Abley</dc:creator>
				<category><![CDATA[DNS]]></category>
		<category><![CDATA[ICANN]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>
		<category><![CDATA[中文]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4809</guid>
		<description><![CDATA[解析器是互联网上的服务器，它们使用域名系统 (DNS) 协议 [TXT, 120 KB] 检索来自权威服务器的信息，并将应答返还到最终用户应用程序。它们通常可以在企业和 ISP 网络中找到，还有一些公共解析器服务，由像 Google 和 OpenDNS 这样的组织提供。您也可以将自己的计算机配置为一台解析器，或者使用 ISC BIND9 和 NLNet Labs 的 unbound 等免费软件在您自己的网络中部署自己的解析器。 那么，总共有多少台解析器呢？由于任何人都可以运行一台解析器，这似乎很难计算。然而，事实上所有在互联网上与权威服务器直接对话的解析器都会留下痕迹，只要稍作数据处理我们就可以知道数量。 早在 2010 年，ICANN、VeriSign 和 NTIA 就完成了一次成功的合作，在 DNS 根区域中部署了 DNSSEC [TXT, 52 KB]。作为该项目的一部分，根服务器运营机构收集了发送到其各个根服务器基础架构的 DNS 请求，并将最终数据寄存在 DNS-OARC 以供分析。 这一数据收集做法的目标是努力发现由于 DNSSEC 部署给 DNS 客户端带来的任何潜在问题。不过，这一做法的附属产物是一个能够洞察 DNS 流量的数据集，这些流量是在一系列具有高度代表性的 DNS 解析器和 DNS 权威服务器之间产生（几乎所有解析器都会时不时地与根服务器对话）。 其中一个已实现的数据收集时间基线特别长。这一收集称为&#8221;LTQC&#8221;（长期查询收集），它只和初始查询有关。初始查询是指每个解析器在启动时发送给根服务器的首个查询，目的是获取最新的 DNS 根服务器名称集。13 个根服务器中有 11 个为这一收集贡献了数据，包括由 [...]]]></description>
				<content:encoded><![CDATA[<p>解析器是互联网上的服务器，它们使用<a href="http://www.ietf.org/rfc/rfc1035.txt">域名系统 (DNS) 协议</a> [TXT, 120 KB] 检索来自权威服务器的信息，并将应答返还到最终用户应用程序。它们通常可以在企业和 ISP 网络中找到，还有一些公共解析器服务，由像 <a href="http://code.google.com/speed/public-dns/">Google</a> 和 <a href="http://www.opendns.com/">OpenDNS</a> 这样的组织提供。您也可以将自己的计算机配置为一台解析器，或者使用 <a href="http://www.isc.org/software/bind">ISC BIND9</a> 和 <a href="http://www.nlnetlabs.nl/projects/unbound/">NLNet Labs 的 unbound</a> 等免费软件在您自己的网络中部署自己的解析器。</p>
<p>那么，总共有多少台解析器呢？由于任何人都可以运行一台解析器，这似乎很难计算。然而，事实上所有在互联网上与权威服务器直接对话的解析器都会留下痕迹，只要稍作数据处理我们就可以知道数量。</p>
<p>早在 2010 年，ICANN、VeriSign 和 NTIA 就完成了一次<a href="http://www.root-dnssec.org/">成功的合作</a>，在 DNS 根区域中部署了 <a href="http://www.ietf.org/rfc/rfc4033.txt">DNSSEC</a> [TXT, 52 KB]。作为该项目的一部分，<a href="http://www.root-servers.org/">根服务器运营机构</a>收集了发送到其各个根服务器基础架构的 DNS 请求，并将最终数据寄存在 <a href="http://www.dns-oarc.net/">DNS-OARC</a> 以供分析。</p>
<p>这一数据收集做法的目标是努力发现由于 DNSSEC 部署给 DNS 客户端带来的任何潜在问题。不过，这一做法的附属产物是一个能够洞察 DNS 流量的数据集，这些流量是在一系列具有高度代表性的 DNS 解析器和 DNS 权威服务器之间产生（几乎所有解析器都会时不时地与根服务器对话）。</p>
<p>其中一个已实现的数据收集时间基线特别长。这一收集称为&#8221;LTQC&#8221;（长期查询收集），它只和初始查询有关。初始查询是指每个解析器在启动时发送给根服务器的首个查询，目的是获取最新的 DNS 根服务器名称集。13 个根服务器中有 11 个为这一收集贡献了数据，包括由 ICANN 运营的根服务器 L 根。数据在 2009 年 11 月到 2010 年 7 月间收集。</p>
<p>以下是我们采用的方法：我们查看了包含在 LTQC 数据包捕获中的每一个请求，并计算了唯一 IPv4 和 IPv6 源地址的数量。</p>
<p>在收集期间，我们查看了 9,945,017 个唯一源地址，其中 59,489 (0.60%) 个是 IPv6，9,885,528 (99.40%) 个是 IPv4。</p>
<p>那么我们看不到哪些解析器？</p>
<p>我们看不到那些不在互联网上直接向权威服务器发送查询，而是通过其他中间解析器发送的内部解析器。这类解析器包括那些隐藏在将 DNS 查询重新定向到中央缓存的<a href="http://en.wikipedia.org/wiki/Middlebox">中间盒</a>之后，或者以其他方式更改正常初始行为的任何解析器。</p>
<p>我们不一定能看到部署在<a href="http://en.wikipedia.org/wiki/Network_address_translation">网络地址转换器 (NAT)</a> 之后的内部解析器 － 至少，在这种情况下我们可能只能看到其中一些解析器。</p>
<p>我们看不到那些在数据收集期开始之前启动（和初始化）、并在收集期结束之前不再初始化的解析器。</p>
<p>显然我们也看不到任何在收集期结束后启动的解析器，并且我们推测，鉴于互联网的总体发展，解析器的数量很有可能增加。</p>
<p>任何在收集期间重新编号（并在重新编号事件前后都进行了初始化）的解析器都将计数两次。直观上看，这一影响很小；我们认为大多数解析器很少重新编号，因为它们一般是通过地址而非名称来引用。</p>
<p>鉴于我们测量的数据预期会因上述影响而产生误差，因此我们似乎可以将答案归结为一个有效数字；这至少能给我们一个下限的数量级。</p>
<p>最后我们得到的是什么？今天在互联网上至少有 1000 万个 DNS 解析器。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/03/%e4%ba%92%e8%81%94%e7%bd%91%e4%b8%8a%e7%9a%84%e5%8d%83%e4%b8%87%e4%b8%aa-dns-%e8%a7%a3%e6%9e%90%e5%99%a8/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Десять миллионов распознавателей DNS в Интернете</title>
		<link>http://blog.icann.org/2012/03/%d0%b4%d0%b5%d1%81%d1%8f%d1%82%d1%8c-%d0%bc%d0%b8%d0%bb%d0%bb%d0%b8%d0%be%d0%bd%d0%be%d0%b2-%d1%80%d0%b0%d1%81%d0%bf%d0%be%d0%b7%d0%bd%d0%b0%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5%d0%b9-dns-%d0%b2-%d0%b8/</link>
		<comments>http://blog.icann.org/2012/03/%d0%b4%d0%b5%d1%81%d1%8f%d1%82%d1%8c-%d0%bc%d0%b8%d0%bb%d0%bb%d0%b8%d0%be%d0%bd%d0%be%d0%b2-%d1%80%d0%b0%d1%81%d0%bf%d0%be%d0%b7%d0%bd%d0%b0%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5%d0%b9-dns-%d0%b2-%d0%b8/#comments</comments>
		<pubDate>Thu, 22 Mar 2012 16:06:30 +0000</pubDate>
		<dc:creator>Joe Abley</dc:creator>
				<category><![CDATA[DNS]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>
		<category><![CDATA[Русский]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4815</guid>
		<description><![CDATA[Распознаватели &#8211; это серверы Интернета, использующие протокол системы доменных имен (DNS) [TXT, 120 Кб] для получения информации от полномочных серверов и выдачи ответов приложениям конечных пользователей. Они зачастую расположены в корпоративных сетях и у поставщиков услуг Интернета, существует также ряд служб распознавания общего пользования, предоставляемых такими организациями, как Google и OpenDNS. Возможно также настроить собственный [...]]]></description>
				<content:encoded><![CDATA[<p>Распознаватели &ndash; это серверы Интернета, использующие <a href="http://www.ietf.org/rfc/rfc1035.txt">протокол системы доменных имен (DNS)</a> [TXT, 120 Кб] для получения информации от полномочных серверов и выдачи ответов приложениям конечных пользователей. Они зачастую расположены в корпоративных сетях и у поставщиков услуг Интернета, существует также ряд служб распознавания общего пользования, предоставляемых такими организациями, как <a href="http://code.google.com/speed/public-dns/">Google</a> и <a href="http://www.opendns.com/">OpenDNS</a>. Возможно также настроить собственный компьютер для работы в качестве распознавателя, либо развернуть собственный распознаватель в своей сети, используя для этого бесплатное программное обеспечение (например, <a href="http://www.isc.org/software/bind">ISC BIND9</a> и <a href="http://www.nlnetlabs.nl/projects/unbound/">NLNet Labs unbound</a>).</p>
<p>Сколько же всего существует распознавателей? Учитывая то, что создать распознаватель может кто угодно, измерить общее количество весьма непросто. Однако на практике все распознаватели, обменивающиеся данными непосредственно с полномочными серверами в Интернете, оставляют след. Обработав данные, мы получим конкретное число.</p>
<p>Еще в 2010 году ICANN, VeriSign и NTIA провели <a href="http://www.root-dnssec.org/">успешную совместную работу</a> по развертыванию <a href="http://www.ietf.org/rfc/rfc4033.txt">DNSSEC</a> [TXT, 52 Кб] в корневой зоне DNS. В рамках этого проекта <a href="http://www.root-servers.org/">операторы корневых серверов</a> собрали запросы DNS, поступившие в инфраструктуру корневых серверов каждого из них, и поместили полученные данные в <a href="http://www.dns-oarc.net/">DNS-OARC</a> для проведения анализа.</p>
<p>Целью сбора этих данных была попытка выявить наличие потенциальных проблем с клиентами DNS, которые могли возникнуть в связи с развертыванием DNSSEC. Побочным результатом этой работы стали данные о трафике DNS между репрезентативной выборкой распознавателей DNS и полномочными серверами DNS (почти все распознаватели периодически обращаются к корневому серверу).</p>
<p>Одна из проведенных процедур сбора данных охватывала особенно длительной период. Этот набор данных называется LTQC (Long-Term Query Collection, долгосрочный сбор запросов) и содержит только данные о первичных запросах, то есть, первоначальных запросах, которые каждый распознаватель при запуске передает на корневой сервер, чтобы получить актуальный набор имен корневых серверов DNS. 11 из 13 корневых серверов предоставили данные в этой набор, в том числе сервер корневой зоны L &ndash; корневой сервер, управляемый ICANN. Сбор данных происходил с ноября 2009 года по июль 2010 года.</p>
<p>Использовалась следующая методика: мы рассматривали каждый запрос в пакете LTQC и считали количество уникальных адресов IPv4 и IPv6, с которых направлялись запросы.</p>
<p>За период сбора данных мы отметили 9 945 017 уникальных адресов, из которых 59 489 (0,60%) составляли адреса IPv6, а 9 885 528 (99,40%) &ndash; адреса IPv4.</p>
<p>Какие распознаватели мы не видим?</p>
<p>Мы не видим внутренние распознаватели, которые не отправляют запросы на полномочные серверы непосредственно через Интернет, а передают их через промежуточные распознаватели. В этот класс распознавателей входят те из них, которые расположены за <a href="http://en.wikipedia.org/wiki/Middlebox">промежуточными устройствами</a>, которые перенаправляют запросы DNS в центральный кэш или иным образом изменяют нормальный алгоритм инициализации.</p>
<p>Мы можем не видеть внутренние распознаватели, развернутые за <a href="http://en.wikipedia.org/wiki/Network_address_translation">транслятором сетевых адресов (NAT)</a> &ndash; по крайней мере, в такой ситуации мы можем видеть только часть из них.</p>
<p>Мы также не увидим распознаватели, запущенные (и инициализированные) до начала периода сбора данных и не выполнявшие повторной инициализации до конца этого периода.</p>
<p>Мы, конечно, не увидим распознаватели, появившиеся после окончания периода сбора данных; предположительно, количество распознавателей выросло в связи с общим ростом Интернета.</p>
<p>Любой распознаватель, номер которого был изменен во время периода сбора данных (и который поэтому был инициализирован до и после изменения номера), окажется учтенным дважды. Мы считаем, что эффект от этого незначителен; изменение номера распознавателя происходит нечасто, поскольку обычно обращение к ним выполняется по адресу, а не по имени.</p>
<p>Учитывая ожидаемую погрешность в данных, возникающую по перечисленным выше причинам, выглядит справедливым округлить ответ до одной значащей цифры; это, по крайней мере, дает нам порядок нижнего предела.</p>
<p>Что получается в итоге? В Интернете на сегодняшний день существует как минимум 10 миллионов распознавателей DNS.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/03/%d0%b4%d0%b5%d1%81%d1%8f%d1%82%d1%8c-%d0%bc%d0%b8%d0%bb%d0%bb%d0%b8%d0%be%d0%bd%d0%be%d0%b2-%d1%80%d0%b0%d1%81%d0%bf%d0%be%d0%b7%d0%bd%d0%b0%d0%b2%d0%b0%d1%82%d0%b5%d0%bb%d0%b5%d0%b9-dns-%d0%b2-%d0%b8/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Dix millions de résolveurs DNS sur l&#8217;Internet</title>
		<link>http://blog.icann.org/2012/03/dix-millions-de-resolveurs-dns-sur-linternet/</link>
		<comments>http://blog.icann.org/2012/03/dix-millions-de-resolveurs-dns-sur-linternet/#comments</comments>
		<pubDate>Thu, 22 Mar 2012 16:05:21 +0000</pubDate>
		<dc:creator>Joe Abley</dc:creator>
				<category><![CDATA[DNS]]></category>
		<category><![CDATA[Français]]></category>
		<category><![CDATA[L-Root]]></category>
		<category><![CDATA[Languages]]></category>

		<guid isPermaLink="false">http://blog.icann.org/?p=4823</guid>
		<description><![CDATA[Les résolveurs sont des serveurs sur Internet qui utilisent le DNS [TXT, 120 Ko] pour récupérer les informations depuis les serveurs officiels et renvoyer les réponses aux applications de l&#8217;utilisateur final. On les trouve souvent en entreprise et sur les réseaux ISP, et il y a de nombreux services publics de résolveurs fournis par Google [...]]]></description>
				<content:encoded><![CDATA[<p>Les résolveurs sont des serveurs sur Internet qui utilisent <a href="http://www.ietf.org/rfc/rfc1035.txt">le DNS</a> [TXT, 120 Ko] pour récupérer les informations depuis les serveurs officiels et renvoyer les réponses aux applications de l&#8217;utilisateur final. On les trouve souvent en entreprise et sur les réseaux ISP, et il y a de nombreux services publics de résolveurs fournis par <a href="http://code.google.com/speed/public-dns/">Google</a> et <a href="http://www.opendns.com/">OpenDNS</a>. Vous pouvez également configurer votre propre ordinateur pour devenir un résolveur, ou déployer votre propre réseau en utilisant un logiciel gratuit comme <a href="http://www.isc.org/software/bind">ISC BIND9</a> et <a href="http://www.nlnetlabs.nl/projects/unbound/">NLNet Labs&#8217; unbound</a>.</p>
<p>Alors, dans l&#8217;ensemble, combien de résolveurs y a-t-il ? Étant donné que tout le monde peut en devenir un, cela semble difficile à mesurer. Il s&#8217;avère, cependant, que tous les résolveurs qui parlent directement aux serveurs officiels sur Internet laissent une trace et, avec un peu de données critiques, nous pouvons parvenir à un chiffre.</p>
<p>Au début de 2010, ICANN, Verisign et NTIA ont conclu une <a href="http://www.root-dnssec.org/">collaboration réussie</a> pour déployer <a href="http://www.ietf.org/rfc/rfc4033.txt">DNSSEC</a> [TXT, 52 Ko] dans la zone racine du DNS. Dans le cadre de ce projet, <a href="http://www.root-servers.org/">des opérateurs du serveur racine</a> ont recueilli des demandes faites à leur infrastructure individuelle de serveur racine, et ont livré les données de résultat avec <a href="http://www.dns-oarc.net/">DNS-OARC</a> pour analyse.</p>
<p>L&#8217;objectif de cet exercice de collecte de données était d&#8217;essayer d&#8217;identifier tous les problèmes potentiels des clients DNS causés par le déploiement du DNSSEC. Toutefois, le produit dérivé de cet exercice est un ensemble de données qui donne un aperçu dans le trafic DNS entre un ensemble hautement représentatif des résolveurs DNS et les serveurs officiels DNS (presque tous les résolveurs parlent à un serveur racine une fois de temps à autre).</p>
<p>Un des exercices de collecte de données menés avait une base de temps particulièrement longue. La collecte fait référence au « LTQC » (<em>Long-Term Query Collection</em> &#8211; Recueil de demandes à long terme) et ne concerne que des demandes d&#8217;amorçage, qui est la demande initiale que tout résolveur envoie à un serveur racine lorsqu&#8217;il démarre afin d&#8217;obtenir un ensemble actualisé de noms de serveurs racines DNS. 11 serveurs racines sur 13 ont collaboré à cette collecte de données, y compris la racine L, le serveur racine exploité par l&#8217;ICANN. Les données ont été collectées entre novembre 2009 et juillet 2010.</p>
<p>Alors, voici notre méthodologie : nous examinons chaque demande contenue dans la capture de paquets LTQC et nous comptons la quantité d&#8217;adresses source uniques IPv4 et IPv6.</p>
<p>Au cours de la collecte, nous avons vu 9 945 017 adresses source uniques, parmi lesquelles 59 489 (0,60 %) étaient des IPv6 et 9 885 528 (99,40 %) étaient des IPv4.</p>
<p>Alors quels sont les résolveurs que nous ne verrons pas ?</p>
<p>Nous ne verrons pas les résolveurs internes qui n&#8217;envoient pas directement des demandes aux serveurs officiels sur Internet, mais qui préfèrent les envoyer à d&#8217;autres résolveurs intermédiaires. Sont également compris dans cette catégorie de résolveurs tous ceux qui sont cachés derrière des <a href="http://en.wikipedia.org/wiki/Middlebox">dispositifs intermédiaires</a> redirigeant les demandes DNS à un cache central, ou bien qui changent le comportement normal de l&#8217;amorçage.</p>
<p>Nous ne verrons pas forcément les résolveurs internes qui sont déployés derrière un <a href="http://en.wikipedia.org/wiki/Network_address_translation">Traducteur d&#8217;adresses de réseau</a> &ndash; en tout cas dans une situation comme celle-ci, nous ne pourrions voir que certains d&#8217;entre eux.</p>
<p>Nous ne pourrons pas voir les résolveurs qui ont démarré (et amorcé) avant le démarrage de la période de collecte des données, et jamais réamorcé ensuite avant la fin de cette période.</p>
<p>Nous ne pourrons évidemment pas voir non plus tous les résolveurs qui sont arrivés en direct après la fin de la période de collecte, et nous supposons que le nombre de résolveurs est sans doute en augmentation en raison de la croissance générale d&#8217;Internet.</p>
<p>Tout résolveur ayant été renuméroté au cours de la période de collecte (et amorcé avant et après le moment de la rémunération) serait comptabilisé deux fois. Intuitivement, cela donne l&#8217;impression d&#8217;avoir des effets mineurs ; nous croyons que la plupart des résolveurs sont renumérotés assez rarement car ils sont en général mentionnés par leur adresse plutôt que par leur nom.</p>
<p>Étant donné les erreurs prévisibles dans le nombre que nous avons mesuré en raison des effets mentionnés ci-dessus, il semble nécessaire d&#8217;arrondir le résultat à un simple chiffre significatif ; ceci nous permettra au moins d&#8217;avoir un ordre de grandeur pour une limite inférieure.</p>
<p>Que nous resterait-il ? Qu&#8217;il y a au moins 10 millions de résolveurs DNS sur Internet aujourd&#8217;hui.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.icann.org/2012/03/dix-millions-de-resolveurs-dns-sur-linternet/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
