要約

  • DNSのAuthoritative Answerビットは、Questionの名前、またはAnswerで最初の所有者名に結び付く。同じ応答にある別名の宛先、Authority、グルー、AdditionalのRRsetは異なる出所を持ち得る。
  • 検証可能な記録では、RRsetごとに所有者、型、セクション、ゾーンカット、キャッシュ由来、DNSSEC状態を保存し、後続問合せもつなぐ。一つのヘッダビットを応答全体の権威性や真正性に拡張してはならない。

shop.exampleを問い合わせると、その名前に権威を持つサーバーがCNAMEを返した。続く宛先アドレスはキャッシュから取り出され、Additionalには次の問合せを省くための別のアドレスも入った。ヘッダのAAは1である。

監査DBが三つのRRsetを一行にまとめ、「authoritative=true」とだけ残せば、後日、宛先ゾーンから直接得たアドレスとの不一致を説明できない。別名を宣言した権威、キャッシュの時点、補助情報という差が消えているからだ。

これは実在する障害ではなく、記録設計の境界を試す仮想例である。

AAが指すのは答えの入口

Paul Mockapetrisが著したRFC 1035は、AAを応答で有効なAuthoritative Answerビットと定義する。応答サーバーがQuestionセクションのドメイン名に対する権威であることを示す。別名によってAnswerに複数の所有者名が現れる場合は、問合せ名と一致する名前、またはAnswerの最初の所有者名に対応する。

つまりAAはRRsetごとの証明欄ではない。応答経路の入口におけるサーバーの立場を示すだけで、その後に現れるすべての名前、セクション、データ源を同じ管轄に置くものではない。

RFC 1034のサーバー処理を追うと、混在が自然に生まれる。権威データでCNAMEが見つかればAnswerへ移し、QNAMEを正規名に変えて処理を再開する。委任に着けばNSをAuthorityへ置き、グルー、権威データ、キャッシュから得られるアドレスをAdditionalへ加える。最後には、ローカルにある有用なRRも追加できる。

一つのワイヤメッセージに収まったことと、一つの証拠階級に属することは同じではない。

セクション名だけでも足りない

RFC 1035では、Answerは質問への回答、Authorityは権威サーバーへの手掛かり、Additionalは関連するが厳密には回答ではない情報である。セクションを保存することは重要だが、それだけで信用度は決まらない。

親ゾーンが子ゾーンのネームサーバー用アドレスをグルーとして渡す場面を考える。アドレスを得るためにそのネームサーバーへ聞く必要がある、という循環を断つためのデータだ。解決を進める価値は高いが、親がゾーンカットの下に権威を持つわけでも、子がそのアドレスを直接答えたことになるわけでもない。

RFC 2181は出所の順位を明示する。グルー以外のゾーンファイルや転送データ、権威応答のAnswer、Authority、グルー、非権威のAnswer、Additionalは別々に扱われる。後から得た権威RRsetは、以前Additionalとしてキャッシュした値を置き換えられる。Additionalがより強いデータを押しのける根拠にはならない。

順位を捨てたキャッシュは、出所を意図せず洗浄する。補助情報だったアドレスが後にAnswerとして返されると、権威を獲得したように見える。しかし経過した時間が変えたのはTTLであり、発行主体ではない。

別名の先では管轄が変わる

RFC 2181は、別名への権威応答では、その別名を記述するRRだけが必ず権威データであり、後続データはキャッシュ由来かもしれないと説明する。正規名について権威ある回答が必要なら、改めて問い合わせるべきである。

RFC 6604はCNAMEやDNAMEのxNAME連鎖について、各段階で権威状態が異なり得ると再確認した。それでもAAはAnswerの最初の所有者名を基準にする。

shop.exampleのサーバーがservice.vendor.testへのCNAMEを権威をもって示すことと、後者のアドレスを権威をもって示すことは別だ。キャッシュされたアドレスを添えるのは合理的でも、vendor側ゾーンの発言にはならない。境界を越えるのは次の問合せであり、別の応答と時刻を持つ。

したがって台帳は、入力名、CNAME/DNAME RRset、発行ゾーン、元応答、次の名前、後続問合せを辺として残す。最終アドレスだけに畳み込むと、応答速度は得られても、誰が何を主張したかは失われる。

権威と真正性は別の軸

AAという名前は暗号学的な響きを持たないはずだが、運用画面ではしばしば緑の信頼表示へ変換される。RFC 6604は、AAヘッダビットがDNSSECで保護されないと明記する。TSIGやSIG(0)によるトランザクション保護と、RRsetに対するDNSSEC検証も別である。

RFC 4035では、RRsetの状態をSecure、Insecure、Bogus、Indeterminateに分ける。RRSIG、DNSKEY、DS、トラストアンカー、否定応答の証明、検証方針によって決まり、AAからは導けない。

ADもAAの強化版ではない。DNSSEC対応サーバーは、Answerと関係するAuthorityのRRsetを真正と見なす場合にだけADを設定する。クライアント側には、再帰サーバーと通信路への信頼、または自前の検証が必要だ。Additionalは一つのAD表示で自動的に検証済みにはならない。

同じメッセージで、最初の名前へのAAは正しく、CNAMEはSecure、宛先はInsecure、グルーはAdditional、上流への通信路は未認証、という状態が成立する。一色のバッジでは表現できないのが正常である。

Mockapetrisの記録を広げすぎない

Internet Hall of Fameの人物紹介は、Paul Mockapetrisが1983年にUSC Information Sciences InstituteでDNSを発明したと記録する。RFC 1034と1035は彼の著者名を残し、紹介ページの歴史的な公開写真は本稿の編集用肖像の本人確認資料になった。

それは、現在の権威サーバーの運用者、ゾーン所有者、トラストアンカー管理者であることを意味しない。後続RFCも共同体の標準化成果だ。人物の貢献を正確に描くには、基礎仕様が最初から置いた制限を尊重する必要がある。

パケットのラベルではなくRRsetの受領記録を作る

まずQNAME、QTYPE、QCLASS、再帰要求、DO/CD、トランザクションID、送信時刻を保存する。応答では生バイト、送信元エンドポイント、トランスポート、受信時刻、トランザクション認証の有無を固定する。

次にRRsetへ分解し、所有者、型、クラス、セクション、観測TTL、ゾーンカット、bailiwick、既知ならゾーン・転送・キャッシュ・グルーの別、キャッシュ投入時刻と期限を記す。サーバー内部の出所が分からないなら、不明のまま残す。AAで埋めてはならない。

AAの欄には、元のQNAME、Answer先頭所有者、応答サーバー、権威ゾーンだけを置く。別名と委任は後続問合せへつながる関係として残す。親のNSとグルー、子への直接問合せは関連付けても同一化しない。

DNSSEC状態はRRset単位で、署名、DS/DNSKEY経路、トラストアンカー、検証時刻、理由とともに保存する。受信ADは上流の主張として別欄に置く。アプリケーションが使ったRRsetとキャッシュ世代も最後に結ぶ。

そのとき初めて、過不足のない文が書ける。このサーバーはこの先頭名についてAAを設定した。このRRsetはこのセクションと出所から来た。この検証器はこの状態を与えた。次の名前の権威は別の問合せで確かめた。AAは応答全体の代弁をやめたとき、正確な証拠へ戻る。

情報源