自宅ネットワークの DNS ログから始まった調査

この話の発端は、あるエンジニア（Mike Howells 氏）が自宅で運用する Raspberry Pi ベースの DNS フィルタリングツール「Pi-hole」のログに映った一行でした。（出典）

毎時間ごとに同じクエリが記録されていたのです：

aa.ns.charter.com という名前が、ドメインコントローラー（SKYE）から定期的に解決要求され、ブロックされている

Charter は米国大手 ISP の Spectrum 傘下。ホスト名から見る限り、Charter の権威 DNS サーバーのようなものです。一見すると地味なログですが、エンジニアが掘り下げていくと、単なる DNS フィルタリングの問題では済まない実態が浮かび上がります。

Pi-hole は自宅ラボの 3 台の Windows Server 2025 ドメインコントローラー（SKYE、BOYD、EMMA）を経由した DNS クエリを監視していました。これらのサーバーは dnscrypt-proxy 経由で Cloudflare・Quad9・NextDNS といった上流リゾルバーに問い合わせています。徹底的にプライバシーとセキュリティを意識した構成です。

なぜ「ブロック」と判定されたのか—ブロックリストではなく

最初の仮説は、33 個のアドリストのうちどれかが aa.ns.charter.com を検出しているのではないか、というものでした。しかし Pi-hole の「Find Domains in Lists」ツールで調べると、結果は驚くべきものでした。

  • 完全一致：0件
  • 正規表現一致：0件
  • ブロックリスト一致：0件

どのブロックリストにも該当していないのに、Pi-hole は「ブロック」と表示していた

さらに調査を進めると、レスポンスタイムが約 69 マイクロ秒—つまり、実際の上流への問い合わせではなく、キャッシュまたは合成されたレスポンスが即座に返されていたことがわかります。

エンジニアが dnscrypt-proxy・Cloudflare の 1.1.1.1・Quad9 の 9.9.9.9 に直接 dig コマンドで問い合わせると、すべてが同じ答えを返していました：

aa.ns.charter.com → 0.0.0.0（null sinkhole アドレス）

つまり、Pi-hole は単に「ブロック」しているのではなく、上流の複数の DNS リゾルバーから 0.0.0.0 という異常な応答を受け取り、それを UI で「ブロック」と表示していたというわけです。

権威 DNS の深い層にあるバグ

この調査から、実際の問題が浮き彫りになります。DNS リゾルバーがなぜ 0.0.0.0 を返すのか。それは、aa.ns.charter.com が Charter 自身の権威 DNS サーバーであるのに、Charter がそのドメインに対して 意図的な sinkhole レコードを返していた可能性があるということです。

ISP インフラストラクチャ内部で、7年前から存在していた設定ミスまたはバグが無自覚に稼働していた

このような状況は、以下の理由で深刻です：

  • 自動化システムの動作に影響：ドメインコントローラーが毎時間このクエリを送信し続けている理由が何かは不明ですが、Windows の内部システムが定期的にこれを実行している可能性がある
  • ISP DNS の信頼性問題：複数の上流リゾルバーが同じ 0.0.0.0 を返すため、これは Charter の権威サーバー側の根本的なデータベース問題である可能性が高い
  • 7年間の放置：2019 年頃から存在していたとすれば、相当数の契約者が無自覚に影響を受けている可能性がある

参考として、最近のネットワークインフラの高度化を見ると、中国の Southeast University では 50G-PON 技術を用いた AI 搭載の全光キャンパスネットワークが展開されており、end-to-end レイテンシーが 0.1 ミリ秒という精密な環境が実現されています。（出典）一方で、この記事が示唆するのは、従来型の DNS インフラが必ずしも同じレベルの精度で監視・保守されていないという現実です。

自分自身、Python スクリプトで定期的に外部サービスの DNS 設定を検証するツールを書いたことがありますが、このような silent failure（見た目には正常に見えるが、内部で異常が続く）は本当に厄介で、ログを丹念に監視している環境でなければ発見が遅れます。ホームラボでも business 環境でも、DNS は「忘れられたインフラ」になりやすいのです。

セキュリティと運用の観点から

この事例が示唆する課題は複数あります。

観点 意味するところ
ISP の品質管理 大手 ISP でさえ 7 年来のバグを見逃していた可能性
自動検出の重要性 ホームラボのような小規模環境でも異常検知できた
DNS の可視化 Pi-hole のようなツールなしには発見困難だった
運用ログの価値 定期的なログ監視が問題解決の鍵になった

開発者や運用者の皆様にとって、この事例から学べることは：

  • DNS は「あるもの」と思わず、定期的に検証する。Pi-hole のログを眺める習慣が発見につながった
  • 数値は嘘をつかない。69 マイクロ秒という応答時間の異常さに気づくことが重要
  • 複数のリゾルバーに同じ問い合わせをしてみる。Cloudflare・Quad9・NextDNS すべてが同じ応答をしたことで、問題の根本がどこにあるかが特定できた