トピック
DNS 委任権限
「トピックの観点から見たDNSトピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」

欧州・中東のクラウドサービストレンド
Genesis Cloudのネットワーク境界を読む:登録情報、ピアリング、BGP、DNSは何を証明するのか
登録情報、相互接続、DNS、BGP 観測、アプリケーション到達性を分けて検討し、公開記録が示す範囲と示さない範囲を明らかにする。

インターネット史
名前は完成して見えた。それでもリゾルバーは書き換えた:RFC 1535
DNS トレースを時刻順ではなく、管理権限の順に読んでみる。最初の二つの問い合わせは組織内、三つ目は無関係な公開ドメイン、四つ目が利用者の意図したらしい絶対名である。RFC 1535 が示した危険は、一つの入力が知らないうちに複数の管轄へ配られ、最初の応答が意味を決めてしまうことだった。

リーダー
Warren Kumariと、耐えられるDNS障害の設計
DNS のレジリエンスとは、障害をなくすことではない。壊れた経路を無期限に隠すことでも、古い情報を平常時から優先することでもない。役に立つサービスを限定的に維持しながら、何が壊れ、どこまで古さを許し、いつ別の経路へ移り、利用者や運用者にどのような信号を返すのかを、あらかじめ設計しておくことである。Warren Kumari が複数の共同執筆者と関わった DNS 標準は、この考え方を異なる角度から示している。

グローバルの地域 ISP トレンド
TLSA レコードを公開しても証明書の受入れは保証されない
TLSA レコードが DNS に存在していても、クライアントが利用できない、証明書と一致しない、接続を拒否すべき場合がある。DANE の保証は DNSSEC 状態、パラメータ、提示された証明書チェーン、クライアント方針、時刻がそろって初めて成立する。

グローバルの地域 ISP トレンド
NSEC3 Opt-Out の証明だけでは委任は安全にならない
DNSSEC 応答の署名が正しく検証できても、子ゾーンへの委任が安全とは限らない。NSEC3 Opt-Out が証明するのはハッシュ区間についての限定された命題であり、その区間に含まれ得るすべての委任へ信頼の連鎖を与えるものではない。

グローバルのクラウドサービストレンド
暗号化DNSがポリシー境界を動かす
DNS の暗号化は問い合わせ経路を守る一方で、リゾルバーを選ぶ主体、ローカルポリシーの適用場所、障害を説明する責任者を変える。その移動を運用可能な形で可視化する必要がある。

グローバルのクラウドサービストレンド
DNSSEC鍵ロールオーバーを支配する四つの時計
DNSSEC 鍵のロールオーバーは、権威 DNS サーバー群への反映、リゾルバーのキャッシュ、親ゾーンの委任、設定済みトラストアンカーが互いに矛盾しない状態へ達して初めて完了する。

IETF
RDAPはDELEGの二つの項目を削除した。参照先の書き込みモデルにはまだ残る
登録データの公開画面だけを見ても、その値がどう運ばれたかは分からない。ドメイン登録では、EPP の操作、権威 DNS の状態、RDAP の JSON 応答が別々の境界を持つ。9月4日に出た RDAP DELEG 草案の第05版は、読み取り側を DELEG-11 に合わせて二つの古い項目を外した。一方、規範参照している EPP 草案の正式スキーマは、その二つを今も受け付ける。これは稼働障害の報告ではない。三つの表現を結ぶ規則が、まだ一つの検証可能な契約になっていないという話である。
ケースファイル
パロディーはアドレスバーの後で始まった――PETA v Doughney
PETA は勝訴した。しかし、求めた費用のすべてを相手方に負担させたわけではなく、損害賠償も得ていない。この結末から読み始めると、*PETA v Doughney* が単純な「商標権者対パロディー」の事件ではなかったことが見える。第四巡回区控訴裁判所が問題にしたのは、`peta.org` が先に組織とのつながりを示し、ページ上の「People Eating Tasty Animals」という反対メッセージが後から現れた順序だった。さらに、登録時の説明、商業サイトへのリンク、他のドメイン、PETA に提案を促す発言が、一つの記録として評価された。

