要約

  • RFC 9103は、平文のゾーン転送を受動監視して内容を一括取得する経路をTLSで閉じる。一方、通信相手の関係、暗号化トラフィックの大きさや時刻、DNSSEC列挙、通常の権威応答までは隠さない。
  • 信頼できるXoTの記録には、primaryの認証、ゾーン単位の要求認可、全メッセージのTLS利用、複製の受理、transfer group全体の一貫性、受信側の保管方針が別々に必要である。

攻撃者はAXFRを要求する必要すらなかった

primaryがIP ACLで接続元を限定し、TSIGを要求していれば、無関係なクライアントは転送を受けられない。しかし、許可されたsecondaryへの応答が平文TCPを通るなら、経路上の観測者はACLを突破する必要がない。TSIGの共有鍵も要らない。正規の受信者に届くレコードを横から読むだけでよい。

RFC 9103はこの収集経路を対象にする。2021年8月にIETF Standards Trackとして発行され、完全転送のAXFRと増分転送のIXFRをTLS上で運ぶXFR over TLS（XoT）を定めた。転送ストリームは、個別照会よりも密度の高い名前、アドレス、サービス関係を一度に含み得る。そこから平文の観測者を外す意味は大きい。

ただし、脅威モデルは範囲を明示している。保護対象は転送中の現在のゾーン内容と大きさであり、ゾーンの存在、転送という行為、関係するネームサーバーの識別子を秘匿するものではない。暗号化後も通信量とタイミングから活動を推測できる場合がある。

したがって、「この転送のペイロードは受動監視から守られた」は検証可能な主張である。「ゾーンは非公開になった」は別の主張だ。

鍵は同じ安全性を開けない

TSIGは共有秘密でDNSメッセージの出所と完全性を検証する。RFC 5936は転送クライアントの認可にもTSIGを用いる。だがRFC 8945のメッセージ認証は暗号化ではない。TSIGが正しくても、平文のレコードは経路上から読める。

TLSはチャネルを扱う。RFC 9103では、secondaryがStrict Privacy profileでprimaryを認証し、primaryはmTLS、またはIP ACLと有効なTSIG／SIG(0)の組合せでクライアントを認可する。Strict TLSはサーバー認証とチャネル機密性を、mTLSはさらにクライアント認証を、TSIGはデータ出所認証を与える。それぞれ異なる証拠である。

TLS接続が成立しても、すべてのゾーンを取得する権限にはならない。複数ゾーンの要求が同じ接続を再利用できるため、一般的な実装ではXFR要求を受けてから要求単位でACLを評価する。ポートが応答したこと、TLSが成立したこと、特定ゾーンの転送が許可されたことを一つの状態にまとめてはならない。

日常経路より例外経路が主張を壊す

RFC 9103は、対象ゾーンの転送に関わるすべてのprimariesとsecondariesをtransfer groupと呼ぶ。全体の機密性を主張するには、グループ内のAXFRとIXFRのすべてがXoTだけを使う必要がある。一つの旧式secondaryや移行用の平文経路が残れば、そこが弱点になる。

よくある落とし穴はfallbackである。IXFRが提供できず、同じ認証済みTLS接続上でAXFRに切り替わるなら、量は増えてもチャネルの性質は保てる。ところがTLSが使えないと平文へ戻る設計なら、機密性の主張自体が消える。TLS proxyで暗号化が終わり、backendへ平文で送る場合も同じだ。

Opportunistic TLSは認証に失敗しても接続を続けたり、TLSが利用できなければ平文へ戻ったりできる。RFC 9103がXoTの保護にこれを不十分とする理由はここにある。

検証できる項目には差がある。TSIGなし、未許可アドレス、平文で転送を要求し、拒否を確認するのは比較的容易だ。全secondaryが未署名データを拒否するか、Strict TLSを使うか、第三者secondaryが先の複製にも同じ方針を適用するかは外部から見えにくい。RFCはその調整・強制を対象外とする。

受信成功は保管責任の開始点

primaryの認証、secondaryの認可、TLS 1.3、IXFRの完了、新serialの受理がすべて成功したとする。経路上の受動観測者は内容を失った。しかしゾーンの複製は、今度は別の管理領域に入った。

複製はゾーンファイル、journal、データベース、snapshot、backup、debug logに残り得る。運用者やsupport systemがアクセスし、別のsecondaryへ再転送することもある。権威サーバーは公開すべきレコードに通常照会で答える。これらはTLSの失敗ではなく、正しく複製された後の保管と公開の問題である。

そこで受信側の証明には、保存場所、アクセス主体、backupとlogの保持、再転送先、新しいpeerを加える手続、関係終了時の処理が必要になる。証明書やTSIG鍵を無効にすれば次の転送は止められるが、すでに渡ったファイルやbackupは回収できない。

ZONEMDも役割が違う。RFC 8976のdigestは独立したゾーンオブジェクトの検証に使える。RFC 9103がいう通りXoTとは補完的かつ直交的である。digestは転送を隠さず、TLSはゾーン内容の正確さ、最新性、人間の承認を保証しない。

公開DNSは公開のまま動く

転送盗聴とゾーン列挙は別の経路である。NSECを使う署名ゾーンは歩査できる場合がある。NSEC3はowner nameをhash化して列挙を難しくするが、XoTの機能ではない。通常の権威照会も、公開用レコードを返し続ける。

だからこそ結論は二方向に正確でなければならない。公開DNSだから転送を平文にしてよいわけではない。同時に、転送を暗号化したから公開レコードまで秘密になったわけでもない。閉じたのは、高密度の複製ストリームをそのまま読む一つの経路である。

八つの欄で作る転送機密性の受領票

範囲にはゾーン、policy version、transfer group、責任者を記す。primary identityには認証名またはSPKI pin、certificate、TLS version、実際のendpointを置く。secondary admissionにはmTLS、またはIP ACLとTSIG／SIG(0)、ゾーン単位の判断、拒否試験を置く。

transportにはAXoT／IXoT、平文禁止、fallback、proxy境界を記す。completionには要求serial、IXFRからAXFRへの変更、受理serial、errorを記す。replica custodyにはstorage、access、backup、log、onward peerを記す。

residual exposureには通常照会、NSEC／NSEC3、endpoint関係、size・timing signalを記す。revalidationにはcertificate、key、ACL、proxy、secondary、topology、signing policy、operatorの変更を置く。

TLS handshakeが証明するのはチャネルである。TSIGが証明するのはメッセージである。完了した転送が証明するのは配達である。どれも単独では、すべての複製の機密性を証明しない。

出典