高度な DNSSEC

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

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

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

コンソール

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

  1. マネージド ゾーンに移動します。
  2. ゾーンの DS レコードを表示するには、Zone details ページの右上にある [Registrar Setup] リンクをクリックします。
  3. DS レコードの情報をメモしたら、[gcloud] コマンドタブのステップ 2 に進みます。

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

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 レコードとすべてのキーの詳細を取得するには、通常はゼロ(0)である KEY_SIGNING Key(KSK)の IDが必要です。次のコマンドを使用します。

    $ gcloud dns dns-keys describe --zone example_zone ksk_id \
     --format "value(ds_record())"
    

    次のコマンド オプションを置き換えます。

    • example_zone: プロジェクト内の DNS ゾーンの名前
    • ksk_id: ID 番号(通常は 0)
  3. 前のコマンドの出力をコピーして、次のステップで使用します。

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

    44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb
    
  4. サブドメインの委任をセキュアに行うための DS レコードを作成するには、次のコマンドを使用してトランザクションを開始します。

    $ gcloud dns record-sets transaction start -z example_zone
    

    次のコマンド オプションを置き換えます。

    • example_zone: プロジェクト内の DNS ゾーンの名前
    • subdomain.example.com: ゾーンの DNS 名のサブドメイン

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

    Transaction started [transaction.yaml].
    

  5. 続いて、以下のコマンドを使用してレコードセットを追加します。

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type DS --name subdomain.example.com \
     DS_record-and_key"44300 8 2 92966cefacccd85b3bf00fcbcc4318b5f97a27889489b8e89b5bd56f83066ddb"
    

    次のコマンド オプションを置き換えます。

    • example_zone: プロジェクト内の DNS ゾーンの名前
    • subdomain.example.com: ゾーンの DNS 名のサブドメイン
    • DS_record-and_key: 手順 2 で取得した DS レコードとキー

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

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

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

    $ gcloud dns record-sets transaction add -z example_zone \
     --ttl 3600 --type NS --name subdomain.example.com \
    

    次のコマンド オプションを置き換えます。

    • example_zone: プロジェクト内の DNS ゾーンの名前
    • subdomain.example.com: ゾーンの DNS 名のサブドメイン
  7. 次の RData を入力します。

    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 -z 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 を再度有効にします(example_zone は、実際のプロジェクトの DNS ゾーン名で置き換えます)。

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

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

次のコマンドは、256 ビット ECDSA と NSEC を使用する DNSSEC を有効にして、Cloud DNS を使用して可能な限り最小の DNSSEC 署名レスポンス パケットを作成できるようにします。example_zone は、プロジェクトの DNS ゾーンの名前に置き換えます。

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

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 に準拠しています)、KSK に RSASHA256 を使用し、ZSK に ECDSA を使用できます。ドメイン登録事業者または TLD レジストリで ECDSA がサポートされていない場合、レスポンスのサイズを小さくする必要があります。

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

NSEC のレスポンスはこれよりも多少小さくなりますが、ゾーン ウォーキングに対して保護されません。NSEC を使用すると、存在しないドメイン(Google Public DNS)に対するクエリを減らすことができます。他の DNSSEC 検証リゾルバは、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 の機能リクエストをご覧ください。

次のステップ