高度な DNSSEC を使用する

このページでは、マネージド ゾーンで DNSSEC を有効にした場合に使用できる、高度な Domain Name System Security Extensions（DNSSEC）オプションについて説明します。これらのオプションは、さまざまな署名アルゴリズムと不在証明から、DNSSEC の使用が必須または推奨されているレコードタイプを使用する機能まで、多岐にわたります。

DNSSEC のコンセプトの概要については、DNSSEC の概要をご覧ください。

DNSSEC で署名されたサブドメインを委任する

プライマリ ドメインで DNSSEC を有効にすると、委任されたサブドメインで DNSSEC を有効にできます。委任されたサブドメインで DNSSEC を有効にするには、まず Cloud DNS ゾーン内に DS レコードを作成します。また、1 つ以上の NS レコードを作成する必要があります。

委任されたサブドメインの DS レコードを作成するには、ゾーンの DS レコードを取得する必要があります。委任されたゾーンも Cloud DNS でホストされている場合は、 Google Cloud コンソールまたは Google Cloud CLI から DS レコードを取得できます。

コンソール

  1. Google Cloud コンソールで、[Cloud DNS] ページに移動します。

    [Cloud DNS] に移動

  2. DS レコードを表示するマネージド ゾーンに移動します。

  3. ゾーンの DS レコードを表示するには、[ゾーンの詳細] ページの右上にある [レジストラの設定] をクリックします。

  4. DS レコードは [レジストラの設定] ページにあります。

  5. NS レコードを作成するには、レコードの追加の手順に沿って操作してください。

[レジストラの設定] ページ

gcloud

  1. 委任されたサブドメインの DS レコード情報を取得するには、次のコマンドを実行します。

    gcloud dns dns-keys list --zone SUBDOMAIN_ZONE

    SUBDOMAIN_ZONE は、プロジェクトの委任されたサブドメインの DNS ゾーン名に置き換えます。

    出力は次のようになります。

    ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
0   1234     KEY_SIGNING   True
1   12345    ZONE_SIGNING  True

  2. 完全な DS レコードとすべてのキーを取得するには、KEY_SIGNING キー（KSK）の ID （通常は 0）が必要です。次のコマンドを実行します。

    gcloud dns dns-keys describe --zone SUBDOMAIN_ZONE KSK_ID \
   --format "value(ds_record())"

    次のように置き換えます。

    • SUBDOMAIN_ZONE: プロジェクトの委任されたサブドメイン DNS ゾーンの名前
    • KSK_ID: KSK ID 番号（通常は 0）

    出力は次のようになります。

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb

  3. 以降の手順で使用するため、前のコマンドの出力をコピーします。

  4. 安全な再委任用の DS レコードを作成するには、次のコマンドを実行してトランザクションを開始します。

    gcloud dns record-sets transaction start --zone PARENT_ZONE

    PARENT_ZONE は、委任されたサブドメインのレコードを作成するプロジェクト内の親 DNS ゾーンの名前に置き換えます。

    出力は次のようになります。

    Transaction started [transaction.yaml].

  5. 次に、下のコマンドを実行してレコードセットを追加します。

    gcloud dns record-sets transaction add --zone PARENT_ZONE \
   --ttl TIME_TO_LIVE \
   --type DS \
   --name subdomain.example.com \
   "DS_RECORD_AND_KEY"

    次のように置き換えます。

    • PARENT_ZONE: プロジェクト内の親 DNS ゾーンの名前
    • TIME_TO_LIVE: ゾーンの有効期間（TTL）例: 3600
    • subdomain.example.com: ゾーンの DNS 名のサブドメイン
    • DS_RECORD_AND_KEY: 手順 2 でコピーした DS レコードとキー（44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb など）

    出力は次のようになります。

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
Record addition appended to transaction at [transaction.yaml].

  6. NS レコードを追加するには、次のコマンドを使用します。

    gcloud dns record-sets transaction add --zone PARENT_ZONE \
   --ttl TIME_TO_LIVE \
   --type NS \
   --name subdomain.example.com \

    次のように置き換えます。

    • PARENT_ZONE: プロジェクト内の親 DNS ゾーンの名前
    • TIME_TO_LIVE: ゾーンの有効期間（TTL）例: 3600
    • subdomain.example.com: ゾーンの DNS 名のサブドメイン

  7. 次の RRData を入力します。

    ns-cloud-e1.googledomains.com. \
ns-cloud-e2.googledomains.com. \
ns-cloud-e3.googledomains.com. \
ns-cloud-e4.googledomains.com.

    出力は次のようになります。

    Record addition appended to transaction at [transaction.yaml].

  8. トランザクションを実行するには、次のコマンドを使用します。

    gcloud dns record-sets transaction execute --zone EXAMPLE_ZONE

    EXAMPLE_ZONE は、プロジェクトの DNS ゾーンの名前に置き換えます。

    出力は次のようになります。

    Executed transaction [transaction.yaml] for managed-zone [dns-example].
