インスタンス接続

この項では、インスタンス接続の様々な側面について説明します。

仮想ネットワーク・インタフェース・カード(VNIC)

Private Cloud Applianceのコンピュート・ノードには、物理ネットワーク・インタフェース・カード(NIC)があります。いずれかのサーバーでコンピュート・インスタンスを作成して起動すると、ネットワーキング・サービスは、インスタンスがネットワーク経由で通信できるように、物理インタフェースの上にVNICが作成されるようにします。各インスタンスには、起動時に自動的に作成およびアタッチされるプライマリVNICがあります。プライマリVNICは、インスタンスの作成時に指定したサブネットに存在します。インスタンスから削除できません。

VNICを使用すると、インスタンスはVCNに接続でき、インスタンスがVCNの内外のエンドポイントとどのように通信するかを決定します。各VNICはVCN内のサブネット内にあり、次のアイテムが含まれます:

VNICが属するサブネットの1つのプライマリ・プライベートIPv4アドレス。
VNICが存在するサブネットのオプションのプライベートIPv4アドレスを最大31個。
任意で割り当てられる、各プライベートIPのオプションのパブリックIPv4アドレス。
各プライベートIPアドレスのDNSのオプションのホスト名。
MACアドレス。
VNICネットワーク・トラフィックでソース/宛先チェックを有効または無効にするフラグ。
1つ以上のネットワーク・セキュリティ・グループ(NSG)のオプション・メンバーシップ。
Oracleに割り当てられた識別子(OCID)。
選択および割り当てることができるオプションのわかりやすい名前。

セカンダリVNICは、起動後にインスタンスに追加できます。セカンダリVNICを使用できるようにするには、そのインスタンスOSも構成する必要があります。インスタンスのVNICの最大数はシェイプによって異なります。各セカンダリVNICは、プライマリVNICとは異なるサブネット(同じVCN内または別のセカンダリVNIC内)に存在できます。セカンダリVNICは、プライマリVNICと同じサブネットにあってもかまいません。ただし、同じサブネットCIDRブロックからインスタンスに複数のVNICをアタッチすると、特にLinuxインスタンスで非対称ルーティングが発生する可能性があります。

ノート:

同じサブネットの複数のIPアドレスを持つ構成で非対称ルーティングを回避するために、Oracleでは、1つのVNICに複数のプライベートIPアドレスを割り当てるか、ポリシーベースのルーティングを使用することをお薦めします。

トラフィックがセカンダリVNICを介してインスタンス上のサービスに送信され、サービスが応答した場合、返信パケットは自動的にそのVNIC IPアドレスをソースIPアドレスとして持ちます。その応答が同じインタフェースに戻り、正しいデフォルト・ゲートウェイを見つけるには、ポリシーベースのルーティングが必要です。

セカンダリVNICは常にインスタンスにアタッチする必要があり、移動できません。セカンダリVNICを作成するプロセスによって、インスタンスに自動的にアタッチされます。セカンダリVNICをデタッチするプロセスによって、自動的に削除されます。インスタンスを終了すると、自動的にデタッチされて削除されます。アタッチされたVNICの数に関係なく、インスタンス帯域幅は固定されます。インスタンスの特定のVNICに対して帯域幅制限を指定することはできません。

デフォルトでは、すべてのVNICがネットワーク・トラフィックに対してソース/宛先チェックを実行します。 VNICは、各ネットワーク・パケットのヘッダーにリストされているソースと宛先を確認します。 VNICが送信元または送信先でない場合、パケットは削除されます。 VNICがトラフィックを転送する必要がある場合 - たとえば、ネットワーク・アドレス変換(NAT)を実行する必要がある場合 - VNICでソース/宛先チェックを無効にする必要があります。

VNICはサブネット内に存在しますが、インスタンスにアタッチします。インスタンスへのVNICアタッチメントは、VNICまたはインスタンス自体とは別のオブジェクトです。 VNICとサブネットは常に同じコンパートメントに存在しますが、インスタンスへのVNICアタッチメントは常にインスタンス・コンパートメントに存在します。ネットワーク管理者がネットワークを管理し、他のユーザーがインスタンスを管理するアクセス制御シナリオを設定した場合、この区別はIAMポリシーに影響します。

VNICは、非常にアクティブなアプリケーションが他のアプリケーションの使用可能な帯域幅を受け入れられないレベルに減らさないように、レート制限されています。レート制限は、各インスタンスのVNICインタフェースに適用されます。

レートは、各インスタンス・シェイプに関連付けられた最大ネットワーク帯域幅未満の値に制限されます。一般に、帯域幅の制限は、シェイプが使用するVNICの最大数とともに増加しますが、最大帯域幅の保証はありません。

