「IPv6とDNS」にまつわる二つのナゾ
最近、特集執筆のためIPv6の取材をする機会があった。IPv6のことはご存じの方も多いと思うが、いまのIPネットワークで使用されるIPv4の後継にあたるプロトコルである。2011年3月ころとみられるIPv4アドレスの枯渇（関連記事）や、4月以降にNTT東西のNGN上でIPv6インターネット接続サービスが始まる（関連記事）ことをきっかけに普及が進むとみられている。 機器/ソフトベンダーやサービス事業者にIPv6関連の取材をしていると、たびたび「ナゾ」が出てくる。ここでは最近記者が遭遇した「IPv6でDNSを使う」ときの二つのナゾを紹介したい。 DNSの役割はIPv4でもIPv6でも同じだ。ホスト名からIPアドレスを調べる正引きも、IPアドレスからホスト名を調べる逆引きも利用できる。ところがIPv6では、IPv4のようにはいかないのだ。 ナゾその1：DNS問い合わせのうち、なぜIPv6アドレス
DNSの歴史（第5回「DNSサーバーの誕生」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 前回，DNSのアーキテクチャや仕様が決まるまでをお話しました。実際にネット上でDNSを利用するには，DNSを実装したサーバー，つまりDNSサーバーが必要です。「DNSの歴史」最終回である5回目は，DNSサーバーについて解説します。 RFCに基づくDNSが最初に実装されたサーバー，すなわち，最初のDNSサーバーは，RFCを書いたPaul Mockapetris氏自身による「JEEVES」です。JEEVESはその後，UNIX系OSの一種である「4.3 BSD」のために開発された「BIND（Berkeley Internet Name Domain）」に置き換えられて，現在に至ります。 BINDは，カリフォルニア大学バークレー校「Computer Systems Research Group（CSRG）」により，開発されました。CSRGに在籍
DNSの歴史（第4回 普及までの道のり）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 HOSTS.TXTに代わる，新たな名前解決の方法である「DNS」。開発の中心人物は，Jon Postel氏，南カリフォルニア大学情報科学研究所(SIS)に所属していたPaul Mockapetris氏，そして，Craig Partridge氏を中核とした，Information Sciences Institute（ISI）のあるグループでした。 1983年11月，Jon Postel氏が開発スケジュールをまとめ，RFC881 *1 として発表しました。DNSの基本概念と実装や仕様については，RFC882 *2とRFC883 *3 として，Paul Mockapetris氏が発表しました。なお，基本概念については，1982年にもRFCが発行されています *4。 *1 RFC881 The Domain Names Plan and Sc
DNSの歴史（第3回「DNSに必要な条件」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 「HOSTS.TXTの破綻」を教訓に，ARPAnetは，「新たな名前解決の方法」として以下の条件を満たすシステムを開発しようとしました。それが現在のDomain Name System (DNS) です。 （1）分散管理できること 「HOSTS.TXT」の二の舞を演じないためには，不可欠の条件でした。HOSTS.TXTのように，1カ所に管理を集中すると，そのホストは過負荷状態になってしまい，いとも簡単にダウンしてしまうことは実証済みでした。 （2）階層的にホスト名（名前空間）を管理できること 現在のドメイン名などを見ると「.」で区切られて，階層化されていることが分かります。階層的な名前空間を使用することにより，ホスト名が重複するのを避けようとしたのです。これも，HOSTS.TXTの失敗に学んだ条件です。階層化という発想自体は，UNIXの
DNSの歴史（第2回「HOSTSファイルからDNSへ」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 当初，「HOSTS.TXT」ファイルで名前解決を図っていたARPAnetですが，ホスト数の増大により，様々な問題が発生しました。そのため，ARPAnetは危機に陥りました。ネットワークが正常に機能しなくなりつつあったのです。 具体的には，次のような問題が発生しました。 （1）SRI-NIC *1 の負担増大 ARPAnet上に存在する，すべてのホスト情報を記載したHOSTS.TXTファイルの容量は，大変大きくなっていました。1ホストにつき1行増えるので，ファイルは何万行にもなりました。また，当時は現在とは比較にならないほど，接続回線は細いものでした。複数のユーザーが大容量のファイルを転送しようとすると，回線はすぐに一杯になってしまいました。 そのため，管理の手間もさることながら，そのファイルを保存しておくためのサーバー・リソースや，その
DNSの歴史（第1回 「HOSTSファイルの崩壊」）
吉川 洋太郎 ラック コンピュータセキュリティ研究所 インターネットやイントラネットといった，TCP/IPネットワークの利用には不可欠なDNS（Domain Name System：ドメイン・ネーム・システム）。ホスト名を問い合わせると，そのホストのIPアドレスを返してくれます（これを「名前解決」といいます）。また，その逆も可能です。 そのため，数字の羅列であるIPアドレス（例えば，“211.2.246.25”）を覚えていなくても，意味がある文字列で構成されるホスト名（例えば，“itpro.nikkeibp.co.jp”）を覚えていれば，そのホストへアクセスできます。 今や当たり前のように利用しているDNSですが，TCP/IPネットワークが構築されたときから，存在するわけではありません。DNSが現在のように利用可能になるまでには，紆余曲折（うよきょくせつ）がありました。このコラムでは，5回
NTT東日本のフレッツ 光ネクスト障害、原因はDNSサーバーの操作ミス
NTT東日本は2010年10月19日、10月7日に生じたフレッツ 光ネクスト回線からインターネットに接続できない障害が発生した件について、その原因と再発防止策の最終報を公表した。 今回起こった障害は、フレッツ 光ネクストユーザーの一部にインターネットに接続できない事象が起こったというもの（関連記事）。原因は、フレッツ 光ネクスト用の中継網「NGN」内部に設置しているDNSサーバーの一部に障害が発生したためとしている。つまり障害の内容は、正確には「インターネットに接続しているときに接続先サーバーの名前解決ができなかった」ということになる。例えばメールソフトなどに送受信用のサーバーを直接IPアドレスで指定していた場合は、障害発生中でもインターネット経由でメールの送受信はできたという。ただし、Webページへのアクセスなど、一般に接続先サーバー名を指定して使うアプリケーションは、利用できない状態に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
