ク・ミニ実験室の 図 15 .000 0 .. flags : qr rd ra; QUERY: 1 ′ ANSWER: ー >>HEADER くく - opcode : QUERY,: status : GOt answer : 910ba1 op し土 ons : printcmd 親 DNS サーバーに対して dig プログラムを実行した結果 $ d 土 9 @ns . example . com antares . north . example . com くく > > DiG 9 . 3 . 1 くく > > @ns . example . com antares . north . example . com Server Fa ⅱ u 「 e 工ラーが発生 SERVFA 工 L,E id: 19549 0 ′ AUTHORITY: 0 ′ ADD 工 T 工 ONAL: ネットワー 0 QUESTION SECTION: ー antares . north . example . com. Query time : 3 msec IN SERVER: 192 .168 . 1 . 1 # 53 ( ns . example . com ) WHEN : Sat Oc し 15 01 : 4 5 : 19 2 0 0 5 MSG S I ZE rcvd : 4 3 ANSWER SECTION も AUTHORITY SEC 引 ON もない 図 16 DNS の通信の流れを石信忍する マ発信元アドレスマ受信先アドレス プ . マサマリ 30 DNS クライアント 親 DNS サーパー 子 DNS サーパー 33 NDNS サーパー 32 3 1 問合せ 親 DNS サーパー 子 DNS サーパー NDNS サーパー DNS クライアント DNS ONS DNS DNS DNS クライアントー・親 DNS サ DNS クライアント、 - -- 親 DNS サ ーバ 図 17 子 DNS サーバーか返した応答 RA RO TC AA Dpcode OR 日 ags ldent if icat ion The Domai n Name Syst em ( DNS ) 0X8080 10503 . 000 . Q ID : 36166 OPCODE:O RET=O NAME:antares.north.example.com TYPE=A 0 1 D: 1 0 5 0 3 OPCODE:O RET=O NAME:anta res. north. examp 厄 . com TYPE: A R ID ニ 10503 OPCODE:O RET=O NAME:antares.north.example.com TYPE=A R I D ニ 3 6 1 6 6 OPCODE: 0 RET=2 NAME: anta res. no h. examp . com TYPE= A Standa rd query Response 子 DNS サ 問合せ Recu 門 i on 観引 lab Recu rsi on not des i red Not レ心訌 ed Non っ沚 ho 「 i tati ve answe 「 Response Code Numbe r of Ouest i ons NO error . 0000 0 resou rce reco rd( :Numbe r of Answe r RRS 1 resou rce 諾 ( 勞 Number of Additional RRs 1 resource record(s) i on Que ry Name Type C ss A 猷 ho 「社 Y Name Type C k55 T i To L ive Resource Daf-a Lerlhth 2 (NS: an authoritative name server) anta res. no rth. examp ー e. com 1 (): & hcnst address) 1 (the lnternet) 1 (the lnternet) 3S00 圓 0 :Authoritat ive N 引肥 Server A. ROOT-SERVERS. NET 応答とともに、ルートサー バーの 1 つが権限をもつ サーバーとして返された し、本来なら antares.north.example.com の権限をも っているはずの子 DNS サーバーが、 antares.north.example.com については A. ROOT- SERVERS. NET ( ルートサーバーの 1 つ ) に訊いとく UNIX MAGAZINE 2005 . 12 応答コードは“正常”が返される レコードはみつからなかった も、みつからなかった Name error の状とも異なる結果 と主張しています。これは、レコードがみつかった状態と れ " (Authoritative Name Server フィールド ) 79 です。この応答を受け取った相手が、

