要約

  • DNS CookiesはUDP DNSへ軽量な信号を加え、server側にclient別stateを要求しない。有効なServer Cookieは過去の往復をClient Cookieと送信元IPへ弱く結び付けるだけで、人物や組織、DNS data、秘匿性、on-path攻撃への耐性は証明しない。
  • RFC 9018のversion 1は16-byte Server Cookie、SipHash-2-4、timestamp、設定可能なsecretを定める。anycastでは全nodeが同じepochを検証できなければならず、secretの配布とrotation自体が実行権限になる。
  • 証拠はCOOKIEのraw bytes、validation reason、source view、node、epoch、BADCOOKIE、緩和した防御、response size、retry outcomeを結ぶ必要がある。valid flagは証拠の結論にすぎない。

「以前に届いた」と「誰であるか」の間

大きな署名済みanswerを狙うUDP queryがauthoritative anycast serviceへ集中したとする。初見のsourceには小さなresponseだけを返し、偽装アドレスへのamplificationを抑える。あるresolverは、先ほど自分で選んだClient Cookieとserverから受け取ったServer Cookieを付けて戻る。検証が成功し、policyは少し大きいanswerを許す。

画面に「known client」と表示すれば理解しやすい。しかし、その表現はprotocolより強い。CGNATのpublic addressは短時間に別のsubscriberのtrafficを運び得る。on-path observerはoptionを複製できる。あるanycast nodeだけが、他siteでretire済みの旧secretを受理しているかもしれない。bytesが通っても、背後の主体が同じとは限らない。

DNS Cookiesが答えるのは、もっと限定された問いである。許容された時間とepochの中で、この見かけのsource addressで受信できた何者かが、このClient Cookieに結び付くserver-generated valueを得たか。queryの目的、resolverの健全性、契約上の権利は答えない。

権限を生むのはconsumerである。validatorが一つのfactを返し、rate limiterやresponse-budget policyが、そのfactと引き換えにどれだけのresourceを与えるか決める。

同じoptionに収まる二つの役割

IANAはEDNS option code 10をCOOKIEへ割り当てている。RFC 7873では、serverの値をまだ知らないclientが8-byte Client Cookieだけを送る。server responseはそれを返し、Server Cookieを追加する。次のrequestが両方を持ち帰るため、serverはclientごとの巨大なtableなしに確認できる。

Client Cookieは身分証ではない。RFC 9018はserver IPごとに異なる値と64 bitsのentropyを求め、client IPが変われば新しくし、program restartを越えて残さないことを想定する。serverにとっては、clientが自分の往復を照合するための値であり、名前やaccountではない。

Version 1 Server Cookieは16 bytes、Client Cookieと合わせたoptionは正確に24 bytesである。SipHash-2-4はClient Cookie、version、reserved field、timestamp、client IPを入力し、Server Secretをkeyとする。off-path actorは最初のresponseを受け取れず、有効なMACを新しく作ることも難しい。

server-side statelessnessはattack時のmemory負荷を抑える。一方で、secret、clock、exact parsingが重要になる。不正なlengthを寛容に受け入れること、時刻差を放置すること、必要以上にsecretを配ることは、UI上のenabled statusを変えずに保証を変える。

弱い保証に強い特権を与えない

有効なcookieは、sourceだけを偽ったrequestと、過去にresponseを受け取った可能性の高いrequestを区別する。この差を使い、first contactではtruncateするanswerを返したり、valid clientへ限定的にresponse budgetを広げたりできる。

ただし、on-path observerはcookieを見ることができ、有効期間中に再利用できる。DNS Cookiesはqueryを暗号化せず、RRsetを署名せず、resolverのsoftwareやoperatorを識別しない。DNSSEC、transaction entropy、DoT/DoH/DoQは別の問いに答える。緑色の「secure DNS」一つに統合してはならない。

実務上の原則は明確である。cookieが緩和できるのは、off-path forgeryというthreatへ直接対応する防御だけだ。recursion ACL、DNSSEC validation、abuse block、global rate ceilingを自動で無効化しない。compromised resolverも有効なcookieを持てる。

source IPも主体ではない。NATは多数を一つにし、mobilityは出口を変え、leaseは再割り当てされる。address bindingはpacket-level riskには価値があるが、社会的identityへ昇格させる根拠にはならない。

Anycastでsecretは共同運用資産になる

同じanycast IPへの連続queryが、別の都市、vendor、nodeへ届くことがある。次のnodeが前のnodeのServer Cookieを検証できなければ、route changeのたびにclientは初見へ戻る。RFC 9018がinteroperable constructionとconfigurable Server Secretを定める理由である。

rotationは三段階で進む。第一段階では全nodeへ新secretを配り、旧secretで生成しながら新旧をverifyする。第二段階で新secretによる生成を始め、旧値のverifyを続ける。第三段階でclient更新期間を待って旧secretをretireする。順序を崩すと、地理ごとのBADCOOKIE churnになる。

configuration deliveryはruntime convergenceではない。nodeごとに非秘密のepoch identifier、learned/generating/accepting状態、clock healthを示す必要がある。secretは相互運用が必要な最小setに限定し、無関係なaddress、environment、customerを一つのfailure domainへまとめない。

BADCOOKIEから原因を決めつけない

invalid Server Cookieは、expiry、client address変更、Client Cookie変更、unknown epoch、malformed option、spoofingのいずれでも生じる。BADCOOKIEは新しい値を返し、Client Cookieが一致するclientにbounded retryを許す。無限retryは防御ではなく新しいloadになる。

site別の分布を見る。一つのsiteだけ多ければsecret drift、mobile populationで増えればNATやaddress change、全siteでillegal lengthが増えればparser abuseが疑われる。intentを決める前にvalidation categoryを残す。

first contact、valid、expired、malformed、unknown epoch、BADCOOKIE、successful retry、abandonment、TCP fallbackを測る。forgeを落としてもlegitimate resolutionを完了できなければ、deploymentは成功していない。

共通層は小さく、実行判断はlocalに

Heng LuのMinimum Initial Specificationとして読むと、option code、wire length、algorithm、time semantics、BADCOOKIEが共有層である。response budget、DDoS policy、key custody、adoption timingまで世界共通にする必要はない。

Localized Future Decisionにより、capacity不足のserverはvalid cookieがあっても追加privilegeを拒める。cookie未対応の相手とのDNS自体も無効にはならない。Voluntary AdoptionではRFC publicationではなく、implementation、test、deployment、relianceが現実を作る。

IANA registryはsymbolic coordination、24-byte optionはprotocol state、responseを拡大するpolicy branchはexecutable power、送信packetはconsequenceである。running-code primacyは各層を実測させるが、codeが動いたというだけでdecisionを正当化しない。

情報源