高度な DNSSEC

マネージド ゾーンで DNSSEC を有効にする場合に使用できる高度な DNSSEC 構成オプションがいくつかあります。これらのオプションには、各種署名アルゴリズム、不在証明、DNSSEC が必須であるか推奨されるレコードタイプを使用する機能などがあります。これらすべてのオプションについて以下で説明します。

DNSSEC で署名されたサブドメインの委任

プライマリ ドメインで DNSSEC を有効にすると、委任されたサブドメインで DNSSEC を有効にすることができます。これには(この場合は Cloud DNS ゾーン内での)DS レコードの作成が必要です。

Google Cloud Platform Console を使用して、委任されたサブドメインの DS レコードを作成できます(1 つ以上の NS レコードも作成する必要があります)。委任されたゾーンも Cloud DNS でホストされている場合は、マネージド ゾーンに移動し、[ゾーンの詳細] ページの右上にある [レジストラの設定] リンクをクリックすると、GCP Console から DS レコードを取得できます。

[レジストラの設定] ポップアップ

また、gcloud コマンドライン ツールを使用して次の情報を取得することもできます。

$ gcloud dns dns-keys list EXAMPLE ZONE
ID  KEY_TAG  TYPE          IS_ACTIVE  DESCRIPTION
0   1234     KEY_SIGNING   True       -
1   12345    ZONE_SIGNING  True       -

作成する必要がある鍵の完全な DS レコードとすべての詳細情報を取得するには、KEY_SIGNING Key(KSK)の ID(通常はゼロ(0))が必要です(見やすくするため、一部の詳細が省略され、公開鍵が短縮されています)。EXAMPLE_ZONE をゾーン ID に置き換え、KSK_ID を上記の ID に置き換えます。

$ gcloud dns dns-keys describe --zone EXAMPLE_ZONE KSK_ID \
--format "value(ds_record())"
1234 7 1 2FD4E1C67A2D28FCED849EE1BB76E7391B93EB12

次の例に示すように、gcloud を使用してセキュアなサブ委任用の DS レコードを作成することもできます。