ク・ミニ実験室の 図 3 キャッシュの有無による若速度の違い 物 0 ASTEC Ey 。 s ~デ。.@Iキャプチャデをタく cache ー t 0 上れ 0 刃 自ファイル ( E ) 偏集 ( 印表示 ) キャプチャ 0 モニタツール (I) 設定 0 .000 0 .. 少 ' ラ LAN ロ フ .. マ発信元アドレスマ受信先アドレスマ 諢白 @ 斗囹に印 プ . マサマリ ウインドウ ネットワー 曰 X 227 DNS クライアント 230 キャッシュサー丿ー 671 DNS クライアント 672 キャッシュサーパー DNS クライアント キャッシュサー ) ーー ー DNS クライアント キャッシュサー ) ーー キャッシュ DNS DNS DNS DNS 0 ID : 64756 叩 C 叩 E : 0 RET:O NAME= R I D:84756 OPCODE= 0 RET= 0 NAME= 0 1 D: 40307 OPCODE: 0 RET= 0 NAME- R I D : 40307 OPCODE: 0 RET= 0 NAME- a res. res. res. —ant & r 5. 1 回目の応答にかかった デルタ時問 時間は 0.279 ミリ秒 2 回目の応答にかかった 0 . 000273 10 .054885 0 . 圓 1 8 0 4 0 .000000 時間は 1 .804 ミリ秒 図 4 しないホストの名前を問し哈わせた結果 $ dig @192 . 168 . 1 . 1 cluster . north ・ example くく > > DiG 9 . 3 . 1 くく > > @192 .168 . 1 . 1 cluster . north. example . com 910ba1 options : printcmd GO し : flags : qr rd ra; QUERY: 1 . ANSWER: ー >>HEADER くく一 opcode : QUERY,: status : . C om NXDOMAIN,: id: 47702 . 名有莎工ラ ーを示す 0 ′ AUTHOR 工 TY: 1 ′ ADDIT 工 ONAL: 0 QUESTION SECTION: ;cluster . north . example . com . レコードがみつからな かった (ANSWER →・ SECTION がない ) AUTHOR 工 TY SECT 工 ON : north . example . com . 2 8 工 N IN SOA 10 8 0 0 root . ns . north . example . com . 2005101604 Query time : 3 msec S ERVER : 192 . 16 8 . 1 . 1 # 5 3 ( 192 . 16 8 . 1 . 1 ) WHEN : Sat Oc し 15 0 2 : 3 5 : 3 3 2 0 0 5 ・ ns . north . example . com . 三 - 3 6 0 0 6 04 8 0 0 8 6 4 0 0 no h. examp 巵.com ゾーンに対して 権限をもつ DNS サーバー MSG SIZE rcvd: ( 誌面の都合上、で折り返しています。以下同様 ) The Domai n Name Syst em ( DNS ) 図 5 DNS バケットのヘッダ ldentification 日 5 AA RD RA Response Code Numbe r 可 . い .9 . Number of Answer RRs Numbe r of Add i t i on 引 RRs Opcode 54478 0X8483 8 7 Response Standard que ry Authoritat ive answer をを」 nc ed Recu rsi on no を des i red : Name error: Recursion available 0 reSOU rce reso リ rce reSOU rce . 0 01 1 record(s):, record(s) .000 . Answe 「として返されたレコードは 0 個 ・ ANSWER SECTION がないので、問合せに対応する 0 たのは north.example.com ゾーンの権限をもつ DNS ・ AUTHORITY SECTION の表示によると、応答し UNIX MAGAZINE 2005. 12 応答コードは "Name er 「 0 「 " (dig プログラムでは NXDOMAIN と表示 ) 73 きの status は、、 NOERROR")0 前解決でエラーが起きている ( レコードがみつかったと ・ status が、、 NXDOMAIN " になっていることから、名 レコードはみつかっていない。

