
2026/01/20 2:13
**回答** **Aレコード**が先に登場しました。 * DNSでは、A(Address)レコードはホスト名をIPv4アドレスへ直接結び付けます。 * CNAME(Canonical Name)レコードは後に導入され、IP アドレスではなく別の名前へのエイリアスとして機能します。そのため解決には A(あるいは AAAA)レコードが必要です。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
(以下、翻訳)
改訂された要約
2026年1月8日、Cloudflare の 1.1.1.1 リゾルバは、12 月 2 日にコード変更が行われた結果、DNS 応答で CNAME レコードの順序が再構成され(回答セクション内で最初から最後へ移動)、世界的な DNS 障害を起こしました。Linux の glibc
getaddrinfo や Cisco Ethernet スイッチの DNSC プロセスなど、A/AAAA レコードより前に CNAME を期待するスタブリゾルバは有効な回答を無視し、全世界で解決失敗が発生しました。
Cloudflare は問題を迅速に検知しました。変更は 12 月 10 日にテストされ、1 月 7 日からグローバルに展開されました。インシデントは 18:19 に宣言され、18:27 にリバートが開始され、19:55 にはサービスが完全に復旧しました。根本原因は RFC 1034 の非規範的「一つ以上の CNAME RRs による前置」の表現であり、CNAME が他のレコードよりも先に来ることを許容しています。一方、RFC 4035 は署名付きゾーンについて明示的な「MUST」を使用しますが、未署名ゾーンの順序付けは必須としません。
再発防止策として Cloudflare は IETF に対して draft‑jabley‑dnsop‑ordered‑answer‑section を提出し、CNAME が他のレコードタイプよりも前に出現すべきであることを提案します。その間、クライアントは DNS 応答を許容的に解析するよう採用すべきです。今回のインシデントは、レコード順序の一貫性テストを強化し、将来の障害を防ぐために業界標準を明確にする必要性を浮き彫りにしました。
本文
2026‑01‑14
読み込み時間
2026年1月8日、メモリ使用量を削減することを目的とした 1.1.1.1 の定期更新が、インターネット全体のユーザーに DNS 解決失敗を引き起こしました。根本原因は攻撃や障害ではなく、DNS 応答内のレコード順序の微妙な変化でした。
タイムライン
| 時間(UTC) | 内容 |
|---|---|
| 2025‑12‑02 | 1.1.1.1 コードベースにレコード再配置を導入 |
| 2025‑12‑10 | テスト環境へ変更をリリース |
| 2026‑01‑07 23:48 | 本番へのデプロイ開始 |
| 2026‑01‑08 17:40 | サーバーの90%に到達 |
| 2026‑01‑08 18:19 | インシデント宣言 |
| 2026‑01‑08 18:27 | リリースをロールバック |
| 2026‑01‑08 19:55 | ロールバック完了 ― 影響終了 |
何が起きたのか?
キャッシュメモリ使用量を改善する過程で、CNAME レコードの順序を変更しました。この変更は 12月2日に導入され、12月10日にテストへリリースされ、1月7日から本番に展開が始まりました。
DNS CNAME チェーンの仕組み
www.example.com を問い合わせると、解決器は以下のようなエイリアスチェーンを受け取ります:
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
解決器は各中間レコードをキャッシュし、それぞれに TTL を設定します。チェーンのどこかが期限切れになると、その部分だけが再解決されます。
ロジック変更
以前は:
impl PartialChain { /// キャッシュエントリへレコードを統合して、完全なキャッシュを作成。 pub fn fill_cache(&self, entry: &mut CacheEntry) { let mut answer_rrs = Vec::with_capacity(entry.answer.len() + self.records.len()); answer_rrs.extend_from_slice(&self.records); // CNAME を先頭に answer_rrs.extend_from_slice(&entry.answer); // その後に A/AAAA entry.answer = answer_rrs; } }
メモリ節約のため、これを次のように変更しました:
impl PartialChain { /// キャッシュエントリへレコードを統合して、完全なキャッシュを作成。 pub fn fill_cache(&self, entry: &mut CacheEntry) { entry.answer.extend(self.records); // CNAME を最後に } }
その結果、一部の応答で CNAME が最終解決済みアドレスの後ろに配置されることがありました。
影響を受けた理由
多くの DNS クライアントは、CNAME が他のレコードより前に現れると仮定しています。クライアントは回答セクションを走査しながら「期待名」を追跡します:
;; QUESTION SECTION: ; www.example.com. IN A ;; ANSWER SECTION: www.example.com. 3600 IN CNAME cdn.example.com. cdn.example.com. 300 IN A 198.51.100.1
CNAME に遭遇すると、期待名を更新し、それ以降のレコードがその名前と一致する場合のみ受け入れます。もし CNAME が最後に来ると、クライアントは先頭のレコードを不整合として破棄します。
影響を受けた実装例:
- glibc の
は A/AAAA レコードより前に CNAME を期待。getaddrinfo - あるイーサネットスイッチ上で Cisco の DNSC プロセスが、再構成された応答を受信すると再起動ループになるケース。
すべての実装が壊れるわけではない
systemd-resolved のように回答全体を先にパースし、名前で検索するクライアントは順序に関係なく正しく処理できます。したがって、再配置による影響は受けません。
RFC が示すこと
RFC 1034(1987)では次のように述べられています:
「問い合わせへの回答は、必要ならば一つ以上の CNAME RR で前置され、その後に実際の解決が続く。」
「possibly prefixed」は規格的な意味を持たず、MUST や SHOULD といったキーワードは使用していません。RFC 2119(1997)以降ではそれらの用語が導入されましたが、曖昧さは残ります。
RFC 1034 は RRset を次のように定義します:
「RR の順序は重要ではありません…」
ただし、異なる RRset がメッセージ内でどのように並べられるかについては具体的な指示がなく、解釈の余地があります。後続の RFC(例:4035)は安全性レコードに対して MUST を使用した明確な順序規則を定めています。
CNAME チェーンの順序
CNAME が他のタイプより前に来るとしても、チェーン自体が順不同だとクライアントは失敗します:
cdn.example.com. 3600 IN CNAME server.cdn-provider.com. www.example.com. 3600 IN CNAME cdn.example.com. server.cdn-provider.com. 300 IN A 198.51.100.1
各 CNAME は別々の RRset に属し、RFC はそれらの間に特定の順序を要求していません。
解決器がすべきこと
RFC 1034 の解決器章(5.2.2)では、CNAME を見つけた際には、その新しい名前で再度問い合わせを開始するよう推奨しています。この指針は完全な再帰解決器向けであり、glibc の
getaddrinfo のようなスタブ解決器には必ずしも適用されません。スタブ解決器はこのロジックを省略しているため、順序の仮定が崩れると失敗します。
DNSSEC との対比
後続の RFC(例:4035)では、署名付き RRset に対して明確な順序ルール(MUST や優先順位)が設けられています。未署名ゾーンに関しては、RFC 1034 の曖昧さが残ります。
CNAME は必ず最初に来るべきか?
RFC では必須の順序を定めていませんが、多くの広く使われているクライアントはこの慣例に依存しています。将来的なインシデントを防ぐため、我々は次の対策を取っています:
- 再配置変更をロールバック。
- 以後再度順序を変更しない方針を採択。
- CNAME の明確な順序ルールを提案する Internet‑Draft を作成。
ドラフトは https://datatracker.ietf.org/doc/draft-jabley-dnsop-ordered-answer-section で確認でき、DNSOP ワーキンググループで議論されます。
Cloudflare について
Cloudflare の Connectivity Cloud は企業ネットワークを保護し、インターネット規模のアプリケーション構築を支援します。Web を高速化し DDoS 攻撃から守り、Zero‑Trust の実現に貢献しています。無料アプリ https://1.1.1.1 でインターネットをより速く安全にする方法をご覧ください。
ミッションの詳細は https://www.cloudflare.com/about/ をご覧いただき、キャリアページから求人情報も探せます。