Created     [https://dns.googleapis.com/dns/v1/projects/example/managedZones/example_zone/changes/42].
ID  START_TIME                STATUS
42  2019-08-08T23:12:49.100Z  PENDING

高度な署名オプションを使用する

マネージド ゾーンで DNSSEC を有効にする場合、または DNSSEC を使用してマネージド ゾーンを作成する場合は、DNSSEC 署名アルゴリズムと不在証明タイプを選択できます。

マネージド ゾーンの DNSSEC 設定（レコードの暗号署名に使用するアルゴリズムなど）は、DNSSEC を有効にする前に変更できます。マネージド ゾーンですでに有効化されている DNSSEC を変更するには、まず、DNSSEC を無効にして必要な変更を加えた後、次のコマンドを使用して DNSSEC を再度有効にします。

gcloud dns managed-zones update EXAMPLE_ZONE --dnssec-state on

EXAMPLE_ZONE は、プロジェクトの DNS ゾーンの名前に置き換えます。

詳細については、マネージド ゾーンの DNSSEC の有効化をご覧ください。

次のコマンドは、256 ビット ECDSA と NSEC を使用する DNSSEC を有効にします。これにより、Cloud DNS を使用して、可能な限り最小の DNSSEC 署名レスポンス パケットが作成されるようになります。

gcloud dns managed-zones update EXAMPLE_ZONE \
  --dnssec-state on \
  --ksk-algorithm ECDSAP256SHA256 --ksk-key-length 256 \
  --zsk-algorithm ECDSAP256SHA256 --zsk-key-length 256 \
  --denial-of-existence NSEC

EXAMPLE_ZONE は、プロジェクトの DNS ゾーンの名前に置き換えます。

KSK または ZSK アルゴリズムのいずれかまたは鍵の長さを指定する場合は、コマンドにそのすべてと引数を指定する必要があります。

--ksk-algorithm --zsk-algorithm --ksk-key-length --zsk-key-length

不在証明はアルゴリズムにかかわらず、NSEC または NSEC3 として指定できます。

次の表に、サポートされているアルゴリズムと引数を示します。Cloud DNS では、他のアルゴリズムやパラメータの使用は許可されません。

アルゴリズム KSK の長さ ZSK の長さ コメント
RSASHA256 2048 1,024、2,048
RSASHA512 2048 1,024、2,048 広範囲にサポートされていません
ECDSAP256SHA256 256 256
ECDSAP384SHA384 384 384 広範囲にサポートされていません

アルゴリズムが指定されていない場合、Cloud DNS は次のデフォルトを使用します。

鍵のタイプ デフォルトのアルゴリズム デフォルトの鍵長
鍵署名鍵（KSK） RSASHA256 2048
ゾーン署名鍵（ZSK） RSASHA256 1024

RSASHA256 と RSASHA512 のセキュリティとパフォーマンスにおける違いは最小限であり、署名付きレスポンスのサイズは同一です。鍵の長さは重要です。鍵が長いと処理に時間がかかり、レスポンスのサイズが大きくなります（ルートゾーンと TLD のレスポンス サイズの分析、および Windows でのサーバー側パフォーマンスの分析をご覧ください）。

ECDSA のリゾルバ サポートは、かなり最近のシステムのみに制限されています。ECDSA で署名されたゾーンを検証できない古いリゾルバは、そうしたゾーンを未署名と見なします。これは、DNSSEC を使用する新しいレコードタイプを使用している場合、安全でない可能性があります。通常、レジストラとレジストリは 256 ビット ECDSA をサポートしますが、すべてに共通ではありません。384 ビット ECDSA をサポートしているレジストリはほんのわずかで、レジストラはさらに少数です。古いクライアントをサポートする必要がない場合は、ECDSA を使用すると効果的なことがあります。署名のサイズが大幅に削減され、処理にかかる時間が短縮されます。

マネージド ゾーン内で KSK と ZSK に異なるアルゴリズムを使用しないでください。異なるアルゴリズムを使用すると、互換性が低下し、セキュリティが損なわれる可能性があります。DNSSEC 検証リゾルバは、ゾーン内のレコードの署名すべてに DNSKEY アルゴリズムが使用されているわけではないゾーンの検証で不合格になることがあります。RFC 6840 には、「DNSKEY RRset の作業では、すべてのアルゴリズムについて主張してはなりません」と書かれていますが、実際には前述のとおりです。この問題がなければ（ほとんどの検証リゾルバは RFC 6840 に従っています）、ドメイン レジストラや TLD レジストリで ECDSA をサポートしておらず、レスポンスのサイズを小さくする必要がある場合、KSK に RSASHA256 を使用でき、ZSK に ECDSA を使用できます。

NSEC3 はデフォルトの不在証明タイプであり、ゾーン内のすべてのレコードを検出しようとするゾーン ウォーカーに対する限定的な保護を提供します。NSEC3PARAM の設定は固定されています。NSEC3 opt-out はセキュリティ上の理由で無効になり、64 ビットソルトを使用した追加のハッシュ イテレーションが 1 つ（合計で 2 つ）あります。

NSEC のレスポンスはこれよりも多少小さくなりますが、ゾーン ウォーキングに対して保護されません。また、NSEC を使用すると、存在しないドメインに対するクエリも削減できます。Google Public DNS と他の DNSSEC 検証リゾルバは、Cloud DNS ゾーンにクエリを送信することなく、キャッシュに保存された NSEC レコードからの否定レスポンスを統合できます。