図 13 サブドメインの榔艮を襄したシステム構成 DNS クライアント ④応答 ③応答 ① antares.north.example.com の問合せ example.com ドメイン 親 DNS サーバー ns.example.com ー north.example.com ・ : を権限委譲 ② antares.north.example.com ー の問合せ no h. exam e.com ドメイン 子 DNS サーバー ns.north.example.com 親 DNS サーノヾーは、子 DNS サーバーに north.example.com ゾーンを権限委譲 子 DNS サーバーは no 員 h. examp 巨 com ソーンの情報を管理 スです。 図 13 のように、 2 つのゾーンを 2 台の DNS サーバー で管理しているネットワークを考えてください。各 DNS サーバーは、キャッシュ・サーバーとしても動作します。 ・ example.com ゾーンの権限は親 DNS サーバ example.com/ がもつ。 ・ north.example.com ゾーンの権限は親 DNS サーバ 1. DNS クライアントが親 DNS サーバーに問い合わせる。 のように通信カ毓れます。 ple.com ゾーンの情報を問い合わせると、正常な場合は次 DNS クライアントか覿 DNS サーバーに north. exam- ample.com/ カゞもつ。 ーから権限委譲された子 DNS サーバー ns. north. ex- 78 4. 親 DNS サーバーが DNS クライアントに応答を返す。 3. 子 DNS サーバーカ DNS サーバーに応答を返す。 子 DNS サーバーに問合せを送る。 いるのが子 DNS サーバーであることを知っているので、 2. 親 DNS サーノヾーは north.example.com を管理して 図 14 子 DNS サーバーの named. conf ファイルの変更 options { directory "/etc/namedb" ・ : zone "north . example . type master; "north. . com. UNIX MAGAZINE 2005 . 12 error)o しかし、 ANSWER SECTION はありません Response Code " の値はエラーになっていません (NO 怪しい状態になっていることが分かります。 が返した応答バケット ( 図 17 ) の内容を詳しく調べると、 そこで、子 DNS サーバ ns.north.example.com では、正常な場合と区別がつきません。 すくなくとも、図 16 に示した DNS の通信の流れだけ から背後で起きていることを見通すのは難しいでしよう。 ります。しかし、よほど置れている人でないと、この表示 となっていて、正しく動作していないことはひと目で分か TION がない ・ ANSWER SECTION および AUTHORITY SEC- ・ status が SERVFAIL (Server Failure) 工ラー north.example.com を問い合わせると、 ーーしこ antares. い。 DNS クライアントが親 DNS サーバ まずは図 15 の dig プログラムの実行結果を見てくださ 象カ起きるのか川頁を追ってお話ししましよう。 すこし先走ってしまいましたが、具体的にどのような現 テイプ・キャッシュも効きません。 ます。名前解決ができないというエラーにはならず、ネガ い状態は、先月号で紹介した Lame Delegation にあたり 限委譲されたゾーンを子 DNS サーバーが管理できていな 態はもうすこし厄介になります。親 DNS サーバーから権 しかも、単純に名前解決のエラーカ起きるだけでなく、事 合せは失敗すると考えられます。 example.com ゾーンの情報を取り出せなくなるので、問 てみましよう。もちろん、子 DNS サーバーから north. まるごとコメントアウトし ( 図 14 ) 、ゾーン情報を削除し ルから、 north.example.com ゾーンのステートメントを こで、子 DNS サーノヾーの /etc/named. conf ファイ com ゾーンの情報を引き出せない状態にする この zone ステートメントをコメントアウトし、 no 「 th. examp .

図 18 親 DNS サーバーが出力したエラーメッセージ 15 ー 10 -2005 1 : 52 : 15 . 765 :lame server. resolvingi 'antares . north . example . com' 、 ()n 'north . example . com'?) . 192 . 16 8 . 10 . 1 # 5 3 Lame DeIegation の発生を匂わせるメッセージ 図 19 子 DNS サーバーかイ亭止しているときに dig プログラムを実行した結果 $ d 土 9 @192 .168 . 1 . 1 antares . north . example . com くく > > DiG 9 . 3 . 1 くく > > @192 .168 . 1 . 1 antares . north. example . com 910ba1 options : printcmd : connection timed ou に no servers could be reached: DNS サーバーに到達できないうちに時間切れになった 2. ルートサーバーから順に親 DNS サーバーまでたどり着 いて 1. ルートサーバーに問い合わせ 80 キャッシュカかない例をもう 1 つ紹介しましよう。 DNS サーバーが重加乍していない ネガテイプ・キャッシュは働きません。 このように、ゾーン情報が登録されていないケースでは、 同じ処理の繰返しになりました。 キャッシュには記億されません。そのため、 2 回目以降も 返さなかったせいなのか、親 DNS サーバーのネガテイプ・ らそうはなりませんでした。子 DNS サーバーがエラーを となれば無駄な通信が減って万々歳なのですが、残念なが 制されて・ 3. 親 DNS サーバーから子 DNS サーバーへの問合せカ郵 2. 親 DNS サーバーのネガテイプ・キャッシュに記億され 1. 子 DNS サーバーの設定の誤りが 2 回目の問合せでは、 こまでが 1 回目の問合せで起きる出来事です。 ージも出力されていました。 が起きていることを知らせる図 18 のようなエラーメッセ また、親 DNS サーバーのログには、 Lame Delegation ライアントには Server Failure 工ラーが返されています。 ていることに気づいた親 DNS サーノヾーにより、 DNS ク こでは実際には、子 DNS サーバーからの応答カ呉っ 性もあります。 を繰り返すと、無限に DNS の呼出しを続けてしまう危険 3. ふたたび子 DNS サーバーに問い合わせて・・ 図 13 のネットワークで子 DNS サーバーが止まってい ると仮定します。 dig プログラムを使って子 DNS サーバーが管理してい UNIX MAGAZINE 2005 . 12 ( あらい・みちこ Rworks) DNS キャッシュのトラブルも疑ってみてください。 り、 DNS の通信カ緲に多いと感じるときは、今回紹介した も紹介しました。 DNS で返されるゾーン情報が古かった ための上限の設疋、キャッシュか勠かないケースについて た。また、キャッシュ時間の設疋方法やいざというときの ャッシュとネガテイプ・キャッシュについてお話ししまし 今回は、 DNS キャッシュの基本から始まり、通常のキ ☆ イムアウト時間だけ待たされました。 ッシュには記億されず、名前解決を問い合わせるたびにタ ところが、サーバーと通信ができないという情報はキャ はないはずです。 きらめてエラーが返されるので、タイムアウトを待っこと シュに保存されるなら、 2 回目以降は早々に名前解決をあ こでもし、、、名前解決ができない " という情報がキャッ ほどでした ) 待たされるという難点があります。 待っているあいだ、タイムアウト時間だけにこでは 10 秒 ので正常な動作です。ただし、子 DNS サーノヾーの応答を ple.com を管理している子 DNS サーバーが止まっている 名前解決ができないこと自体は、 antares. north. exam- に到達しないうちに時間切れになった " ことが分かります。 から、、、問い合わせた名前を管理している DNS サーバー と、図 19 のような表示になりました。最後のメッセージ る antares.north.example.com について問い合わせる

