ドメイン - みる会図書館

2.6.2 DNS の導入 DNS では、ホスト名をドメインの階層構造として構成します。ドメインは、サイトの集まりです。それらには、固有のネットワーク ( たとえば、キャンパス内のすべてのマシン、または、 BITNET の上のすべてのホストなど ) のドメインや、 ( アメリカ政府などのような ) 何らかの組織のドメイン、また地理的なドメインなどがあります。たとえば、大学は edu ドメインに分類されます。各大学では、その下をサプドメインに分けています。 Groucho Marx 大学には groucho.edu ドメインが割り当てられ、数学科の LAN には maths.groucho.edu が割り当てられます。学科のネットワーク上のホストは、ホスト名にドメイン名を付けて識別します。したがって、 er- dos は、 erdos.maths.groucho.edu となります。これは正式ドメイン名、または FQDN (Fully Qualified Domain Name) と呼ばれ、全世界で一意にこのホストが識別されます。図 2 ー 3 はドメイン名空間の一部分を示します。単一のドットによって示されるツリーのルートエントリーは、まさしくルートドメインと呼ばれ、ほかのすべてのドメインを含みます。ホスト名が何らかの ( 暗黙の ) ローカルドメインに属しているのでは名前の最後の要素がルートドメインであることを意味します。なく正式ドメイン名であることを示すためにドットを付けて書かれます。これは、 2.6 DNS(Domain Name System) ・ 37 ウンロードして、インストールしなければなりませんでした。しかし、インターネットが成長するにつれて、この方法のいくつかの問題が明らかになりました。 HOSTS. TXT を定期的にインストールするという管理の負荷だけでなく、それを配布するサーバの負荷が非常に大きくなったのです。さらに、すべての名前は NIC に登録されなければならず、また名前が重複して発行されないように管理する必要もありました。このため、 1984 年に新しい名前識別方法として DNS (Domain Name System: ドメインネームシステム ) が採用されました。上記の問題点をドメインはドメイン名階層構造での位置にしたがって、トップレベル、第 2 レベル、文献目録 [ 3 ] RFC 1033 RFC 1034 RFC 1035 解決する DNS は Paul Mockapetris 氏によって設計されました。 DNS については、 Paul Albitz 、 Cricket Liu 共著『 DNS and BIND ( 発行 / 発売 : アスキー ) 』で詳細に解説されています。 DNS を定義する RFC は 1033 、 1034 、および 1035 です。

2. LINUXネットワーク管理

2.6 米国政府機関。・ uucp DNS(Domain Name System) ・ 39 かって、公式に UUCP 名としてドメインなしで使用されていたすべてのサイトが、このドメインに移動されました。最初の 4 つは米国のインターネットに属しますが、米国以外のサイトの場合もあります注 6 。特に、 net ドメインは米国外のサイトをたくさん含んでいます。しかし、 mil と gov は米国のみで使用されます。米国以外の国では、一般に、 ISO ー 3166 で定められた 2 文字の国別コードをトップドメインとして使用します。たとえば、フィンランドは fi ドメイン、フランスは fr 、ドイツは de 、また、オーストラリアは au 、日本は jp などです。これらのトップレベルのドメインの下は、各国の NIC が、自由にホスト名を構成しています。たとえば、オーストラリアでは、 com.au 、 edu.au などのように、国際的なトップレベルドメインと似た 2 番目のレベルのドメインがあります。ドイツでは、この余分なレベルを使用せず、ドメインも含めて組織名を含む多少長めの名前を使用しています。たとえば、 ftp.informatik.uni-erlangen.de などといったホスト名は珍しくはありません。効率が重視されるドイツならではのものです。もちろん、これらの国名ドメインは、そのドメイン下のホストが実際にその国に存在しているかどうかには関係ありません。そのホストがその国の NIC に登録されていることを示すだけです。たとえば、スウェーデンの製造会社が、オーストラリアに支店を持っていても、全社のホストが se のトップレベルのドメインに登録されている場合もあるのです。ドメイン名の階層構造によってドメイン名空間を組織化すれば、名前が重複してしまうという問題を解決することができます。 DNS では、あるホスト名を全世界のすべてのホスト名と異なる名前にするには、そのドメイン内でユニークであればよいのです。しかも、正式名はとても覚えやすいはずです。これだけでも、大きなドメインをいくっかのサブドメインに分ける意義があります。注 6 カナダのトロント大学 (the university of Toronto) は、従来 edu ドメインの toronto.edu を使っていましたが、最近では utoronto. ca を使うのが一般的です ( 監注 ) 。