$ gcloud dns record-sets transaction start -z EXAMPLE_ZONE
Transaction started [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type DS --name SUBDOMAIN.EXAMPLE.COM \
'36283 5 1 0173d13977ffdf12716E3A1225B1B0B639B8CB46'
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e1.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e2.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e3.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction add -z EXAMPLE_ZONE \
--ttl 3600 --type NS --name SUBDOMAIN.EXAMPLE.COM \
ns-cloud-e4.googledomains.com.
Record addition appended to transaction at [transaction.yaml].
$ gcloud dns record-sets transaction execute -z EXAMPLE_ZONE
Executed transaction [transaction.yaml] for managed-zone [dns-example].
Created [https://www.googleapis.com/dns/v1beta2/projects/dns-example-info/managedZones/dns-example/changes/38].
ID  START_TIME                STATUS
38  2016-02-08T23:12:49.100Z  PENDING

高度な署名オプション

マネージド ゾーンで DNSSEC を有効にする場合、または DNSSEC を使用してマネージド ゾーンを作成する場合は、DNSSEC 署名アルゴリズムと不在証明タイプを選択できます。DNSSEC がまだ有効ではない場合、DNSSEC 設定の変更はマネージド ゾーンに対してのみ有効です。DNSSEC がすでに有効になっているマネージド ゾーンの設定を変更する場合は、DNSSEC を無効にしてから、異なる設定で再度有効にします。

以下のコマンドは、Cloud DNS を使用して可能な限り最小の DNSSEC 署名レスポンス パケットを作成するために、256 ビット ECDSA と NSEC を使用する 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
creationTime: '2016-04-29T14:15:08.085Z'
description: Example Cloud DNS Zone
dnsName: cloud.example
dnssecConfig:
  defaultKeySpecs:
  - algorithm: ECDSAP256SHA256
    keyLength: 256
    keyType: KEY_SIGNING
    kind: dns#dnsKeySpec
  - algorithm: ECDSAP256SHA256
    keyLength: 256
    keyType: ZONE_SIGNING
    kind: dns#dnsKeySpec
  kind: dns#managedZoneDnsSecConfig
  nonExistence: NSEC
  state: 'ON'
id: '9140081045636672726'
kind: dns#managedZone
name: EXAMPLE_ZONE
nameServers:
- ns-cloud-e1.googledomains.com.
- ns-cloud-e2.googledomains.com.
- ns-cloud-e3.googledomains.com.
- ns-cloud-e4.googledomains.com.

KSK または ZSK アルゴリズムのいずれかまたは鍵の長さを指定する場合は、コマンドに 4 つのオプションとその引数をすべて指定する必要があります。不在証明はアルゴリズムにかかわらず、NSEC または NSEC3 として指定できます。

サポートされるアルゴリズムと引数を次の表に示します。この表には、デフォルト値と、リクエストされた場合にのみ提供される弱値も記載されています。

アルゴリズム KSK の長さ ZSK の長さ コメント
RSASHA1 1,0242,048 1,0242,048 SHA-1 は弱いアルゴリズムとみなされています
RSASHA256 1,0242,048 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 に異なるアルゴリズムを使用しないでください。異なるアルゴリズムを使用すると、互換性が低下し、セキュリティが損なわれる可能性があります。 厳密な検証リゾルバは、2 つのアルゴリズムを使用して Cloud DNS ゾーンを解決することを拒否する場合があります。厳密なリゾルバ(リゾルバのほとんどは、かなり厳密度が低いです)にこだわらない場合に、レジストラとレジストリで ECDSA がサポートされておらず、レスポンスのサイズを小さくする必要がある場合には、KSK に RSASHA256 を使用し、ZSK に ECDSA を使用すると便利です。

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

NSEC のレスポンスはこれよりも多少小さくなりますが、ゾーン ウォーキングに対して保護されません。NSEC を使用すると、存在しないドメインに対するクエリも削減できます。Google Public DNS(および近い将来にはその他の多くのリゾルバ)は、Cloud DNS ゾーンに対するクエリを実行することなく、NSEC キャッシュの否定レスポンスを統合できます。

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

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

SSHFP

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

SSHFP レコードは、アルゴリズム番号、フィンガープリント タイプ番号、サーバー鍵フィンガープリントの形式をとります。SSH のアルゴリズム番号は次のとおりです。

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

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

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

StackExchange では SSHFP の作成についての提案を公開しています。既存の既知のホストファイルまたは構成管理を使用してサーバーをスキャンすることにより SSHFP を生成するツールもあります。 これらの記事にはその他の例とリンクが記載されています。

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 に基づく独自の認証局インフラストラクチャで生成された証明書を使用して、HTTPS サーバーを安全に構成できます。

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

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

SMTP メール プロトコルは、暗号化を無効にするダウングレード攻撃に対して特に脆弱であり、DANE ではこれを防止することができます。Internet Society は、Let's Encrypt から入手可能な無料の自動証明書を使用して SMTP 用の DANE を使用する方法を説明する 2 部構成のチュートリアルを公開しています(Let's Encrypt 証明書で特定の TLSA レコード形式を使用しないことを呼びかけるアドバイスに留意してください)。

また、https://dane.sys4.de/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 ベースの公開において重要です。たとえば、(DNSSEC で署名された an.example ゾーン内で)Alice が TXT レコードを次のように公開するとします。

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

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

この手順を使用して、「PKA バージョン 1」の TXT レコード(DNS の鍵の概要での呼び名)を生成できます。別の手順でも、OpenPGP CERT レコードの作成方法が説明されています(ただし CERT レコードと OPENPGPKEY レコードはいずれも Cloud DNS ではサポートされていません)。

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 検証と、エラー報告に関するドメイン ポリシーとレポートを指定します。

「Test your email」バリデーターを使用して、この 3 種類すべてのレコードを使用するようにドメインが正しく構成されていることを検証できます。Common Mistakes FAQ では、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 だけが、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 自体を実装するインターネット サービス プロバイダを必要としますが、リバースゾーン委任のために DNSSEC をサポートできるプロバイダもあります。

Google Compute Engine VM の外部 IP のリバースゾーンでは、委任がまだサポートされていないことに注意してください。Google Compute Engine の機能リクエストをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud DNS のドキュメント