問われて初めて現れた名前：DNSワイルドカードが既定値を限定した理由

要約

*.example にアドレスRRsetがあり、blue.example がないとする。後者への問い合わせに、サーバーは所有者名を blue.example とした肯定応答を返せる。値とTTLはワイルドカードから来るが、表示された所有者そのものはゾーンに保存されていなかった。

RFC 1034 は1987年、ワイルドカードRRをレコード合成の指示と説明した。未知の名前へのメール配送を共通化することが代表例だった。しかし、これは無数の名前を登録する仕組みでも、星印を正規表現にする仕組みでもない。条件が成立したときに権威サーバーが一つの処理を行う規則である。

したがって肯定応答は、誰かがその名前を個別に用意し、確認し、意図した証拠ではない。DNSが示すのは、ゾーンの規則に従えばその応答を作れたという事実までである。

サーバーは最初にラベルを完全一致させる。問い合わせ名が存在すれば、ワイルドカードは不足する型を補わない。AAAAはあるがMXがない名前はMXなしとなり、*.example のMXを借りることはない。

存在には、自身のRRsetが不要な場合もある。より深い子孫を持つ中間名は、空の非終端として木に存在する。その沈黙した節点も探索位置を変える。深い場所に一件追加した結果、以前は得られたワイルドカード応答が止まることがある。

最後の子孫を削除すれば逆も起こる。空の非終端が消え、広いワイルドカードが再び使える。星印側のデータではなく、その権限を囲む木が変化したのである。

実装経験とDNSSEC設計は、初期文書の表現をより厳密にする必要を示した。RFC 4592 は、問い合わせ名と根側から最長の連続ラベルを共有する既存節点を「closest encloser」と定義した。

完全一致が木から外れた後、候補はその直下の *.<closest-encloser> だけである。それが存在すれば合成元となる。存在しなければワイルドカード合成は行われない。

祖先へ戻って別の星印を探すこともない。候補が存在しても要求型を持たなければ、結果はワイルドカードのデータなしで終わる。遠い既定値が穴を埋めることはない。

一つの問い合わせに合成元は最大一つ。この規則で入れ子のワイルドカードも決定的になる。「配下をすべて覆う」という説明が不正確なのは、より近い節点が一つ加わるだけで候補が計算し直されるからだ。

最初のラベルが完全に * である名前だけがワイルドカード名になる。ほかの位置にある星印には特別な意味がない。問い合わせに文字どおり * を書いても、多数の名前を検索する命令にはならず、通常のラベルとして扱われる。

合成後はRR型の通常処理へ戻る。ワイルドカードCNAMEが合成されれば、続いて普通の別名解決が行われる。これはDNSをアプリケーションの転送器や証明書規則、部分一致エンジンに変えない。

RFC 1034は、ゾーン境界を越えてワイルドカード既定値を適用しないとした。委任に到達した親は子のサーバーを示し、親の星印で子の空白を埋めない。子は自らの権威データとして別のワイルドカードを置ける。

これは制御権の切れ目である。親が名前空間を委ねた後も、見えない予備回答を保持することはできない。子の運用者も親の既定動作が自動継承されるとは考えられない。

ワイルドカード応答には「より具体的な名前がなかった」という前提がある。RFC 4035 は署名ゾーンに、この前提の証明を求めた。展開後のRRsetと署名だけでなく、完全一致または近い一致が存在しないことを示す認証済みNSEC証拠も必要になる。

RRSIGのラベル数により、応答が問い合わせ名を表示していても、検証者は署名対象だった元のワイルドカード所有者を復元できる。検証するのはデータの出所と、そのデータが優先順位上使えたことの両方である。

ただしDNSSECは、入力した名前が人の意図どおりか、接続先が安全か、上位層が権限を与えるべきかを証明しない。署名ゾーンの主張と木の規則を認証するだけだ。

閉じた資料は RFC 1034、RFC 4592、RFC 4035 である。機構、用語、DNSSEC証明要件を定めるが、現在の普及率、問い合わせ量、悪用、製品挙動は測っていない。