メインコンテンツまでスキップ

6. SUPPORT SERVICES (サポートサービス)

このセクションでは、3つのカテゴリーのサポートサービスについて説明します:ドメイン名変換、ホスト初期化、リモート管理。

6.1 DOMAIN NAME TRANSLATION (ドメイン名変換)

6.1.1 Introduction (はじめに)

ドメインネームシステム (DNS) は、ホスト名をIPアドレスに変換し、その逆も行う分散データベースシステムです。DNSはインターネットの運用に不可欠です。

すべてのインターネットホストは、名前解決のためにDNSサーバーにクエリを行うDNSリゾルバを実装しなければなりません (MUST)。

6.1.2 Protocol Walk-Through (プロトコルの詳細)

DNSはクライアント-サーバーモデルで動作します:

  • リゾルバ: DNSサーバーにクエリを行うクライアント
  • ネームサーバー: DNSクエリに応答するサーバー

DNSメッセージ形式

DNSメッセージは以下で構成されます:

  • ヘッダー: クエリ/応答フラグとカウントを含む
  • 質問セクション: クエリを含む
  • 回答セクション: クエリに答えるリソースレコードを含む
  • 権威セクション: 権威サーバーのNSレコードを含む
  • 追加セクション: 追加の有用なレコードを含む

リソースレコードタイプ

一般的なDNSリソースレコード (RR) タイプには以下が含まれます:

  • A: IPv4アドレス
  • AAAA: IPv6アドレス
  • CNAME: 正規名 (エイリアス)
  • MX: メール交換機
  • NS: ネームサーバー
  • PTR: ポインター (逆引き)
  • SOA: 権威の開始
  • TXT: テキスト文字列

6.1.3 Specific Issues (個別の問題)

6.1.3.1 Resource Record Caching (リソースレコードキャッシング)

DNSリゾルバは、Time-To-Live (TTL) 値に従ってリソースレコードをキャッシュすべきです (SHOULD)。リゾルバはTTL値を尊重しなければなりません (MUST)。

6.1.3.2 Negative Caching (ネガティブキャッシング)

リゾルバは、存在しないドメイン名やリソースレコードに関する情報をキャッシュするネガティブキャッシングを実装すべきです (SHOULD)。

6.1.3.3 Multiple Addresses (複数アドレス)

DNSクエリが複数のアドレスを返す場合、最初の接続が失敗したらリゾルバはすべてのアドレスを試すべきです (SHOULD)。

6.1.3.4 CNAME Records (CNAMEレコード)

リゾルバは、実際のアドレスを取得するためにCNAMEチェーンをたどることで、CNAMEレコードを正しく処理しなければなりません (MUST)。

6.1.4 DNS Requirements Summary (DNS要件のまとめ)

機能セクションMUSTSHOULDMAY備考
DNSリゾルバの実装6.1.1
リソースレコードのキャッシュ6.1.3.1
TTL値の尊重6.1.3.1
ネガティブキャッシングの実装6.1.3.2
CNAMEレコードの処理6.1.3.4
複数アドレスの試行6.1.3.3

6.2 HOST INITIALIZATION (ホスト初期化)

6.2.1 Introduction (はじめに)

ホスト初期化とは、ホストが起動時に構成パラメータを取得するプロセスを指します。ホスト初期化の一般的なプロトコルには以下が含まれます:

  • BOOTP: ブートストラッププロトコル
  • DHCP: 動的ホスト構成プロトコル
  • RARP: リバースARP

6.2.2 Protocol Walk-Through (プロトコルの詳細)

BOOTP/DHCP

BOOTPとDHCPにより、ホストはサーバーからIPアドレス、サブネットマスク、デフォルトゲートウェイ、その他の構成パラメータを検出できます。

プロセスは通常以下を含みます:

  1. ディスカバリー: クライアントがディスカバリーメッセージをブロードキャスト
  2. オファー: サーバーが構成パラメータを提供
  3. リクエスト: クライアントが特定のパラメータを要求
  4. 確認応答: サーバーが構成を確認

6.2.3 Specific Issues (個別の問題)

6.2.3.1 Configuration Parameters (構成パラメータ)

ホスト初期化プロトコルは、少なくとも以下のパラメータを提供すべきです (SHOULD):

  • IPアドレス
  • サブネットマスク
  • デフォルトゲートウェイ
  • DNSサーバーアドレス

6.2.3.2 Lease Time (リース時間)

リースされたアドレスを使用するDHCPのようなプロトコルでは、クライアントはリース時間を守らなければならず (MUST)、期限切れ前にリースを更新しなければなりません。

6.2.4 Initialization Requirements Summary (初期化要件のまとめ)

機能セクションMUSTSHOULDMAY備考
BOOTP/DHCPのサポート6.2.1
基本構成パラメータの提供6.2.3.1
リース時間の遵守6.2.3.2

6.3 REMOTE MANAGEMENT (リモート管理)

6.3.1 Introduction (はじめに)

リモート管理プロトコルにより、ネットワーク管理者はインターネットホストをリモートで監視および管理できます。リモート管理の主要なプロトコルは:

  • SNMP: 簡易ネットワーク管理プロトコル

6.3.2 Protocol Walk-Through (プロトコルの詳細)

SNMPはマネージャー-エージェントモデルを使用します:

  • マネージャー: エージェントにクエリを行う管理ステーション
  • エージェント: 管理対象デバイス上で実行され、クエリに応答するソフトウェア

SNMP操作

  • GET: 管理変数の取得
  • GET-NEXT: 次の管理変数の取得
  • SET: 管理変数の変更
  • TRAP: エージェントからマネージャーへの非同期通知

管理情報ベース (MIB)

MIBは、管理情報の構造とセマンティクスを定義します。管理可能な各オブジェクトは、オブジェクト識別子 (OID) によって識別されます。

6.3.3 Specific Issues (個別の問題)

6.3.3.1 SNMP Implementation (SNMP実装)

ホストはSNMPエージェントを実装してもよいです (MAY)。実装される場合、エージェントは少なくともMIB-IIをサポートすべきです (SHOULD)。

6.3.3.2 Security (セキュリティ)

SNMP実装は、コミュニティベースのアクセス制御を実装すべきです (SHOULD)。SNMPv3の場合、実装は認証と暗号化をサポートすべきです (SHOULD)。

6.3.4 Management Requirements Summary (管理要件のまとめ)

機能セクションMUSTSHOULDMAY備考
SNMPエージェントの実装6.3.3.1
MIB-IIのサポート6.3.3.1
アクセス制御の実装6.3.3.2