主要領域
DNS
主要領域 の観点では、「DNS」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
IETF
番号が付いても、検証経路は生まれない
RFC 9563によって、SM2 署名と SM3 ダイジェストを DNSSEC 上で識別できるようになった。しかし、識別子の割当ては IETF の合意、暗号方式の適合性、バリデータの対応、運用ポリシーの受容、利用者が得る名前解決結果までを証明しない。
IETF
予備の権威サーバーは答えた。キャッシュ済み鍵では検証できなかった――RFC 8901
第一の権威 DNS 事業者が停止しても、第二の事業者は応答できる。しかし検証リゾルバーがその答えを受理できるとは限らない。RFC 8901が扱う DNSSEC 冗長性は、NS の本数ではなく署名者間の同期契約である。
インターネット史
Gihan Dias――スリランカの二つの文字をルートへ
通信回線が国に届いた日と、その国の人びとが自分たちの文字で行き先を示せるようになった日は同じではない。Gihan Dias の歩みを追うと、接続の歴史の先に、名前をめぐるもう一つのインフラ整備が見えてくる。
ケースファイル
BINDの脆弱性対応は、修正版の公開だけでは終わらない
BIND の深刻な脆弱性は、入力処理の一部をサービス停止リスクへ変える。ISC が公開した修正版と運用 guidance は、修復の出発点を示す。しかし、実際に影響を受ける運用者を特定し、修正版を展開し、復旧後の耐性を検証したことまで、公開記録だけで確認できるわけではない。
IETF
James Gouldと、方針の正しさまでは証明しない伏字シグナル
RDAP 応答から連絡先が消えている。データが最初から無かったのか、閲覧者に見せなかったのか、画面だけでは区別できない。James Gould らの RFC 9537は、その空白に構造化された説明を添えられるようにした。ただし説明できるのはサーバーが行った伏字処理までであり、隠れた値や方針の正当性まで自動的に証明するものではない。
ケースファイル
社内の名前を公開せずに、例外を確かめる
社内向け DNS を利用してよいと確認するために、社内サービスの一覧まで外部に示す必要はあるのか。RFC 9704は公開する承認とローカルに配る名前の集合を分ける。その設計は、何を見せ、どこまで任せるかという判断も要求する。
IETF
Suzanne Woolfと、機械の身元にはならないサーバーラベル
DNS 応答にサーバー識別子が入っていれば、応答した機械まで特定できたように見える。しかし、anycast、ロードバランサー、運用者が自由に決めるバイト列を考慮すると、その読み方は成立しない。Suzanne Woolf が共同執筆した RFC 4892の価値は、識別子を大きな身元証明にするのではなく、一つの応答に結び付いた小さな運用証拠として設計した点にある。
IETF
Sara Dickinsonと、暗号化だけでは証明できないリゾルバーの約束
DNS の設定画面に鍵の印が出れば、守られたことは確かにある。端末から指定した再帰リゾルバーまでの通信だ。だが、その鍵は問い合わせが到着した後の保存期間や閲覧権限、上流への送信、応答のフィルタリングまでは語らない。Sara Dickinson らがまとめた RFC 8932は、暗号化された経路の先に残る運用判断を、比較可能な約束として表に出した。
ICANN
Allison Mankinと、原因を証明できなかった名前衝突の標本
ルート DNS で同じ名前が何千回観測されても、それだけでは利用者の数も、名前を作ったアプリケーションも、委任後に壊れる機能も分からない。Allison Mankin が共著した RFC 8023は、正確な観測値と、まだ証明されていない説明の間に境界を置く。
ケースファイル
鍵は見えていた。まだ信頼してはいけない
新しい公開鍵を自分自身で署名し、古い鍵を消すよう親へ頼む。その署名から分かるのは秘密鍵を持っていることまでで、委任を変更する権限までは分からない。9月7日を期限とした DNSOP の最終意見募集で、本当に設計すべき対象はこの間にある信頼状態だ。
ケースファイル
最後の点を消した瞬間、信頼境界がずれた
DNS から見れば、`example.co.uk` と `example.co.uk.` は同じノードを指し得る。ところがアプリケーションでは、二つの表記が別々の安全判断を引き起こすことがある。9月7日に締め切られる DNSOP のワーキンググループ最終意見募集と、2026年の curl 脆弱性を並べると、正規化は表示上の後始末ではないと分かる。どの判定より先に行うかが、境界そのものを決める。
IETF
QNAME 最小化はプライバシーのスイッチではなく、問い合わせシーケンスの契約である
QNAME 最小化を有効にしても、上流へ見える名前、負荷、障害はキャッシュの状態で変わる。検証すべき対象は機能フラグではなく、委任情報と否定応答から生じる上限付きの問い合わせシーケンスだ。
ケースファイル
DNSは合図を受け取った。それでも親は判断しなければならない：RFC 9859の委任境界
RFC 9859 は委任保守の確認を早める仕組みである。通知を親側の承認に、応答を DS 公開の証拠に変える仕組みではない。