ユーザーは帯域幅制限を直接指定できません。レート制限はシステム機能です。各VNICに適用されるレートは、インスタンスの起動時にシェイプ・オプションに基づきます。

IPアドレス指定

インスタンスは通信にIPアドレスを使用します。各インスタンスには、少なくとも1つのプライベートIPアドレスがあり、オプションで1つ以上のパブリックIPアドレスがあります。プライベートIPアドレスを使用すると、インスタンスはVCN内の他のインスタンス、またはオンプレミス・ネットワーク内のホストと通信できます。パブリックIPアドレスを使用すると、インスタンスはPrivate Cloud Applianceネットワーク環境の外部のホストと通信できます。

テナンシ内の特定のタイプのリソースは、セキュアなアプライアンス・ネットワーク環境の外部から直接アクセスできるように設計されているため、自動的にパブリックIPアドレスが付きます。たとえば: NATゲートウェイ。他のタイプのリソースは、そのように構成した場合にのみ直接アクセス可能です。たとえば: VCN内の特定のインスタンス。直接パブリック接続では、VCNにインターネット・ゲートウェイがあり、パブリック・サブネットでルート表およびセキュリティ・リストが正しく構成されている必要があります。

プライマリおよびセカンダリIPアドレス

IPアドレスはネットワーク・インタフェースに割り当てられます。一部のネットワーク・モデルでは、これは「IPレイヤー」であり、他のモデルでは「レイヤー3」ですが、ネットワーク・インタフェースでは通信にIPアドレスが必要です。 IPパケットには、常に発信元IPアドレスと着信先IPアドレスが含まれます。ソースIPアドレスと宛先IPアドレスが同じIPサブネット上にある場合、パケット配信は直接行われます。発信元IPアドレスと着信先IPアドレスが異なるIPサブネット上にある場合、パケット配信は1つ以上のルーターまたはゲートウェイを介して行われます。

多くの場合、特に仮想クラウド環境では、ネットワーク・インタフェースに複数のIPアドレスが必要です。別名「エイリアス」とも呼ばれ、1つのIPアドレスを持つネットワーク・インタフェースには、実装によって決定される制限をすでにいくつか与えることができます。インタフェースの初期IPアドレスは、通常、プライマリIPインタフェース・アドレス(変更可能)であり、その他はすべてセカンダリIPインタフェース・アドレスになります。

セカンダリIPアドレスは、多くのネットワーク・シナリオで役立ちます。すべての階層化プロトコルでは、特定のレイヤー上で複数のプロセスを実行できます。 TCP/IPでは、IP層は、複数のTCP層プロセスと、TCP層の上で実行されるアプリケーションをサポートできます。他のモデルでは、これはレイヤー3が複数のレイヤー4以上をサポートできることを意味します。

仮想環境で非常に有用な利点は、独自のIPアドレスを必要とするアプリケーション(SSL証明書を使用するwebサイトなど)が、Webサイトをセカンダリ・アドレスにリンクすることで単一のIPプライマリ・アドレスを共有できることです。

セカンダリ・アドレスを使用すると、単一のネットワーク・インタフェースで、IP層の上で実行されているさまざまなアプリケーションへの複数の接続をサポートできます。インタフェースが複数のセカンダリIPアドレスの1つ宛てのパケットを受信するたびに、そのインタフェースに割り当てられたセカンダリIPアドレスのリストにパケットの宛先アドレスが一致するということは、「この内容は重要です。それをさらに処理する」。

その場合、すべてのセカンダリ・アドレス宛先パケットがインタフェースで処理されるときに、1つのIPアドレスがプライマリである必要があるのはなぜですか。パケットがIP層の上のアプリケーションからではなく、IP層自体のサービスから供給される場合、パケットは常にプライマリIPアドレスを使用します。たとえば、問題を報告したり、MTUやその他のパラメータでインタフェースの変更をルーターに通知したりするインタフェースでは、常にプライマリ・アドレスをパケット発信元アドレスとして使用します。

プライマリ・アドレスは、インタフェースの「安定」アドレスです。セカンダリ・アドレスは頻繁に出入りしますが、プライマリIPアドレスの変更は慎重に考慮する必要があります。

プライベートIP

ネットワーキング・サービスは、プライベートIPv4アドレスとDNSのオプションのホスト名で構成される、Oracleに割り当てられたOCIDで識別されるプライベートIPオブジェクトを定義します。各インスタンスは、起動時にプライマリ・プライベートIPオブジェクトを受け取ります。 Networkingサービスは、DHCPを使用してプライベートIPアドレスを割り当てます。このアドレスはインスタンスの存続期間中に変更されず、インスタンスから削除できません。プライベートIPオブジェクトは、インスタンスの終了時に終了します。