記事
LACNIC WHOIS の nslastaa は最終成功確認日であり、現在の DNS 健全性ではない
レジストリ応答に日付があると、現在も有効な保証のように見えやすい。しかし LACNIC が `nslastaa` に与えている意味は限定的だ。これは、掲載されたサーバーで正しい逆引き DNS 設定が最後に観測された日を記録する。過去の成功を示す有用な証拠ではあるが、現在の応答性や BGP 到達性まで証明するものではない。

グローバルのクラウドサービストレンド
DNS Cookieはクライアント認証ではない
DNS Cookie は、以前に発行されたプロトコル状態を返す問い合わせと、送信元アドレスを名乗るだけのパケットをサーバーが区別する助けになる。複数のオフパス攻撃を難しくする一方、共有リゾルバーの背後にいる人物、契約者、端末を特定するものではなく、DNS 経路上の観測者にも対抗できない。

記事
APNICは97億件のDNSクエリを数えた。それでも再試行した層は特定できない
APNIC Labs の実験では、権威サーバーが返す状態だけを変えると、そこへ届くクエリ数が桁違いに変わった。無応答では約97億件に達した。割り算は再現できる。だが、再送を決めた主体は合計値から復元できない。この境界を守らなければ、有力な観測が、見えていない層への断定に変わる。
記事
ルートKSKロールオーバーではリゾルバーの準備状況が継続性を決める
DNS 自体が正常でも、古いトラストアンカーを持つ検証リゾルバーの利用者には障害が見える。ルート KSK ロールオーバーでは、鍵は中央で変わるが、継続性は分散したリゾルバー群で決まる。
ケースファイル
二文字だけが事件ではなかった――Virtual Works対Volkswagenと`vw.net`をめぐる電話
二十四時間という期限は、短いドメインの希少性を意図の証拠へ変えた。第四巡回区控訴裁判所が重視したのは`vw.net`の二文字そのものではない。登録時の会話、約二年間の実利用、代替名、そして Volkswagen へ向けた売却条件を一つの時間軸で読んだ。
記事
LACNICの逆引きDNSエニーキャストはレジストリ継続性を分散制御に変える
逆引き DNS は停止するまで目立たない。LACNIC のエニーキャスト構成は、レジストリの継続性が単一サーバーではなく、配置、経路、同期、観測の運用に支えられることを示す。
IETF
拡張DNSエラーは失敗を説明しても別の応答を許可しない
DNS の失敗はプロトコル上正しくても、運用判断には情報が足りないことがある。RFC 8914は、結果を変えずに応答者が原因を詳しく示す仕組みを定めた。この分離は観測性を高める一方、診断情報をセキュリティ回避や方針変更の命令に変えない統制を必要とする。

IETF
ドローンIDがDNS委任になるとき:RFC 9886とリモートIDを支える登録連鎖
Broadcast Remote ID が運ぶのは小型の DRIP エンティティ Tag(DET)だが、それが登録体系に実際に含まれることを認証するための公開証拠は、放送フレーム内に集約されていない。逆引き DNS の委任、HHIT/BRID レコード、証明書チェーンに分散している。
IETF
ローカルルートはDNSレジリエンスを運用者の切替判断に変える
RFC 8806は、再帰リゾルバーと同じホストでルートゾーンの完全な複製を利用する方法を示す。外部ルートへの経路依存を減らし、途中の観測者からルート問い合わせを隠せる一方、複製の鮮度と遠隔ルートへの復帰を運用者自身の責任にする。
ケースファイル
ヘッダーは NOERROR。署名された本文は名前の不存在を証明した:RFC 9824
ロールバック後、二つの画面が同時に「正常」を示した。一方は旧設定が復元されたと言い、もう一方は NXDOMAIN の比率が元に戻ったと言う。しかし、署名済み NXNAME を検証した件数、CO 能力を保持したキャッシュ件数、下流で書き換えられた RCODE は誰も数えていなかった。設定と見た目は戻っても、証拠の経路が戻ったとは限らない。RFC 9824 を導入する責任は、この三つを分離して証明することから始まる。

インターネット史
その名前は .US にあった。ゾーンが委任済みとは限らない――RFC 1480
ネームサーバーの応答に一つの名前が現れる。その事実だけでは、申請者が子ゾーンを運営しているのか、上位側が A レコードを直書きしたのか、あるいは非 IP ホスト宛てのメールを MX で預けているのかは分からない。RFC 1480 の申請手順は、同じ見た目の背後にある三つの責任系統を分けていた。
