第20回 いろいろなキャッシュ：dnsmasq, cache proxy | gihyo.jp
Ubuntuを利用していく上で、一時的なデータをキャッシュすることで体感速度や利便性を向上させることができます。今回はターミナルからの設定に慣れることも兼ねて、キャッシュ関連の設定を行うレシピを紹介します。 preloadの利用 第8回で紹介したpreloadも一種のキャッシュです。詳細な使い方は第8回を参照してください。 DNSのキャッシュ――dnsmasqを使う Webブラウザなどを用いてインターネットアクセスを行う場合、システム側では暗黙でDNS解決を行い、ホスト名からIPアドレスを取得しています。Windowsでは暗黙で、Mac OS XではlookupdがDNS解決の結果をキャッシュしていますが、Linuxではキャッシュを行わず、都度DNSサーバへ問い合わせを行ってしまいます。 ローカルでdnsmasqというDNSサーバを稼働させることで、これらのキャッシュと同等の処理を行わせよ
「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アドレス
ドメイン名のしくみ - JPNIC
郵便で手紙を送る時に住所が必要であるのと同様に、 インターネットでは、電子メールを送ったりウェブサイトを見たりするために、 相手がインターネット上のどこにいるのかを特定する必要があります。 ドメイン名は、言ってみれば「インターネット上の住所」にあたるものです。 ドメイン名の構成 ドメイン名は、以下のように表示されます。(下線の部分がドメイン名) 電子メールアドレスの場合 [email protected] ウェブアドレスの場合 www.example.co.jp ピリオド(.)で区切られた部分は「ラベル」と呼ばれます。 一つのラベルの長さは63文字以下、ドメイン名全体の長さは、 ピリオドを含めて253文字以下でなければなりません。※1 ラベルには、英字(A～Z)、数字(0～9)、 ハイフン( - )が使用できます(ラベルの先頭と末尾の文字をハイフンとするのは不可)。 ラベル中では大文字・
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回
RFC1034(DOMAIN NAMES - CONCEPTS AND FACILITIES)
トップページ - 翻訳ドキュメント - RFC 1034 原文：ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt 原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。 サイト内関連リンク：RFC 1035 DNS 実装と仕様 Network Working Group Request for Comments: 1034 Obsoletes: RFCs 882, 883, 973 DOMAIN NAMES - CONCEPTS AND FACILITIES ドメイン名- 概念と機能 1. STATUS OF THIS MEMO 1. この文書の位置付け This RFC is an introduction to t
NTT東日本のフレッツ 光ネクスト障害、原因はDNSサーバーの操作ミス
NTT東日本は2010年10月19日、10月7日に生じたフレッツ 光ネクスト回線からインターネットに接続できない障害が発生した件について、その原因と再発防止策の最終報を公表した。 今回起こった障害は、フレッツ 光ネクストユーザーの一部にインターネットに接続できない事象が起こったというもの（関連記事）。原因は、フレッツ 光ネクスト用の中継網「NGN」内部に設置しているDNSサーバーの一部に障害が発生したためとしている。つまり障害の内容は、正確には「インターネットに接続しているときに接続先サーバーの名前解決ができなかった」ということになる。例えばメールソフトなどに送受信用のサーバーを直接IPアドレスで指定していた場合は、障害発生中でもインターネット経由でメールの送受信はできたという。ただし、Webページへのアクセスなど、一般に接続先サーバー名を指定して使うアプリケーションは、利用できない状態に
Webを再起動する７人？んな馬鹿な話があるかいｗ - おっホイ別館 − はてな村の物語
Netの世界に転がる、様々なネタを見ては楽しむ、「Newsサイト」として、最近ほぼ毎日拝見している 「Gizmodo Japan」 のエントリーに、妙な記事が載っていた。 WWWへのアクセス権を持つ7人 http://www.gizmodo.jp/2010/07/seven-people-have-been-entrusted-with-the-keys-to-the-internet.html 抜粋： 上の画にあるこのカード。世界で7人だけが保持している、大災害時にWold Wide Webを再起動させる力を持つカードなのです。 んなアホな、Netの世界にシングルエンドポイントSingle Point of Failure（SPOF）（1箇所のシステムがサービスを提供できなくなると、システム全体が止まる）がある訳無いし、ましてやWWW−http/httpsプロトコル限定とか有り得ない！
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ietf.org/rfc/rfc1034.txt