3. LINUXネットワーク管理

13.4 メール経路制御・ 265 い対処法は、 UUCP ネットワークの中でドメインネームシステムを採用することです。もちろん、 UUCP からネームサーバに照会することはできません。でも、多くの UUCP サイトは、内部的に経路制御を行う小さなドメインを作っています。マップの中で、これらのドメインは、 1 つか 2 つのホストだけをメールゲートウェイとして公表し、そのドメイン内の各ホストに対するマップエントリーは作りません。ゲートウェイは、そのドメインに出入りするすべてのメールを処理します。ドメイン内の経路制御方式は、外部からはまったく見えません。これは、上に述べたスマートホスト方式と非常に相性がよいのです。外部への経路情報は、ゲートウェイだけが維持します。ドメイン内のマイナーなホストでは、そのドメイン内部の経路とメールハプへの経路を記したほんの小さな paths ファイルだけ手作業で作っておけばすみます。メールゲートウェイも、世界中の UUCP サイトへの経路情報を持つ必要はありません。自分のデータベース内にある全ドメインへの経路さえ持てばいいのです。たとえば、次の pathalias 工ントリーは、ドメイン sub. org 内のサイト宛のすべてのメールを smurf に送ります。 .sub.org swim!smurf!%s claire@jones.sub.org 宛のメールは、 smurf!jones!claire というエンべロープアドレスを付けられて、 swim に送られます。ドメインネーム空間は階層構造になっているので、メールサーバは、より詳細な経路とあまり詳細でない経路を混在させられます。たとえば、フランス国内のあるシステムは、 fr ドメイン内のサブドメインに対しては詳細な経路を持っかもしれませんが、 us ドメイン内のホスト宛のメールは、米国内のどこかのシステムへ送ってしまいます。このようにして、ドメインべース経路制御にの手法の呼び名 ) は、経路制御データベースのサイズおよび必要な管理上のオーバーヘッドを大幅に減らします。しかし、 UUCP 環境の中でドメイン名を使用する主要な利点は、 RFC 822 に従えば、 UUCP ネットワークとインターネット間を簡単に橋渡しできるということです。今日では、多くの UUCP ドメインが、スマートホストの役目をしてくれるインターネットゲートウェイに接続されています。インターネットホストは Usenet マ、ゾプの代わりに DNS を使用しているので、インターネットを経由してメッセージを送る方が速く、経路情報もずっと信頼できます。 RFC 822

4. LINUXネットワーク管理

10.1 NIS に関する知識・ 181 てきました。 NIS には、 NIS を通してシステム設定データの一部を共有するすべてのホストの集合という、特有のネットワーク概念があります。それが NIS ドメインです。あいにく、 NIS ドメインは DNS で出てきたドメインとはまったく関係がありません。あいまいさを避けるために、本章ではどのタイプのドメインを意味しているのかを常に明記します。 NIS ドメインは、純粋に管理上の機能だけを持ちます。そのドメイン中の全マシン間のパスワードの共有を除いて、ユーザには意識されません。それゆえ、 NIS ドメインに与えられた名は管理者に対してだけ重要です。通常、ローカルネットワーク上にあるほかの NIS ドメイン名と異なれば、どのような名前でもかまいません。たとえば、バーチャル・プルーワリー社の管理者なら、プルーワリーとワイナリーにそれぞれ brewery と winery の 2 つの NIS ドメインを作るかもしれません。もう 1 つの非常に一般的な方法は、単純に DNS ドメイン名を NIS でも使用することです。あなたのホストに NIS ドメイン名を表示したり、セットするには、 domainname コマンドを使用します。引数なしで起動すると、現在の NIS ドメイン名が表示されます。ドメイン名をセットするには、スーパーユーザになって、次のように入力します。 # domainname NIS ドメインは、アプリケーションが照会する NIS サーバを決定づけます。たとえば、ワイナリーにあるホスト上のログインプログラムは、もちろんワイナリーの NIS サーバ ( もしいくつかあれば、その内の 1 つ ) にユーザのパスワード情報を照会しなければいけません。一方、プルーワリーにあるホスト上のアプリケーションは、プルーワリーのサーバに照会しなければいけません。こで 1 つ疑問なのは、クライアントが正しいサーバをどのようにしてみつけるかということです。もっとも簡単な解決法は、サーバの置かれたホストの名前を書いた設定ファイルを持っことです。しかしこの方法では、クライアントが混んでいる時には別のサーバ ( もちろん、同じドメイン内の ) を使うことができないので、柔軟性がありません。そのため、既存 NIS では、その NIS ドメイン内にある適当な NIS サーバを検出する ypbind と呼ばれる専用デーモンを使用します。 NIS 照会を行う前に、アプリケーションは、まず ypbind にどのサーバを使用すべきか聞きます。 ypbind は、ローカルな IP ネットワークにプロードキャストして、各サーバを調

