DNSSECは10年以上にわたって標準でありながら、採用は不均一なままです。暗号は十分に理解され、運用モデルも十分に文書化されています。多くの組織がそれを有効にすることを止めるのは管理です: 署名鍵(KSK)とゾーン署名鍵(ZSK)はゾーン全体の信頼ルートであり、ほとんどの企業はそれらの鍵をベンダーの手に置きたくないのです。
クラウドDNSプロバイダーはDNSSEC署名と配信を提供しますが、鍵はプロバイダーのKMSに存在します。プロバイダーは取り消し、ローテーション、または召喚を受ける可能性があります — あなたのゾーン整合性はプロバイダーの継続的な運用に条件付けられます。一部の組織はこのトレードオフを受け入れますが、規制対象セクター(政府、防衛、金融)の多くは受け入れられません。
歴史的な代替案は、自己管理のDNSSEC署名パイプラインを運用することです: カスタム鍵管理を伴うBIND、スケジュールで鍵をローテーションするスクリプト、外部HSM統合、署名済みレコードを受け取るスレーブ構成。これは機能しますが、運用上のオーバーヘッドは大きく、障害モードはサイレントです(期限切れRRSIG、欠落したNSECチェーン)。
TR7 GTMはDNSSECを権威DNSプレーンの残りと同じ運用者表面に持ち込みます — ドメインごとのオプトイン、ファーストクラスデータとしての署名済みレコード、署名を運ぶゾーン転送 — 外部署名サービスに依存せずに。
DNSSECは、すべてのDNSSECレコードタイプのファーストクラスサポートと組み合わさったドメインごとの機能フラグです。署名と配信はTR7 GTMノード上で発生し、鍵管理は運用者と共に留まります。
TR7 GTMの各DNSドメインはブールスキーマフィールドを介してDNSSECを独立して有効または無効にします。混合展開 — 一部の署名済みゾーン、一部の未署名ゾーン — は群全体のコミットメントを強いることなく同じ群上で共存します。
DNSKEY、DS、NSEC、NSEC3、NSEC3PARAM、RRSIG、CDS、CDNSKEYは、A、AAAA、CNAME、MXおよびその他と並んでサポートされるレコードタイプリストの一部です。スキーマはそれらを別のサブシステムではなくデータとして扱います。
運用者はSOAシリアルがどう増分されるかを選択します: DEFAULT(YYYYMMDD01形式)、INCREASE(変更ごとに+1)、EPOCH(UNIXタイムスタンプ)、OFF(手動制御)。シリアル進行はDNSSECバリデーターと下流スレーブにとって重要です。
AXFR/IXFRはDNSSECレコードを他のレコードタイプと共に転送します。Expressモードスレーブはマスターの署名済み応答を再署名なしに配信します — 単一の署名ポイント、複数の配信ポイント。
TR7 GTMでのDNSSECは運用表面 — スキーマ、転送、配信、整合性 — をサードパーティ署名者に委任せずにカバーします。
各DNSドメインは`dnssec`ブールフィールドを保持します。trueの場合、ゾーンはDNSSECアクティブとして扱われます: DNSKEYとDSレコードが期待され、RRSIGレコードはワイヤー上で各RRsetに伴い、NSEC/NSEC3レコードはゾーンの名前空間をカバーします。
DNSKEYレコード(ゾーンの公開鍵)はスキーマで通常のレコードとして管理されます。運用者はDNSKEYコンテンツをインポートまたは定義します。ローテーションは標準的な事前公開ロールオーバーパターンに従い、古いものの削除前に新しいDNSKEYレコードを追加することで処理されます。
DSレコード(委任署名者)は親ゾーンで管理されます。親ゾーンと子ゾーンの両方がTR7 GTMにホストされている場合、DSレコードは自然に伝搬します。親が別の場所にある場合、運用者は上流送信のためにDSレコードをエクスポートします。
NSECとNSEC3レコードは、クエリされた名前が存在しないことを証明します。NSEC3はゾーン列挙を打ち破るためにソルトとイテレーションを追加します。両方のレコードタイプはスキーマでファーストクラスであり、ゾーンの一部として配信されます。
RRSIGレコードはRRsetに対する暗号署名を運びます。スキーマはRRSIGをレコードタイプとしてサポートし、AXFR/IXFR転送は署名済みRRsetと共にRRSIGを運びます。
CDSとCDNSKEYレコードは、子ゾーンの意図したDS状態を親に伝えます — 親側の自動化を可能にします(RFC 7344)。複数のDNSプロバイダーにわたって委任を運用する組織に有用です。
SOAシリアル進行のための4つの運用者選択可能なモード: DEFAULT(日付ベースのYYYYMMDD01)、INCREASE(変更ごとに+1)、EPOCH(UNIXタイムスタンプ)、OFF(手動制御)。署名済みゾーンは、キャッシュされた署名を無効化するためにすべての変更でシリアルを進める必要があるため、シリアル値はDNSSECに重要です。
各ドメインは、NOTIFY経由で署名済みゾーン更新をプッシュするスレーブサーバーIPをリストできます。運用者は独自の下流スレーブ(PowerDNS、BIND、NSD)を運用し、分散配信のための署名済みコピーを受け取ります。
上流マスターから取得されたExpressモードドメインは、マスターのDNSSEC状態を継承します。マスターが署名する場合、TR7は署名済み応答を配信します。マスターが署名しない場合、TR7は未署名を配信します。署名の判断はマスターに属します。
完全なレコードタイプリスト(A、AAAA、AFSDB、ALIAS、CAA、CERT、CDNSKEY、CDS、CNAME、DNSKEY、DNAME、DS、HINFO、KEY、LOC、MX、NAPTR、NS、NSEC、NSEC3、NSEC3PARAM、OPENPGPKEY、PTR、RP、RRSIG、SOA、SPF、SSHFP、SRV、TKEY、TSIG、TLSA、SMIMEA、TXT、URI)は、8つのDNSSEC関連タイプをファーストクラスメンバーとして含みます。
TR7 GTMでのDNSSECは、ゾーン転送、鍵ローテーション、親委任、バリデーター期待と共に運用されます。
DNSSECはドメインごとに有効化されます。運用者はDNSSECをゾーンごとにロールアウトし、各ゾーンを検証してから拡大します。混合状態は無期限にサポートされます — 一部のゾーンは署名済み、一部は未署名で、同じTR7群上に置けます。
DNSKEYロールオーバーは標準的な事前公開/二重署名パターンに従います: 新しい鍵をDNSKEYレコードとして追加、キャッシュが更新されるのを待ち、アクティブな署名者を切り替え、古い鍵を引退させます。スキーマは各鍵をデータとして扱い、ロールオーバースケジュールは運用者制御です。
RRSIGレコードは有効期間インターバルを運びます。運用者はリフレッシュ頻度を定義します — 通常署名は一時的な署名パイプラインの問題中にバリデーター失敗を避けるため、有効期限前に更新されます。プラットフォームは運用者アクション用に今後の有効期限を表面化します。
NSECはゾーンウォーキングを可能にします(攻撃者がすべての名前を列挙できる)。NSEC3はソルトとイテレーションを追加してウォーキングを防ぎます。運用者はゾーンごとに選択します — 公開向けゾーンは列挙を防ぐためにNSEC3を使用することが多く、クローズドゾーンはシンプルさのためにNSECを使用することがあります。
ゾーン切りの委任には、親がDSレコードを公開する必要があります。親ゾーンがTR7にホストされている場合、DSレコードは親のレコードセットの一部です。親が別の場所にある場合、運用者はCDSレコードからDS値をエクスポートし、上流に送信します。
下流スレーブサーバーはAXFR/IXFR経由で署名済みゾーンを受け取り、配信します。スレーブは再署名せず、マスターの署名を信頼します。これは分散配信(複数のスレーブPOP、地域キャッシュ)を再署名オーバーヘッドなしにサポートします。
コンプライアンスのためにDNSSEC整合性を要求する公共部門ゾーンは、署名鍵をセキュリティ境界内に保つ必要があることが多い。TR7のオンプレDNSSECは、クラウドプロバイダーに委任せずにこの要件をサポートします。
銀行および決済処理ゾーンは、顧客向けサービスに対するDNSスプーフィング攻撃を防ぐためにDNSSECを使用します。ドメインごとのオプトインにより、銀行は広範なロールアウトの前に各ゾーンを検証しながらDNSSECをゾーンごとにロールアウトできます。
マスターがゾーンを署名し、TR7ノードはExpressスレーブとして機能し、マスターの署名済み応答を配信します。署名は一度発生し、配信はエッジごとの再署名オーバーヘッドなしに大規模に発生します。
冗長性のために複数のDNSプロバイダーを使用する組織は、親ゾーンが現在のDS値を自動的に学習できるよう、TR7を介してCDSレコードを公開します。親側の自動化により手動ロールオーバー調整が低減されます。
TR7 GTMでオンプレDNSSECをご覧ください: ドメインごとのオプトイン、ファーストクラスデータとしてのすべてのDNSSECレコードタイプ、署名をそのまま運ぶゾーン転送。