トピック
DNS 委任権限
「トピックの観点から見たDNSトピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
ICANN
アクセント付きのドメインに、まとめて移る条件を
ラテン文字の附加記号を含むトップレベルドメインを、対応する ASCII の表記と一緒に運用する。その例外を認める案には、事業者や支配権が変わる際も一体で扱う条件が付く。使える表記が増える利点と、移行の自由度を併せて考える必要がある。
インターネット史
ドメイン項目は組織を指したが、組織そのものではなかった：RFC 1279
別名には「同じものだ」という意味が含まれる。RFC 1279 が DNS 型の木と組織型の木を接続するとき、まさにその意味を拒んだ。ドメインから大学へたどれても、ドメインが大学になるわけではない。メールボックスから人物へたどれても、文字列が人物になるわけではない。接続の便利さより、置換できないものを置換しない規律が先に置かれた。
IETF
Wes Hardakerと、二つのTTLを生き延びる必要があったDNSサーバー
旧サーバーを止める時刻は、子ゾーンの設定画面だけを見ても決められない。インターネットのどこかでは、親から受け取った別の時刻表がまだ正しく動いているからだ。
インターネット史
名前はローカルだった。それでも番号には記録が要った：RFC 1101 の DNS マッピング境界
1989 年の DNS はホスト情報を配布できたが、ネットワーク番号からそのネットワーク名を尋ねる標準的な方法はまだ持っていなかった。RFC 1101 は `IN-ADDR.ARPA` のホスト部がゼロの名前、PTR、そして必要時のマスクを運ぶ A レコードでその隙間を埋めようとした。ここから読めるのは、照会が万能の真実を生むという話ではない。ローカルな名前を検索可能にする記録は、番号を割り当てず、ネットワークを支配せず、通信の成否も証明しないという境界である。
IETF
Tobias FiebigとDNSの四つの到達性証明
「四つ」と聞くと、四台のサーバーを想像しやすい。RFC 10001が求めるのはそうではない。IPv4 で応答する権威サーバーを二つ、IPv6 で応答する権威サーバーを二つ確認する。二台のデュアルスタック機が両方に数えられるからこそ、台数と障害分離を混同しない設計が必要になる。
インターネット史
名前サービスは交渉役になりかけた――RFC 830がドメインと能力を分けた方法
宛先から二つのアドレスが返ったとしても、どちらが要求したサービスを実行できるかはまだ分からない。RFC 830の提案では、複数アドレスは選択肢であり、能力の証明ではなかった。ドメインを見つける処理の後に、別のプロセス同士が「何を提供できるか」を交渉したからである。この二段構えは、後に定着した DNS とは異なる共通層を描いていた。
IETF
David LawrenceとTTLを越えて残ったDNS応答
DNS 応答の TTL が切れた瞬間に、権威サーバーへの経路まで途切れることがある。RFC 8767は、その古い応答を無条件に復活させる仕様ではない。実際の更新試行が失敗したときだけ、期限を区切って返し、同時に権威データを探し続ける。キャッシュは継続性を支えても、名前の権威にはならない。
IETF
Steve ShengとDNSSEC保守を止めなかったロック
管理画面ではドメインが「ロック中」なのに、親ゾーンの DS レコードは正当に更新されている。RFC 10026が解くのは、この一見した矛盾だ。問うべきなのはロックという表示ではなく、誰が設定し、誰のどの命令を拒み、別の認証済み保守経路がなぜ開いていたのかである。
IETF
Peter Thomassenと全権威サーバーへの確認を要した更新
DNS の一回答は、名前解決には十分でも、親ゾーンを書き換える根拠としては足りない。Peter Thomassen による RFC 9975は、委任された権威サービス全体を観測し、不一致なら何も変更しないという境界を親側自動化に与えた。
ケースファイル
DNS の値札は、ドメインを売る権限までは証明しない
RFC 10023 は、使用中のドメインにも「交渉可能」という標識を置けるようにした。発見の手間を減らす標識と、売主の本人性、正式な価格、移転の完了を証明する仕組みは別物である。
ケースファイル
AAAAはあった。権威には届かなかった：RFC 10001が変えるDNS委任検証
ゾーン検査は AAAA の存在を確認し、変更を承認した。ところが IPv6-only の反復リゾルバーは、親側グルーの先にある兄弟ドメイン依存で停止した。RFC 10001が求めるのはレコード欄の充足ではない。アドレスファミリーごとに、委任グラフ全体を実際に歩いて権威へ到達する証拠である。
ケースファイル
空の応答リストは失敗ではない：RFC 10029が分けるDNS配送と証拠の完了
追加で二つのレコード種別を求めたのに、返ってきた完了リストは空だった。これは「何もない」という回答ではない。サーバーが拡張を理解した一方、追加種別を一つも完全には収めなかったという証拠だ。RFC 10029は、一個の応答を完全な判断材料と呼ぶ前に、その差分を読むよう求めている。
ケースファイル
レジストリがTTLを公開しても、リゾルバの時計は別に進む：RFC 10037とDNS変更窓の権限
RDAP で TTL が300と表示された瞬間を、移行の開始時刻にしてはならない。その値はレジストリのデータベースに設定された状態を示す。権威 DNS への掲載、再帰リゾルバに残る時間、利用者が到達するサービスの成否は、それぞれ別の場所で決まる。RFC 10037はこの違いを消す規格ではなく、一つ目を正確に観測するための規格である。
ケースファイル
エラーは新しい問い合わせとして戻った――DNS Report-Channelとフィードバックの権限
権威サーバーは応答を送り続けながら、検証リゾルバーがなぜそれを拒んだかを知り得ない。DNS Error Reporting は、その見えない判断を別の DNS 問い合わせとして返す。ただし、返送先を示す権限、エラーを認定する権限、報告を信頼する権限、ゾーンを直す権限は一つにならない。
ケースファイル
パケットは正確な長さを隠した、それでもリズムは語った――EDNS PaddingとDNSプライバシーの限界
DNS を暗号化すれば、問い合わせ名と応答内容は経路上の観測者から見えにくくなる。しかし、暗号文の大きさまで消えるわけではない。EDNS Padding は余分なバイトでその輪郭を粗くする。評価すべきは増えた量ではなく、異なる通信が同じ見た目になった数である。
ケースファイル
DNSが結んだのは候補だった――SVCB／HTTPSと接続を選ぶクライアントの権限
署名された DNS 応答に、優先する接続先、プロトコル、ポートがそろっていても、それだけでは接続は完成しない。理解できるか、代理経路を守れるか、実際に到達できるか、元のサービス名を認証できるかは、クライアント側に残る。
ケースファイル
フィードは正しかった。答えを書き換えたのはローカルだった――DNS RPZの権限境界
同じ脅威情報でも、NXDOMAIN、NODATA、DROP、TCP への切替え、リダイレクトでは利用者が経験する現実が違う。RPZ が運ぶのは候補となる方針であり、どの現実を選ぶかは購読側のリゾルバーが決める。
ケースファイル
ダイジェストは一致した。それでもゾーンは誤っていた――ZONEMDが証明できる完全性の範囲
暗号学的な照合は、壊れていない誤りを正しく認証することがある。ZONEMD を導入する組織に必要なのは、強い検証を弱めることではなく、その結果を運用上の正しさへ拡大解釈しないことである。
ケースファイル
シグナルは署名済みだった。委任はまだ安全ではなかった――CDS/CDNSKEYと親DSを公開する権限
子ゾーンが正しく署名した鍵変更の意思を DNS に置いても、最初の信頼経路は自動的には生まれない。CDS/CDNSKEY が機械化するのは親子間の連絡であり、運用上の支配、登録者の委任、親側の受入れ、リゾルバーの検証を同じ権限に変えるものではない。
ケースファイル
カタログは正しかった。削除権限はなかった：DNS Catalog Zonesが構成を権力に変えるとき
壊れたカタログを受け取った DNS サーバーは、最後に有効だったメンバーを維持できる。難しいのは、壊れていないカタログである。構文上は完全でも、空のメンバー一覧が誤りなら、自動化は誤った削除を正確かつ高速に実行してしまう。