高度な 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 Console または gcloud コマンドライン ツールから DS レコードを取得できます。

コンソール

  1. Google Cloud Console で、[Cloud DNS] ページに移動します。

    Cloud DNS に移動する

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

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

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

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

レジストラの設定ページ

gcloud

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

    gcloud dns dns-keys list --zone EXAMPLE_ZONE
    

    EXAMPLE_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 EXAMPLE_ZONE KSK_ID \
       --format "value(ds_record())"
    

    以下を置き換えます。

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

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

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

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

    gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
    

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

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

    Transaction started [transaction.yaml].
    

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

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

    以下を置き換えます。

    • EXAMPLE_ZONE: プロジェクト内の親 DNS ゾーンの名前
    • TIME_TO_LIVE: ゾーンの存続時間(秒)。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 EXAMPLE_ZONE \
       --ttl TIME_TO_LIVE \
       --type NS \
       --name subdomain.example.com \
    

    以下を置き換えます。

    • EXAMPLE_ZONE: プロジェクト内の親 DNS ゾーンの名前
    • TIME_TO_LIVE: ゾーンの存続時間(秒)。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 として指定できます。

サポートされているアルゴリズムと引数を、次の表に示します。この表では、リクエストでのみ使用できるデフォルト値は太字弱い値は斜体で記載しています。

アルゴリズム KSK の長さ ZSK の長さ コメント
RSASHA1 1,0242,048 1,0242,048 SHA-1 は弱いアルゴリズムとみなされています
RSASHA256 10242048 1,024、2,048
RSASHA512 1,024、2,048 1,024、2,048 広範囲にサポートされていません
ECDSAP256SHA256 256 256 サポートされない可能性があります
ECDSAP384SHA384 384 384 広範囲にサポートされていません

RSASHA1 は互換性保持のために必要な場合を除き、使用しないでください。長い鍵でこのアルゴリズムを使用するセキュリティ上の利点はありません。

