要約

  • RFC 3123はIPv4とIPv6のprefixを順序付きで運ぶAPL RRを定義し、negation bitも保存した。しかしempty list、複数RR、未知のaddress family、!の意味はapplication specificationが別に決める必要があった。
  • syntaxが正しくDNSSECやTSIGで保護されたrecordでも、証明できるのは表現のoriginやmessageの範囲である。prefix control、policy authority、ACLのinstall、packet match、service outcomeは別のreceiptを要する。

DNSに入ったのはpolicyではなく語彙だった

2001年までにDNSはhost nameをaddressへ変えるだけの仕組みではなくなっていた。RFC 1034とRFC 1035のResource Record modelはmail routeやname serverなど多くのinfrastructure dataを運んだ。RFC 1101は組織のnetwork情報を公開する方法を示し、古いBINDにはTXTに書かれたaddress rangeをzone dataへのaccess制限に利用する例もあった。

ここでは表現方法と運用上の意味が混ざりやすい。2001年6月にExperimentalとして公開されたRFC 3123は、両者を分離した。DNS type 42のAPLは、ADDRESSFAMILY、PREFIX、N bit、AFDLENGTH、AFDPARTを持つ。family 1はIPv4、2はIPv6で、一つのRRに両方を含められた。

しかし文書はlistの共通目的を定義しなかった。組織が保有するとされるrangeの公開、classless reverse zoneの記述、access controlの材料はpossible applicationにすぎない。それぞれは別文書で指定される必要があり、例はimplementationの存在さえ意味しない。

DNS nameとtypeとpayloadは、ある表現がどこに置かれたかを示せる。だが誰がoperatorを拘束できるか、どのlocal ruleを選ぶか、どのactionが実際に起きたかまでは決めない。directoryはstatementを配っただけでprincipalにはならない。

感嘆符にはまだ判決が入っていなかった

zone fileではitemの前に!を置け、wire formatのN bitがその有無を保存した。見た目からdeny、exclude、unauthorizedと読みたくなるが、RFC 3123はそのshortcutを認めなかった。negated itemのexact semanticsはapplication側が定義する。

empty RDATAもvalidで、empty listを表した。ただし「誰も許可しない」「制限なし」「判断材料なし」「他のruleを継承」のどれかはrecordから分からない。RRsetに複数のAPL RRがあっても、その組合せ方はapplicationに残った。

想定するaddress familyと、別のfamilyや将来のunknown familyに出会った時の処理も明示事項だった。itemを無視する、RR全体を拒否する、将来のreaderのため保存する、という選択は同じではない。parserがfieldを理解しても、選択権までは取得しない。

共通layerはlocalに検証できる最小限へ留まり、future decisionはadopterに残る。punctuationを暗黙の世界共通policyにしない設計だった。

Orderとduplicateを消すことは禁止された

DNS serverやresolverはAPLを親切に整形してはならなかった。同じitemの複数出現は許され、mergeは禁止。orderも保存し、rearrangeやaggregateをしてはならない。listを単なる数学的setだと思えば冗長に見えるが、RFCはその前提を持たなかった。将来のapplicationが位置や反復に意味を持たせるかもしれないからだ。

transportの仕事はstatementを忠実に残すことであり、知らないpolicyを最適化することではない。隣接prefixをまとめたり二個目を消したりすれば、priorityやexceptionを破壊する可能性がある。

一方、address bytesには限定されたcanonical ruleがあった。prefix情報を持たない末尾のzero octetはAFDPARTから除く。同じIPv4またはIPv6 prefixが一つのwire encodingを持つためで、当時参照されたDNSSECのcanonicalizationに必要だった。

canonical bytesは「何を比較しsignするか」を安定させる。「signされた内容が何を命令するか」は安定させない。representationのdeterminismとpolicyのauthorityは別問題である。

Securityはstatementを守れてもmandateを作れない

RFC 3123は、参照するDNSSECまたはTSIGの技術がなければDNSから得た情報をunsafeと考えるべきだとした。同時に、prefix公開がtopologyを漏らし、APLからaccess-control listを組み立てる行為がsecurityを損なう可能性も警告した。

DNSSECはsigned DNS dataのoriginとintegrityを検証する助けになる。TSIGは設定済みparty間のDNS messageやtransactionをauthenticateする。改ざんされたlistがconsumerの判断を変える以上、どちらも重要だ。しかしzone operatorがfirewallを命令する権限を持つか、applicationがcurrent dataを読んだか、compileが成功したか、正しいinterfaceに付いたか、packetがそこを通ったかは証明しない。

必要なのはquery nameと時刻、exact RRset、validation state、application contractとversion、local configuration、compiled policy、enforcement receipt、traffic observationを別々に残すことだ。最初から最後へ飛ぶと、publicationをcontrolに取り違える。

DNSはdelegationとcacheによってstatementを効率よく配れる。しかしstatementのdistributionはdecision authorityのdistributionではない。zone publisherとadopting operatorは異なる主体である。

Type 42はdeployment counterではなかった

文書には組織のrange、classless reverse zone、AXFR restriction、multicast rangeという具体的な例がある。だがexample domain上のsyntax illustrationであり、RFC自身がapplicationをspecifyせず、現在または将来の存在を示さないと明記する。

Experimentalというstatusもfield trialのreceiptではない。RFC process上の分類である。後のRFC 3597はunknown RR typeをsoftwareがどう扱うかを標準化したが、APL adoptionを測定していない。RFC 4034はDNSSEC RRとcanonical処理を詳しくしても、APLへ普遍的意味を追加しない。

sourceが支えるhistoryはdesignまでである。RFC 3123はfamily、prefix length、negation、order、duplicateを保持するcompactなcontainerを作った。named implementation、zone corpus、failure、successを語るには別の一次証拠が必要だ。

境界を残したことが成果だった

shared formatは同じ表現を壊さず交換するために必要な部分だけを決めた。applicationがowner-name convention、empty behavior、multi-RR interpretation、family policy、negationを決め、operatorが採用を決め、policy engineがinstallし、packetがそのpathを通って初めてoutcomeが生じる。

分離はsuccessを保証しないが、failureの所在を見えるようにする。authentic recordがstaleな場合、正しいspecが誤設定される場合、ACLが別interfaceにinstallされる場合、成功receiptがあってもtrafficが別pathを通る場合がある。

同じprefix文字列がDNS、application model、compiled rule、packet logに現れても、一つのfactではない。time、actor、authorityが違う。

RFC 3123はDNSをnetworkの支配者にしなかった。prefix materialを正確に運ばせながら、decisionはrecordの外で証明すべきものとして残した。

情報源

  1. https://www.rfc-editor.org/rfc/rfc3123.txt
  2. https://www.rfc-editor.org/info/rfc3123
  3. https://datatracker.ietf.org/doc/rfc3123/
  4. https://www.rfc-editor.org/rfc/rfc1034.txt
  5. https://www.rfc-editor.org/rfc/rfc1035.txt
  6. https://www.rfc-editor.org/rfc/rfc1101.txt
  7. https://www.rfc-editor.org/rfc/rfc2317.txt
  8. https://www.rfc-editor.org/rfc/rfc2535.txt
  9. https://www.rfc-editor.org/rfc/rfc2845.txt
  10. https://www.rfc-editor.org/rfc/rfc2874.txt
  11. https://www.rfc-editor.org/rfc/rfc3597.txt
  12. https://www.rfc-editor.org/rfc/rfc4034.txt