図 6 スレープサーバーの north.example.com/bk ( ゾーン車医によりマスターサー / ヾーからコピーされたファイル ) の内容 :. N. : : ←追加された設定 E$TTL 86400 1 day 三 north . example . com 工 N SOA 2 0 0 5 0 8 0 6 3 3 10 8 0 0 3 6 0 0 6 0 4 8 0 0 8 6 4 0 0 NS NS : $ORIGIN north . example . com. ns1 ns2 追加された設定 図 7 スレーブサーバーカ直後に表示されるメッセー ン slave$ . /named starting B 工 ND 9 . 3 . 1 ー 9 0 6 -Aug ー 2 0 05 22 : 3 3 : 02 . 6 71 Ioad 土 ng configuration from ー /etc/named. conf ー 0 6 -Aug ー 2 0 05 2 2 : 3 3 : 02 . 6 8 3 192.168.10.1 ( マスターサーバー ) から 192.168.10.2 ( スレ ーブサーバー ) に no 曲 . examp com のゾーン情報を転送 0 6 -Aug ー 2 0 0 5 2 2 : 3 3 : 0 2 . 7 3 8 runn 1 ng . com/工 N zone north . Transfer started . 0 6 -Aug ー 2 0 0 5 2 2 : 3 3 : 0 2 . 744 . com/IN' from transfer Of 'north . exampl 0 6 -Aug ー 2 0 0 5 2 2 : 3 3 : 0 2 . 74 5 192..168..10 . 1 # 53 ; connected us 土 ng . 192 : 168 . 10 . 2 # 1171 06 ー Aug ー 2005 22 : 33 : 02 . 869 zone north. example . com/工 N: transferred serial 2 叩 P. .Qf 06 ー Aug ー 2005 22 : 33 : 02 . 870 transfer Of 'north. example . com/IN' from 192 . 16 8 . 10 . 1 # 5 3 : end Of transfer 06 ー Aug ー 2005 22 : 33 : 02 . 871 zone north. example . com/工 N: sending notifies ( seri al 2 0 0 5 0 8 0 6 3 3 ) . ln-addr. arpa/IN: Transfer started . 06 -Aug ー 2 0 0 5 2 2 : 3 3 : 0 3 . 24 3 zone 10 . 16 8 . 192 ー 10 .168 .192 . 土 n ー addr. arpa / 工 N ー from 06 ー Aug ー 2005 22 : 33 : 03 .244 transfer of 192 : 168..10 . 1 # 53 三 cpnnected. us4ng. 192 . 16 8 . 10 . 2 # 1172 . in-addr. arpa/ 工 N : 耳月よ且耳 06 -Aug ー 2 0 05 2 2 : 3 3 : 0 3 . 3 73 zone 10 . 16 8 . 192 烏よ .. 20q Q . Q. 0. Q. Q. ー 10 .168 .192 . 土 n ー addr . arpa / IN ー from 06 - Aug ー 2005 22 : 33 : 03 .374 transfer Of 192 .168 .10 . 1 # 53 : end of transfer ns1. north . example . com. r00 し . ns1. north. example . com. ( 三 refresh ( 3 hours) re.try ( 1 hour) expire ( 1 week) minimum ( 1 day) . north. example nsl . com . . north. example ns2 . com . 192 . 168 . 10 . 1 192 . 168 . 10 . 2 ・← SOA レコード DNS サーバー DNS サーバーの 旧アドレス north.example.com のゾーン転送 SOA のシリアル番号は 2005080633 10.168.192 のゾーン転送 ステートメントの directory で指定したディレクトリから ・ SOA レコードのコメントか変更されている の相対パスになります。たとえば、図 4 の例では、 など小さな違いはありますが、マスターサーバーと同じ内 /etc/namedb/north.example.com/bk 容が保存されていることが分かります。 にゾーン情報のコピーカ躱存されます。 スレーブサーバー起動時の処理 ゾーン中幻医後に north.example.com/bk に保存された ゾーン情報を図 6 に示します。図 3 とくらべると、 マスターサーバーとスレープサーバーの設定が終った ら、両方のサーバーを起動しましよう。 ・ゾーンのドメイン名を表す、、 $ ORIGIN " が追加されて 図 7 は、 -g オプションでメッセージを表示させながら いる 68 UNIX MAGAZ 工 NE 2005. 10

