要約

  • 親が child.example のサーバーとして ns.child.example を示すと、その住所を調べるために、まだ到達できない同じ子ゾーンへ尋ねる循環が生じる。
  • Glue は親の委任応答に限定的な住所の写しを置いて循環を断つ。これは到達性の手掛かりであって権威回答ではなく、後の仕様は信頼順位と不完全な Glue の通知方法を明確にした。

実行できない紹介

反復型 DNS 検索では、リゾルバーがルートから紹介をたどる。ルートは TLD を示し、TLD は子ゾーンを示し、リゾルバー自身が次の権威サーバーへ問い合わせる。この連鎖は、子のサーバー名が子自身の内部にあると止まる。

親が child.example の権威を ns.child.example へ委任したとする。次のパケットには A または AAAA 住所が要る。ところが、その住所の権威データは child.example にあり、問い合わせ先はまさに住所が分からないサーバーである。「そのサーバーの住所を、そのサーバーに聞け」という自己参照になる。

自ゾーン内にサーバー名を置くこと自体は自然である。難しさは、管理境界を越えるための座標が境界の向こう側に保存されている点にある。

子から借りた一つの住所

1987年11月の RFC 1034 はゾーンカットを定めた。親ゾーンは NS レコードで子のサーバー名を示す。しかし名前だけでは通信を始められない。そこで親は、カットの下にあるサーバーの住所レコードを持ち、紹介応答に入れる。これが Glue である。

Glue は二つの段階を接着するが、子ゾーンの権威データではない。RFC 1034は、サーバー名がカットの下にある場合に必要で、紹介の一部としてだけ使われると境界を置いた。

親が一般的に「このホストの正しい住所はこれだ」と答えるのではない。「委任先へ最初の問い合わせを送るには、この住所を試せ」と伝える。到達した後の権威回答は子から得る。

親は委任を起動できるかどうかに実質的な力を持つ。子は自ゾーンの内容を管理する。リゾルバーは紹介を実行し、証拠を更新する。一つの住所レコードに三つの役割を背負わせないことが、分散性を実務にした。

弱い例外でなければならない理由

追加セクションのデータは別の問い合わせを省ける。だが、質問されていないレコードを添付できるため、過信すれば危険である。起動用のヒントがキャッシュ内で権威回答へ昇格すると、由来の違いが消える。

1997年の RFC 2181 は信頼順位を整理した。権威ゾーンデータは非権威回答や追加情報より上位にある。低信頼の未認証データは、後で回答として返せる形で保存してはならない。Glue は次の問い合わせを導けるが、記憶された時間だけで権威にはならない。

同じ名前の Glue が複数のゾーンにあり、値が食い違う場合もある。正しく構成された権威コピーなら起きない衝突が、親側の起動情報では起こり得る。リゾルバーには住所の集合だけでなく、出所と順位が必要である。

必須の Glue と不要な Glue

RFC 8499 は関係を整理した。委任されたゾーン内のサーバーは in-domain であり、Glue がなければ名前解決は失敗する。

同じ親の別の子にあるサーバーは sibling である。通常はその兄弟ゾーンの委任をたどって住所を引けるため、sibling Glue は最適化に近い。ただし二つの兄弟が互いの内部にサーバーを置くと循環し、親の住所情報が必要になる。

親ゾーンの外にある out-of-bailiwick サーバーに Glue を与えても起動問題は解けない。リゾルバーは DNS 木の正しい枝でその名前を調べられる。作用域外の追加住所を受け入れることは、曖昧さと攻撃面を増やすだけである。

Bailiwick はプロトコル上の範囲であり、法的な管轄ではない。親が有用な起動情報を出せる位置にいるかを示すだけで、ドメインや組織や IP 住所の所有を証明しない。

一つの委任に二つの時計

親と子は関係する別々のデータを持ち、キャッシュは別々の TTL で古くなる。RFC 1035 は必要な Glue がないゾーンファイルを読み込まない検査を求めた。また、NS レコードがキャッシュに残る一方で短い Glue TTL が切れ、候補サーバー名はあるのに住所が一つもない事態も説明した。

住所変更は単一の編集ではない。子が先に新住所を公開し、親の Glue が遅れることも、その逆もある。温まったキャッシュは動き続け、空のキャッシュだけが壊れた起動経路を示す。可用性は変更順序、重複期間、世界中の失効時刻に依存する。

親は古い Glue で子を孤立させられるが、全キャッシュを観測できない。子は正しい権威データを出していても、新しいリゾルバーが到達できない。これは強いが全知ではない制御である。

全部が一通に入らないとき

現代の紹介応答には DNSSEC 材料も入り、UDP サイズには上限がある。一部の実装は Glue の一部だけを送り、不足を示さなかった。形式上は応答でも、到達に必要な証拠集合が欠けていた。

2023年9月の RFC 9471 は RFC 1034を更新した。in-domain サーバーについて利用可能な Glue をすべて入れるか、サイズ制約なら TC フラグを立てなければならない。リゾルバーは不完全さを知り、完全な応答を運べるトランスポートで再試行する。

文書は限定された運用証拠を示す。2020年6月には必要な Glue が収まらず TC も立たない応答が観測された。2021年末の ICANN CZDS データでは、約2億900万の委任のうち222件が循環する sibling NS だけに依存していた。これは全 DNS 障害の率ではない。まれな依存形でも処理を決定的にする必要があるという証拠である。

修正は新しい中央権威を作らない。サーバーが不完全さを明示し、リゾルバーが再試行し、運用者が親子データを整合させる。共通義務は相互運用に必要な範囲へ絞られた。

細い橋は権利証ではない

Glue は一つの限定例外で自己参照を解いた。親が住所を持つのは、それなしでは子へ届かないからである。リゾルバーが使うのは、権威へ最初のパケットを送るためである。どちらも所有権、サーバーの健全性、組織の正統性を証明しない。

歴史的な成果は高速化だけではない。委任は次の権威を名指しし、Glue は到達を助け、子は権威回答を出し、リゾルバーは差を保つ。インターネットは循環から抜けたが、起動用ヒントを主権者にはしなかった。

出典と限界

1987年のゾーンカット、紹介、Glue は RFC 1034 と RFC 1035、信頼順位と衝突は RFC 2181、現在の用語は RFC 8499、完全性・切り詰め・二つの観測は RFC 9471 に基づく。後代の用語を1987年へ投影せず、観測を全数調査とも扱わない。