要約

  • Sam Weilerが執筆したRFC 5074は、親ゾーンから通常のDSレコードを得られない署名済みゾーンを検証するため、DNSSEC Lookaside Validation（DLV）を説明した。
  • DLVも信頼を不要にはしない。リゾルバーは先に別のDLVドメインを信頼アンカーとして設定し、そのドメインの認証済みレコードを対象ゾーンのDSに相当する情報として使う。
  • ISCは2017年に登録情報を削除した一方、古いリゾルバー向けに署名済みの空ゾーンを維持した。RFC 8749は2020年、通常のDNSSEC委任が広がったことと検証コードの負担を理由に、DLVをHistoricへ移した。

親ゾーンから先へ検証をつなげない場面

ゾーンが自らDNSSEC署名を付けていても、リゾルバーがその署名を信頼できる起点までたどれるとは限らない。標準的な委任では、親ゾーンがDelegation Signer（DS）レコードを公開し、子ゾーンのDNSKEYと親の署名済みデータを結び付ける。上位のどこかが未署名だったり、レジストラーが子ゾーンのDSを受け付けていなかったりすれば、検証の連鎖はそこで途切れる。DNSSEC導入の初期には、ルートや多数のトップレベルドメインがまだ署名されておらず、実際に起こり得る問題だった。

DLVはもう一つの入り口を設けた。RFC 5074によると、独立して署名されたDLVドメインは、自身の直接の子ではない下位ゾーンについても認証済みの記録を公開できる。リゾルバーはDLVレコードセットを検証したうえでDSと同じように扱い、対象ゾーンのDNSKEYや署名をさらに確認する。RFC 4431はDLVリソースレコードをタイプ32769と定めており、この仕様はMark AndrewsとSam Weilerの共著だ。Weilerが単独で書いたのではなく、RFC 5074でバリデーターの挙動と仕組み全体を記述した。

別経路は、信頼の判断をなくしたのではなく移した。リゾルバーの運用者は、利用する前にDLVドメインの信頼アンカーを設定しなければならない。RFC 5074は、通常の信頼アンカーが適用できる場合はまずそちらを試すよう勧めており、通常の検証に成功すればDLV処理は不要だ。複数のDLVドメインが同じゾーンを覆う場合の優先順位は実装に委ね、運用者が設定できるようにすることを推奨した。選択肢は増えたが、その選択を誰が行うかは明確に残された。

廃止の告知だけでは古い設定は消えない

ISCによれば、同社のDLV RegistryはDNSSEC普及を助ける暫定策として2006年に始まった。ルートやトップレベルドメインの委任に署名が増えるにつれ、別経路の必要性は薄れていった。W. MekkingとDan Mahoneyが執筆したRFC 8749は、ルートが2010年7月に署名され、2019年5月には1,531のトップレベルドメインのうち1,389がルートから安全な委任を受けていたと記録する。2020年、このRFCはRFC 4431とRFC 5074をHistoricに再分類した。

しかし、標準文書の状態を変えても、運用中の設定は自動では更新されない。ISCは2017年9月30日に登録情報を取り除いたが、dlv.isc.orgを署名済みの空ゾーンとして残した。ISCの説明では、ゾーンまで完全に削除すれば、DLVを参照する設定が残った一部の旧BINDリゾルバーが、多数の問い合わせにSERVFAILを返すおそれがあった。空ゾーンは古い設定から有効なDLV情報を返さず、同時にISCが試したレガシー環境への急な影響を避けるための措置だった。すべてのリゾルバーが同じ挙動をするという一般則ではない。

RFC 8749は利益と費用の両方を挙げる。DLVは親ゾーンの署名やレジストラーによるDS受け入れへの圧力を下げる一方、検証コードを複雑にする。執筆者が挙げた実装はBIND 9とUnboundで、民間企業での利用は把握していないと記している。これは2020年当時の文書の範囲であり、2026年の導入状況を数えたものではない。根拠から言えるのは限定的だ。DLVは通常経路が整う前の穴を埋めたが、退場時にはその標準を支えた古い設定も扱わなければならなかった。

ここではHeng LuのNote 64を編集上の問いとしてのみ参照する。共有の仕組みを必要最小限に保てるか、変更を実際の導入で判断できるかを問う視点だ。WeilerやDNSSECについての証拠ではない。

参照資料