要約

  • 2月の報告で ns1.ibits.xyz を二度記載していた逆引きDNSオブジェクトは、現在その名前と ns2.ibits.xyz を記載している。9月の観測では親側の応答にも両方の名前があり、最初のサーバーはSOAに権威応答した。旧事例を未修正のままとして扱うことはできない。
  • 属性の行数、異なる委任先名の数、観測された権威応答、一つの障害で同時停止しない構成は別の主張である。重複入力への限定的な対策は、サービス全体の保証やアドレス資源への制裁を意味しない。

消えた重複から始める

2026-09-14、UTC 04:12の読み取り専用照会では、8.c.4.f.f.0.c.2.ip6.arpa のWHOISオブジェクトは ns1.ibits.xyz と ns2.ibits.xyz を返した。ns1.afrinic.net に同じ逆引きドメインのNSを尋ねても、親側はこの二つの名前を示した。さらに最初の委任先へのSOA照会では、NOERROR、権威応答を示すAAフラグ、SOAレコードが得られた。

これは2月の報告より良い結果である。同じ名前を二度書いた状態は、少なくともこのオブジェクトの現在の表示には残っていない。親が一つの名前しか示さない状態でもない。最初のサーバーへの今回のSOA照会は、古いメールにあるREFUSEDとは異なる結果になった。この改善を認めることが、証拠に沿った分析の出発点となる。

ただし、観測は一つの場所、一つの時刻、一つのオブジェクトに限られる。二番目のサーバーへのSOA、個々のPTR、複数の地域からの到達性、障害時の切り替えは検証していない。両名のアドレス、経路、設置場所、事業者の違いも調べていない。公開WHOISサービスで登録オブジェクトを探すことはできるが、ここで得た運用上の証拠は記述した照会の範囲だけである。

また、誰が修正したのか、いつ修正したのか、一般的な入力検査が変わったのかは分からない。保存された一件の内容が改善したことと、すべての新規作成経路に新しい検査が導入されたことは異なる。登録内容の照会から、修正者や組織全体の展開を逆算して断定することはできない。

古い精密な報告も、現在の状態を確かめずに使えば新しい不正確な指摘になる。今回の結果は、重複がまだあるという話を退ける。しかし、行数を冗長性と読み替えてよいという話まで支えるわけではない。直った点と、まだ測っていない点を同時に残すことで、事例の意味はむしろ明確になる。

2月に何が問題とされたのか

2026-02-19、Frank Habicht はデータベース作業部会への最初のメールで、同じ nserver: の値を二度含むドメインオブジェクトの作成を拒否すべきかと尋ねた。提示された逆引きドメインには ns1.ibits.xyz が二行あった。既存の検査についても説明を求め、議長としての発言ではないと明記していた。決定の告知ではなく、検討を促す質問である。

翌日の補足メールでは、当時の文書の字義上は入力が認められることを受け入れている。問題にしたのは、人が二行を見て二つの権威サーバーと一定の予備能力があると思い込む可能性だった。添付された親側の照会結果は一つのNS名だけを示し、そのサーバーに対する別のSOA照会はREFUSEDを返していた。

この二つの結果は、同じ欠陥を別表現にしたものではない。名前の重複は、登録の二行がDNSの二つの委任先にならない理由を示す。SOAの拒否は、対象がそのゾーンをどう扱ったかに関する別の観測である。重複行を消すだけで権威応答が生まれるわけではなく、正常に応答するようになっても同じ名前が別の名前になるわけではない。

メールのコマンド出力は、その参加者が当時報告した結果として読む必要がある。この記事の著者が2月に実行した測定ではない。9月の読み取り専用照会は別の時点の証拠であり、現在の改善を示す。日付と観測者を混ぜなければ、過去の再現手順をそのまま現在の障害認定に変える誤りを防げる。

DNSでは同じデータを二つの選択肢にしない