ミニ実験室⑩ ネットワーク・ 図 1 north. example ・ com ドメイン north.example.com ドメイン nsl .north.example.com マスターサーバー 192.168.10.1 マスターのゾーン情報 DNS の問合せ ゾーン転送 DNS クライアント DNS の問合せ コピーしたゾーン情報 ns2.north.example.com 192.168.10.2 スレーブサーバー ・ローカルホスト (localhost) のゾーン スレーブサーバーの準備 ・ローカルホストの逆引きゾーン 今回は、スレープサーバーを動作させ、マスターサーバ ゾーン情報の内容についての説明は省略しますにれら ーと同期する仕組みを調べてみましよう。 のゾーン情報を定しなくても、この連載でおこなう DNS 図 1 は、下記の 2 台だけで構成されたゾーン north. の実験に支障はありません ) 。 example.com を表しています。 図 3 は、マスターサーバー側の north.example.com/ zone ファイルです。今回は、スレープサーバーの情報もゾ ・マスターサーバー : nsl.north.example.com ーンファイルに追加しています。言田は省きますが、逆引 ・スレープサーバー : ns 2. nort h.example.com き用の 10.168.192. zone ファイルにもスレープサーバー マスターサーバーとスレープサーバーを用意する場合、 の情報を追加してください。 ゾーン情報はマスターサーバーだけに設疋し、スレープサ 図 4 は、図 2 と対になるスレープサーバーの named. ーバーは必要なゾーン情報をマスターサーバーからコピー conf ファイルです。 します。このコピー操作をゾーン転送と呼びます。 スレープサーバーはゾーン転送で得た情報を使い、マス ターサーバーと同様に DNS クライアントからの問合せに 応答します。 DNS クライアント側からみると、マスター サーバーとスレープサーバーに区別はありません 1 。 図 1 の構成の DNS サーバーを用意し、動作を確認して みましよう。 図 2 はマスターサーバーの named. conf ファイルで、前 回紹介した DNS サーバーの named. conf に次のゾーン情 報を追加したものです。 ルートドメインのゾーン 1 実祭には、マスターサーバーとスレープサーノヾーでは、ゾーン情報の更新のタ イミングや不整合カ起きたときの状態が異なります。 マスターサーバーの named. conf マスターサーバーの named. conf ファイルをすこし詳 しくみてみましよう。 図 5 は、スレープサーノヾーがない場合とある場合の zone ステートメントの違いを比較したものです。スレープサー バーがある場合の設疋には、 allow—transfer { 192 .168 . 10 . 2 ; が追加されています。 allow-transfer は、マスターサーノヾーからのゾーン転 65 UNIX MAGAZINE 2005 . 10

図 2 マスターサーバーの named. conf ファイル ートゾーン情報 directory "/etc/namedb" options { type hint; 三 zone "localhost" { type master; file " localhos む . zone" : z one " O . 0 . 12 7 . 1 n ー addr . arpa ー type master; f 土 le " 0 . 0 . 12 7 . zone " ・←ル ・←逆引きのゾーン情報 loca 旧 ost の正引きと 追加したゾーン情報 ーンの情報 zone "north. example. com" し一 north.example.com ソ type master; file "north. example . com. zone" allow-transfer { 192 . 16 8 . 10 . 2 ー zone " 10 .168 .192 . 土 n - addr . arpa " type master; f 土 1 e " 10 . 16 8 . 19 2 . zone " allow-transfer 192 . 168 . 10 . 2 { ← no 員 h. examp 巨 com の逆引きのゾーン情報 図 3 マスターサー / ヾーの north. example. C01蝨 . zone ファイル $TTL 86400 IN SOA ns1. north . example . com. r00 む . ns1. north. example . com. ( 三 2 0 0 5 0 8 0 6 3 3 10 8 0 0 3 6 0 0 6 0 4 8 0 0 8 6 4 0 0 . C om . . COm . ns1 : ns 2 IN IN 工 N 工 N NS NS Seria1 Refresh after 3 hours Retry after 1 hour Expire after 1 week Minimum TTL Of 1 day ns2 . north . example . north . example ns1 スレーブサーバー 192 . 168 . 10 . 2 192 . 168 . 10 . 1 ・← SOA レコード DNS サーバーの旧アドレス ノヾー DNS サー 送を許可するホストの指定で、スレープサーノヾーの IP ア 66 allow-transfer の言定がない場合は、すべてのホストに 2 を設疋しています。 ドレスを設定します。ここでは、 IP アドレス 192.168. 川 . ゾーン転送が許可されます。ゾーンのすべてのホスト情報 は、セキュリティの面から望ましくありません。最近では、 をインターネット上の誰もが簡単に入手できるような状態 UNIX MAGAZ 工 NE 2005. 10 ゾーン転送を許すホストを allow-transfer によって制限

masters { 192 .168 . 10 . 図 5 スレーブサーノヾーの有無による ( マスターサーノヾー ) (a) スレーブサーバーがない場合 zone "north . example . type master; file "north. example (b) スレーブサーバーがある場合 zone "north. example . type master; file "north. example : allow-transfer zone " 10 . 16 8 . 19 2 . in ー addr type slave ー f i 1 e " 10 . 16 8 . 19 2 . bk " { 192 .168 . 10 masters ネットワー 図 4 スレーブサーバーの named. conf ファイル . com . . com . directory "/etc/namedb" ・ op に土 ons : ZOne ク・ミニ実験室⑩ type hint ー . r00 し " ・ : zone " 10ca1hos し” { type master; file "localhost . zone" 三 zone "0 . 0 .127 . in-addr . arpa' type master; f 土 1 e " 0 . 0 . 12 7 . zone " zone "north . example . type slave ー file "north . example . com. bk" ・ ←ルートゾーン情報 ← loca 旧 ost の正引きと逆引きのゾーン情報 スレーブサー / ヾーの情報 named. conf 0 男攣し、 スレーブサーバーに ゾーン転送を許可 192 . 16 8 . 10 . 2 ← するのが - ヨ殳的です。 スレーブサーバーの named. conf 次に、スレープサーノヾーの設疋をみてみましよう。 DNS サーバーは、個別のゾーンごとにマスターサーバーになる か、それともスレープサーバーになるかを設定できます。 また、スレープサーバーになるときは、どのマスターサー UN 工 X MAGAZINE 2005 . 10 ノヾーからゾーン情報を中幻医するかを指定できます。 図 4 の、 zone "north. example . com" { type slave; file "north. example . com. bkt masters { 192.168.10.1 ; } ; は、 north.example.com ゾーンのスレープサーノヾーの設 定です。、、 type slave" はこのゾーンのスレープサーバー として動作することを未し、、、 file ' ' 川 er 田 me " " はゾーン 情報をイ尉寺するファイル名の指定です。そして、、、 masters ・ } ; " はマスターサーバーの指定 です。 67 対パスで指定してください。相対パスの場合は、 options ら始まる緲寸パスか、スラッシュ以外の文字から始まる相 ゾーン情報を書き込むファイル名は、スラッシュ ( / ) か ルに書き込みます。 バーからゾーンの情報を入手し、 file で指定されたファイ く必要はありません。 masters で指定されたマスターサー スレープサーバーではゾーンファイルの中身を書いてお

ーク・ミニ実験室⑩ ネットワ 図 8 ゾーン医の様子 ー回区 ・・ ASTEC Eyes—ーキャプチャデタく zo れ 0 ー ansfe 「 - e れ c > ] 自ファイル 0 編集 ( 印表示 OØキャプチャ 0 モニタ ( ) ツール設定 0 ウインドウヘルプ ( 旦 ) 」 9 north. example. NET ゾーン転送要求データが 2 つのバケットに分割さ ロ当 ; @ 、斗「目に副 れた フレーム ID マ発信元アドレスマ受信先アドレスマプ .. マサマリ 0 S ー master DNS Q ID : 61491 OPCODE=O T : 0 E= no 杙 h. exampl e. com TYPE=SOA DNS T00 0 rt an 引 yze DNS n い nu i Packet DNS R 1 D : 7 囲 7 OPCODE= 0 RET=O NAME: no 杙 h. examp 尾 . com TYPE: AXFR 尸 Q ID : 61216 OP 間 DE ニ 0 RET=O NAME=IO. 168.192.tn-addr. arpa TYP.. DNS r DNS R ID : 61216 OPCODE:O RET:O NAME ニ 10.168.132. in-addr.arpa TYP.. DNS Too 5h0 杙 to 引 yze r DNS Cont i nu i ng Packet DNS R ID : 55434 OPCODE:O RET:O NAME 引 0.168.132. in-addr. arpa TYP Ouesti on Ouery Type C lass Answer Type Class Time To 凵冊 Resource Data Length MNAME RNAME ソーン転送前に SOA レ コードを問い合わせる north.example.com のゾーン転送 10.168.192. in - addr. 十 a 「 pa ゾーンに関するや りとり DNS R Ⅲ : 引 431 叩間ÜE : 0 RET:O ÅAME= no rt h. examp 厄 . com TYPE=SOA master 5 S ー ave 7 S ー maste 「 8 slave 1 4 1 5 er S ー 1 9 5 ー mast e r 2 1 S ー ave 22 S ー ave ニを一へ ロ 0 h. ex 師 p 厄 . com 6 (OA: marks the s い杙 of a zone of authority) 1 (the lnternet) no 杙 h. exampl e. com 6 (SOA: nrks the start of z 旧 0 「 authority) 1 (the lnternet) 400 32 n 引 .8 h. ex 師 p 熔 . co 用 「 00 し n 引 . no 杙 h 記 x 毓 p 厄 . com DNS に / 10 ] ID : 1 master ー〉 s lave D NS 図 9 スレーブサーバー走加寺のゾーン輯医の様子 スレーブ マスター スレープサーバーを起動した様子です。 最初に通常の起動メッセージカ俵示されたあと、 ・ north.example.com ・ 10.168.192. in ー addr. arpa の 2 つのゾーンの中幻医メッセージが表示されています。 のように、スレープサーバーを初めて起動したときは、起 動直後にゾーン車幻劫咥生します。 ゾーン転送の様子をプロトコルレベルで確認してみまし よう。図 8 は、スレープサーバーの起動後におこなわれた DNS データのやりとりを、ネットワーク・アナライザ 2 で 表示したものです。また、このときのシーケンスを図示し たのカ咽 9 です。 スレープサーバーは、最初はゾーンに関する情報をもっ ていません。そこで、起動時にマスターサーバーから SOA レコードを取得し、シリアル番号などを調べます。このと きの SOA レコードの問合と応答を表すのが、図 8 のフ 2 アールワークスの ASTEC Eyes on the net (http://www.astec eyes ・ com/) の表示です。 north.example.com ソーン SOA レコードの問合せ SOA レコードの応答 AXFR の問合せ AXFR の応答 10.168.192. in - add 「 . arpa ソーン SOA レコードの問合せ SOA レコードの応答 AXFR の問合せ AXFR の応答 ・いいをいむいー レーム ID 0 ~ 1 の行です。 図 8 の下半分の領域は、 バーからの応 マスタ 69 UNIX MAGAZ 工 NE 2005. 10

図 12 ゾーン情報の同期 昌ファイル編集 ( 印表示 (Y) キャプチャ 0 モこタ ( 迎ツし設定 0 = ラ north.example.com NET ロ睡白住ー @ 住第圄↓む副 O ID : 13837 OPCODE:O RET20 NAME=north 朝 0 ASTEC Eyes [ キャプチャデタくⅸ fr. e れ c 〉 ] サーノヾー SOA レコードの応答 ウインドウ並 フレーム ID 発信 . マ受信 ... マ ブ . サマリ 定期的に SOA レコード を取得 回区 マデルタ時問 325 326 344 345 861 圏 2 873 879 圏 3 囲 5 囲 7 Slave master S ー ave maste r Slave maste r 5 ー master S ー ave slave e r mast 8 r S ー e r S ー ave mast e r S ー ave e r S ー ave mast e r master 5 ー DNS DNS DNS DNS DNS DNS DNS DNS DNS DNS DNS ロ I D= 45423 OPCODE: 0 RET= 0 NAME:no rth. R ID : 45423 OPCODE=O RET=O NAME:north. O I D= 41053 OPCODE= 0 RET= 0 NAME:no rt h. R I D= 41 0 53 OPCODE: 0 RET: 0 NAME= no 杙 h R ID : 13897 OPCODE:O RET:O NAME=north Q ID : 25343 OPCODE=O RET:O NAME=north. R I D= 2 5 343 OPCODE: 0 RET: 0 NAME= no rt h examp ー e examp ー e exampl e . examp 厄 . . exampl e . exampl e examp ー e . example . com 三 TYPE: SOA 三 . c 。 m 打鷲印 : TYPE= SOA : com え縟印 . co TYPE= SOA : . com えミ明 . com 三 TYPE=SOA 三 . com え明 . com. 0 . 圓 0000 0 .000776 481 .333973 0 . 圓 0737 528.011346 0 . 0 圓 753 SOA レコードを取得 する間隔 : T00 sho rt t 0 聞引 yze 三 Cont i nu i Packet 三 R I D= 5 9 6 OPCODE: 0 RET±O NAME= no rt h. examp . com TYPE= I XFR Ⅸ FR によるゾーン転送 511 .004372 0 . 0 圓 765 0 . 00 1 8 1 1 0 .000203 0 .002481 ・←この間のタイミング でマスターサーバー のゾーン情報を更新 レコードが更新された マスターサーバーの SOA ワークスペース 1 図 13 スレーブサーバー乍中のゾーン輯医 スレーブサーバー リフレッシュ時間 : ャ SOA レコード A レコード NS レコード シリアル番号 の問合せをおこなう されていれは、Ⅸ FR シリアル番号が更新 マスターサーバーの SOA レコードの問合せ SOA レコード シリアル番号 Ⅸ FR の問合せ ゾーン転送 マスター Ⅸ FR の応答 バー側のゾーンファイルの内容を更新して確認しましよう。 ファイルを書き換えたらシリアル番号を増やしてください。 なお、ゾーンファイルの更新後は、 DNS サーバーのプ ロセス (named) に HUP シグナルを送ることを忘れない でください。 DNS サーバーのプロセス ID は /var/run named. pid に保存されています。 k111 -HUP ' cat /var/run/named. pid' 図 12 では、 SOA レコードの取得を 3 回繰り返したあ 72 とのタイミングでゾーンファイルを書き換えました。した がって、スレープサーバーが 4 回目に取得した SOA レコ ードのシリアル番号は新しくなっており、続いてゾーン転 送要求 (IXFR) をおこなっています ( 図 13 ) 。 シリアル番号を戻す マスターサーバーのゾーンファイルのシリアル番号を増 やすと、スレープサーバーの情報か要新されます。それで は、シリアル番号を減らしたらどうなるのでしようか。 UNIX MAGAZINE 2005. 10

ワークステーションのおとーー 0 おまけ システムに必要なパッチを評価しています . Password : $ sud0 smpatch analyze カ陬得できます。 smpatch analyze" とするだけで、必要なパッチの一覧 patch というコマンドがあります。たとえば、 root で Solaris 10 には、 OS へのパッチ適用を簡単にする sm- 取得されたパッチリスト . 必須パッチ。 120199 ー 02 SunOS 5 . 10 : 119315 ー 03 SunOS 5 . 10 : App1ications Patch 119719 ー 01 SunOS 5 . 10 : 119012 ー 02 SunOS 5 . 10 : 118868 ー 01 SunOS 5 . 10 : 120543 ー 01 SunOS 5 . 10 : 120302 ー 01 SunOS 5 . 10 : 119313 ー 03 SunOS 5 . 10 : sysidtool Patch SOIaris Management WBEM Patch sendmail patch Apache Patch ttymon patch crypto Patch kmdbmod patch さらに、 れます。 smpatch update " とすれば、パッチが適用さ http://groups ・ google.com/group/comp.unix. s01aris/browse-thread/thread/67008c2f7c5b 0656 / 20e8087fe202ad4f に情報があり、 # rm /var/sadm/patch/119107—03/prebackout # smpatch remove —i 119107 ー 03 とすればよいでしよう」 さっそく comp. unix. solaris ニュースグループを覗い てみると、下記の説明がみつかりました。 lt 100kS like patch 119107-03 adds the ” Sun Update Connection CIient, ” which changes the outbound site you connect tO (getupdates.sun.com versus update- server.sun.com/ , and adjusts several additional proper- ties (comapare 'smpatch get' between a new build and a freshly patched system). The URI smpatch now uses tO grab updates doesn't exist on getupdates.sun.com/ which seems to be the heart of the problem. つまり、パッチ 119107 ー 03 が悪さをしているようです。 これを、次のようにして削除します。 # cd /var/sadm/patch/119107—03/ # ls README. 119107 ー 03 postbackout 便利に使っていたのですが、先日、これがうまく動かな # smpatch analyze くなりました。 URL : https : //getupdates. sun. com/solaris/ 403 for Server returned HTTP response code: Fai1ure : Cannot connect tO retrieve detectors : システムに必要なパッチを評価しています . URL の部分を以前の、 156 「この問題については、 答をいただきました。 あるメーリングリストで訊いてみたところ、次のような回 しばらく試行錯誤したのですが、どうにもなりません。 Fai1ure : Cannot connect tO retrieve detectors : システムに必要なバッチを評価しています . # smpatch analyze =https : //updateserver. sun. com/solaris/ # smpatch set patchpro ・ patch. source=> に変更してみましたが、やはりダメです。 ・ https://updateserver.sun.com/solaris 10g pkgrm— 1 i s t prebackout smpatch. SUNWswmt . undo # mv prebackout prebackout . ORG # smpatch remove —i 119107 ー 03 remove patch 119107 ー 03 Transition old—style patching ・ Executing postbackout script ・ # smpatch update システムに必要なパッチを評価しています . 取得されたパッチリスト . パッチをダウンロード中 /var/sadm/spool ・ 120199 ー 01 has been validated . 119145 ー 02 has been validated . 119252 ー 02 has been validated . 119315 ー 02 has been validated . これで、パッチの適用はできるようになりました。ただ し、 119107-03 も適用されてしまうので、 smpatch up- date/analyze を実行する前にこれを削除する必要があり ます。 UNIX MAGAZINE 2005. 10 ( さかした・しゅう Acutus Software)

荒井美千子 お詫びと訂正 54 ページの図 3 (north.example.com/zone ファイル ) を組み合わせて使っている箇所です。たとえば、 9 月号の 誤っていたのは、ゾーンファイル内で NS と CNAME いました。お詫びするとともに、以下のように訂正します。 正があります。例として紹介したゾーンファイルカって いきなりですが、 8 月号と 9 月号の記事の内容について訂 IN NS IN CNAME perseus IN A 連載 ネットワーク・ミニ実験室 スレープサーバーとソーン転送 IN NS ns . north. example . com. perseus 192 . 168 . 10. 1 と記述した箇所がありましたが、 DNS のルール上、 C- NAME は NS や MX などのレコードと組み合わせて使 ってはいけないことになっています。 上記のように NS と CNAME を組み合わせると、資源 を浪費したり、不要なトラフィックを発生させてしまうか もしれません。また、 DNS サーバーの種類やバージョン によっては、 north.example.com ゾーンを管理している ネームサーバーが正しく動作しない Lame Delegation と 呼ばれる状態になる可能性もあります。 NS レコードを設定する際は、 CNAME と組み合わせ ずに下記のように言古杢してください。 IN A ns . north. example . com. 192 . 168. 10 . 1 転んだのにタダで起きるのはもったいないので、 Lame については次号でもうすこしお話ししたいと 64 思います。 Delegation スレーブサーバー UNIX MAGAZINE 2005. 10 が用意します。 ため、マスター / スレープサーバーはいずれもプロバイダ側 があります。この場合の名前解決はプロバイダ任せになる 用として固定ではない IP アドレスが割り当てられること SOHO などでは、プロバイダからインターネット接続 といった組合せで運用されることが多いようです。 バイダに 1 台のスレープサーバー 2. サイト内に 1 台のマスターサーバー、利用しているプロ 1. サイト内に 1 台のマスターサーバーと複数台のスレープ DNS サーバーを 2 台以上動作させることになっており、 インターネットの運用ルールとしては、ゾーンごとに 前回に紹介した DNS サーバーはマスターサーバーです。 ーバーと呼ばれる場合もあります ) をもっことができます。 アップとして機能するスレーブサーバー ( セカンダリ・サ ー情報を保持するマスターサーバーに加えて、そのバック さいわい DNS の仕組みでは、名 - 前解決のためのマスタ くのホストが景彡響を受けるのは間違いありません。 トで名前角夬が失敗する・・・・・・とはならないでしようが、多 で、 DNS サーバーカ亭止した瞬間に世の中のすべてのホス なくなってしまいます。現実にはキャッシュ機能のおかげ や障害で停止すると、そのゾーンに対する名前解決ができ 況になるでしよう。唯一の DNS サーバーがメンテナンス が世の中に 1 台しかないとしたら、なんとも心許ない状 ところで、あるゾーンの情報を提供する DNS サーバー 名前解決において重要な役割を担っています。 前回までに説明したように、 DNS サーバーはホストの

図 10 ゾーン輯医の要求テータをつなぎ合わせて表示 00 0.. を 0 ASTEC & ー以トリームく ~ 0 れ e 一 a れ s 「上れ 0 刃 昌ファイ井の編集 ( 印表示キャプチャ 0 モニタ ( M ) ツル設定 0 ウインドウヘルプ ( 印 回区 咄ラ north.example.com NET ロー物ー囲斗住 ス . マアドレス 1 マポト 1 マ。マアドレス 2 マボト 2 マ ・当 0 パイト プロトコルマサマリ 53 53 53 53 つなぎ合わせたあとの north.example.com / のゾーン転送の要求 要求テータ arpa のソーン転送の 10.168.192. in - add 「 . へつなぎ合わせたあとの テータ T e slave S ー ave oma i n Name Syst em 1 1 7 1 1 1 7 2 1 1 7 2 DNS 35 1 1 7 1 0X0000 7887 master mast e r er . 0000 mast er .000 . DNS DNS DNS DNS R I D: 7 圏 7 OPCODE:O RET:O NAME: no rt h. exampl e. co ロ ID : 55434 OPCODE:O RET=O NAME : 10 . 168 .132. in-a R ID : 55434 OPCODE=O RET:O NAME : 10 . 168 .192. in-a 0 Ⅲ : 7 囲 7 OPCOOE:O T : 0 NAME:north.example. cr-k DNS Record Length ldent ification F lags 0pcode AA TC zero Response Cöde Numbe r of Questi ons Number of Answer RRs Number of A 沚 ho 「社 y RRs Ouery 日リ rsion not avai b Recursi on no を des ⅳ Not truncated Non っ hori いい肥明 5 鸛 r Standard 叩 y NO error Nu&r 0 「 Addit ional RRs 0 resourcerecord(s) 0 resource 代 CO rd(s ) 0 「” 0 リ rce record(s) 252 (ÅXFR.• a request for レ s r of an enti 肥 20n8 ) ゾーンに対する要求 north.example.com 要求しているレコード の種類は AXF 日 t on Ouery Name Type Class DNS north.example.com 1 (the lnternet) 答の詳細の一部です。、、 Answer" 領域の TTL (Time 168.192. in-addr. arpa の逆引きゾーンについて同様のや に関するやりとりです。フレーム ID 14 ~ 22 では、 10. こまでは、 north.example.com ゾーンの情報の車幻医 答がフレーム ID 8 のバケットで返されています。 ン転送の要求が 2 つのバケットに分割して送られ、その応 ットに分かれていることを未しています。ここではゾー と表示されていますが、これは一連のデータカ夏数のバケ Continuing Packet T00 short tO analyze フレーム ID 5 および 7 の行は、 いるのがフレーム ID 5 、 7 、 8 の 3 行です。 サーノヾーからゾーン情報を取得します。この様子を表して SOA レコードの取得後、スレープサーバーはマスター ードの内容と一致していることを確認しておきましよう。 NAME) の表示が、ゾーンファイルに設疋した SOA レコ To Live) やそのゾーンを管理する DNS サーバー (M- 70 りとりがおこなわれています。 [ 1 / 4 ] ID:O slave ー > master DNS ゾーン転送 swer 2 、 3 ・・・・・は、それぞれ応答に含まれる 2 番目のレ 図 11 はゾーン転送の応答バケットの一部です。 An- ードを表すわけではないことに注意してください。 示す A レコードのように、ゾーンファイル内の特定のレコ は、ネームサーバーを表す NS レコードや IP アドレスを 定されたゾーンに関するすべての情報を返します。 AXFR 送を意味するタイプで、 DNS サーバーは応答として、指 AXFR (a transfer of an entire zone) とはゾーン転 ことが分かります。 ・ AXFR タイプのレコードを要求している (Type) ・ north.example.com ゾーンに文寸して (Query Name) ti 。Ⅱ " 領域の表示を見ると、 転送の部分を表示したものです。図の下のほうの、 Ques- 図 10 は、分割されたバケットをつなぎ合わせてゾーン おきましよう。 ゾーン転送の部分のプロトコルをもうすこし詳しくみて UNIX MAGAZ 工 NE 2005. 10

図 15 重加勺更新か無効なら AXFR 形式でゾーン車医がおこなわれる The Doma i n Name Syst em ( DNS) DNS Record Length ldent i f i cati on 日 ags TC RD RA Zero N リ e 「 0 「 Quest i ons Number 0 「 Answer RRs Response Code 224 763 0X8480 .000 0 .000 . . 0000 : 6 「 eso 町 c 日 ræord ( 5 ) 三 Standard query A 「 ita い answer Not t 間 nc 訌 ed Recursion not desired Recursi on 日Ⅱ ab NO Number 0f A 沚 h0 「社 Y RRs ・・årce 「 6 信 ) Number 0 「 AdditionaI RRs 0 resource record(s) Questi on y N 8 Type nswer Name Type 引 ass Time To 凵 no 日 h: e 叩厄 . com 6 (SOÅ: marks 土 h 日 s い杙 0 「 a 202 of authority) north.example. C0第 ・ 1 " ・ erne い : 25 1 (IXFR: incremental transfer) 三 500 1 (the lnternet) 6 つのリソースレコードが返される レコード情報が続く north.example.com ソーンの 問合せのタイプはⅨ FR ックの負荷を押し上げる要因になります。そこで、ゾーン 情報の更新を効率よくおこなうため、変更ぶんだけを送る 機能が DNS の仕様に追加されました。これが IXFR で す。 IXFR を実行したときに変更部分だけカ送されるの は、 BIND9 では、、動的更新 " を有効にしている場合だけ です。それ以外の場合はマスターサーバー側に次のような メッセージか表示されます。 06 ー Aug ー 2005 23 : 06 : 39 . 219 client 192 .168 . 10.2 # 1157 : transfer of 'north. example . com/IN' : AXFR— style IXFR started 06 ー Aug ー 2005 23 : 06 : 39 . 220 client 192.168.10.2 # 1157 : transfer of 'north. example . com/IN' : AXFR— style IXFR ended このメッセージから判断すると、 AXFR 形式 (AXFR- style) で IXFR データカ云送されたようです。実際のパ ケットを確認すれば簡単に分かりますが、このときの DNS の応答で返されるレコードは、 1. SOA レコード ( 同じ内容 ) が 2 回 2. NS レコードが 2 つ ( マスタ 3. A レコードが 2 つ バーとスレープサー の合計 6 つです。 AXFR の場合と同様、すべてのレコー 74 ドカ答バケットに含まれていました ( 図 15 ) 。 このことから分かるように、スレープサーノヾーが IXFR 要求を出した場合は、マスターサーバー側の設定によって データの転送量が減るかどうかが決まります。 ☆ DNS を運用するうえで、スレープサーバーは欠かすこ とができません。スレープサーバーはマスターサーバーの 負荷を軽減し、いざというときのバックアップとしても動 作します。 マスターサーバーが管理しているゾーン情報は、ゾーン 車医によってスレープサーバーにコピーされます。 今月は、スレープサーバーとゾーン転送の動作を中心に お話ししました。ゾーン転送の動作の調査、障害発生時の 現象解析には、 DNS サーバーカ咄力するメッセージやネッ トワーク・アナライザカ陏効です。これらカ咄力する情報 をもとにに、ふだんから自分のサイトで利用している DNS サーバーの動作や、、クセ " を把握しておくことをお勧めし 0 ( あらい・みちこ Rworks) UNIX MAGAZINE 2005. 10