5. LINUXネットワーク管理

266 ・ 13 章電子メールインターネットから到達できるようにするため、 UUCP べースのドメインは、通常それらに対する MX レコード ( 上記参照 ) をインターネットゲートウェイ上に公表しています。たとえば、 moria が orcnet.org というドメインに属しているとしましよう。このドメインのインターネットゲートウェイは gcc2.groucho.edu です。この場合、 moria はスマートホストとして gcc2 を使用するので、外部のドメイン宛のメールはすべて、インターネットを経由して配達されます。他方、 gcc2 は * . orcnet. org に関する MX レコードを公表し、サイト orcnet に送られてきたすべてのメールを moria に配達します。 * .orcnet.org の中のアスタリスクはワイルドカードで、ほかの関連レコードを持たない、そのドメイン中のすべてのホストを意味します。 UUCP だけのドメインは、こんな設定になっているものです。残る唯一の問題は、 UUCP 転送プログラムには完全なドメイン名 (FQDN) が扱えないという点です。ほとんどの UUCP は、最高 8 文字までのサイト名しか扱えないように設計されています。ドットのような非英数字の使用などまったく問題外な UUCP が圧倒的です。そのため、 RFC 822 に基づく名前と UUCP ホスト名との間で、何らかのマッピングを行う必要があります。このマッピングを行う方法は、メール処理プログラム ( メーラ ) によってまったく異なります。 FQDN を UUCP 名にマッピングする 1 つの一般的な方法は、 pathalias ファイルを使用することです。 ernie!bert!moria!%s moria.orcnet.org これは、完全なドメイン名で指定されたアドレスを純 UUCP スタイルのバンパス形式に変換します。このための専用ファイルを用意しているメーラもあります。たとえば、 sendmail では uucpxtable というファイルを使用します。 UUCP ネットワークからインターネットにメールを送るときには、逆の変換 ( ドメイン化と呼ばれている ) が必要な場合があります。メールの送信者が配送先アドレスに完全な正式ドメイン名を使用すれば、メッセージをスマートホストにフォワードするとき、エンべロープアドレスにそのドメイン名を残しておくことで、そのような手間は省けます。しかし、どのドメインにも属さない UUCP サイトも残っています。それらは通常、擬似ドメイン uucp を追加することによってドメイン化されます。 pathalias データベースは、 UUCP べースのネットワークでの主要な経路情報を供

6. LINUXネットワーク管理

40 ・ 2 章 TCP / 旧ネットワークの話 DNS では、さらにサブドメインを管理する権利を管理者に委ねることもできます。たとえば、 Groucho 計算センターの管理者が、各学科に対してサブドメインを作成するとします。 math サブドメインと physics サブドメインを例としましよう。物理学科のネットワークが大規摸で複雑で外部から管理できない場合 ( 物理学者というのは手に負えない場合が多いのですが ) 、 Groucho コンピュータ・センターの管理者は phYSiCS.groucho.edu ドメインを物理学科のネットワークの管理者に委ねることができます。管理者は、外部との干渉なしにすべてのホスト名を自由に使用でき、ネットワーク上の IP アドレスも自由にホストに割り当てることができます。このために、ドメイン名空間はドメインに基づいたゾーンに分けられます。ゾーンとドメインの微妙な違いに注意してください。ゾーン groucho.edu には、コンピュータセンターが直接管理するホスト名、たとえば数学科のホスト名などが含まれるだけですが、ドメイン groucho.edu には Groucho Marx 大学内のすべてのホスト名が含まれます。物理学科のホストは異なるゾーン、すなわち physics.groucho.edu に属します。図 2 ー 3 では、ゾーンの先頭ドメイン名には小さな丸が付けてあります。 2.6.3 DNS を使用した名前の検索一見したところ、このドメインとゾーンが名前の識別をひどく複雑なものにしているように思えます。では、ホストに対する名前の割り当てを中央で管理するものがないとすると、どのようにしてアプリケーションはそれらを認識するのでしようか。こでは、 DNS の実にユニークな機能について説明しましよう。たとえば、 erdos の IP アドレスを知りたいとします。 DNS は、 erdos 管理者に尋ねなさい、と指示するでしよう。実際、 DNS は巨大な分散データベースです。それは、あるドメインやドメインの集合に関する情報を提供するネームサーバによって実現されます。各ゾーンでは、少なくとも 2 つ、通常は 2 、 3 個のネームサーバがそれぞれのゾーンのホストに関する信頼できるすべての情報を持っています。 erdos の IP アドレスを得るには、 groucho.edu ゾーンのネームサーバに問い合わせ、必要なデータをサーバから返してもらいます。「行うは言うより難し」と思うでしよう。それでは、どのようにして Grouch0 Marx 大学のネームサーバにアクセスするのでしようか。アドレスを識別する神様があなた

