連載 /UNIX Communication Notes—O ドメイン major ・ ac ・ jp の /etc/hosts ファイル リスト 1 192.9.200. 10 192.9.200. 11 192.9.200. 12 192.9.200. 15 192.9.200. 16 192.9.200. 17 192.9.200.18 192.9.200. 19 192.9.200.20 192.9.200.21 127.0.0. 1 192.9.200. 14 192.9.200. 13 localhost tigers . major. ac ・ JP tigers giants ・ maJ0r ・ ac ・ JP giants red—sox. major. ac . 」 p red—sox yankees. major ・ ac ・ jp yankees athletics. major ・ ac ・ JP athletics cubs . major ・ ac ・ JP cubs reds . major ・ ac. JP reds mailgate mets . major ・ ac ・ JP mets angels ・ maJ0r ・ ac ・ JP angels astros . major ・ ac ・ JP astros houston ftp b1ue—Jays ・ maJ0r ・ ac ・ jp b1ue-Jays pirates. major ・ ac ・」 p pirates リスト 2 maJ or SOA レコード IN ・ ac ・ JP ・ このゾーンは 名前の記述方法 SOA yankees ・ major ・ ac ・ JP ・ suguru ・ maJ0r ・ ac ・ JP 1 10800 3600 3600000 86400 ) Seria1 Refresh 3 hour Retry 1 hour Expire 1000 hours Minimum 24 hours ゾーン情報を言当するファイルでは、名前 ( ドメイン名 やホスト名 ) の言当の仕方に注意しなけれはなりません。 前回説明したように、 DNS の決めた名前空間では、最 上位はルートサーバーか管理しています。ルートサーバー の管理するゾーンは、名前空間の、、根 " となる部分です。 " ( ドット ) 1 文字で表記されます。 UNIX MAGAZINE 1993.8 あるホストの情報は、リスト 1 に示す /etc/hosts ファイ 報を記述するという前提で説明をします。このドメインに これ以降は、ドメイン major ・ ac. jp についてゾーン情 これ以降の説明 けていないものは、すべて相対表記として扱われます。 キストに依存して評価されます。名前の最後にドットを付 一方、相対表記はファイル内でのデータの言当のコンテ ださい。これか絶対表記であることを示しています。 となります。最後にドットが付いていることに注意してく aist—nara. ac ・ JP ・ 名の糸色オ表記は、 ます。たとえは、奈良先端科学技術大学院大学のドメイン 糸寸表記の場合、名前空間の根からの情報をすべて記述し 名前の表記ガ去には、絶対表記と相対表記があります。 ルで管理されており、これを BIND を用いて管理するこ とを想定して解説を進めていきます。 それでは、ドメイン major ・ ac. jp のゾーン情報をファ イル majo て・ zo Ⅱ e に記述していくことにしましよう。 SOA レコード 最初に記述しなければならないのが SOA レコードで す。これは、データファイルがどのゾーンに対する情報か 特定し、その情報をネームサーバーがどのように提供する かを指定します。 リスト 2 に、 SOA レコードの言当例を示します。 SOA レコードでは最初にドメイン名を書き、このファ イル己述するドメインを明らかにします。ここでは糸寸 表記でドメイン名 maj 。 r ・ ac ・ jp ・を記述していることに 注意してください。 次の IN と SOA は、このレコードが INter Ⅱ et クラス の SOA レコードであることを表しています。 その次に書かれている名前は、データファイルを作成し たホストのホスト名です。リスト 2 の場合、データファイ ルは yankees ・ major ・ ac ・ jp. で作成したことを表して います。 最後に書かれているのが、ゾーン窈青報管理者のメール アドレスです。左から最初のドットを、池 " ( アットマー 59

