パブリック、プライベート、静的、専用は独立したアドレスプロパティです。ルーティング、ファイアウォール、フォワードDNS、リバースDNS、TLSもカバーするデプロイマップを作成し、各設定をそれを制御する当事者と検証してください。
アドレスのプロパティは異なる問いに答える
パブリックとプライベートは、アドレスがどこにルーティングされることを意図しているかを表します。静的と動的は、割り当てが時間の経過とともにどのように動作するかを表します。専用と共有は、アドレスがサービス内でどのように使用または割り当てられるかを表します。これらは別々のプロパティです。安定したパブリックアドレスが多数のサイトにサービスを提供することがあり、プライベートアドレスが制御されたネットワーク内で動的に割り当てられることがあります。
デプロイにおける各アドレスの役割を記述してください。パブリックエントリポイント、内部データベース、管理ルート、アウトバウンド接続などです。次に、誰がそれを割り当て、何が変更できるかを特定してください。これにより、専用は永久に固定を意味する、パブリックはサービスが到達可能を意味するといった仮定に構成作業が依存するのを防ぎます。到達可能性はルーティング、ファイアウォール、アプリケーションのリスナーにも依存します。
プライベートアドレス指定でもルーティングとアクセス制御が必要
RFC 1918は、プライベートネットワーク用にIPv4範囲10.0.0.0/8、172.16.0.0/12、192.168.0.0/16を予約しています。それらのアドレスはグローバルに一意なパブリック宛先ではありません。ネットワークは、アウトバウンド接続のためにプライベートアドレスを変換したり、明示的なルートを通じてプライベートネットワークを接続したりする場合があります。変換の背後にあるインバウンドサービスには、意図的な公開方法が必要です。DNSレコードを変更するだけではそのルートは作成されません。
IPv6には、リンクローカルアドレス指定やグローバルにルーティング可能なユニキャストアドレスを含む、独自のアドレスタイプとスコープがあります。IPv4ファイアウォールや変換ルールがIPv6をカバーすると仮定せず、個別に確認してください。プライベートアドレスは認証メカニズムではなく、パブリックIPv6アドレスはすべてのサービスを公開する理由にはなりません。関連する各ネットワークからアクセスをテストし、適切な境界で管理を制限してください。
安定した名前と安定したアドレスは関連している
DHCPはプロトコルを通じてアドレス構成を割り当て、リースを使用できます。動的に割り当てられたアドレスはしばらく変更されない場合がありますが、その永続性が契約上の保証になるわけではありません。アプリケーションが安定したアドレスに依存する場合は、昨日の接続から推測するのではなく、プロバイダーの割り当てと変更ポリシーを確認してください。
動的DNSはアドレス変更後に名前を更新できますが、クライアントは以前の回答をキャッシュする場合があります。また、到達不能なリスナー、欠落したインバウンドルート、キャリアグレードのアドレス変換を克服することはできません。ネットワークが接続を許可し、アプリケーションが更新遅延を許容する場合に使用してください。ホスト型デプロイでは、許可リストや外部統合を構築する前に、意図したアドレスライフサイクルを文書化してください。
| プロパティ | 確認すべきこと | よくある誤った仮定 |
|---|---|---|
| パブリックまたはプライベート | ルーティングスコープとアクセス経路 | アドレスだけでサービスが到達可能になる |
| 静的または動的 | 割り当てと変更ポリシー | 変更されないリースは永続的である |
| 専用または共有 | 割り当てと許可される使用 | 専用アドレスが匿名のアイデンティティを提供する |
| IPv4またはIPv6 | ルーティングとファイアウォールの両方の構成 | 一方のプロトコルの設定が他方をカバーする |
フォワードDNSとリバースDNSは所有者が異なる
フォワードDNSは名前をAやAAAAアドレスレコードなどのデータにマッピングします。リバースDNSはアドレス関連の名前空間とPTRレコードを使用して、アドレスを名前に関連付けます。フォワードDNSゾーンを制御する組織が、アドレス範囲のリバースDNSを制御する組織と同じであるとは限りません。リバース名を約束する前に、正しい構成パスを入手してください。
適切なリゾルバを通じてレコードを確認し、結果を記録してください。ホストを識別することを意図したPTRの場合は、対応するフォワードレコードが期待されるアドレスを指しているかどうかも確認してください。リバースDNSは運用上の識別や一部のメールシステムチェックをサポートできますが、アプリケーションを認証したり、メッセージ配信を保証したりするものではありません。メール送信には、独自のドメイン、評判、認証のレビューも必要です。
すべてのHTTPSサイトに専用アドレスが必要なわけではない
HTTPホストルーティングとTLS Server Name Indication拡張により、サポートされているクライアントとサーバーは名前でサイトや証明書を選択できます。したがって、複数のHTTPSサイトが、ドメインごとに1つのパブリックアドレスを必要とせずに1つのアドレスを使用できます。その構成が適切かどうかは、実際のホスティング構成と必要なクライアントによって決まります。
追加アドレスは、サポートされているネットワーク分離や個別のエンドポイントを期待する外部システムなど、文書化された要件がある場合にのみ選択してください。アドレスは評判の問題に対する免疫を提供したり、サービスを運営する人物を識別したりするものではありません。証明書、ホスト名ルーティング、アドレス割り当てを別々のチェックとして扱ってください。ユーザーが実際に訪問するホスト名を通じて、提供される証明書を検証してください。
レコードを変更する前にデプロイマップを使用する
各ホスト名、アドレスレコード、リスナー、ファイアウォール経路、責任者を含む小さなマップを作成してください。管理、バックアップ、アウトバウンド許可リストも含めてください。SwissOctet構成に必要なアドレスオプションが記載されているか確認し、リバースDNS制御に依存する前にそれについて問い合わせてください。カタログオプションを、すでにプロビジョニングされた実際の割り当てとして提示しないでください。
移行中は、ユーザーをそこに誘導する前に、宛先アプリケーションとTLS設定を準備してください。DNSキャッシュを考慮し、実行可能なリカバリパスを維持してください。フォワード解決、実際のアプリケーション到達可能性、期待されるリバース名を別々に検証してください。マップがあると、誤ったレコード、閉じたポート、不一致の証明書はそれぞれ異なる問題であり所有者も異なるため、障害を特定しやすくなります。
実践チェックリスト。
- アドレスの役割、割り当て、所有権をマップする。
- IPv4とIPv6を別々に確認する。
- DNSに依存する前にインバウンドルーティングを検証する。
- 誰がPTRレコードを制御しているかを特定する。
- ホスト名、証明書、アプリケーションをまとめてテストする。
重要な詳細。
専用IPはサービスを匿名にしますか？+
いいえ。それは割り当てまたは使用の取り決めを表すものであり、アイデンティティやプライバシーの保証ではありません。アカウント、トラフィック、アプリケーションデータには別々の意味合いがあります。
自分のドメインのDNSパネルからPTRレコードを設定できますか？+
関連するリバースゾーンも制御している場合に限ります。通常、アドレスプロバイダーがそのゾーンを制御するか、別のリクエストプロセスを提供します。
各HTTPSドメインに独自のアドレスが必要ですか？+
必ずしも必要ではありません。サポートされているクライアントとサーバーは、名前ベースのルーティングとTLS SNIを使用できます。実際のホスティングとクライアントの要件を確認してください。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- RFC 1918: プライベートインターネットのためのアドレス割り当て www.rfc-editor.org
- RFC 2131: 動的ホスト構成プロトコル www.rfc-editor.org
- RFC 1035: DNSの実装と仕様 www.rfc-editor.org
- RFC 4291: IPv6アドレス指定アーキテクチャ www.rfc-editor.org
- RFC 6066: Server Name Indicationを含むTLS拡張 www.rfc-editor.org
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。