○このドキュメントは有効期限を過ぎており無効です
ネームサーバとその設定について（第1.7版）
｀８９年１０月３日
（最終更新：｀９１年１０月１日）
東京大学 理学部 情報科学科
高田広章
hiro@is.s.u-tokyo.ac.jp
注意： このドキュメントは，国内のネームサーバ立ち上げの初期に書かれた
ため，現在では実情にあわない点があることをご了承下さい．全面バージョン
アップをして下さるボランティアを歓迎します．
このドキュメントは，ネームサーバの設定を行なう際に必要となるテクニカ
ルな面を中心に解説したものである．ＩＰアドレスの取得方法，ドメイン名の
取得方法，国内のＩＰネットワークへの接続許可，インターネットへの接続許
可については，このドキュメントの範囲外である．
１．ネームサーバとは
ネームサーバとは，一般にホスト名からそのＩＰアドレスを検索するための
サーバのことを言う．ネームサーバの規格には何種類かあるが，以下ではイン
ターネットで使われている BIND（Berkeley Internet Name Domain Sever）に
ついて述べる．なお，BIND の詳細については参考文献を参照されたい．
BIND の特徴は，階層構造を持つドメイン名をサポートする分散データベー
ス構造をとっていることで，それぞれのドメイン内のアドレスの管理は，それ
ぞれのドメインの管理者が行なうことになる．
またネームサーバは，電子メイルの転送の際にも重要な役割を果たす．現在
JUNET で使われているメイルの配送ルールは，ドメインごとに転送先を静的に
記述するものであるが，このような方法は各ドメインのドメインマスターマシ
ンに大きな負担を強いることになる．ネームサーバを使ったメイルの転送では，
ネームサーバに問い合わせることにより目的マシンのアドレスを取りだし，そ
のマシンにダイレクトにメイルを転送するため，ドメインマスターの負担を軽
減し，保守作業を楽にすることができる．また，ＩＰで接続されていないドメ
インやマシンに対しても，メイルの中継マシンを指定する機能がある（MX レ
コード）．
インターネットにおけるメイルの転送は，すでにネームサーバを使ったもの
に移行しており，インターネットからダイレクトにメイルを受け取りたい場合
には，ネームサーバの正しい設定が不可欠になる．
２．サーバと resolver
一口にネームサーバの設定と言った場合に，その内容は，サーバ側の設定と
resolver 側（ないしはクライアント側）の設定に分かれる．
サーバ側の設定とは，自分のドメインのアドレスを内外に知らせるために，
ネームサーバ（unix では named または in.named）のための設定ファイルを
書き，ネームサーバを立ち上げ，そのネームサーバの存在を必要な範囲に知ら
せることである．このようなネームサーバをそのドメインの primary server
という．設定すべきファイルは，/etc/named.boot およびその中に記述される
ファイルである．また，primary server がダウンしている時に来る問い合わ
せに対応するため，authorized secondary server を立ち上げることも重要で
ある．
resolver とは，ネームサーバを呼び出してホスト名をＩＰアドレスに変換
するためのライブラリ群のことで，resolver 側の設定とは，自分のマシンか
らネームサーバを使うための設定の事を言う．設定すべきファイルは，
/etc/resolv.conf 等である．ホスト名からＩＰアドレスを得る必要がある各
アプリケーション（telnet，ftp，rlogin などなど）は，/etc/hosts を検索
する代わりに resolver を呼び出してＩＰアドレスを獲得することになるが，
このあたりのメカニズムはマシンによって大きく異なるため，自分のマシンが
どのようにネームサーバに対応しているか知る必要がある．
また，他のネームサーバに負担をかけないために，他で設定されたデータを
キャッシュするためのネームサーバ（プログラムとしては primary server と
同じ）を立ち上げる場合が多い．このようなサーバを，（unauthorized な）
secondary server ないしは caching server（この２つは動作が違う）という
が，この立ち上げ作業も，resolver 側の設定と考えた方が考え易い．１つの
ネームサーバが，あるドメインに対しては primary server として働き，他の
ドメインに対しては secondary server となることも可能である．
この２つの設定は独立のもので，片方だけ行なってもう片方は行なわない事
もありうる．
３．BIND の分散サーバの仕組み
BIND の分散ネームサーバの仕組みについて説明する．階層的なドメイン名
の意図は，各ドメイン内の設定は，各ドメインの管理者が行なうと言う事であ
る．すなわち，まずインターネット全体に１つ，ルートの primary server が
決められている．ルートの primary server は，各トップドメインのネームサー
バがどのマシンかを知っている．例えば，インターネットのルートの primary
server は，jp のネームサーバがどのマシンかを知っている．同様に jp のサー
バは *.jp（ac.jp，go.jp などなど）のサーバを知っており，ac.jp のサーバ
は，*.ac.jp（u-tokyo.ac.jp，keio.ac.jp などなど）を知っている．それを
検索する側のネームサーバは，最低限ルートのネームサーバのみ知っていれば，
そこから順にたどって任意のドメインに属するホストのアドレスを取り出せる
ことになる．
そのため，あるドメインの primary server の設定が終ったら，上位ドメイ
ンのネームサーバの管理者に連絡して，上位ドメインの設定内に，下位ドメイ
ンのネームサーバに関する記述を追加してもらう必要がある．
４．日本国内の事情
最近，日本国内でもＩＰリンクのある範囲が急速に拡大しており，またイン
ターネットとのＩＰリンクができたこともありネームサーバの設定の必要性が
高まってきた．
ところが，国内のネットワークでネームサーバを設定する際に重大な問題が
あることが指摘された．それは，以下のような問題が起こる事である．インター
ネットから見えるネームサーバに，インターネットから接続できないマシンが
はいっていた場合に，インターネットからのメイルはそのマシンに直接送られ
ようとするが，接続できないためメイルの送信ができなくなってしまう．かと
言って，インターネットからは接続できないが，国内では接続されているマシ
ンがネームサーバを使って検索できないのは不便である．
そこで，日本国内のＩＰネットワークを運営するにあたって，次のような方
法を用いてこの問題を解決することにした．すなわち，サーバ側の設定を行な
う際に，インターネットから見えるネームサーバと，国内から見えるネームサー
バとを別々に立ち上げることとし，前者のサーバには，国内的には接続されて
いるが，インターネットからは接続できないマシンを登録してはならないもの
とする（誤って登録した場合，メイルが届かなくなることがある）．もちろん，
この２つのサーバに登録されている内容が全く同じ場合（つまり，すべてのマ
シンにインターネットから接続できる時）には，１つのサーバで兼用できる．
また，インターネットから接続できるマシンを持たないドメインに対しては，
国内向けのサーバのみでよいことは言うまでもない．
つまり，インターネットから接続できるマシンのみを登録したネームサーバ
系列Ａと，国内で接続できるすべてのマシンを接続できるネームサーバ系列Ｂ
の２つの系列があることになる．ところが，前者のネームサーバからは国内の
マシンの一部が検索できず，後者のネームサーバからは海外のマシンが検索で
きないため，これに加えて，国内のマシンも国外のマシンも検索できる第３の
ネームサーバ系列Ｃが必要になる．このネームサーバの系列は，他の２つのサー
バ系列へ問い合わせに行くだけ（つまり，secondary server または caching
server）なのでサーバ側の設定は必要なく，ドメインの階層の意味で系列化さ
れているわけではない．
５．ネームサーバ系列の組織
４で述べた３つのネームサーバ系列を整備する必要があるわけだが，この際
に重要となるのは，実際にどのマシンがどの系列のサーバとなるかをはっきり
させることである．それぞれの系列のマシンは次のように使われる事になる．
系列Ａ 海外から見えるマシンを管理する．海外からのみアクセスされるため，
海外とのリンクがある所に置いた方が信頼性が上がり，トラフィック
も減らせる．なお，この系列に属するマシンは，自分の上で動いてい
るネームサーバを使わず，/etc/resolv.conf の設定により他のマシ
ンのネームサーバを呼ぶ事になる．
系列Ｂ 国内のＩＰネットワークに接続されているすべてのマシンを管理する．
国内の海外に接続できないマシンからアクセスされる．インターネッ
トとは無関係なので，国内からアクセスしやすい場所に置き，必要な
ら secondary server を立ち上げるのが良い．
系列Ｃ このサーバではマシンの管理は行なわない．国内の海外に接続できる
マシンからアクセスされる．海外のサーバへもアクセスするため，海
外リンクがあるところに置き，必要なら secondary server を立ち上
げるのが良い．
これらの事情を考えて，現在次の様に組織している．（* は primary server．
系列Ａ，Ｂのその他は，authorized secondary server）
系列Ｂ 系列Ｃ 系列Ａ
------------------------------------------------------------------------
root ccut.cc.u-tokyo(*) --- nic.ddn.mil.(*)
などなど
jp ccut.cc.u-tokyo(*) kogwy.cc.keio jp-gate.wide.ad.jp.(*)
utsun.s.u-tokyo ns.tisn.ad.jp.
*.jp ccut.cc.u-tokyo(*) kogwy.cc.u-tokyo jp-gate.wide.ad.jp.(*)
utsun.s.u-tokyo ns.tisn.ad.jp.
u-tokyo ccut.cc.u-tokyo(*) relay.cc.u-tokyo ns.tisn.ad.jp.(*)
utsun.s.u-tokyo jp-gate.wide.ad.jp.
前にも述べたように，系列Ｃの系列化は，他の２つの系列と意味あいが異なる．
各ドメインにネームサーバを立ち上げる際には，この表に，それぞれのドメイ
ンについての欄を追加していく事から始めることになる．
なお，ネームサーバの設定にあたっては，これらのマシンでの設定を参考に
するとよい．
逆引き用のサーバ（in-addr.arpa）に対しても同様の方法をとる．jp-gate
および ns.tisn は，海外に接続されたすべてネットワークの逆引き用の
secondary server となり，インターネットに対しては jp-gate および
ns.tisn をサーバとして登録する．ccut は，国内のネットワークのみを含ん
だ in-addr.arpa の primary server となる．系列Ｃのマシン（つまり，その
おおもとの kogwy および utsun）からは，インターネットの arpa ドメイン
の secondary server となり，かつ国内の in-addr.arpa ドメインの
secondary server となることで，インターネットに接続されているネットワー
クと，国内からのみ見えるネットワークの両方を検索できる．これは，インター
ネットのネームサーバにおいて，逆引きのアドレスが arpa ドメイン内に直接
記述されている事を利用している．
６．ネームサーバ設定の際の注意
ネームサーバ設定の際に，参考文献 [1][2] には書いてないが注意すべき点
を挙げる．
６．１ ANY について
参考文献の [1] には，ＩＰに限らない情報欄には ANY と書くようにあるが，
named は ANY に対応していない場合がある．すべて IN とするほうがよい．
６．２ MX レコードについて
MX レコードは，メイルの配送の際に重要となる設定である．ワイルドカー
ドを用いた MX レコードの書き方は，便利であるが使い方に注意が必要である．
それは，ワイルドカードで MX レコードが書いてあっても，そのもののアドレ
スの記述が別にあれば，ワイルドカードに対する MX レコードが使われなくな
ることである．例えば，
$ORIGIN is.s.u-tokyo.ac.jp.
* IN MX 5 spica.is.s.u-tokyo.ac.jp.
spica IN A 133.11.14.1
acrux IN A 133.11.14.5
とあると，acrux.is.s.u-tokyo.ac.jp 宛のメイルは spica ではなく，acrux
にダイレクトに送られる．これを変更したい場合には，
$ORIGIN is.s.u-tokyo.ac.jp.
* IN MX 5 spica.is.s.u-tokyo.ac.jp.
spica IN A 133.11.14.1
acrux IN A 133.11.14.5
IN MX 1 spica.is.s.u-tokyo.ac.jp.
というように，ワイルドカードを使わずに個別に MX レコードを指定する必要
がある．そのため，多くのマシンについて，アドレスは登録したいがメイルは
メイルサーバで受け取りたい場合や，ネームサーバには登録されているがＩＰ
接続できない場合には，マシンごとに MX レコードを書く必要がある．
６．３ メイルを受け取れないマシンについて
ネットワーク上にＩＰアドレスを持つのは，メイルを受け取れるマシンばか
りではない．例えば，端末サーバやＰＣは通常メイルを受け取る事はできない．
このようなマシンに対して，アドレスのみを設定しておくと，万一そのマシン
に対してメイルを送ろうとしたユーザがいた場合に，タイムアウトするまで
（３日とか７日とか）リトライしつづけることになる．
これを回避する１つの方法は，６．２に書いた方法でそのようなマシンに対
する MX レコードを，他のメイルが受け取れる適当なマシンに対して設定し，
そのマシンで適切に処置をすることである．適切な処置としては，そのマシン
でユーザ名を解釈してしまうか，エラーとして返送するかのどちらかとなろう．
前者のようにするには，メイルを受け取れないマシンの名前を，メイルを受け
取るマシンの別名であるかのように sendmail.cf を設定すればよい．
６．４ ドメインに対する MX レコードについて
ユーザ名＠ドメイン名でメイルを受け取りたい場合には，ドメインについて
の MX レコードを指定する必要がある．今までの JUNET のコンベンションに
あわせて，これを指定する方がよい．ドメインに対する MX レコードを指定す
る時は，@ を用いると良い．例えば，
$ORIGIN is.s.u-tokyo.ac.jp.
@ IN MX 0 spica.is.s.u-tokyo.ac.jp.
とすると，user@is.s.u-tokyo.ac.jp 宛のメイルは，spica に届く事になる．
その他のホスト名でないアドレスに対してメイルを受け取りたい場合にも同様
の方法が使える．ただし，sendmail.cf がそのアドレスを自分宛として解釈で
きる事が前提となる．
６．５ その他のレコードについて
HINFO レコードはコメントにすぎないので，設定するかどうかは各ドメイン
で決めてよい．WKS については，設定した方が安全である．その場合，今の段
階ではとりあえずは smtp だけ書いておけばよい（メイルを受け取り損なう心
配はなくなる）．MB，MR，MINFO の各レコードは，まだ実験中であまり使われ
ていない．
６．６ forwarders について
系列Ｃのネームサーバは，jp ドメインの secondary server となるのが望
ましい．そうでない場合は，forwarders の指定を自分より上位の系列Ｃのネー
ムサーバに対して指定し，slave 指定をする必要がある．ここで上位というの
は，系列Ｃのルートサーバ，すなわち kogwy.cc.keio.ac.jp または
utsun.s.u-tokyo.ac.jp に近いサーバをいう．また，上位のサーバがダウンし
ていた場合のために，forwarders に複数のサーバを指定する事が望ましい．
この場合，近いサーバの方を前に書くべきである．
このようにしないと，一度でもルートサーバに検索に行った際に，jp の
primary server として jp-gate.wide.ad.jp ないしは ns.tisn.ad.jp を教え
られてしまい，正しく国内のアドレスを取り出す事ができなくなるからである．
また，海外に対するネームサーバの検索を減らす効果もある．
６．７ authorized secondary server と unauthorized secondary server
ドキュメントには明確な記述がないが，secondary server には authorized
と unauthorized の２種類がある．authorized secondary server とは，
primary server の設定ファイル中および１つ上位のドメインの設定ファイル
中にその server に対する NS レコードが書かれているもので，primary
server の管理者の承認なしに立ち上げることはできない．authorized
secondary server は，primary server のダウンに備えて，少なくとも１つ用
意した方がよい．この場合に，authorized secondary server は，必ずしも自
ドメイン内に置く必要はない．
unauthorized secondary server はその他の secondary server で，自由に
立ち上げる事ができる．これはむしろ resolver 側の設定の一部と考えた方が
良い．
この２種類の server の最大の違いは，ホスト名等をルートの側から探す場
合に，もし primary server にアクセスできなければ authorized secondary
server にアクセスするのに対して，unauthorized secondary server は
/etc/named.boot ないしは /etc/resolv.conf の中で明示的にアドレスを指定
されない限り，使われることはないことである．
６．８ その他の注意
ネームサーバの設定ファイルの SOA レコード中の Serial フィールドは，
secondary server のデータの取り込みの際に重要な役割を果たしている．設
定データを更新するたびに，必ず値を増やす必要がある．
また，ネームサーバの設定ファイルを更新した場合には，ネームサーバを起
動しなおすか，HUP シグナルを送る必要がある．
ネームサーバの設定ファイル中のホスト名は，最後に "." がない限り，そ
のファイルのオリジンからの相対名である．MX レコードや PTR レコード等で
最後の "." を忘れないように注意する必要がある．ファイルのオリジンは，
$ORIGIN 指定で変更されない限り，/etc/named.boot から得られる．
NS または MX の記述は各設定ファイル中で完結していなければならないよ
うだ．これは系列Ａのネームサーバ（つまりインターネットのルートから検索
できるドメインのネームサーバ）の場合は *推奨* だが，系列Ｂのネームサー
バで系列Ａのサーバを兼ねていないもの場合は *必須* となるようだ（確かで
はない）．特に逆引きファイル中では忘れがちなので，注意が必要である．
多くのドメインの secondary server になる場合，ネームサーバプロセスは
思った以上にメモリを使うので注意が必要である．例えば，utsun のネームサー
バは，約 3MB のメモリを使っている．
６．９ ヒント
ネームサーバを設定した後で，nslookup を使ってデータをダンプさせてチェッ
クしたり，named の状態のダンプをチェックする事は，設定の間違いの発見に
役立つ場合が多い．secondary server のキャッシュファイルはチェックしや
すいので有用である．
７．ネームサーバの嘘つき問題
８．ネームサーバの配置の例
８．１ u-tokyo.ac.jp ドメインの場合
u-tokyo.ac.jp（東京大学）ドメイン内には，インターネットから接続でき
るマシンと接続できないマシンの両方がある．そのため，系列Ａと系列Ｂのネー
ムサーバの両方を別々に立ち上げる必要がある．また，トラフィックを減らし，
検索を効率良く行なうために，系列Ｃのネームサーバも立ち上げた方がよい．
実際には，５章の表に示した通り，系列Ａの primary server として
ns.tisn を，系列Ｂの primary server として ccut を用いる事とした．また，
系列Ｃの name server として relay を設定する．６．６に示したガイドライ
ンにより，relay は forwarders 宣言を用いて kogwy と utsun を指定する．
東大内のクライアントマシンの内，インターネットと接続可能なものは，ネー
ムサーバとして relay を用いる．ただし，１つの組織（学部，学科）内に多
くのクライアントマシンがある場合には，relay の負担を軽減するために，ロー
カルにネームサーバを持つ事が望ましい．このローカルなネームサーバは，必
要な（よくアクセスする）ドメインの unauthorized secondary server とな
り（全く secondary server にならなくても，ネームサーバはキャッシュを行
なうので，立ち上げる効果はある），forwarders として relay を指定する．
forwarders として kogwy または utsunを指定する事も可能であるが，トラフィッ
クを減らすために relay を最初に指定するのが望ましい．
一方，インターネットと接続不可能なものは，ネームサーバとして ccut を
用いる．この場合も，１つの組織内に多くのクライアントマシンがある場合に
は，ローカルにネームサーバを持つ事が望ましい．このローカルなネームサー
バは，必要な（よくアクセスする）ドメインの unauthorized secondary
server となり，forwarders として ccut を指定する．forwarders の指定は
オプションである．
８．２ s.u-tokyo.ac.jp ドメインの場合
s.u-tokyo.ac.jp（東京大学理学部）ドメイン内のマシンは，すべてインター
ネットから接続できる．そのため，系列Ａと系列Ｂのネームサーバの両方を別々
に立ち上げる必要はない．トラフィックを減らし，検索を効率良く行なうため
に，系列Ｃのネームサーバは必要となる．
実際には，系列Ａ，Ｂの primary server として ns.tisn を用いる事とし
た．また，系列Ｃの name server としては utsun が自ドメイン内にあるので，
それを用いる．
理学部内のクライアントマシンはネームサーバとして utsun を用いる．た
だし，１つの組織（学科）内に多くのクライアントマシンがある場合には，ロー
カルにネームサーバを持つ事が望ましい．このローカルなネームサーバは，必
要な（よくアクセスする）ドメインの unautorized secondary server となり，
forwarders として utsun を指定する．実際，いくつかの secondary server
が立ち上げられており，utsun のネームサーバへ直接アクセスするマシンを減
らすようにしている．
９．各マシン／ＯＳにおける resolver 対応
以下で named が新しいかどうかは，BIND4.8 以降でサポートされている
directory，forwarders，slave と言った機能があるかどうかを示す．なお，
BIND の最新版は BIND4.8.3 であり，BIND4.8 よりかなり改良されているので，
こちらを使うのが好ましい．
4.3BSD
1. named は新しいバージョンがリリースされている．
2. クライアントは，すべて BIND に対応している．ただし，ライブラリを作
る際にそのように設定する必要がある．
Sun OS 4.0
1. named は新しいバージョンが標準．BIND4.8.3 を若干の修正でコンパイル可
能．
2. ypserv が BIND に対応する．ただし，SunOS 4.0.1 の ypserv にはバグ
がある．パッチテープが出ている．4.0.3 では修正済み．また，共有ライ
ブラリ中の関係するライブラリを交換することによって対応させることも
可能である．
SunOS4.0 で ypserv がネームサーバを見るように設定する方法はマニュア
ルが不親切でわかりにくい．SunOS4.0 では，YP 用の関係する DBM ファイル
にネームサーバを参照するようにマークをつけることになる．具体的には，
/var/yp/Makefile の
| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byname; \
という行を
| $(MAKEDBM) -b - $(YPDBDIR)/$(DOM)/hosts.byname; \
に修正し，touch /etc/hosts; make することで，ホスト名前からアドレスを
取り出す際にネームサーバを参照するようになる．さらに，
| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/hosts.byaddr; \
という行にも -b をつけることで，逆引きの際にもネームサーバを見にいくこ
とになるが，セキュリティ上の問題があるためにこの設定は勧められない．
VAX (Ultrix 3.0)
1. named は新しいバージョンが標準．
2. クライアントは，BIND に対応している．/etc/svcorder により，yp，
bind，localをどういう順番で見にいくかが設定可能．
LUNA (UNIOS-B 1.20Beta)
1. named は古いバージョンが標準．
2. クライアントはすべて BIND に対応している．まず YP を見に行って，見
つからなかった場合のみ named を見に行く．
Apollo SR10
1. named は古いバージョンが標準．BIND4.8.2 をいくつかの修正でコンパイ
ル可能．
2. クライアントはすべて BIND に対応しているようだ．（resolv.conf があ
るかどうかではなく，ローカルに named がいるかどうかで named を呼ぶ
か決めているらしいが，詳細は不明．）
他のマシン／ＯＳについては未調査．
１０．配布
このドキュメントは，自由にコピー／配布／修正してよいものとする．ただ
し，内容の修正を行なった場合は，その旨記述しなければならない．また，著
作者の名前およびこの節の内容の改変／削除は禁止する．
また，このドキュメントの内容の不備等から生じた損害について，著作者は
何の責任も負わないものとする．
このドキュメントに間違いや不備などを発見された方は，連絡下されば幸い
です．また，内容に関するコメントも歓迎します．
１１．謝辞
このドキュメントの内容に有益なコメントを下さった村井純氏，尾上淳氏，
その他の皆様に感謝します．
参考文献
[1] Dunlap, K.J. and Karels, M. J., Name Server Operation Guide for
BIND (Release 4.8).
[2] manual page for NAMED(8), RESOLVER(3)(5), GETHOSTBYNAME(3).
[3] RFC974, MAIL ROUTING AND THE DOMAIN SYSTEM.
[4] RFC1032, DOMAIN ADMINISTRATORS GUIDE.
[5] RFC1033, DOMAIN ADMINISTRATORS OPERATIONS GUIDE.
[6] RFC1034, DOMAIN NAMES - CONCEPTS AND FACILITIES.
[7] RFC1035, DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION.