RSASHA256RSASHA512 のセキュリティとパフォーマンスにおける違いは最小限であり、署名付きレスポンスのサイズは同一です。鍵の長さは重要です。鍵が長いと処理に時間がかかり、レスポンスのサイズが大きくなります(ルートゾーン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 レコードからの否定レスポンスを統合できます。

DNSSEC で保護されたゾーンでの新しい DNS レコードタイプの使用

ドメインが DNSSEC により完全に保護されたら、いくつかの新しい DNS レコードタイプを使用できるようになります。これらのレコードタイプは、DNSSEC で署名されたゾーンの信頼性と完全性の保証を利用してその他のサービスのセキュリティを強化します。

SSHFP

SSHFP レコードには、SSH クライアント アプリケーションが SSH サーバーを検証するために使用できる、SSH サーバーの公開鍵のフィンガープリントが含まれます。SSH クライアントは通常、最初の接続でサーバーの公開鍵を確認するためにユーザー インタラクションを必要とし、鍵が変更された場合には警告を生成します。SSHFP を使用するように構成されている SSH クライアントは常に、サーバーに対し、そのサーバーの SSHFP レコードに含まれている鍵を使用します。SSHFP レコードのないサーバーの鍵だけが、再利用のために保存されます。

SSHFP レコードの形式は、次のとおりです。

  • アルゴリズム番号
  • 指紋タイプ番号
  • サーバーキーのフィンガープリント

SSH のアルゴリズム番号は、次のとおりです。

  1. RSA
  2. DSA
  3. ECDSA
  4. ED25519

フィンガープリントのタイプは、次のとおりです。

  • SHA-1(非推奨、互換性目的のみ
  • SHA-256

StackExchange では SSHFP の作成についての提案を公開しています。既存の既知のホストファイルまたは構成管理を使用してサーバーをスキャンすることにより SSHFP を生成するツールもあります。その他の例とリンクについては、SSHFP レコード: DNS で公開 SSH ホストキーを提供するをご覧ください。

TLSA と DANE

TLSA レコードには、事前に構成されている一連の認証局(CA)による署名に依存せずに、X.509 証明書(HTTPS により使用される証明書など)の検証に使用できる情報が含まれています。

これを使用すると、独自の CA を設定して HTTPS の証明書を生成できます。これにより、通常は事前構成された信頼できる CA に対するアプリケーション サポートがない SMTP のようなプロトコルに対する証明書も検証できます。

RFC 6698 および関連する RFC で規定されている DANE(Domain Authentication of Named Entities)は、多数のプロトコルとアプリケーションを保護するため特定の方法で TLSA レコードを使用します。IETF Journal および Internet Society は、有用な紹介記事DANE の概要を公開しています。

HTTPS

DANE を使用すると、OpenSSL や Cloudflare の CFSSL に基づく独自の CA インフラストラクチャで生成された証明書を使用して、HTTPS サーバーを安全に構成できます。

SIDNLabs の HTTPS サーバー向け DANE バリデーターは、HTTPS の DANE デプロイメントをテストする際に役立ちます。

SMTP(メール)TLS 証明書の検証

SMTP メール プロトコルは、暗号化を無効にするダウングレード攻撃に対して脆弱であり、DANE ではこうした攻撃を防ぐ方法を提供します。

Internet Society には、無料の自動証明書を持つ DANE for SMTP の使用に関する 2 部構成のチュートリアルがあり、Let's Encryptから入手できます。これには、Let's Encrypt 証明書で特定の TLSA レコード形式を使用しないようにするアドバイス が含まれています。

Common Mistakes には、優れたアドバイス(および HTTPS と SMTP 用の DANE ドメイン バリデーター)があります。また、Test your email バリデータも DANE を検査します。

XMPP(Jabber チャット)TLS 証明書の検証

XMPP(および SRV レコードを使用するその他のサービス)でも DANE を利用できます。XMPP の例では、RFC 7673 で指定されている DANE-SRV 構成が使用されています。

TXT(OpenPGP / GnuPG)公開鍵の関連付け

TXT レコードは DNSSEC なしで使用できますが、DNSSEC で署名された TXT レコードを使用すると信頼性が大幅に高まります。これは、OpenPGP(GnuPG)公開鍵(X.509 認証局などの既知の認証局により署名されていない公開鍵)の DNS ベースの公開において重要です。

たとえば、Alice が DNSSEC で署名された an.example ゾーンで次のような TXT レコードを公開し、指定された URI にある ASCII-armor 形式の公開鍵のコピーをホストしていれば、Bob は、適切なセキュリティで alice@an.example の OpenPGP 鍵を検索できます(このセキュリティは web-of-trust 検証の代わりにはなりませんが、未知の認証局による OpenPGP 暗号化が可能となります)。

    alice._pka 86400 IN TXT "v=pka1;fpr=083382bac0059be3d6544c8b0dcf16f482a6;uri=https://an.example/a.asc"

この手順を使用して、バージョン 1 PKA の TXT レコード(DNS で鍵の公開での呼び名)を生成できます。

DNS で PGP 鍵を公開するための完全ガイドでは、OpenPGP CERT レコードの作成方法を説明しています(ただし、Cloud DNS は CERT や OPENPGPKEY レコードをサポートしていません)。

OpenPGP 鍵を Keybase.io に登録した場合、独自のサーバーで鍵をホストする必要はありません。代わりに、https://keybase.io/KEYBASE_USERNAME/key.asc などの URL を使用できます(KEYBASE_USERNAME は Keybase.io のユーザー名に置き換えます)。

OpenPGP 鍵を鍵サーバーにアップロードしている場合は、その鍵サーバーの hkp: URI(hkp://subkeys.pgp.nethkp://pgp.mit.edu など)も使用できます。ただし、ポート 11371 をブロックしているファイアウォールで保護されているユーザーは、鍵サーバーにアクセスできない可能性があります(一部の鍵サーバーはポート 80 HTTP URL を提供します)。

TXT(SPF、DKIM、DMARC)

3 種類の他の TXT レコードを、次に示します。これらは、メールサービスを保護して、スパマーや詐欺師がユーザーのドメインから発信されたように見える(実際にはそうでなくても)メールを送信できないようにするために使用できます。

  • SPF: ドメインにメールを送信できる SMTP サーバーをドメイン名または IP アドレスで指定します。

  • DKIM: メールがドメインから送信されたものであることを検証し、送信中にメッセージが改ざんされることを防止するために使用する一連の公開鍵を発行します。

  • DMARC SPF および DKIM 検証と、エラー報告に関するドメイン ポリシーとレポートを指定します。

この 3 種類のレコードすべてを使用するようにドメインが正しく構成されていることを確認するには、Test your email バリデータが使用できます。SPF レコードの構成に関する有用なアドバイスについては、Common mistakes FAQ をご覧ください。

DNSSEC により強化されるその他のレコードセット タイプ

TXT の他に、DNSSEC を必要としないが DNSSEC のメリットを利用できるレコードセット タイプがいくつかあります。

CAA

Certification Authority Authorization(CAA)レコードセットを使用すると、ドメインに対して TLS や他の証明書を生成できる公開 CA を制御できます。この制御は、ドメイン検証済み(DV)証明書を発行する公開 CA(LetsEncrypt.org など)が、使用しているドメインの証明書を発行しないようにする場合に最も有用(かつ効果的)です。

通常、CAA レコードは、0 issue "best-ca.example" のような形式です。これにより、best-ca.example CA(他に CA なし)は、CAA レコードセットが存在するドメイン内の名前に対して証明書を発行できます。複数の CA が証明書を発行できるようにする場合は、複数の CAA レコードを作成します。

RFC 6844 では、CAA レコードセット タイプの使用法についてさらに詳しく説明しており、DNSSEC の使用が強く推奨されています。

IPSECKEY

IPSECKEY レコードを公開することで、IPsec トンネルを介した日和見暗号化を有効にすることもできます。strongSwan IPsec VPN の実装には、IPSECKEY レコードを使用するプラグインがあります。

RFC 4025 セクション 1.2 では、IPSECKEY レコードを通常のフォワード ゾーン(service.example.com など)に配置することに加え、セキュリティ ゲートウェイでリバースゾーン ip6.arpa および in-addr.arpa 内の IPSECKEY レコードを検索する必要があることを規定しています。

リバースゾーンの DNSSEC サポートはフォワード ゾーンの場合に比べ一般的ではなく、DNSSEC を実装するインターネット サービス プロバイダ(ISP)を必要とします。ただし、リバースゾーン委任のために DNSSEC をサポートできる ISP もあります。

Compute Engine VM の外部 IP アドレスのリバースゾーンでは、委任がまだサポートされていません。

次のステップ

  • マネージド ゾーンの作成、更新、一覧表示、削除については、ゾーンの管理をご覧ください。
  • Cloud DNS の使用時に発生する可能性のある一般的な問題の解決策については、トラブルシューティングをご覧ください。
  • Cloud DNS の概要については、Cloud DNS の概要をご覧ください。