インスタンスにセカンダリVNICがアタッチされている場合、それらの各VNICにもプライマリ・プライベートIPがあります。プライベートIPには、任意の時点でパブリックIPを割り当てることができます。プライベートIPをVCN内のルート・ルールのターゲットとして使用することはサポートされていません。

セカンダリ・プライベートIPについて

インスタンスの起動後、そのVNICのいずれかに「セカンダリ・プライベートIP」を追加できます。インスタンスのプライマリVNICまたはセカンダリVNICに追加できます。セカンダリ・プライベートIPアドレスは、VNICが属するサブネット内にある必要があります。両方のVNICが同じサブネットに属している場合、セカンダリ・プライベートIPをあるインスタンスのVNICから別のインスタンスのVNICに移動できます。

セカンダリ・プライベートIPの一般的なユースケースは次のとおりです:

インスタンス・フェイルオーバー: セカンダリ・プライベートIPをインスタンスに割り当てます。インスタンスに問題が発生した場合は、そのセカンダリ・プライベートIPを同じサブネット内のスタンバイ・インスタンスに簡単に再割当てできます。また、セカンダリ・プライベートIPにパブリックIPが関連付けられている場合、そのパブリックIPはプライベートIPとともに移動します。
単一インスタンスでの複数のサービスまたはエンドポイントの実行: たとえば、複数のコンテナ・ポッドを実行するインスタンスがあり、各ポッドはVCN CIDRから独自のIPアドレスを使用します。コンテナは、VCN内の他のインスタンスおよびサービスに直接接続します。別の例: それぞれ独自のIPアドレスを使用して複数のSSL webサーバーを実行できます。

セカンダリ・プライベートIPアドレスには次のプロパティがあります:

これらは、すべてのシェイプおよびOSタイプでサポートされています。
割当てできるのは、インスタンスが起動されるか、セカンダリVNICが作成されてアタッチされた後のみです。
これらは、インスタンスを終了するか、セカンダリVNICをデタッチおよび削除すると自動的に削除されます。
VNICからセカンダリ・プライベートIPを削除すると、そのアドレスがサブネット内の使用可能なアドレスのプールに返されます。
VNICは、最大31個のセカンダリ・プライベートIPを保持できます。
アタッチされているプライベートIPアドレスの数に関係なく、インスタンスの帯域幅は固定されます。インスタンスの特定のIPアドレスの帯域幅制限は指定できません。
セカンダリ・プライベートIPには、予約済パブリックIPを任意に関連付けることができます。

ノート:

セカンダリ・プライベートIPをVNICに割り当てた後、それを使用するようにインスタンスOSを構成する必要があります。 LinuxおよびMicrosoft Windowsの手順については、「Oracle Private Cloud Applianceユーザーズ・ガイド」を参照してください。

パブリックIP

プライベート・クラウド・モデルでは、パブリックIPアドレスは、事実上一意でパブリックにルーティング可能なインターネットIPではなく、クラウド環境のVCN外部のアドレスです。アプライアンスの初期設定時に、オンプレミス・ネットワークからのアドレスのプールは、パブリックIPとして使用するために予約されています。システムを使用するには、これらのパブリックIPの小さいセットが必要です。

パブリックIPアドレスをインスタンスに割り当てて、外部通信を有効にできます。インスタンスには、アドレス・プールからパブリックIPアドレスが割り当てられます。技術的には、割当てはインスタンスのプライベートIPオブジェクトであり、プライベートIPが割り当てられているVNICはパブリック・サブネットに存在する必要があります。特定のインスタンスに複数のセカンダリVNICを含めることができます。各VNICは(プライマリ)プライベートIPを持ちます。したがって、特定のインスタンスをVNIC全体で複数のパブリックIPに割り当てることができます。

ネットワーキング・サービスは、Oracle(割り当てられたOCID)によって識別されるパブリックIPオブジェクトを定義します。これは、プライベートIPv4アドレスと、パブリックIPのタイプと動作をさらに定義する追加のプロパティで構成されます。パブリックIPには2つのタイプがあります:

「エフェメラル」パブリックIPは一時的であり、インスタンスの存続期間中に存在します。
「予約済」パブリックIPは、割り当てられているインスタンスの存続期間を超えて永続的に存在します。割当てを解除し、別のインスタンスに再割当てできます。

次の表は、両方のタイプの違いをまとめたものです:

特性	エフェメラル・パブリックIP	予約済パブリックIP
許可された割当	VNICプライマリ・プライベートIP 制限: VNICごとに1つ、インスタンスごとに2つ	VNICプライマリ・プライベートIP 制限: VNICごとに1つ
作成	オプションで、インスタンスの起動時またはセカンダリVNICの作成時に作成および割り当てられます。 VNICがまだ存在しない場合は、後から作成して割り当てることができます。	いつでも作成します。必要に応じて割り当てることができます。
未割当	いつでも割当て解除でき、それによって削除されます。これは、インスタンスを起動したユーザーがパブリックIPを含んでいたが、インスタンスにパブリックIPが含まれないようにする場合に実行できます。インスタンスを停止しても、その一時的パブリックIPはインスタンスに割り当てられたままになります。	いつでも割当て解除できます。これにより、予約済パブリックIPのテナンシ・プールに返されます。
別のリソースへの移動	エフェメラル・パブリックIPを別のプライベートIPに移動することはできません。	割当て解除してから別のプライベートIPに再割当てすることで、いつでも移動できます。別のVCNまたはアベイラビリティ・ドメイン内に存在できます。
自動削除	その存続期間はプライベートIPの存続期間に関連付けられています。次の場合に自動的に割当て解除および削除されます: プライベートIPが削除されますそのVNICはデタッチまたは終了インスタンスの終了	Never 削除するまで存在します。
有効範囲	可用性ドメイン	リージョン(リージョン内のどの可用性ドメインでもプライベートIPに割り当てることができます)
コンパートメントおよび可用性ドメイン	プライベートIPと同じ	プライベートIPとは異なる場合があります

パブリック・サブネットでインスタンスを起動すると、特に指定しないかぎり、インスタンスはデフォルトでパブリックIPを取得します。特定のパブリックIPを作成した後は、そのタイプを変更できません。たとえば、アドレス203.0.113.2のエフェメラル・パブリックIPが割り当てられているインスタンスを起動した場合、エフェメラル・パブリックIPをアドレス203.0.113.2の予約済パブリックIPに変換できません。

直接公開されるように設計されたリソースは、作成時にプールから割り当てられたパブリックIPアドレスを自動的に取得します。 NATゲートウェイの場合、割り当てられたアドレスはリージョナル・エフェメラル・パブリックIPです。他のエフェメラル・パブリックIPと同様に、割り当てられたリソースを終了すると、自動的に割当て解除されて削除されます。ただし、他のエフェメラル・パブリックIPとは異なり、自分で編集したり、割当て解除することはできません。

DHCPオプション

Networkingサービスは、DHCPを使用して、起動時にインスタンスに構成情報を自動的に提供します。 DHCPでは一部の設定を動的に変更できますが、その他の設定は静的であり、変更されることはありません。たとえば、インスタンスを起動するときに、インスタンスのプライベートIPアドレスを指定するか、システムによって選択されます。インスタンスが起動するか、インスタンスDHCPクライアントを再起動するたびに、DHCPは同じプライベートIPアドレスをインスタンスに渡します。インスタンスの存続期間中にアドレスが変更されることはありません。

ネットワーキング・サービスには、VCN内のインスタンス上で特定タイプの構成を制御できるDHCPオプションが用意されています。これらのオプションの値は自由に変更できます。また、その変更は、次に特定のインスタンスDHCPクライアントを再起動したり、インスタンスを再起動したときに有効になります。

1つのVCN内の各サブネットは、それに関連付けられた単一のDHCPオプションのセットを保有できます。そのオプションのセットは、サブネット内のすべてのインスタンスに適用されます。各VCNには、初期値を変更できるDHCPオプションのデフォルト・セットが付属しています。異なるDHCPオプションのセットを作成して割り当てる場合を除き、すべてのサブネットはVCNデフォルト・セットを使用します。

構成できるDHCPオプションは、次のとおりです:

ドメイン・ネーム・サーバー

デフォルト設定はDNSタイプ= Internet and VCN Resolverです。

かわりに、DNSタイプにCustom Resolverを設定した場合は、最大3つのDNSサーバーを選択できます。
検索ドメイン

DNSラベルを使用してVCNを設定する場合、「ドメインの検索」オプションのデフォルト値はVCNドメイン名です: <VCN_DNS_label>.oraclevcn.com。それ以外の場合は、DHCPオプションのデフォルト・セットに「ドメインの検索」オプションが存在しません。

通常、DHCPオプションのセットが最初に作成されるとき - デフォルト・セットまたはカスタム・セット -これらのすべてがtrueの場合、ネットワーキング・サービスによって自動的に「ドメインの検索」オプションが追加され、VCNドメイン名(<VCN_DNS_label>.oraclevcn.com)に設定されます:
- VCNにはDNSラベルがあります。
- DNSタイプ= Internet and VCN Resolver。
- DHCPオプションのセットの作成時に、選択した検索ドメインを指定しませんでした。
DHCPオプションのセットを作成したら、常に「ドメインの検索」オプションを削除するか、別の値に設定できます。 DHCPオプションのセットには、1つの検索ドメインのみを指定できます。