連載 / コアダンプするんですけどー① リスト 2 static な配列を返す関数列 char *testfunction2(int selection) static char table [ 16 ] ; switch (selection) { / * This must be static * / case 0 : strcpy(table , break; case 1 : strcpy(table , break; default : strcpy(table, break; return table ; ” f00 " ) ; は関数の内部に文字列を用意しなければなりません。これ についても、次のような 3 通りのインプリメントが考えら れます。 1. malloc() などでメモリエリアを確保する 2. static な配列を用意する 3. 関数の呼出し元が責任をもってエリアを用意する 1 の場合は、 ・関数を繰り返し呼び出しても、以前の結果は壊れない ・ free() を忘れると大変だ というような特徴があります。引数の値に応して文字列を 返す変換関数を作ると、リスト 1 のようになります。 2 の場合には、反対につねに同しェリアを使用するため、 ・関数を呼び出すたびに前回の結果を破壊する ・ static なエリアなので、 free() する必要がない ということになります。さきはどのリスト 1 を static な配 列を返す関数に書き換えた例をリスト 2 に示します。この 例のとおりメモリの消費量がはっきりしていて、 free() す る義務もないので、ちょっとした変換関数などには手軽に 使うことができます。 3 は、 UNIX のライプラリ関数などでよく使われてい るやり方です。この場合は、関数のなかでエリアの大きさ をチェックするのか難しいので、エリアの大きさは別の引 数で渡す必要があります。また呼出し元でも、メモリエリ アを確保するためのコードが必要になりますので、前の 2 っとは基本的にプログラムの雰囲気が変わってきます。 138 リスト 3 strcpy() ライクな関数」 char *testfunction3(char *s, int selection) switch (selection) { case 0 : f00 ) ・ strcpy (s , break ; case 1 : strcpy(), "bar") ; break ; default : return NULL ; 自分で関数を作っていると、 UNIX のライプラリ関数 の仕様を真似したくなりませんか ? 一般的な呼出し形式 に従っておくとみんなカ硬ってくれそうとか、なんとなく かっこいいなあとか、筆者は思います。で、文字列を返す ライプラリ関数といえば、 strXXX() や index() などが 有名ですので、この辺を参考にしてみましよう。 ライプラリ関数の仕様を念頭においてリスト 1 を書き換 えてみたのがリスト 3 です。工ラーのとき ( 引数が 0 / 1 以 外 ) には NULL を返すようにしたところがリスト 1 と異 なっています。 リスト 3 の場合、関数の内部はかなりシンプルにまとめ ることができます。けれども、文字列がコピーされる領域 については関数の内部ではなんの保証もしていません。 れは、すべて呼出し側て責任をとらなければならないとい うことです。つまり、リスト 2 のときには、おせつかいに も関数側でメモリを用意してくれましたが、リスト 3 では、 どのくらいメモリか消費されるかは自分で見当をつけなけ return S ; UNIX MAGAZINE 1993.8

連載 / C 十十 AD Ⅵ SOR ー⑨ るデストラクタか呼び出されるのである。オプジェクト に対して delete カ呼び出されるときは、いつでもそのオ プジェクトに対するデストラクタか呼び出される。デス トラクタはオプジェクトの激しい動きを監視しているの で、これらを理解することはたちの悪いバグをなくすの に役立つだろう。 デストラクタの彳難リは、オプジェクトを消去する前に、 周囲との関係を平穏裡に整理することである。これにはさ まざまな使い方がある。デストラクタは、いままさにタけ也 に赴こうとしているオプジェクトが、はかのオプジェク トに対して、自分の臣冬を伝えるために使われる。またデ ストラクタは、オプジェクト実行時間についての統計を書 き出すときにも使える。しかし、おそらくもっとも重要な 使い方は、オプジェクトを消去する前にメモリを確実に解 放するということである。 たとえは、オプジェクトを要素とする双方向リストを 考えてみる。要素のリストは次のようなクラスになるだ some_type *value ; list—element *next—ele, *prior—ele; private : //other stuff &list—element ( ) ;//a destructor list—element ( ) ; //a constructor public : class list—element{ ろう。 決できる。デストラクタは、オプジェクトを削除するとき 正しく書かれたデストラクタなら、このような間題は解 発見しにくいバグに悩まされることになるだろう。 ばそのメモリ空間は空のままだが、再利用されていると、 示す 2 つのリスト要素ができることになる。運がよけれ る。このような削除をおこなうと、あるメモリ空間を指し 体であるオプジェクトを削除してしまうというものであ グは、リスト中の要素を取り除かすに、リストの要素の実 このようなリストを扱うコードに共通して発生するハ して要素の内容 ( イ間をイ尉寺する。 ト上の次の要素へのポインタと前の要素へのポインタ、そ これはかなり標準的な内容で、各リストの要素はリス 94 リストから要素を取り外すコードで実行できる ) 。もしこ をかならす 0 にセットすることができる ( 多くの場合、 にはつねに呼び出されるので、 next-ele と prior-ele れらが 0 でなければ、デストラクタは実際にオプジェク トを削除する前に、そのオプジェクトをリストから取り外 すコードを呼び出す。このように、リストからの取外しを 正しくおこなってからでないと要素カ哨リ除できないので、 リストの整合性はつねに保たれるようになる。 コンストラクタとテストラクタ デストラクタのもう 1 つの利用法は、前節であげたク ラスの例で説明できる。リストが一尉寺しているのは、ある 値へのポインタである。この値は、最初に設定されるとき におそらく new を呼び出すことによって生成されたもの である。したがって、メモリを解放するときは、つねに デストラクタを使わなければならない。 ということは、 list-element オプジェクトのデスト ラクタには、次のような行が含まれていなければならな delete value ; これでリストか破壊されたときに、メモリを取り込ん だままヒープ中にとどまり、二度とそのメモリ空間を再 利用できないような状態のオプジェクトを放置すること はなくなる。 これはあっけないはど簡単にみえる。もし、ほかのオ プジェクトに対するコンストラクタを使ってヒーフ上に オプジェクトを生成したのならば、そのオプジェクトに対 するデストラクタのなかで、作成したオプジェクトを削除 しなければならない。原理は簡単だがこれに従うのは難し い。 C + + システムでよくみられる失敗は、メモリのリー ク ( 確保したメモリ領域を解放し忘れること ) か、ある いはそのほかのヒープの管瓔の問題と関係があること か経験的に分かっている。信じがたいことだが、同しオ プジェクトを何度も消したり ( その結果どうなるかは実 装によって違う ) 、オプジェクトを見失ったり、まった く消さない ( たんにヒーフ。から出すだけ ) などということ も簡単にできてしまうのだ。 このような問題は、さまざまな原因から起こる。この 問題を回避するもっとも簡単なガ去の 1 つは、コンスト ラクタとデストラクタを、つねに 2 つで 1 組の緊密な関 係をもった関数として扱うことである。つまり、コンス トラクタ中で new を呼び出したら、かならずそれに対 UNIX MAGAZINE 1993.8

連載 / コアダンプするんですけどー① リスト 4 せつかく static な配列を返す関数なのに」 char *testfunction4(int selection) static char table [ 16 ] ; switch (selection) { / * This must be static * / case 0 : strcpy(table, return tab1e ; case 1 : strcpy (table , return tab1e ; default : return NULL; " f00 " ) ; "bar") 図 2 文字列定数でコアダンプしたときの dbx % dbx unixlike Reading symbolic information. Read 138 symbols program terminated by signal SEGV (access t0 address exceeded protections) (dbx) list 7 8 9 10 11 12 13 14 15 16 strcpy(buffer, bre ak ; case 1 : strcpy(buffer, ” f00 ” ) ・ break ; default : buffer break; NULL ; return buffer ; (dbx) print buffer testfunc(buffer = 0X2330 "ABC" , selection = 0 ) , w4str() at 0Xf773312C (dbx) where CCa237621 'testfunc'buffer = 0X2330 "ABC" ればなりません。 (dbx) main() , line 23 in unixlike. c" 明したほかの関数の引数として使うときの問題がっきまと なっています。しかし NULL を耐妾返すのは、最初に説 この例では、 default のときに NULL を返すように えす作ってみたのがリスト 4 です。 を返す仕様にするにはどうしたらよいでしようか。とりあ ことにしましよう。リスト 3 のように、エラー時に NULL もう一度リスト 2 をもとにプログラムを書き直してみる UNIX MAGAZINE 1993.8 用できる ・それを関数のリターン値とすると、式刎直として直接利 ・ static な酉改」を返すのはお手軽だ したがって、 います。 line 7 in unixlike . ・ところが、 NULL を返す可能があると、 strcpy() な どの引数には茁妾使うことができない ということになり、せつかく使いやすくできているように 見えたリスト 4 にも、問題があることが分かりました。 これがたとえば、さきほどのリスト 3 の場合だと、次の ようにして呼び出すことカそきます。 if (testfunction3(s, selection) = = NULL) error ( ) ; else process(s); リスト 3 では、リターン値が NULL になるときには引 数で渡された文字列の実体は操作しません ( したがって、 関数側ではその値を保証しない ) 。そのため、呼出し元で 139

表 6 mkcd 呆存ファイル ム . cf i . cff . cfd .cfl . cfc . cfv 内容 設定内容 ( 図 5 、リスト 3 ) 変換結果のフォーマット情報 ( 図 6 、 変換結果のディレクトリ情報 ( 図 7 、 変換結果のロケーション情報 ( 図 8 、 出力パネルのキュー情報 ( 図 8 ~ 11 、 出力パネルのポリューム情報図 11 、 リスト 5 ) リスト 4 ) リスト 6 ) リスト 7 ) リスト 8 保存 " お尺すると、フォーマット変換した結果のリスト がファイルに出力されます。保存されるファイルの一覧を 表 6 に、保存されたファイルの内容の例 ( ーでフォー マット変換したもの ) をリスト 3 ~ 8 に示します。 おわりに ォーマットできないなどの点はありますが、勺にはか イルの扱いに制限があったり、 Macintosh の HFS がフ もあるようです。 CD-ROM Creator にも UNIX ファ えないとか、 CD-I 専用のように単峩能であるなどの問題 なかには、 MS-DOS の制約から ISO 9660 level 2 か扱 PC をベースにしたシステムも多く存在します。これらの CD-R 作製機は、この連載で紹介したもののはかに、 安価に CD-ROM を作ることができます。 ROM Studio はすでにソニー NEWS があれは、わりに をベースにした CD-ROM Studio を紹介しました。 CD- 今回は、 CD ー R の作製の 2 回目としてソニーの NEWS なり安定しています。 ( やすだ・なおよし日外アソシェーツ ) いっそう進むことを願っています。 変もメディアの特徴を活力せるような標ヒ、規剳ゞ マテープより CD-ROM のはうが人気があるようです。 ソフトウェアの配布用メディアとして、匠ではストリー どの面から大きな魅力を備えています。 UNIX 関係でも ディアではありませんが、容量の大きさや手軽さ、価格な CD-ROM は、性能的にはけしてバラ色のスーパーメ [ 赭文献 ] 110 tion 、 1992 N Ⅵ TF -628 Release 1.2 使用説明書」、 Sony Corpora- [ 1 ] 「 CD-ROM フォーマット変換ツール CD-ROM Creator リスト 3 mkcd の言聢保存ファイル ( *. c 升 ) # CD-ROM Creator Re1ease 1 . 2 . 1 # Disc Format lnformation : cd # Date: Thu Apr 8 18 : 26 : 37 1993 —format aiSO —lbs 2048 —system APPLE COMPUTER, INC. , TYPE : 0002 —volume JGE_DICTIONARY -v01umeSet MULTI_MEDIA_DICTIONARY —publisher NICHIGAI ASSOCIATES INCORPORATED —dataPreparer NICHIGAI ASSOCIATES INCORPORATED —application MMDIC —copyright COPYRIGHT. SUN —abstract —bibliography —creation 1993 ー 04 ー 01 04 : 07 : 13 —modification —expiration —effective —path / /cdrom/IPA/CDROM/COPYRIGHT . SUN /cdrom/IPA/CDROM/COPYRIGHT . MAC —path /MAC /cdrom/IPA/CDROM/MAC/* —path /SPARC /cdrom/IPA/CDROM/sparc/* -path /JGE /cdrom/IPA/CDROM/JGE/JGE. ABT /cdrom/IPA/CDROM/JGE/ITAIJI . CDB /cdrom/IPA/CDROM/JGE/KEYO . CDB /cdrom/IPA/CDROM/JGE/KEY1. CDB /cdrom/IPA/CDROM/COMPUTER/PHOTO .256 /cdrom/IPA/CDROM/COMPUTER/PHOTO. BW /cdrom/IPA/CDROM/COMPUTER/VOICE. SND —path / /cdrom/IPA/CDROM/uti1 リスト 4 mkcd のディレクトリ情報ファイル (). cfd) # CD—ROM Creator Re1ease 1 . 2 . 1 # Directory Structure : cd # Date: Thu Apr 8 19 : 18 : 29 1993 ROOT 2 file(s) ー COMPUTER 12 file(s) JGE ー MAC 13 file(s) 4 file(s) SPARC UNIX MAGAZINE 1993.8

$japanese $j apanese next ; unshift (@ー else { # 日本語の始まり # 日本語の終り # 無関係のシーケンス # ーに戻してもう 1 度 # 日本語のなかなら文字列の長さの半分、そうでなければ長さを加算 $c + = $japanese ? (1ength($-)/2) : length($-) ; if (eof) { print"$ARGV: $. lines $c chars\n" # ファイルの終りで表示する close ARGV; 前回は EUC と SJIS 用の wc プログラムの例をいくっ かとりあげたが、今度は JIS コード用の wc プログラムの 例を挙げて、 JIS コード文字列を扱うプログラムについて 説明しよう。 JIS コードの場合、日本語文字の始まりと終りを表す工 スケープ・シーケンスがあり、実際の日本語データを見た だけでは、それが日本語かどうかを判定することはできな い。そのため、どうしてもモードを意識したプログラムに ならざるをえない。 筆者が使う常套手段は、読み込んだ文字列をまずェスケ ープ文字で split してしまう方法である。このときに、 split する文字列を、 のように ( ) で話ると、区切り文字列も含んだリストを作る という文字列を / ( \ e ) / で split すると、 " 123 \ e456 \ e789 " ことができる。たとえは、 \e" " 456 " ( " 123 " " 789 " ) というリストが得られる。それを先頭から処理していけ ば、どこで ASCII と日本語が切り替わるかが分かる、とい う寸法である。 (1) は、 JIS コードのファイルを読み込んで、そのなかに文 160 字がいくつ含まれているかを表示するプログラムである。 ます、エスケーフ文字で区切った文字列のリストを得る while (defined($— と、それを、 UNIX MAGAZINE 1993.8 正規表現を用いてエスケープ・シーケンス全体を使って の値がモードを表しているということである。 ま使える。ポイントは、そのときの $japanese という変数 こは決まり文句なので、どんな場合でもほとんどそのま ェスケープ・シーケンスの処理の部分がすこし面倒だが、 うでなければ文字列の長さぶんの値をそれぞれ加算する。 て加算すれはよい。日本語ならば文字列の長さの半分、そ たんなる文字列だから、そのなかに含まれる文字数を数え リスト要素が単独のエスケープ文字でなけれは、それは いう変数で記憶する。 本語文字列のなかにいるか、そうでないかを $japanese と 除いてしまう。そして、そのシーケンスに従って、現在日 を調べて、もし工スケープ・シーケンスならばそれを取り スである可能生が高い。そこで、次のリストの要素の先頭 れに続く文字列が日本語の始まりと終りを表すシーケン 能生もあるからだ。 $ ーがエスケープ文字であった場合、そ く。 defined を使っているのは、 " O " という文字列がくる可 というループで先頭から順番に $ ーに代入して処理してい

連載 /UNIX Communication Notes リスト 5 CNAME レコードの言己 mailgate ・ maJ0r ・ ac ・ JP ・ IN CNAME reds . maJor ・ ac ・ JP ・ houston ・ major ・ ac ・ JP ・ IN CNAME astros ・ maJor ・ ac ・」 p ・ ftp ・ maJ0r ・ ac ・ JP ・ IN CNAME astros ・ major ・ ac ・」 p ・ ネームサーバーの情報を記述するには、ネームサーバー を動かす計算機を決定しなければなりません。プライマ リ・ネームサーバーの言 t 算機は次のような点を考慮して決 めるとよいでしよう。 ・すくなくとも管理の権限をもつシステム ( スーパーユー サーになれるシステム ) であること。 ・スワップエリア、メモリに余裕のあるシステムであるこ と。ネームサーバーはけっこうメモリを消費します。 安定して動いているシステムであること。 ・ネットワークと接続性のよいシステムであること。た とえば、 19.2Kbps の SLIP の先のシステムよりも、 IOMbps の Ethernet で接続されたシステムを選ぶは うが、ネットワークの利用を考えると安じ、できます。 一方のセカンダリ・ネームサ→ヾーは系目織内で用意して もいいのですが、別の系目織にお願いしてセカンダリ・ネー ムサーバーになってもらうほうが安心です。 ほとんどの組織では、インターネットとの接続は 1 カ 所のゲートウェイからで、そのゲートウェイか落ちるとイ ンターネットと妾続が失われます。このため、同一組織 内にセカンダリ・ネームサーバーを置いても、ゲートウェ イに障害か起きたときにはセカンダリ・ネームサーバーが 本来の機能をインターネットに提供できないことになって しまいます。このことから、セカンダリ・ネームサーバー については、 ホストアドレスの記述 . A レコード SOA レコードと NS レコードか記述できたら、次は具 イ勺なゾーン内の情報を記していきます。 ホスト名から IP アドレスへの変換の情報を与えるのが A レコードです。リスト 4 を見てください。 A レコードで は、最初にホスト名を、そして IN と A を書き、最後に IP アドレスを書きます。これにより、ホスト名から IP ア ドレスへのマッピングを定義するのです。 最初の行を見てください。ルーフ。バック・インターフ ェイス (loopback interface) の名前として使われている localhost はドメインに含めてしまい、 127.0.0.1 を定義 しておきます。 別名のま諚 . CNAME レコード リスト 1 に示した / etc / れ osts ファイルでは、ある IP アドレスに対して、正式な名前のはかに別名を用意してい ます。ネームサーバーのゾーン情報でも同じように別名を 己述できます。これに使われるのが CNAME レコード です。 リスト 5 を見てください リスト 1 に示した /etc/hosts で定義されている 3 つの別名を CNAME レコードで記述したものです。 CNAME レコードでは、 最初に別名を、次に IN と CNAME を書き、最後にホス トの正式名を書きます。ある名前に対して正式なものを決 めることから、 CNAME (Canonical NAME) レコード と呼はれているのです。 以 - ヒのすべてをまとめると major ・ zone の内容はリス ト 6 のようになります。 ルートサーパー情報の記述 次にルートサーバー情報を指定するファイルを記述しま す。このファイルをて。。 t . cache とします。 前回も説明しましたが、ルートサーバーは名前空間の根 こから名前空間の冓造をたど の部分を管理しており、 っていくと、インターネットでのすべての名前に到達でき るようになっています。このファイルは、ルートサーバー 一三ロ 組織内に 1 つ以 E 組織外に 1 つ以 E とするのか望ましいでしよう。ただし、セカンダリ・ネー ムサ→ヾーの数を多くすると、プライマリ・ネームサ→ヾ ーでゾーン情報を更新した際の転送にネットワークをむだ に使うことになります。このため、現在の国内のインター ネットでは、 系砌大」に 1 つ 組系外に 1 つ というのが一勺な設定です。 61 UNIX MAGAZINE 1993.8

Daemons and Dragons リスト 2 gatekeeper が送ってきたバケット 22 : 28 : 29 .018684 gatekeeper. dec . com. domain > ace . BSDI . COM . domain: 129 * 3 / 0 / 0 PTR clm. NFS の監視結果の一部 : 08.870466 五 illtop. 1d0f > ace . nfs : ・ 08.875229 hilltop. 1d10 > ace . nfs : ・ 08.879815 hilltop. 1d11 > ace . nfs: 22 : 29 : 12.903075 illtop. 1d12 > ace . nfs: 22 : 29. 22 : 29. 22 : 29 リスト 3 ( 119 ) getattr [nfs] lookup [nfs] 100 readlink [nfs] lookup [nfs] 108 108 100 だが、感激してばかりもいられない。コロラド・スプ UNIX MAGAZINE 1993.8 6 名前が知られすぎても困るので、変更してある。 うだ。 対してポーリングをおこなっていることを表しているよ ノヾージョン 2 のサーノヾーカゞ、 stratuml のシステムに バー 6 と通信しているところなのだろう。残りの部分は、 分かる。つまり、現在どこかにある stratumO のサー (Network Time Protocol) のノヾケットであることが の名前も含んでいることだ。このバケットは、 NTP イン名であるだけでなく、その通信に使われるポート こで注目すべき点は、システムの名前は正式なドメ と送信先のコンピュータが右矢印を挟んで表示される。 タイムスタンプの後ろには、送信元のコンピュータ しい。 なりの根性が必要であると思う。しかし、とてもすばら である。プログラムに 6 桁の小数を表示させるには、か 最初の部分は、ローカルタイムによるタイムスタンプ 6 prec 246 [tos OxdO] ace. BSDI . COM. ntp: v2 server strat 1 P011 22 : 28 : 28.137518 fake. system.com/ntp > ある ) 。 バケットの典型的な例である ( 誌面の都合上、改行して 表示させたときの、オプションを何も指定しない場合の 次に挙げるのは、 tcpdump を使ってディスプレイに バケットをもっと詳しく見ることにした。 ーこには 2 人しかいない。そこで、 だろう ? とにかく、 ケットが、どうやってネットワーク上に存在しているの 失敗しているのだろうか ? また、こんなにたくさんのパ 大学のコンピュータにバケットを送るのに、 1 分ごとに ットは何をしているのだろう ? どうして、イリノイ州立 リングスの丘の上にある小さなネットワーク上で、バケ さらに、イリノイ州立大学のコンピュータへの DNS の問合せ情報を調べたところ、こちら側から NTP 情 報を問い合わせていることが分かった。しかし、イリノ イにはそんなコンピュータは存在しておらす、もちろん ネットワークにもつながっていない。私は NTP の設定 ファイルを調べ、 NTP サーバーの IP アドレスを変更 第 1 のミステリーの解答 次に私を悩ませたのは、なせ gatekeeper がバケット をわざわざコロラドまで送ってくるのか、ということだ った。 ポート名をチェックして ( リスト 2 ) 、ネームサーバー 情報の交換にちがいないと思い当たり、マニュアルをち よっと読んで確認した。 このレコードは、私のシステム (ace) からの問合せ ( 129 番 ) に対して、 gatekeeper が 3 個のレコード、 0 個のネームサーバー・レコード、 0 個の author レコー ドを返したことを表している。また、最初の答のタイプ は、、 PTR" であった。全体で 119 バイトの情報が返さ オアスタリスクは答が、、 authoritative" であることを 示している。 第 2 のミステリーの解説 さらに、 NFS のリクエストとレスポンスも監視して みた。リスト 3 に挙げるのは、得られた結果の一部分で ある 7 。 かてて加えて、 rlogin プロトコルについても試してみ た。私のもっているような小さなネットワークにおいて 7 正式なドメイン名に関しては、誌面の都合により省略した。 79

2048 ( 182 + 0 ) リスト 6 mkcd のロケーション情報ファイル (). cfl) # Date : Thu Apr # Fi1e Location: # CD—ROM Creator Re1ease 1 . 2 . 1 —A—— 1993 ー 04 ー 05 14 : 26 : 21 + 36 READ . ME; 1 1993 ー 04 ー 05 14 : 26 : 21 + 36 READ . ME; 1 RO OT/SPARC : —D— 1993 ー 03 ー 09 19 : 18 : 27 十 36 . / [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] [ 0 : 0 ] ー > 0 ( 180 + 0 ) ー > 221 ( 181 + 0 ) cd 8 19 : 18 : 29 1993 Mode Fno lntlv #Start 16 17 18 19 20 21 22 23 24 25 26 167 168 173 174 179 180 181 182 End 16 17 18 19 20 21 22 23 24 25 166 167 172 173 178 179 180 181 182 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Path ー > V01umeDescriptor ー > V01umeDescriptor ー > PathTab1e(L) ー > PathTab1e (L) ー > PathTab1e (M) ー > PathTab1e (M) /COPYRIGHT. SUN ; 1 /COPYRIGHT. MAC ; 1 ー > /MAC ー > /MAC/DICTIONARYBROWSER. ; 1 ー > /MAC/DICTIONARYBROWSER. ; 1 ー > /MAC/DICTIONARY_OF_COMPUTER. ; 1 ー > /MAC/DICTIONARY_OF_COMPUTER. ; 1 /MAC/J_G_E_DICTIONARY. ; 1 /MAC/J_G_E_DICTIONARY. ; 1 /SPARC /MAC /READ. ME ; 1 /MAC/READ. ME ; 1 リスト 7 mkcd のキュー情報ファイル (). cfc) # Date : Thu Apr 8 19 : 18 : 29 1993 # Disc Cue Sheet : cd # CD-ROM Creator Re1ease 1 . 2 . 1 #Track 00 01 01 lndex 00 00 01 00 Time 00 : 00 : 00 00 : 00 : 00 00 : 02 : 00 13 : 25 : 45 Form CDROMI_O CDROMI_O CDROMI—I CDROMI_O Contr01 DATA DATA DATA DATA LBN 0 60270 #Disc Name : JAPANESE_GERMAN_ENGLISH—AND_COMP #Producer Name : NICHIGAI ASSOCIATES INCORPORATED リスト 8 mkcd のポリューム情報ファイル ( *. c ん ) #Creation Date : 19930309 #Copyright H01der Name : NICHIGAI ASSOCIATES INCORPORATED # Date : Thu Apr 8 19 : 18 : 29 1993 # Master Tape V01ume List : cd # CD-ROM Creator Re1ease 1 . 2 . 1 #Vo lume NO . 1 112 First Sector 00 : 02 : 00 Last Sector 13 : 25 : 44 Number of Sectors Mode 13 : 23 : 45 1 ←生成しています UNIX MAGAZINE 1993.8

連載 /UNIX Communication Notes リスト 3 NS レコード ル番号が用いられます。数字が大きいはど時間的に新しい バーでは、最新のゾーン情報を判断するのに、このシリア 最初刎直は、ファイルのシリアル番号です。ネームサー ータ取扱いの時間的な要素の言当です。 末尾の括弧で話られている部分は、ネームサーバーのデ ありません。 ます。もちろん postmaster や root を指定しても問題は ど、メールでトラブルをリポートするようなことにも使え かのドメインのネームサーバーでトラブルがあった場合な suguru@major ・ ac. jp を表しています。この情報は、ほ ク ) に読み換えてください。 suguru ・ major ・ ac ・ jp ・は maJ0r ・ ac ・ jp. IN NS giants ・ major ・ ac ・ JP ・ major ・ ac. JP. IN NS yankees ・ major ・ ac ・ JP ・ 1993061901 えば、ファイルを 1993 年 6 月 19 日に更新したならは、 ・ファイルを更新した日時をベースに番号を付ける。たと ・ 1 から順番に付けていく。 ものを表します。通常は、次のような付け方をします。 ゾーン情報のシリアルのほうが大きいとき、すなわちプラ リアルの値を上交します。プライマリ・ネームサ→ヾーの した間隔でプライマリ・ネームサーバーにアクセスしてシ ません。セカンダリ・ネームサーバーは、 refresh に指定 の情報を定期的にチェックして整合生を保たなければなり ンダリ・ネームサーバーは、プライマリ・ネームサーバー 提供する情報のコピーをイ尉寺しています。このため、セカ ンダリ・ネームサーバーはプライマリ・ネームサーバーが リ・ネームサーバーがゾーンの完全な情報を管理し、セカ バーではサーバーの多重イゞおこなわれており、プライマ 隔で、秒単位刎直です。前回説明したように、ネームサー バーカワ。ライマリ・ネームサーバーのデータを参照する間 2 番目の値は refresh と呼はれ、セカンダリ・ネームサー た時間も分かって便利です。 お勧めは日時をベースに付けるガ去で、データを変更し ルを更新することもあるので、そのためのフィールド 日の 1 回目の更新を意味します。 1 日に何回もファイ というように日時情報を付けます。最後の 01 は、その 60 リスト 4 A レコードの言己丕 localhost . maJor ・ ac ・」 p ・ tigers ・ maJ0r. ac ・ JP ・ giants ・ major ・ ac ・ JP ・ pirates . maJOr ・ ac ・ jp ・ IN IN IN IN A A A A 127.0.0. 1 192 . 9 .200. 10 192.9.200. 11 192.9.200.21 イマリ・ネームサーバーのほうか新しい場合には、ゾーン 情報をプライマリ・ネームサーバーから転送してきます。 リスト 2 の例では 10 , 800 秒、すなわち 3 時間を指定して います。 3 番目の値は retry と呼はれます。セカンダリ・ネー ムサーバーが、ゾーン情報を上交するためのプライマリ・ ネームサーバーへのアクセスに失敗した場合、再アクセス をおこなう間隔の指定で、秒単位です。リストの例では 3 , 600 秒、すなわち 1 時間を指定しています。セカンダ リ・ネームサーバーは、プライマリ・ネームサ→ヾーに正 常にアクセスできるまで retry の間隔で繰り返します。 4 番目の値は expire と呼ばれ、セカンダリ・ネーム サーバーがゾーン情報を廃棄する時間を指定しています。 セカンダリ・ネームサーバーはゾーン情報の上交のために プライマリ・ネームサーバーに定期的にアクセスしますが、 expire で指定した時間に達してもアクセスできなかった 場合には、セカンダリ・ネームサーバーはそのゾーン情 報を廃棄し、情是供をおこなわなくなります。例では 3 , 600 , 000 秒、すなわち 1 , 000 時間 ( 約 42 日間 ) を指 定しています。 最後の 5 番目の値は TTL (Time To Live) と呼ばれ、 はかのネームサーバーにキャッシュされた情報の有期間 を表します。前回説明したように、ネームサーバーは一度 問い合わせた情報はローカルにキャッシュし、その情報を 再利用します。この再利用を許す期間が TTL です。 NS レコード 次にネームサーバーを指定する NS レコードを記述しま す。リスト 3 を見てください。 この例では、ドメイン major ・ ac. jp. のネームサーバー として、 yankees. maJ0r ・ ac ・ JP ・、 giants. ma」0て . ac ・ jp ・を指定しています。ここに指定されたネームサーバ ーはこのゾーンに対して管理権限をもつネームサーバーと なります。 UNIX MAGAZINE 1993.8