7. LINUXネットワーク管理

1 10 ・ 6 章ネームサービスとリゾル / ヾの設定加えて参照し直し、今度は成功します。これはとてもありがたいのですが、数学科のドメインから出るとすぐに、完全な正式ドメイン名が必要になります。こはひとつ、物理学科のドメイン上のホストに対しても quark. physics のような省略名が欲しいところです。そこで、サーチリストの出番となります。サーチリストは、 search オプションを使用して指定できます。 search オプションは domain を一般化したようなものです。 domain 文はひとつのデフォルトドメインを指定しますが、 search 文では、デフォルトドメインのリストを指定し、参照が成功するまでリストのエントリが順次使用されていきます。このリストのエントリは、スペースかタブによって区切らなければいけません。 search と domain 文はどちらか一方しか使えず、どちらも 1 回しか指定できません。どちらのオプションも与えられないならば、リゾルバは、ローカルのホスト名から getdomainname ( 2 ) システムコールを使用してデフォルトドメインを推測します。ローカルのホスト名にドメイン部分がなければ、デフォルトドメインがルートドメインであるとみなされます。 resolv. conf に search 文を入れる場合、このリストにどのドメインを加えるかよく考えてください。 BIND-4.9 以前のリゾルバライプラリは、サーチリストがないときの中身は、デフォルトドメインと、ルートに対する親ドメインすべてでした。これはいささか問題でした。 DNS リクエストがまったく見当ちがいのネームサーバにたどりつくことがあったからです。あなたがバーチャル・プルーワリーにいて、 fOOt.groucho.edu にログインしたいとします。指が滑べって、 foot の代わりに f00 という存在しないホスト名をミス入力してしまいました。 GMU のネームサーバは、そのようなホストは知らないと言います。古いスタイルのサーチリストでは、リゾルバは名前に vbrew.com と com を追加したものを試み続けます。これは問題です。 groucho.edu/com は実在するドメイン名かもしれないからです。ひょっとするとネームサーバは、そのドメイン上で f00 をみつけてしまうかもしれません。その結果、 groucho.edu/com のホストが入ってしまいます。これは明らかに意図しなかったこ RFC 1535 とです。一部のアプリケーションにとって、このようなとんでもないホスト参照はセキュリ

8. LINUXネットワーク管理

