1770464796
2026-02-07 11:33:00
1 月 8 日、DNS サービスの定期的な更新により、応答に表示される CNAME レコードの順序が変更され、一部の DNS クライアントがエイリアス レコードが最初に来ると期待していたために名前解決に失敗しました。最新のソフトウェアでは、DNS 応答内のレコードの順序は無関係なものとして扱われますが、Cloudflare チームは、一部の実装では CNAME レコードが他のすべてのレコード タイプより前に出現することを期待していることを発見しました。
この順序が変わると、DNS 解決が失敗し始め、一般的なパブリック 1.1.1.1 DNS サービスの大幅な停止が引き起こされました。 セバスチャン・ニュートブームCloudflare のシステム エンジニアである 氏は、この変更が導入された理由と時期について次のように説明しています。
キャッシュ実装のメモリ使用量を削減するためにいくつかの改善を行う一方で、CNAME レコードの順序に微妙な変更を導入しました。この変更は 2025 年 12 月 2 日に導入され、12 月 10 日にテスト環境にリリースされ、2026 年 1 月 7 日に展開が開始されました。
DNS リゾルバーが CNAME レコードで名前を検索すると、元の名前を最終アドレスにリンクする一連のエイリアス レコードが表示され、各ステップが独自の有効期限でキャッシュされます。 Cloudflareは、このチェーンの一部がキャッシュ内で期限切れになった場合、リゾルバーは期限切れの部分のみを再フェッチし、それを有効な部分と組み合わせて完全な応答を形成することに注意しています。
Cloudflareは、DNSリゾルバーがCNAMEで名前を検索するときに、元の名前を最終アドレスにリンクする一連のエイリアスレコードを確認する可能性があり、リゾルバーは各ステップを独自の有効期限でキャッシュすることを強調しています。このチェーンの一部がキャッシュ内で期限切れになった場合、リゾルバは期限切れの部分のみを再フェッチし、それをまだ有効な部分と組み合わせて完全な応答を形成します。ニュートブーム氏はこう付け加えた。
以前は、コードは新しいリストを作成し、既存の CNAME チェーンを挿入し、新しいレコードを追加していました (…) ただし、メモリの割り当てとコピーを節約するために、代わりに既存の回答リストに CNAME を追加するようにコードが変更されました。その結果、1.1.1.1 が返す応答では、最終的に解決された応答の後に CNAME レコードが下部に表示されることがありました。
;;質問セクション: ;; www.example.com。で;;回答セクション: cdn.example.com。 300 IN A 198.51.100.1 www.example.com。 3600 IN CNAME cdn.example.com。
多くの DNS クライアント実装は順序に依存しませんが、たとえば、 systemd で解決された、その他、を含む アドレス情報の取得 glibc の関数では、レコードの予期される名前を追跡し、応答の前に CNAME レコードが見つかることを期待して順番に反復することで、解決のチェーンを処理します。 Reddit では、あるユーザーが コメント:
一方で、私は彼らの事後調査の詳細とエンジニアリングにおける非常に高い水準を本当に尊敬していますが、他方で、彼らが世界に与える影響を理解するための適切なテスト（およびその文化）が整備されていないのではないかと思わずにはいられません。
で 人気のハッカー ニュース スレッド、多くのユーザーは、メッセージセクションにおけるRRsetとRRの微妙な区別によってRFCが実際に不明確なのか、それともCloudflareの開発者がRFCを誤解しているのかについて議論しています。パトリック・メイは代わりに次のようにコメントしている。
ハイラムの法則の好例: 「十分な数の API のユーザーがいれば、契約で何を約束するかは問題ではありません。システムの観察可能な動作はすべて誰かによって依存されることになります。」これは、「送信するものには保守的であり、受信するものには寛大である」というポステルの法則に従わなかったことと組み合わされています。
で インターネットドラフト IETFで議論される予定で、CloudflareはDNS応答内のCNAMEレコードを正しく処理する方法を明示的に定義するRFCを提案しています。
公開されたタイムラインによると、Cloudflareは1月7日に世界展開を開始し、1月8日の17時40分（UTC）までにサーバーの90％に到達した。同社は直後にこのインシデントを発表し、1 月 8 日の 18:27 UTC に変更の元に戻し始め、19:55 UTC までにロールバックを完了しました。
#RFC #仕様の #CNAME #順序が #Cloudflare #1.1.1.1 #の停止を引き起こした仕組み