インスタンスとDHCPオプションに関する重要なノート:

DHCPオプションのいずれかの値を変更した場合は常に、インスタンスでDHCPクライアントを再起動するか、インスタンスを再起動して変更を有効にする必要があります。これは、そのDHCPオプションのセットに関連付けられたサブネット内の既存のすべてのインスタンスに適用されます。
常にインスタンスにアクセスできるように、DHCPクライアントを実行したままにします。 DHCPクライアントを手動で停止するか、NetworkManagerを無効にすると、インスタンスはDHCPリースを更新できず、リースが期限切れになるとアクセスできなくなります(通常は24時間以内)。別のメソッドを使用してリースの更新を保証しないかぎり、NetworkManagerを無効にしないでください。
DHCPクライアントを停止すると、リースの期限が切れたときにホスト・ルート表が削除される可能性があります。また、iSCSI接続へのネットワーク接続が失われると、ブート・ドライブが失われる可能性があります。
/etc/resolv.confファイルに加えた変更は、DHCPリースの更新時またはインスタンスの再起動時に上書きされます。
/etc/hostsファイルに加えた変更は、DHCPリースの更新時またはインスタンスの再起動時に上書きされます。 Oracle LinuxまたはCentOSインスタンスの/etc/hostsファイルへの変更を永続化するには、次の行を/etc/oci-hostname.confに追加: PRESERVE_HOSTINFO=2。 /etc/oci-hostname.confファイルが存在しない場合は作成します。

名前解決

ドメイン・ネーム・システム(DNS)は、人間が読めることのできるドメイン名をマシン読取り可能なIPアドレスに変換します。たとえば、ブラウザにドメイン名を入力すると、そのドメインの認可ネーム・サーバーが見つかるまで、オペレーティング・システムは複数のDNSネーム・サーバーを問い合せます。認可ネーム・サーバーは、IPアドレスまたはその他のリクエストされたレコード・データで応答します。回答はブラウザにリレーされ、DNSレコードはwebページに解決されます。

VCN内でのDNSの名前解決には、2つのオプションがあります。 DHCPオプションのサブネット・セットを使用して、VCN内の各サブネットのオプションを選択します。

デフォルトの選択肢は、「インターネットおよびVCNリゾルバ」 (Oracle提供のソリューション)です。 2つの部分で構成されます: インターネット・リゾルバおよびVCNリゾルバ。インターネット・リゾルバを使用すると、インスタンスはインターネット上でパブリックに公開されているホスト名を解決でき、インターネット・ゲートウェイまたはオンプレミス・ネットワークへの接続を介してインターネットにアクセスする必要はありません。 VCNリゾルバを使用すると、インスタンスは同じVCN内の他のインスタンスのホスト名(割り当てることができる)を解決できます。

または、「カスタム・リゾルバ」を使用することもできます。名前解決に最大3つのDNSサーバーを使用できます。これらは、インターネット、VCN内、またはDRGを介してVCNに接続されているオンプレミス・ネットワークで使用可能なDNSサーバーです。

ドメインおよびホスト名

VCNおよびサブネットを作成する際、それぞれにDNSラベルを指定できます。サブネットDNSラベルを設定できるのは、VCN自体がDNSラベルで作成されている場合のみです。ラベルは、oraclevcn.comの親ドメインとともにVCNドメイン名とサブネット・ドメイン名を形成します。次に、インスタンスを起動するときに、ホスト名を割り当てることができます。インスタンスの起動時に自動的に作成されるプライマリVNICに割り当てられます。ホスト名は、サブネット・ドメイン名とともに、インスタンスの完全修飾ドメイン名(FQDN)を形成します。

VCNドメイン名: <VCN_DNS_label>.oraclevcn.com
サブネット・ドメイン名: <subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com
インスタンスFQDN: <host_name>.<subnet_DNS_label>.<VCN_DNS_label>.oraclevcn.com

FQDNはインスタンスのプライベートIPアドレスに解決されます。インターネットおよびVCNリゾルバは、プライベートIPアドレスに対応するホスト名を決定できる逆引きDNS参照も有効にします。

セカンダリVNICをインスタンスに追加する場合、ホスト名を指定できます。その結果、FQDNはVNICのプライマリ・プライベートIPアドレスに解決されます。その結果、FQDNはそのプライベートIPアドレスに解決されます。

DNSラベルとホスト名は、次の要件を満たしている必要があります:

VCNおよびサブネットのラベルは文字で始まり、最大15文字の英数字である必要があります。ハイフンとアンダースコアは使用できません。この値は後で変更できません。
ホスト名の長さは最大63文字であり、RFCの952および1123に準拠している必要があります。この値は後で変更できます。
VCN DNSラベルは、テナンシ内のVCN全体で一意である必要があります。サブネットDNSラベルはVCN内で一意である必要があり、ホスト名はサブネット内で一意である必要があります。

ホスト名の検証と生成

VCNおよびサブネットにDNSラベルを設定すると、インスタンス起動時にホスト名がコンプライアンスに対して検証されます。ホスト名を指定しない場合は、インスタンスの表示名が使用されます。表示名が検証に合格しない場合、または指定しなかった場合は、DNS準拠のホスト名が生成されます。生成されたホスト名は、インスタンスの詳細ページの「コンピュートWeb UI」に表示されます。

CLIまたはSDKを使用してインスタンスを起動し、ホスト名または表示名を指定していない場合、システムではそれらが生成されません。つまり、インターネットおよびVCNリゾルバを使用してインスタンスは解決できません。

セカンダリVNICをインスタンスに追加しても、ホスト名は生成されません。インターネットおよびVCNリゾルバを使用してプライベートIPアドレスを解決可能にする場合は、有効なホスト名を指定する必要があります。

パブリックDNSゾーン

VCN内にデプロイされたインスタンスのDNS名前解決を有効にするには、アプライアンス・ネットワーク環境の外部から、Private Cloud ApplianceによってパブリックDNSゾーンの構成サポートが提供されます。テナンシ内で、DNSゾーンまたはDNSネームスペースのセクションを作成する場合は、「コンピュートWeb UI」を使用して管理します。アプライアンスのエッジ・ネットワークは、対象となるドメインのすべてのDNS問合せを処理します。

DNSゾーンの作成時に、管理するドメインの名前を指定 - たとえば: example.com。ゾーンがプライマリかセカンダリかを選択します。プライマリ・ゾーンには独自のDNSレコードが含まれ、セカンダリ・ゾーンは別のゾーンからレコードを取得します。外部ゾーン・レコードにアクセスするには、セカンダリ・ゾーンに外部ゾーン用のサーバーIPアドレスが少なくとも1つ必要です。さらに、TSIG (トランザクション・シグネチャ)キーが必要になる場合があります。 TSIGキーは、セカンダリDNSゾーンの認証に使用される共有シークレットです。これらのキーは、選択したコンパートメントに格納できます。

作成する各DNSゾーンには、次の2つの重要なレコードが自動的に含まれます:

SOA (Start of Authority)レコードは、DNSゾーンに関する認可情報を指定します。この情報には、プライマリ・ネーム・サーバー、ドメイン管理者の電子メール・アドレス、ドメイン・シリアル番号、およびゾーンのリフレッシュに関連する複数のタイマーが含まれます。 SOAレコードの詳細は、RFC 1035を参照してください。
NS (ネーム・サーバー)レコードには、ゾーンの認可ネーム・サーバーがリストされます。 NSレコードの詳細は、RFC 1035を参照してください。

DNSゾーンを構成するには、リソース・レコードの形式で特定のドメイン情報を追加します。たとえば、アドレス・レコードを使用して、ドメイン名をVCNのパブリック・サブネット内のインスタンスのパブリックIPアドレスに解決します。 Private Cloud ApplianceのパブリックDNSゾーンでは、次の表で説明するリソース・レコード・タイプがサポートされます。