14. 11 14.11 ホスト名の修飾ホスト名の修飾・ 295 送信者または受信者アドレスの中に指定された不完全なホスト名 ( つまり、ドメイン名のないもの ) を見つけなければならないことがあります。たとえば、 2 つのネットワーク間をゲートウェイしていて、一方が完全な正式ドメイン名を要求するような場合です。インターネットの UUCP リレーでは、無資格のホスト名は、デフォルトで uucp ドメインにマップされていなければいけません。これら以外のアドレス変更はあまり好ましくありません。 /usr/lib/smail/qualify は、どのホスト名にどのドメイン名を付加すべきかを smail に知らせるファイルです。 qualify ファイルの中のエントリーは、第一欄のホスト名とそれに続くドメイン名とからなります。ハッシュ記号 ( # ) で始まる行は、コメントと見なされます。各ェントリーは、リストの上から順番に検索されます。 qualify ファイルが存在しない場合、ホスト名修飾はまったく行われません。特別なホスト名 * は、任意のホスト名と一致します。これを使えば、該当しないすべてのホストをデフォルトのドメインにマップできます。 * は最後のエントリーとしてのみ使用しましよう。バーチャル・プルーワリー社の場合、すべてのホストは、送信者のアドレスで完全な正式ドメイン名を使用するよう設定されていました。不完全な受信者アドレスは、 uucp ドメインにあると見なされます。したがって、 qualify ファイルで必要なのは次のエントリーだけです。 # /usr/lib/smail/qualify, last changed Feb 12 , 1994 by janet IIIICP

9. LINUXネットワーク管理

10.6 NYS&f 吏用して NIS クライアントを設定する・ 187 domainname winery # yp. conf ー YP configuration for NYS library. しよう。トワーク上にあるホストの場合、ファイルの内容は非常に簡単で、次のようになるでそれには、 /etc/yp. conf 設定ファイルにサーバ名を設定します。ワイナリーのネッ server vbardolino 最初の文は、このホストが winery という NIS ドメインに属していることを宣言します。この行を省略すると、 NYS はあなたが doma ⅲ name コマンドを使ってシステムに割り当てたドメイン名を使用します。 server 文は、使用する NIS サーバを指定します。もちろん、 vbardolino に対応する IP アドレスが hosts ファイルの中になければいけません。あるいは、 server 文で数字の IP アドレス自体を使用してもかまいません。 server コマンドは、上記のような使い方をすると現在の NIS ドメインが何であろうとも、指定したサーバを使用するよう NYS に告げます。しかし、異なる NIS ドメインの間でマシンをしょっちゅう移動するなら、 yp. conf ファイルの中にいくつかのドメインに関する情報を入れておくとよいでしよう。 NIS ドメイン名を server 文に追加すれば、 yp. conf の中に種々の NIS ドメインに対するサーバの情報を持たせることができます。たとえば、ノートパソコンでは、上のサンプルファイルを次のように変更します。 # yp. conf ー YP configuration for NYS library. server vbardolino winery server vstout brewery これよって、プート時に domainname コマンドで望みの NIS ドメインを設定するだけで、 2 つのドメインのどちらでも、そのラップトップを使用することができます。この基本設定ファイルを作り、それを誰でも読み出せるようにしたあと、サーバに接続可能かどうかをチェックするために最初のテストを実行しましよう。 hosts. by- name のような、あなたのサーバが配布するマップをどれか選択して、 ypcat ユーティリティでそれを検索してみてください。 ypcat はほかのすべての NIS 管理ツール

10. LINUXネットワーク管理

6. 1 をコメントにします。以下のオプションが利用可能です。・ 0 て de てリゾルバライプラリ・ 107 これはどの順番でリゾルバサービスを試みるかを決定します。有効なオプションは、ネームサーバに問合せを行う bind 、 /etc/hosts を参照する hosts 、および NIS 参照のための nis です。それぞれ単独でも組み合わせても指定できます。行に書かれた順番で、それぞれのサービスが試みられます。・ multi オプションとして on または off をとります。これは、 /etc/hosts に書かれたホストが複数の IP アドレスを持てるかどうかを指定します。通常、複数の IP を持っことを「マルチホーム」といいます。このフラグは DNS や NIS の問い合わせには関係がありません。・れ 0SP00 { 前章で説明したように、 DNS を使えば、 in-addr. arpa ドメインを使用して IP アドレスに属するホスト名をみつけることができます。しかしネームサーバが誤ったホスト名を与える場合があり、これは、「スプーフ行為」 (spoofing) と呼ばれます。これに対する自衛策として、 IP アドレスが得られたホスト名と本当に対応するかどうかをチェックするようにリゾルバを設定できます。対応していなければ、ネームははねられて、エラーが返されます。この機能は、 nospoof を on に設定することによって有効となります。・ alert このオプションは引数として on または off をとります。オンにすると、 syslog 機能を利用してリゾルバがすべてのスプーフ行為に関連した記録をとるようになります。・ trim このオプションは引数としてドメイン名をとります。このドメイン名は、参照前にす。 trim オプションは複数書けるので、複数のローカルドメインのホストにも対処は、ローカルドメイン名が取り除かれ、 /etc/hosts の参照がうまくいくようにしまローカルドメイン名付きのホスト名参照でホスト名から取り除かれます。これは、ローカルドメインなしのホスト名を指定しておきたい hosts 工ントリーで使えます。