連載 ネットワーク・ミニ実験室 荒井美千子 UNIX MAGAZINE 2005. 12 ーバー / 寸幻する機能です。 1 フォワーダーはまだ紹介していませんが、 DNS の問合ををほカ DNS サ DNS のバケットの流れを追いかけ、 キャッシュの効果 DNS サーバーの負担軽減にもつながります。 として問合せ数が減ることで、負荷が集中しがちな上位の て問合せを、、サポる " ことで高速化できます。また、全体 のなかでは比較的、、重い処理 " ですが、キャッシュを使用し DNS サーバーへの問合せは基本的なネットワーク通信 くてもキャッシュ・サーバーとして動作します。 たときに、問合せ元の DNS サーバーは特別な設定をしな ーほかの DNS サーバーに問い合わせるような使い方をし たりフォワーダー 1 として動作するなど、 DNS サーバーが プログラム ) にこの機能が備わっています。再帰検索をし named 専用のプログラムはなく、通常の DNS サーバ しています。 BIND の場合、キャッシュの機能だけをもつ サーバーを、区別のために、、キャッシュ・サーバー " と記載 図 1 では、問合せとその応答をキャッシュしておく DNS 速化することです ( 図 1 ) 。 ュの目的は、このような仕組みにより名前解決の処理を高 があったときは、記億していた結果を返します。キャッシ なうと、その結果を記億します。そして、次に同じ問合せ キャッシュは、 DNS の問合せを受けて名前解決をおこ けてみましよう。 れが DNS のキャッシュです。今回は、その動きを追いか に立っことなく緞帳の陰から脚本をそっと見せる裏方、そ についてはあまり意識していないかもしれません。表舞台 ふだん名前解決に DNS を利用していても、キャッシュ ロ NS のキャッシュ ・キャッシュの動作 ・キャッシュの有無による応答速度の違い を確認しておきましよう。 図 2 は、同じ問合せを 2 回実行したときの DNS の通 信です。キャッシュ・サーバーは 1 回目は DNS サーバー に問い合わせていますが、 2 回目は問い合わせず、記億し ていた内容を応答として返していることカ毓み取れます。 次に、応答速度をみてみましよう。図 3 は図 2 のうち、 DNS クライアントとキャッシュ・サーバー間の通信だけ を取り出したものです。 、、デルタ時間 " の欄の下線部は、 DNS の問合せ ( 下線部の バケットの直前のバケット ) から応答が返されるまで ( 下 線部のバケット ) の間隔を表しています。これをみると、 DNS の応答までにかかった時間は、 ・キャッシュカいていない 1 回目は約 1.8 ミリ秒 ・キャッシュカ」いている 2 回目は約 0.3 ミリ秒 となり、かなり差があることが分かります。図 3 の例は LAN 内の DNS サーバーで実験したものですが、インタ ーネット上の DNS サーバーへの問合せでは、キャッシュ の効果はもっと大きくなるでしよう。 ネカテイプ・キャッシュ DNS のキャッシュには、問い合わせたレコードの内容 を記億しておく通常のキャッシュと、問い合わせたレコー ドがなかったことを憶えておくキャッシュがあります。後 者は通常のキャッシュと区別して、ネガティブ・キャッシ ュ (negative cache) と呼びます。 ネガテイプ・キャッシュは RFC2308 で規定されて おり、 DNS の仕組みのなかでは比較的新しい機能です。 71