リソース・レコード・タイプ	説明
A	ホスト名をIPv4アドレスに指定するために使用されるアドレス・レコード。 Aレコードの詳細は、RFC 1035を参照してください。
AAAA	使用されるアドレス・レコードは、IPv6アドレスのホスト名をポイントします。 AAAAレコードの詳細は、RFC 3596を参照してください。
ALIAS	ゾーンのapexでCNAME機能を許可するプライベート疑似レコード。
CAA	認証局認可レコードを使用すると、ドメイン名保持者は、そのドメインの証明書を発行する権限を持つ1つ以上の認証当局を指定できます。 CAAレコードの詳細は、RFC 6844を参照してください。
CDNSKEY	子DNSKEYは、CDNSSECキーを子ゾーンから親ゾーンに移動します。このレコードに指定された情報は、他のDNSプロバイダのドメインのCDNSKEY情報と一致する必要があります。このレコードは、Private Cloud Appliance DNSのプライマリ・ゾーンでDNSSECを有効にすると自動的に作成されます。 CDNSKEYの詳細は、RFC 7344を参照してください。
CDS	子委任署名者レコードは、親ゾーンに転送するためのDSレコードの子コピーです。 CDSレコードの詳細は、RFC 7344を参照してください。
CERT	証明書レコードは、公開キー証明書および関連する証明書失効リストをDNSに格納します。 CERTレコードの詳細は、RFC 2538およびRFC 4398を参照してください。
CNAME	標準名レコードは、ドメインの正規名を識別します。 CNAMEレコードの詳細は、RFC 1035を参照してください。
CSYNC	子と親の同期レコードは、子ゾーンから親ゾーンにレコードを同期します。 CNAMEレコードの詳細は、RFC 7477を参照してください。
DHCID	DHCP識別子レコードを使用すると、DHCPクライアント識別子をDNSに格納して、ゾーン内のホスト名競合の可能性を排除できます。 DHCIDの詳細は、RFC 4701を参照してください。
DKIM	ドメイン・キー識別メールは、ドメインに対する到着メールの認証に使用される公開キーを提供するために特別に設定された特別なTXTレコードです。 DKIMレコードの詳細は、RFC 6376を参照してください。
DNAME	委任名レコードはCNAMEレコードと類似した動作ですが、ラベルの下のサブツリー全体を別のドメインにマップできます。 DNAMEレコードの詳細は、RFC 6672を参照してください。
DNSKEY	DNSキー・レコードは、DNSSECに使用される公開キーをドキュメント化します。このレコードの情報は、他のDNSプロバイダのドメインのDNSKEY情報と一致する必要があります。 DNSKEYレコードの詳細は、RFC 4034を参照してください。
DS	委任署名者レコードは最上位ドメインに存在し、子ゾーンDNSKEYレコードを指しています。 DSレコードは、DNSSECセキュリティ認証がゾーンに追加されたときに作成されます。 DSレコードの詳細は、RFC 4034を参照してください。
IPSECKEY	IPSecキー・レコードには、IPセキュリティ(IPSec)システムに接続するためのホスト、ネットワークまたはアプリケーションの公開キーが格納されます。 IPSECKEYレコードの詳細は、RFC 4025を参照してください。
KEY	キー・レコードには、ドメイン名に関連付けられている公開キーが格納されます。現在、SIGおよびTKEYレコードでのみ使用されます。 IPSECKEYおよびDNSKEYは、それぞれIPSecおよびDNSSECで使用するためのキーに置き換えられました。 KEYレコードの詳細は、RFC 4025を参照してください。
KX	キー・エクスチェンジャ・レコードは、一部の暗号化システム(DNSSECを含まない)に関連付けられたドメイン名に対するキー管理エージェントを識別します。 KXレコードの詳細は、RFC 2230を参照してください。
LOC	ロケーション・レコードには、DNS内のコンピュータ、サブネットおよびネットワークの地理的なロケーション・データが格納されます。 LOCレコードの詳細は、RFC 1876を参照してください。
MX	メール交換レコードは、ドメインのメールを受け入れるメール・サーバーを定義します。 MXレコードはホスト名を指している必要があります。 MXレコードはCNAMEまたはIPアドレスをポイントできません。 MXレコードの詳細は、RFC 1035を参照してください。
NS	ネーム・サーバー・レコードには、ゾーンの認可ネーム・サーバーがリストされます。 NSレコードは、作成する新しいプライマリ・ゾーンごとに自動的に生成されます。 NSレコードの詳細は、RFC 1035を参照してください。
PTR	ポインタ・レコード・リバースは、IPアドレスをホスト名にマップします。この動作は、ホスト名をIPアドレスにマップするAレコードの反対です。 PTRレコードは、通常、逆引きDNSゾーンにあります。 PTRレコードの詳細は、RFC 1035を参照してください。
PX	X.400マッピング・プロトコルで使用されるリソース・レコード。 PXレコードの詳細は、RFC 822およびRFC 2163を参照してください。
SOA	Start of Authorityレコードでは、DNSゾーンに関する次のような認可情報を指定します: プライマリ・ネーム・サーバードメイン管理者の電子メールドメイン・シリアル番号ゾーンのリフレッシュに関連する複数のタイマー SOAレコードは、ゾーンの作成時に自動的に生成されます。 SOAレコードの詳細は、RFC 1035を参照してください。
SPF	Sender Policy Frameworkレコードは、電子メールのスプーフィングを検出するように設計されたデータを格納するために使用される特別なTXTレコードです。 SPFレコードの詳細は、RFC 4408を参照してください。
SRV	サービス・ロケータ・レコードを使用すると、管理者は1つのドメインに複数のサーバーを使用できます。 SRVレコードの詳細は、RFC 2782を参照してください。
SSHFP	SSH公開キー・フィンガープリント・レコードは、DNSを使用してSSHパブリック・ホスト・キー・フィンガープリントを公開します。 SSHFPレコードの詳細は、RFC 6594を参照してください。
TLSA	Transport Layer Security Authenticationレコードは、TLSサーバー証明書(公開キー)を、レコードが見つかったドメイン名に関連付けます。この関係は、TLSA証明書関連付けと呼ばれます。 TLSAレコードの詳細は、RFC 6698を参照してください。
TXT	テキスト・レコードには、記述的で人間が読めるテキストがあり、特定の用途に人間が読めないコンテンツを含めることもできます。通常は、人間が読めないテキスト・アイテムを必要とするSPFレコードおよびDKIMレコードに使用されます。 TXTレコードの詳細は、RFC 1035を参照してください。

