DNSの動作と解決ロジック

ドメインネームシステム（DNS）はウェブを支えており、バックグラウンドで透過的に働き、人間が読めるウェブサイト名をコンピュータが読める数値のIPアドレスに変換する。これらのアドレスは、 IPv4 についてはインターネットの RFC 1918 ガイドラインに、 IPv6 については RFC 4193 に準拠しています。要するに、DNSサーバーは、 ibm.com といったドメイン名を、それに対応するIPアドレスと照合するものであり、そのIPアドレスをわざわざ知る必要のある人はほとんどいない。

この変換を行うために、DNSシステムはインターネット上で相互接続されたDNSサーバーのネットワークに問い合わせを行う。このプロセスは、電話帳や地図を使って特定の場所を探すのと似ている。

ネーム・サーバー

ネームサーバーは、ディレクトリに対するクエリに応答するサービスを提供し、意味のあるテキストベースのウェブ名やホスト名をIPアドレスに変換する。

ネームサーバーの委譲は、ドメインのネームサーバーがサブドメインのレコードの要求を受け取り、要求者をサブドメインを管理する委譲されたネームサーバーに参照させることによって応答するときに発生する。このプロセスは、 ibm.com のような大規模ドメインの分散管理を可能にする。

カスタムドメインネームサーバーを使用すれば、DNSプロバイダーのサーバーを、ご自身のドメインのカスタマイズされた参照名とともに利用することができます。例えば、ネームサーバーをプロバイダーのデフォルトである ns1.acme.com の代わりに ns1.cloud.ibm.com と定義することができる。

DNS レコードとグローバル・ロード・バランサーのプロキシー接続

CIS グローバルロードバランサーおよびDNSレコードのプロキシ機能をサポートしています。レコードまたはロードバランサーがプロキシされる場合、そのトラフィックは CIS を経由して直接送信されます。

現在、A、AAAA、または CNAME タイプの DNS レコードをプロキシー接続できます。詳細については、 DNSレコードタイプを参照してください。

プロキシー・モードの設定

ロード・バランサーと DNS レコードは、DNS 専用モードと HTTP プロキシー・モードの両方をサポートしています。同じ CIS インスタンスに HTTP プロキシとDNSのみのドメインを持つことができますが、トラフィックルーティングの動作は異なります。プロキシされるレコードのトラフィックは CIS を経由して流れますが、プロキシされないレコード（DNSのみのモード）のトラフィックはクライアントからオリジンに直接流れます。

HTTP プロキシー・モード

HTTP のプロキシモードでは、 CIS が IBM のIPアドレスを外部に公開しますが、オリジンサーバーのIPアドレスは保護（マスキング）されます。アナウンスされた IP アドレス・レコードでは、自動 TTL が使用されます。トラフィックは CIS を経由して流れ、そこでファイアウォールルールやキャッシュなど、セキュリティ、パフォーマンス、信頼性に関するすべての機能が適用されます。「自動」TTL（5分）を設定することで、 CIS に対して行われる権威サーバーへのクエリ数も削減されます。

DNS 専用モード

DNS専用モードでは、レコードはオリジンIPに解決され、レコードのTTLをカスタマイズすることができます。グローバルロードバランサーの場合、 CIS は正常なオリジンサーバーのアドレスを直接提供しますが、短いTTLを遵守するDNSリゾルバーに依存して、 CIS のDNSに対し、正常なアドレスの最新リストを再問い合わせします。

DNS専用モードでは、 CIS のセキュリティ、信頼性、およびパフォーマンス機能はいずれも適用されません。

ルート・レコードの CNAME フラット化

CIS の "CNAME flattening "機能は、ルートレコードがIETF RFCの制限を回避することを可能にする。この制限により、ルートレコードがCNAMEである場合、そのドメインに対して他のレコードを設定することはできないと定められています。 CIS の権威サーバーは、CNAME自体を返す代わりに、CNAMEのターゲットに対応する A records を返すことでこの制限を回避し、事実上CNAMEを隠蔽しています。この手法により、ルートレコードがCNAMEであっても、MXレコードなどの他のレコードをそのドメインに追加することが可能になります。

保護 DNS

DNSSECとは、DNSデータにデジタル「署名」を付与する技術であり、これによりそのデータの有効性を確信することができます。インターネット上の脆弱性を排除するためには、ルートゾーンから最終的なドメイン名（例： www.icann.org ）に至るまでの検索プロセスの各段階で、DNSSECを導入する必要があります。

DNSレコードの一括変更

CIS はバッチDNSレコード変更をサポートしており、1回の操作で複数のゾーンレコードを更新できます。このアプローチは、手作業を減らし、移行、環境セットアップ、自動化ワークフローなどのドメイン管理タスクを簡素化する。 CIS コンソールは個別の変更をサポートするが、バッチ操作は API を使用するのが最適である。

バッチDNSレコード APIエンドポイントを使用すると、1回のリクエストで複数の DELETES、 PATCHES、 PUTS、 POSTS。

/batch リクエストボディに含まれる操作は、常に以下の順序で処理される：

削除
パッチ
置く
投稿

各オペレーション・タイプの中で、個々のレコードの変更は処理された順に適用される。いずれかの操作が失敗した場合、変更は適用されず、APIは最初に遭遇したエラーを返す。

バッチDNSレコードの主な考慮事項

各オペレーションを/batch リクエストボディで指定する場合、必須フィールドと未指定フィールドの処理方法については、以下のガイドラインに従うこと：

Deletes:各レコード・オブジェクトには、 id フィールドのみが必要です。わかりやすくするために、 name などのフィールドを追加することができますが、その他のフィールドはすべて無視されます。
Patches:各レコード id とは別に、更新したいフィールドを指定します。指定されていないすべてのフィールドは変更されません。
Puts:各レコードの id、 content、 name、 type。また、デフォルト値以外に設定したい他のフィールドも指定する。指定されていないフィールドは、各レコードタイプのデフォルト値となります。この操作は上書きとして機能するので、レコード内のすべてのフィールドが常に影響を受ける。
Posts:新しいレコードを作成する。 id フィールドは必須ではありません。フィールド定義については、 Create DNS Record エンドポイントを参照し、リクエストボディの仕様から適切なレコードタイプを選択してください。

要求の例

この例では、 puts にリストされている最初のレコードのプロキシされたフィールドは、デフォルト値 false を想定している。

{
  "deletes": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353"
    }
  ],
  "patches": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "posts": [
    {
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ],
  "puts": [
    {
      "id": "023e105f4ecef8ad9ca31a8372d0c353",
      "comment": "Domain verification record",
      "name": "example.com",
      "proxied": true,
      "settings": {},
      "tags": [],
      "ttl": 3600,
      "content": "198.51.100.4",
      "type": "A"
    }
  ]
}