図 1 DNS キャッシュ動き 1 回目の問合せ DNS クライアント DNS サーバー キャッシュ・サーノヾー ④問合せと応答を記憶 2 回目の問合せ DNS クライアント DNS サ キャッシュ・サーノヾー ⑥ DNS の問合せ ⑧応答 DNS サーバ - への問合せは 発生しない ⑦記憶していた応答を 取り出す 図 2 キャッシュの有無による DNS の通信の違い ・を ASTEC. Eye に = 。キャプチャデ—タく coc 0 : tim c 〉 ] 憙毳豆鸞こは↓、ー - 回区 ファイ庫 ( 日偏集 ( 印表示 ) キャプチャ 0 モこタ圓ツー外設定 0 ヘルプ ( 旦 ) ウインドウ さラ、 :LAN ロ睡白 &. 斗目に副 フ .. マ発信元アドレスマ受信先アドレスマプ . マサマリ 227 DNS クライアントキャッシュサーパー DNS 0 1 D: 6 4758 OPCODE: 0 RET: 0 NAME- - ant a r 日 5 . no 日 . h . examp 匚 22 キャッシュサーパー DNStt—Ji'— : DNS ロ I D= 446 1 1 OPCODE=O RET: 0 NAME= ant a 「己 5 . no 「 th. examp 匚 キャッシュサー丿ーー 223 : DNS サー丿ーー ¯antares . north. exampl. R I D: 446 1 1 CIPCITE= 0 RET= 0 NAME- ー " ヴ弓ナッド・ " " " 230 十ャッソュザこアぐ " ¯antares . north ID : 6475S ロ P 間 DE ニ 0 RET:O NAME- . examp に 671 DNS クライアント キャッシュサー丿ーー . examp に . north キャッシュ・サーノヾーが DNS サー 672 キャッシュサーパー DNS クライアント . no h . examp に バーに問い合わせている キャッシュ 1 回目 2 回目 [ 9 / 140 ] ID ・ 996 DN 助ライアントー〉キャッシュサ DNS サーバー キャッシュ・サーノヾー DNS クライアント 問合せ 問合せ 1 回目 応大 応答 問合せ 2 回目 応答 ストの名前 (cluster.north.example.com/ を問い合わせ DNS サーバーの種類やバージョンによっては、ネガティ たときの dig の実行結果です。また、このとき DNS サー プ・キャッシュの機構を備えていない場合がありますし、 バーからキャッシュ・サーノヾーへ返された DNS の ) 芯答パ 記億される情報の種類にも違いがあります。 ケットのヘッダ部を図 5 に示します。 ネガテイプ・キャッシュの典型例を 1 つ紹介しましよう。 図 4 の実行結果をみると、次のことが分かります。 図 4 は、キャッシュ・サーバーを経由して存在しないホ 72 2005 . 12 UNIX MAGAZINE

図 9 DNS のトラフィックからキャッシュ時間忍する と応答が発生 10 秒間隔で問合せ DNS クライアント / キャッシュ . 2 囲 3 ロ O サーバー間 22 囲・ 1 OCI 0 3 囲 キャッシュ・サーバー / DNS 2 サーバー間 22 : 囲 . OO 1 囲 22 : 囲 : 30 2 : 09 : 22D8 : 30 2 四 : OO 2209 : 30 22 : 09 : 3 ロ 221 ロロロ を 2 : 10 : 2210 : 30 22 : 1 1 ・ロ 0 22 : 1 0 : 30 2211 :OO 60 秒間隔 3 囲 と応答が発生 10 秒間隔で問合せ 図 10 DNS のトラフィックからネガティブ・キャッシュ時間をる忍する DNS クライアント / キャッシュ・ 2 凹 サーバー間 1 OO 3 凹 ロ 2 : 36 月ロロ 2 : 36 : 3 ロ キャッシュ・サーバー / DNS 2 サーバー間 1 ロ 2 : 36 : 00 D236 : 3 ロ ロ 2 第 7 : 囲ロ引 : 3 ロ 02 : 引 : 00 02 7 : 3 ロ 30 秒間隔 ロ 2 : 38 : ロロロ 238 : 3 ロ ロ 2 : 38: ロロロ 238 ・ 30 ロ 2 : 39 : ロロ ロ 2 : 39 : ロロ 22 : 1 1 : 30 22 : 1 1 : 30 ロ 2 : 39 : 3 ロ ロ 2 : 39 : という処理が 60 回繰り返されます。 同様に、同じゾーンファイルと dnsquery. sh スクリプ 秒になっていることカ寉認できました。 れらから、キャッシュの有効時間が $ TTL で設疋した 60 と DNS サーバー間の通信は 60 秒に 1 回の割合です。 合で通信が発生しています。一方、キャッシュ・サーバー ライアントとキャッシュ・サーバー間は 10 秒に 1 回の割 となっています。グラフの目盛りを読んでみると、 DNS ク の通信 下のグラフはキャッシュ・サーバーと DNS サーバー間 ー間の通信 上のグラフは DNS クライアントとキャッシュ・サーバ を問い合わせた際のトラフィック・グラフで、 図 9 は、このスクリプトを使って実在するホストの名前 76 トを使い、実在しないホストの名前を問い合わせた様子を 表したのが、図 10 のトラフィック・グラフです。 こちらも、 DNS クライアントとキャッシュ・サーバー 間は 10 秒に 1 回の割合で通イ言していますが、キャッシュ・ サーバーと DNS サーバー間は 30 秒に 1 回の通信です。 ですから、 SOA レコードに言定した 30 秒の TTL が、ネ ガテイプ・キャッシュの有効時間として反映されているこ とを確認できます。 キャッシュ時間の上限の言又疋 キャッシュ時間は、ゾーン情報とともに問合せ先の DNS サーバーからキャッシュ・サーバーへと渡されます。キャ ッシュ・サーバーはゾーン情報を保存するとともに、内部 でカウントダウンを始め、キャッシュ時間が経過すると古 くなったゾーン情報を破棄します。 UNIX MAGAZINE 2005. 12

図 6 ネカティブ・キャッシュの重が乍 ファイル ( E ) 編集 ( 印表示 LAN 1 回目だけ DNS サーバーに 問い合わせる キャプチャ 0 モニタツール設定 0 ウインドウヘルプ旧 ) を返した 耋ロこのバケットは Name error 1 回目 2 回目 発信元アドレス 、 .9 際よ . キャッシュサー丿ーー DNSÜ—J\— 2 :DNS*j—)i'— キャッシュサー丿、 DNS クライアント キャッシュサー丿ー 受信先アドレス . まをン : 茗認 .ir 3 NS ロ ID : 40528 OPCCIDE=O RET:O NAME:cluster. north ロ ID : 54478 叩間 DE : 0 RET=O NAME:cluster. north R ID : 54478 OPCODE:O RET=3 NAME:cluster. north R ID : 40528 OPCODE:O RET:3 NAME:cluster. north ロ ID : 22136 OPCODE=O RET=O NAME:cluster. north R ID : 22136 OPCOOE:O RET=3 NAME=cll 」 5レ「 . north . exarnp ー e . example . examp ー e . example . examp ー e . examp ー e TYPE: A TYPE: A TYPE: A TYPE= A . com TYPE: A TYPE: A . COm . com . COtfi . 00m . COm 1 332 キャッシュ 2 回目 1 回目 DNS クライアント キャッシュサー丿ーー : DNS ーちネアント キャッシュサー丿ーー ー DNS クライアント DNS DNS DNS 2 回目は DNS サーバーに問 い合わせず、キャッシュ・サ ーバーがただちに応答を返 キャッシュ・サー / ヾー 問合せ Name er 「 0 「 DNS サーバー 問合せ Name 「「 0 「 問合せ Name error 図 6 は、ネガテイプ・キャッシュの動作の様子を示した ものです。 1.cluster.north.example.com に関する問合せをキャッ シュ・サーバーへ送る。 2. キャッシュ・サーバーは、 1 回目は受け取った問合せを DNS サーバーへ送る。 3. DNS サーバーは、登録されていない名前の問合せを受 けたので、、 Name error" ( 図 5 ) を返す。 4. キャッシュ・サーバーは、 cluster. north. example. com に関する問合せの結果は Name error である " と 記億し、結果を DNS クライアントへ返す。 5.cluster.north.example.com に関する 2 回目の問合せ に対して、キャッシュ・サーバーは即座に Name error を返す (DNS サーバーには問い合わせない ) 。 この例のように、名前解決の要求に対して目的のレコー ドがみつからなかったときも、キャッシュ・サーバ こでは 192.168.1.1 ) はどの名前が解決できなかったかを 74 記應します。 キャッシュの有効時間 キャッシュ時間を長めにしてキャッシュの効果を上げてく また、ホストがあまり入れ替わらないネットワークでは、 され、不整合カ起きる時間を短くできます。 ッシュ時間を短めに設疋しましよう。変更がより早く反映 LAN などで頻繁にホスト名の変更がある場合は、キャ 情報カ転わり、やがて不整合が解消されます。 即座には反映されなくても、ある程度時間カては新しい オリジナルの DNS サーバーの情報が更新されたときに サーバーに問い合わせるようにします。こうすることで、 時間カすると破棄され、次回は再度オリジナルの DNS そこで、キャッシュ・サーバーに記億された情報は、一定 得た情報は旧いままなので不整合カ起きてしまいます。 まうと、オリジナルの情報が更新されてもキャッシュから たんキャッシュした情報をあまりにも長い時間保持してし が、しばしばトラブルの種にもなります。たとえば、いっ キャッシュはうまく利用すれは効率アップに役立ちます UNIX MAGAZINE 2005 . 12