トラフィック管理ステアリング・ポリシー

リング・ポリシーでは、DNS問合せに対するインテリジェントなレスポンスを提供するようにポリシーを構成できます。つまり、ポリシーで定義されたロジックに応じて、問合せに対して様々な回答(エンドポイント)が提供される場合があります。 Private Cloud Applianceは、次のタイプのトラフィック管理リング・ポリシーをサポートしています:

ポリシー・タイプ	説明
ロード・バランサ	ロード・バランサ・ポリシーを使用すると、複数のエンドポイント間でトラフィックを分散できます。エンドポイントに同等の重みを割り当てて、エンドポイント間でトラフィックを均等に分散したり、カスタム重みを比率ロード・バランシングに割り当てることができます。
IP接頭辞ステアリング	IPプレフィクス・ステアリング・ポリシーを使用すると、元の問合せのIPプレフィクスに基づいてDNSトラフィックを制御できます。リクエストの発生元のサブネットに基づいてユーザーをグループに分割し、行ったサブディビジョンに基づいてユーザーを特定のリソースに移動できます。たとえば、外部ユーザーとは異なるレスポンスを内部ユーザーに提供できます。

ポリシー・タイプ

説明

ロード・バランサ

ロード・バランサ・ポリシーを使用すると、複数のエンドポイント間でトラフィックを分散できます。

エンドポイントに同等の重みを割り当てて、エンドポイント間でトラフィックを均等に分散したり、カスタム重みを比率ロード・バランシングに割り当てることができます。

IP接頭辞ステアリング

IPプレフィクス・ステアリング・ポリシーを使用すると、元の問合せのIPプレフィクスに基づいてDNSトラフィックを制御できます。

リクエストの発生元のサブネットに基づいてユーザーをグループに分割し、行ったサブディビジョンに基づいてユーザーを特定のリソースに移動できます。たとえば、外部ユーザーとは異なるレスポンスを内部ユーザーに提供できます。

リング・ポリシーには、DNS問合せに応答するルールが含まれています。これらのルールを使用して、DNSリクエストのプロパティに基づいて回答をフィルタ処理します。 DNS問合せに応じて複数の回答が提供される場合、その回答グループは回答プールと呼ばれます。プール内の回答は優先度でソートされ、適格または不適格とマークされます。不適格な回答はレスポンスから除外されます。

DNSゾーンにアタッチされている場合、リング・ポリシーはカバーするゾーンのすべてのリソース・レコードよりも優先され、リング・ポリシー・ルールからDNSレスポンスが構築されます。たとえば、example.com DNSゾーンにアタッチされているリング・ポリシーに、ドメインapplication.example.comおよびA (アドレス)レコード・タイプの回答を含むルールが含まれている場合、そのゾーンに存在する関連Aレコードに関係なく、リング・ポリシーはその回答で応答します。リング・ポリシーでリクエストされているレコード・タイプの回答がない場合、DNSリクエストは、次のリング・ポリシーまたはベース・ゾーン・レコードに渡されます。

リング・ポリシーは、タイプA、AAAA、CNAMEのレコードのみをサポートします。ドメインには、特定のレコード・タイプをカバーする最大1つのリング・ポリシー・アタッチメントを含めることができます。つまり、DNSゾーン(example.com)には、特定のドメインの様々なレコード・タイプをカバーする複数のアタッチされたリング・ポリシーが存在する可能性があります - たとえば、1つのAレコード・ポリシーと1つのCNAMEレコード・ポリシーはapplication.example.comです。 DNSゾーンには、異なるドメインの特定のレコード・タイプをカバーする複数のアタッチされたリング・ポリシーも含めることができます - たとえば、application.example.comのレコード・ポリシーおよびdatabase.example.comのAレコード・ポリシーです。ただし、回答は1つのポリシーのみ提供できるため、同じドメインおよびレコード・タイプに対する複数のリング・ポリシーはサポートされていません。