要約

  • RFC 3130は、一日か二日のDNSSEC workshopが限界に達し、期限、反復検証、鍵rollover、組織間handoffを観測する継続環境が必要だと記録した。
  • 完全な一実装だけでは相互運用を証明できず、標準の進展には独立した実装と十分な運用経験が必要だった。
  • DNSSECは成熟度の異なるtoolboxであり、zone transfer向けTSIGの実用性は公開署名検証全体の準備完了を意味しなかった。

短い実験では、時計は問題になる前に止められる。

zoneを署名し、recordを交換し、validatorが成功するところまでは一日で見せられる。ところが署名はまだ有効で、鍵は一度もrolloverせず、parentとchildは次の状態を受け渡していない。cacheも寿命を終えていない。見栄えのよい成功は、protocolの時間を最後まで生きた成功ではなかった。

RFC 3130はIETF 49に関連して開かれたstatus meetingのInformationalな要約である。DNSSEC仕様でも逐語録でもない。研究所、registry、RIR、root server関係者、政府、vendorが何を調べ、Draft Standardへ進むため何が足りないかを整理した文書だった。

中心仕様はRFC 2535だった。BIND 8.2は一部を実装し、BIND 9は最初の完全実装と説明された。1999年以降、複数のworkshopが概念と初期codeを検証した。それでもDNSSECは一般利用されていなかった。報告が集団認識を「重要、buzzword、難しい、未成熟」と表現したのは、この距離を示す。

初期workshopは仕様と実装の誤りをよく見つけた。同じ一日・二日形式を繰り返すと、新しい問題は減った。会議はそれを完成とは読まなかった。短期形式が役立たなくなったのは、未解決問題が長期の時間軸へ移ったからだと考えた。

求められたのは継続するtest configurationだった。そこではvalidationの期限、再署名、複数回の鍵変更、階層ごとの状態遷移が実際に起きる。これはpacket testをゆっくり行うことではない。lifecycleそのものを試験対象に加えることである。

時間が経つと制度も動く。あるprojectはregistry、registrar、registrant、DNS operatorの四者を挙げた。一組織が複数役割を持つ場合も、完全に分かれる場合もある。鍵rolloverはbit列の交換だけでなく、別々の組織が正しい順番で受付、公開、検証する仕事になる。

大規模registryは委任先鍵のparent validationとDNSSEC serviceの制度設計を調べていた。NLnet Labsは複数階層へ動作を要求するrollover手順が大TLDでは実用困難になり得ると見た。root関係者は反復検証のため長期testbedを求めた。RIRはreverse treeを検討し、applicationと一般IT部門の利用はまだ薄かった。

“DNSSEC”という名前自体も注意が必要だった。RFC 3130は、RFC 2535の公開署名、RFC 2845のTSIG、RFC 3007のsecure dynamic update、CERT recordをtoolboxとしてまとめた。しかし、この分類は人工的でもあり、各要素の成熟度は異なった。

TSIGによるzone transfer保護は、実施する価値が高い段階にあった。だがlocalなshared secret transactionと、Internet規模の署名delegationは同じauthorityを持たない。一部の成熟を全体へ移すと、未検証のparent validationやresolver、applicationまで準備済みに見えてしまう。

softwareにも独立証人が不足していた。RFC 2026の標準過程は複数の相互運用実装と十分な成功運用経験を求めた。しかし本格的にDNSSEC全体を実装していたのはBINDだけだった。一つのcodebaseは自分自身との整合を示せても、別の開発者が同じ仕様を違って読んだことは発見できない。

会議は約十八か月で第二実装が必要だと認識した。これは必要性の記録であって、納品証明ではない。計画とartefact、workshop成功とdeploymentを混同してはならない。

client利用も不足していた。secure shellなどがDNSSEC dataを使う実験はあったが、gethostbynameのような通常interfaceがvalidation結果をどう渡すかは定まっていなかった。正しい署名をapplicationが使わなければ効果はない。逆に署名を万能authorizationとして扱えば、証拠以上の権限を与える。

protocol課題も残った。NXTによるauthenticated denialは、解決策の副作用が問題を上回るのではないかと議論された。parent-child validationの要素が固まりつつあっても、運用手順は未成熟だった。大zoneのCPU・memory負荷が許容できても、組織間rolloverが可能とは限らない。

この分離がRFC 3130の核心である。計算可能性は運用準備ではない。一実装は相互運用ではない。今日のSecureは期限後のSecureを証明しない。TSIGの成熟はDNSSEC全体の成熟ではない。

後のRFC 4033、4034、4035はRFC 2535の体系を置き換え、RFC 6781は運用practiceを整理し、RFC 5011は時間状態を持つtrust anchor更新を示した。これらは継続的な進化の証拠だが、RFC 3130が全てを直接生んだ証拠でも、2001年のprojectが全て完了した証拠でもない。

一般化すると、test durationはtest scopeである。authorityが期限切れになり、cacheを通り、複数組織を渡るなら、それより短い試験ではsystem全体を観測できない。短い成功を何度繰り返しても、連続した時間の代わりにはならない。

RFC 3130は、communityがproofの意味を変えた瞬間を残した。短期workshopは失敗したのではない。見える範囲を使い切った。次の証拠は、署名が期限を迎えるまで消灯してはならなかった。

典拠