Summary

  • 11月5日の個人草案は、CNAME を含む DNS 応答で問い合わせ名の別名を先に置き、次の別名を連鎖順に続け、最後に目的のレコードを置くよう提案する。以前の広い順序規則を、実害のあった処理に絞った。
  • 草案の1月の事例では glibc の名前解決が失敗し、一部のスイッチが NTP サーバー名を引く際に再起動した。Cisco の公式サポート文書は対象機種群と DNSC プロセスの致命的エラーを挙げる。

新しいフィールドが障害を起こしたわけではない。再帰リゾルバーは一つの Answer 区画に、最初の CNAME、次の CNAME、最終的な A レコードを入れられる。RFC 1034は CNAME を回答の前置きとして述べ、レコードを応答にコピーするよう書いたが、「コピー」が順番に追加する義務なのか明示しなかった。一方は集合として扱い、もう一方は列として読んだ。2026年1月8日、リゾルバーの更新で CNAME 応答の RRSet 順序が変わった。草案の付録によると、回帰試験は順序を重要視しておらず見逃した。glibc の検索が失敗し、設定された NTP 名を引くスイッチの一部が再起動した。

Cisco の通知は Catalyst 1200/1300 と CBS 250/350 の特定ファームウェアを示す。DNSC の致命的エラーを記録し、特定の DNS 応答形式を原因候補に挙げ、別の DNS、名前検索の停止、静的な名前対応を暫定策とする。影響した機器の総数は示さない。IETF の著者は CNAME 順序の変更と事件を結び付けるが、公式資料だけでは全体の損失規模は測れない。

11月の改訂02は、問い合わせ名の CNAME、連鎖する CNAME、最後の目標レコードという順序で追加する狭い修正を提案する。同じ RRSet の中での順序は重要ではない。クライアントは CNAME RRSet のどの並びも受け入れるべきだが、サーバーはその寛容さに頼ってはいけない。8月の改訂01は DNS 区画全般に広い順序を提案していた。作業部会の意見を受け、対象が絞られた。IETF の記録では依然として個人草案であり、RFC 1034 の更新は採択後の話だ。

古いソフトウェアの費用を誰が引き受けるか。

提案はサーバーには保守的な出力を、クライアントには柔軟な読解を求める。検証にはリゾルバーの版、両方の応答バイト列、多段 CNAME、glibc の結果、NTP 検索、スイッチのログをそろえる。

DNS の成功コードだけでは機器の稼働は分からない。