主要領域
DNS
主要領域 の観点では、「DNS」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ケースファイル
鍵は見えていた。まだ信頼してはいけない
新しい公開鍵を自分自身で署名し、古い鍵を消すよう親へ頼む。その署名から分かるのは秘密鍵を持っていることまでで、委任を変更する権限までは分からない。9月7日を期限とした DNSOP の最終意見募集で、本当に設計すべき対象はこの間にある信頼状態だ。
ケースファイル
最後の点を消した瞬間、信頼境界がずれた
DNS から見れば、`example.co.uk` と `example.co.uk.` は同じノードを指し得る。ところがアプリケーションでは、二つの表記が別々の安全判断を引き起こすことがある。9月7日に締め切られる DNSOP のワーキンググループ最終意見募集と、2026年の curl 脆弱性を並べると、正規化は表示上の後始末ではないと分かる。どの判定より先に行うかが、境界そのものを決める。
IETF
QNAME 最小化はプライバシーのスイッチではなく、問い合わせシーケンスの契約である
QNAME 最小化を有効にしても、上流へ見える名前、負荷、障害はキャッシュの状態で変わる。検証すべき対象は機能フラグではなく、委任情報と否定応答から生じる上限付きの問い合わせシーケンスだ。
ケースファイル
DNSは合図を受け取った。それでも親は判断しなければならない：RFC 9859の委任境界
RFC 9859 は委任保守の確認を早める仕組みである。通知を親側の承認に、応答を DS 公開の証拠に変える仕組みではない。