このページでは、マネージド ゾーンで 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 または Google Cloud CLI から DS レコードを取得できます。
Console
Google Cloud Console で、[Cloud DNS] ページに移動します。
DS レコードを表示するマネージド ゾーンに移動します。
ゾーンの DS レコードを表示するには、[ゾーンの詳細] ページの右上にある [レジストラの設定] をクリックします。
DS レコードは [レジストラの設定] ページにあります。
NS レコードを作成するには、レコードの追加の手順に沿って操作してください。
![[レジストラの設定] ページ](https://cloud.google.com/static/dns/images/registrar-setup.png?authuser=0&hl=ja)
gcloud
委任されたサブドメインの 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
完全な 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
以降の手順で使用するため、前のコマンドの出力をコピーします。
安全な再委任用の DS レコードを作成するには、次のコマンドを実行してトランザクションを開始します。
gcloud dns record-sets transaction start --zone EXAMPLE_ZONE
EXAMPLE_ZONEは、委任されたサブドメインのレコードを作成するプロジェクト内の親 DNS ゾーンの名前に置き換えます。出力は次のようになります。
Transaction started [transaction.yaml].
次に、下のコマンドを実行してレコードセットを追加します。
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: ゾーンの存続時間（秒）例: 3600subdomain.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].
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: ゾーンの存続時間（秒）例: 3600subdomain.example.com: ゾーンの DNS 名のサブドメイン
次の 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].
トランザクションを実行するには、次のコマンドを使用します。
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 レコードからの否定レスポンスをsynthesizeできます。
RFC 8624 には、アルゴリズムの選択に関するガイダンスが追加されています。
DNSSEC で保護されたゾーンで新しい DNS レコードタイプを使用する
ドメインが DNSSEC により完全に保護されたら、いくつかの新しい DNS レコードタイプを使用できるようになります。これらのレコードタイプは、DNSSEC で署名されたゾーンの信頼性と完全性の保証を利用してその他のサービスのセキュリティを強化します。
SSHFP
SSHFP レコードには、SSH クライアント アプリケーションが SSH サーバーを検証するために使用できる、SSH サーバーの公開鍵のフィンガープリントが含まれます。SSH クライアントは通常、最初の接続でサーバーの公開鍵を確認するためにユーザー インタラクションを必要とし、鍵が変更された場合には警告を生成します。SSHFP を使用するように構成されている SSH クライアントは常に、サーバーに対して、そのサーバーの SSHFP レコードに含まれている鍵を使用します。SSHFP レコードのないサーバーの鍵だけが、再利用のために保存されます。
SSHFP レコードの形式は、次のとおりです。
- アルゴリズム番号
- フィンガープリント タイプ番号
- サーバーキーのフィンガープリント
SSH のアルゴリズム番号は次のとおりです。
- RSA
- DSA
- ECDSA
- ED25519
フィンガープリントのタイプは次のとおりです。
- SHA-1（非推奨、互換性目的のみ）
- SHA-256
StackExchange では SSHFP の作成についての提案を公開しています。既存の既知のホストファイルまたは構成管理を使用してサーバーをスキャンすることにより SSHFP を生成するツールもあります。その他の例とリンクについては、SSHFP レコード: 公開 SSH ホストキーを提供する DNS をご覧ください。
TLSA と DANE
TLSA レコードには、事前に構成されている一連の認証局（CA）による署名に依存せずに、X.509 証明書（HTTPS により使用される証明書など）の検証に使用できる情報が含まれています。
これを使用すると、独自の CA を設定して HTTPS の証明書を生成できます。これにより、SMTP など、信頼できる事前構成の CA に対してアプリケーション サポートのないプロトコルでも証明書を検証できます。
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.net や hkp://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 レコードの構成に関する有用なアドバイスについては、一般的な間違いに関するよくある質問 をご覧ください。
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 の概要をご覧ください。