図 11 キャッシュ日訐の上限を named. conf ファイルに言見正 op む土 ons { directory "/etc/namedb" え一 cache - t し 1.. 86400 を←キャッシュ時間の上限 ( 86 , 400 秒 = 1 日 ) :max-ncache-ttl 43200 ー ネガティブ・キャッシュ時間の上限 ( 43 , 200 秒 = 12 時間 ) ところで、 DNS サーバーの設疋ミスで意図した以上に 長いキャッシュ時間を設疋してしまうと、すこし困ったこ とになります。 いったん長いキャッシュ時間が DNS サーバーからキャ ッシュ・サーバーに伝わると、そのキャッシュ時間が肩効 になってしまいます。 DNS サーバーの設疋ミスに気づい てキャッシュ時間をすぐに修正しても、次にキャッシュ・ サーバーが DNS サーバーにアクセスし、修正されたキャ ッシュ時間を受け取るのは、誤って設定した長いキャッシ ュ時間の後になります。 管理者としては、明らかに長すぎるキャッシュ時間が渡 されたときに、なす術がないのは不便です。そこで、キャ ッシュ・サーバーには自衛策として、キャッシュ時間に上 限を設けることができます。 キャッシュ時間の上限を設疋するには、 named. conf フ の 2 行を追加します ( 図 11 ) 。 max—ncache—ttl time ; max—cache—ttl 7 れ e ; ァイルの options ステートメントに UNIX MAGAZINE 2005. 12 ファイルの TTL とリフレッシュ時間の値を小さくすれば このゾーン転送の間隔は、マスターサーノヾー側のゾーン コピーすることをゾーン転送と呼びます。 ン情報を、まるごとスレープサーバー (DNS サーバー ) に マスターサーバー (DNS サーバー ) が管理しているゾー て、簡単に補足しておきます。 いでに、 10 月号で解説したゾーン中幻のタイミングについ キャッシュの働きやキャッシュ時間について説明したっ ゾーン転送についての補足 れ秒単位で指定します。 cache-ttl" はネガテイプ・キャッシュ時間の上限をそれぞ max-cache-ttl" はキャッシュ時間の上限を、、、 max-n- ネットワーク・ミニ実験室朝 図 12 リフレッシュ日訐司の下限を named. conf ファイルに言又疋 op し土 ons ↑ •min-refresh-time 1 ・ directory "/etc/namedb" ・ 最初の例は、必要なゾーン情報が登録されていないケー ソーン情報が登録されていない 例を 2 つ紹介しましよう。 最後に、 BIND9 でネガテイプ・キャッシュカ」かない ます。 ん。実際の動作は DNS サーバーの種類によっても異なり ラーは登録しないと明確に決まっているわけではありませ このエラーはネガテイプ・キャッシュに登録し、あの工 スもあります。 ーの設定に誤りなどがあって、キャッシュカ黝かないケー った場合もキャッシュカ黝きます。しかし、 DNS サーバ でなく、名前が登録されていないために Name error にな 最近の DNS サーバーは、名前解決が成功したときだけ しよう。 すこし寄り道をしましたが、キャッシュの話題に戻りま DNS キャッシュが効かないケース ください。 ックを増やすだけです。ゾーン転送の間隔は慎重に決めて 転送は効率面で未がないばかりでなく、無駄なトラフィ しかし、重ねてお断りしておくと、極端に頻繁なゾーン ゾーン転送をおこなわせることも不可能ではありません。 たとえは図 12 のように 1 秒に設定すれば、 1 秒ごとに ことができます。 を設定すれば、更新間隔の下限を標準の 5 分より短くする min—refresh—time time; で、 named. conf の options ステートメントに これは特別な設定をしなかったときの BIND9 の動作 だ " と書きました。 隔は 5 分程度に制限され、それ以上は短くはならないよう 短くなりますが、 10 月号では、、 BIND9 では実際の更新間 リフレッシュ時間の下限 ( 1 秒 ) を設定 77

ネットワー ク・ミニ実験室朝 図 7 ゾーンファイルのキャッシュ時間を変更 キャッシュ時間 ( 秒単位 ) : 60 秒 三 $ TTL 6 0 三 工 N A 工 N SOA ns . nor し h . example 6 0 4 8 0 0 3 6 0 0 10 8 0 0 2 0 0 5101504 root . ns . nOrth . . . . C om . Seria1 Refresh after 3 hours Retry after 1 hour Expire after 1 week Minimum TTL n S : 30 三 工 N IN NS ネガティブ・キャッシュ時間 ( 秒単位 ) : 30 秒 ns . north . example . com 192 . 168 . 10 . 1 19 2 . 16 8 . 10 . 10 0 図 8 10 秒ごとに DNS の問合せをおこなうシェル・スクリプト # ! /bin/sh dig @192 .168 . 1 . 1 $ 1 ・← 192.168.1.1 のサーバーに、引数で渡された名前 ( $ 1 ) を問い合わせる do while [ $num ー 9 し 0 ] 。←ループを 60 回繰り返す num=60 ・一 wh ⅱ e ループの内側の処理を実行する回数 ( ループのカウンタ ) sleep 10 ・一 10 秒待つ num= 、 expr $num ー 1 、・←ループのカウンタを 1 減らす done ださい。 いつもはホストの変更が少なく、キャッシュを長めに設 定しているネットワークでも、近いうちに変更の予定があ れば、事前にキャッシュ時間を短めに設疋しておくとよい でしよう。そうすれば、ホストを変更したときにその情報 が周囲に早く伝わります。情報が周囲に伝わってからキャ ッシュ時間をもとの長さにすれば、キャッシュ効率を以前 の状態に戻すことができます。 キャッシュの有効時間の言又疋 キャッシュの効時間はゾーンごとに設疋できます。図 7 は、 north.example.com ゾーンのキャッシュ時間の設 定例です。 SOA レコードの説明の際に簡単に触れましたが、 $TTL と SOA レコードの最後の値はキャッシュ時間 ( 秒単位 ) を 表しています。とくに BIND9 では、 ・ $TTL は ( 雹甬の ) キャッシュの有効時間 ・ SOA レコードの最後の値はネガテイプ・キャッシュの 効時間 と解釈さ楸それぞれ個別に定できます。 ゾーンファイルに設疋したキャッシュ時間は、 SOA レコ UN 工 X MAGAZINE 2005. 12 ードの情報とともにそのゾーンを管理している DNS サー バーからキャッシュ・サーバーへと渡され、キャッシュ・サ ーバー内でゾーン情報を保持する時間として使用されます。 キャッシュ時間の変更の効果 キャッシュ時間の設疋カ陏効に働いているかを、実際に 測定して確認しましよう。 図 7 は、テストのためにキャッシュ時間をかなり短く ( 60 秒 ) してあります。 ・通常のキャッシュは 60 秒 ・ネガテイプ・キャッシュは 30 秒 このゾーンファイルと、図 8 に示したシェル・スクリプ ト dnsquery. sh を使って簡単な実験をおこないます。 dnsquery. sh は、 DNS の問合せを 10 秒に 1 回発生さ せます。使い方は、 $ dnsquery. sh れのれ e のように、問い合わせる名前を引数として 1 つ渡します。 このシェル・スクリプトの内部では、 1.192.168.1.1 のサーバーに name を問い合わせる 2.10 樹寺つ (sleep する ) 75