RFC 2181の第5節は、DNSのリソースレコード集合、RRSetを定義している。同じ所有者名、クラス、型を持ち、データが異なるレコードが集合を構成する。データまで完全に同じなら、二つ目は意味のある別の選択肢ではなく、サーバーは重複を抑制すべきとされる。同じNS名を繰り返すだけで別の委任先は増えない。

WHOISは、保存された属性を調べ、編集するための情報を見せる。DNSは解決に必要なレコード集合を示す。前者に二行あっても後者では一つの異なる値しかない場合がある。DNSが仕様に沿って動いていても、登録の表示を見る人が行を数えれば、その人の認識だけが実際の委任先数を上回る。

このずれを扱うために、攻撃や現在の停止を仮定する必要はない。入力と表示から運用状態を読む際の、予測可能な取り違えである。修正済みの事例からも、この仕組みは学べる。ただし、学べる仕組みと、この特定のオブジェクトに今も同じ誤りがあるという主張を分けなければならない。

9月には二つの異なる名称が確認された。それによって、旧表示の正確な重複は解消している。しかし、その二名が異なる機械、アドレス、回線、建物、管理権限を表すかは測っていない。名前の違いは重要な事実だが、その後ろにある故障の単位まで自動的に違うとは言えない。

multipleは最低二つという規則ではない

公開テンプレートでは nserver: にmandatoryとmultipleの印が付く。前者は属性の存在が必要だという意味で、後者は繰り返し記載できるという意味である。その組み合わせ自体は最低二行を求めていない。まして二つの独立した権威サービスを保証してはいない。この読み違いは、提案する対策の範囲を変えてしまう。

2月20日の説明では、Habicht が当時リンクされていた入門文書を引用し、複数回の記載が可能という意味を明確にした。2026-03-23、Sylvain BAYA は後続のメールで最初の読み違いを認めた。一方で、単一サーバーの制限、属性比較、正しくサービスされない委任の扱い、実務文書を含む広い検討を提案した。

この反論には正当な部分がある。完全な重複を止めても、用意されていない二番目のサービスは生まれない。ゾーンの権威サーバーとして動作していない機械も、そのままでは直らない。配置や設定の支援が、もう一つの拒否メッセージより役立つ場合はある。ただし、そのことは正確な表示が無用だという意味でも、広い規制が決まったという意味でもない。

現在のテンプレート照会も、mandatory、multiple、inverse keyを返している。詳しい説明は名前の形式、末尾の点、限られた条件下で付けられるアドレスを扱う。それ自体から最低二つの異なる名前を求める条件は読み取れない。新規作成や更新を実行して検査を試してはいないため、すべての本番経路の受付挙動を確認したとも言えない。

AFRINIC の逆引きDNSの手引きは、冗長性のために少なくとも二つのネームサーバーを推奨する。事前設定、検証、委任の伝播についても説明する。これは合理的な運用上の助言である。しかし推奨、属性の繰り返し可能性、すべてのオブジェクトの受付条件は別物であり、互いを置き換えることはできない。

推奨を新しい必須条件にするなら、対象、移行、既存オブジェクトへの影響を独立に説明する必要がある。完全な重複の注意を出すために、先に単一の委任先を持つすべての有用な更新を止める必要があるとは限らない。狭い入力上の手当てと、本当に冗長なサービスを用意する投資は、責任者も費用も異なる。

四つの問いを一つの合格印にしない

まず、属性は何行あるのか。次に、それらは正規化後にいくつの異なる委任先名を示すのか。その後で、どの名前に対応するサーバーが、どの時刻と場所で、何の照会に権威応答したのかを調べる。最後に、想定する障害が起きても有用な応答経路が残るかを確認する。この四つは、同じ尺度の得点ではない。

9月の観測は最初の二問と、三問目の一部に答えている。二番目のサーバーのSOAは未照会であり、四問目の耐障害性は未測定である。親が二名を示したから二経路が独立だとすることも、一番目の成功を二番目に割り当てることもできない。正常な部分は正常と認めながら、範囲外は未確認として残す必要がある。

RFC 2182は、セカンダリーの選択を想定される故障から考える。地理的な分離とネットワーク経路上の分離の両方が重要になる。二台の機械を同じ部屋に置けば、一台の停止には備えられても、同じ停電や上位回線の障害で両方が切断される可能性がある。必要なのは名義上の複数化ではなく、合理的な障害シナリオへの備えである。

離れた拠点にも、同じ管理アカウントや配備手順といった共通の依存関係はあり得る。ただし、それは一般的に調べるべき可能性であり、このゾーンの構成として確認した事実ではない。逆に一つの名前の背後に分散した構成があることも考えられる。名称だけから独立を認定することも、共通故障を断定することも避けるべきだ。

SOAの成功は、個々のPTRが期待どおりか、DNSSECが有効か、異なる利用者が到達できるかを一度に答えない。この調査ではそれらを測っていない。メール配送、利用者損失、全体停止や安全上の被害も評価していない。下流の影響を考えるなら、まず必要な照会と失敗条件を定義し、その条件に対応した証拠を集める必要がある。

成功した観測を残すことと、不明を残すことは矛盾しない。正常な一回の応答を隠す必要はなく、未測定部分を埋めるために合格とみなす必要もない。登録の行数に、サービスの状態、到達性、障害時の生存能力をすべて背負わせるほど、表示は分かりやすく見えても判断は不正確になる。

名前を数える際にもデータを守る

限定的な対策としては、同じ内容の二属性が一つの異なる委任先しか示さないと編集者に知らせる方法が考えられる。作成時に完全な重複を拒否し、直し方を説明する案も検討できる。どちらも予測可能な入力の誤解を減らす提案であり、この記事はAFRINICにすでに導入されたと証明してはいない。

その際、行全体の単純比較や、同じ名前を含む全行の削除は適切ではない。大文字と小文字、任意の末尾の点は、別のDNS名を意味しない場合がある。一方、公開説明では委任されるドメイン内のサーバー名に限り、所定のIPv4またはIPv6のグルーアドレスを付けられる。異なる正当なアドレス情報まで捨ててはならない。

一つの委任先名を表す複数の属性が、それぞれ異なるグルーデータを保存している場合、異なる名前の数は一でも、保存すべきデータは複数ある。名前の正規化と、属性全体の重複排除は別処理である。見かけの数を正す目的で、解決に役立つ情報を失わせれば、小さな入力対策が別の運用上の欠陥を生む。

表示は、元の属性を保持しながら、異なる正規化済みの委任先名の数を別に示せる。権威応答や到達性の観測を載せるなら、時刻と範囲を伴う別の情報とすべきだ。これで「二つ」が行、名前、応答した対象のどれを指すかが分かる。いずれも共通障害を越えてサービスが残るという永久保証にはならない。

実際の冗長性に向けた助言や構築支援には、それ自身の価値がある。重複警告は予備サービスの調達や設定確認を代行しない。しかし、予備サービスの必要性を知ってもらうために、まず表示の誤解を減らすことはできる。入力対策と設備投資は補完できるが、成果、担当者、費用を混ぜるべきではない。

一件の修正から全体展開を推測しない

現在の保存内容は改善しているが、入力検査を実行していない以上、新しい重複がすべて拒否されるかは分からない。照会で見た内容と、作成経路の挙動は別の証拠である。修正済みオブジェクトを全体展開の証明に使えば、旧事例を現在の障害として使うのと反対向きの推測になる。

3月の広い提案にも、同じ区別が必要だ。単一対象の制限や不適切な委任への措置は、入力重複より大きな変更になる。参加者の意見、合意、職員の決定、展開済みの機能はそれぞれ異なる。改善した一件を肯定するために、未確認の一般規則まで肯定する必要はない。

今回得られた最も確かな土台は具体的である。同名の重複は現在のオブジェクトにはなく、親は二名を示し、最初の対象は特定のSOAに権威応答した。今後の耐障害性の調査は、測っていない対象と条件から始められる。古い画像で変化のない現場を描き続けるより、その出発点の方が役に立つ。

資料