パブリックDNS（1.1.1.1）で名前解決できないときの原因と対処

CloudflareのパブリックDNS「1.1.1.1」を使うと特定のドメインだけ名前解決できない、または1.1.1.1自体に届かない、という場合、原因は大きく「1.1.1.1までの経路」「ドメイン側のDNSSEC設定」「キャッシュに残った古い応答」「権威DNSサーバーの不調」に分かれます。この記事では、dig の応答コードとエラー表示から原因を絞り込み、閲覧者としての回避策と、ドメインの管理者としての直し方を順に説明します。

まず症状を2種類に分ける

最初に、問題が「すべての名前で起きる」のか「特定のドメインだけで起きる」のかを確かめます。比較のため、別事業者のパブリックDNSにも同じ問い合わせをします。

dig @1.1.1.1 example.com A
dig @1.0.0.1 example.com A
dig @8.8.8.8 example.com A
dig @1.1.1.1 www.google.com A

Windowsでは Resolve-DnsName example.com -Server 1.1.1.1 -DnsOnly でも同じ確認ができます。

• どの名前でもタイムアウトする：1.1.1.1までの経路の問題です。
• 特定のドメインだけ SERVFAIL や NXDOMAIN になる：ドメイン側の設定やキャッシュの問題の可能性が高くなります。
• 他のパブリックDNSでも同じ結果：1.1.1.1固有ではなく、ドメインの設定そのものの問題です。

dig の出力ヘッダーにある status: が応答コードです。NOERROR で回答が空なら「名前はあるがその種類のレコードが無い」、NXDOMAIN は「名前が存在しない」、SERVFAIL は「リゾルバが正しい答えを得られなかった」を意味します。

原因1：DNSSECの検証に失敗している（特定ドメインだけ SERVFAIL）

特定ドメインだけ1.1.1.1で SERVFAIL になる場合、もっとも多いのがDNSSECの不整合です。1.1.1.1はDNSSECの検証を行うため、署名や鍵の情報が壊れているドメインには、偽の応答を防ぐ目的で答えを返しません。検証をしないリゾルバ（一部のプロバイダーのDNSなど）では普通に引けるため、「1.1.1.1のせいで引けない」ように見えます。

検証を無効にする +cd を付けて比べると判別できます。

dig @1.1.1.1 example.com A        # SERVFAIL
dig @1.1.1.1 example.com A +cd    # 回答が返る → DNSSECの問題

新しめの dig では、出力に EDE: で始まる拡張エラー（Extended DNS Errors）が表示されることがあり、鍵が見つからない、署名の期限切れなど、失敗の理由の手がかりになります。

典型的な原因は、DNSの管理サービスを乗り換えたのに、レジストラにDSレコードが古いまま残っているケースです。新しいDNSサービスでは旧サービスの鍵で署名されていないため、検証が失敗します。ドメインの管理者であれば、レジストラの管理画面でDSレコードを新しいDNSサービスの値に置き換えるか、DNSSECをいったん無効にする手続きをします。DSの変更は親ゾーンでのTTLの分だけ反映に時間がかかります。これから移行する場合は、移行前にDSを削除してTTLが切れるまで待ち、ネームサーバーを切り替えてから新しいサービスでDNSSECを有効にし直す、という順番にすると、途中で検証が失敗する期間を避けやすくなります。状態の確認にはDNSVizなどの可視化ツールが便利です。

閲覧者の立場では修正できないため、サイトの運営者に連絡するのが本来の対処です。検証の無効化を常用するのは、偽の応答を受け取るリスクを高めるため避けてください。

原因2：1.1.1.1まで届いていない（すべてタイムアウト）

どの名前でもタイムアウトする場合は、1.1.1.1との通信そのものが妨げられています。

• 社内ネットワークや公衆Wi-Fiが、外部のDNSサーバーへのUDP/TCP 53番を遮断している。
• ルーターやセキュリティ製品が、DNS通信を自前のサーバーへ転送している。
• 機器やネットワークによっては 1.1.1.1 というアドレスが内部用途に使われており、Cloudflareまで届かない。

dig @1.1.1.1 example.com +tcp でTCPも試し、traceroute 1.1.1.1（Windowsは tracert）で経路を確認します。Cloudflareは診断用のページ（one.one.one.one/help）を用意しており、ブラウザで開くと1.1.1.1に接続できているか、DNS over HTTPSなどを使っているかを確認できます。画面の内容は変わることがあります（2026年10月現在）。

ネットワークの方針で外部DNSが禁止されている環境では、その方針に従い、ネットワーク管理者が指定するDNSサーバーを使うのが正しい対処です。

原因3：古い応答や否定応答がキャッシュされている

DNSレコードを追加・変更した直後に、1.1.1.1だけ古いIPやNXDOMAINを返すことがあります。リゾルバは、以前に取得した応答をTTLの間キャッシュするためです。存在しなかった名前の否定応答も、ゾーンのSOAレコードに基づく時間だけ保持されます。

dig @1.1.1.1 example.com A

ANSWER欄のTTLは、キャッシュに残っている残り秒数です。権威DNSサーバーへ直接問い合わせた結果と比べて、権威側が正しければ、残りTTLが切れるのを待てば解消します。

dig example.com NS +short
dig @ns1.example-dns.net example.com A +norecurse

Cloudflareは1.1.1.1のキャッシュを消す依頼ができる「Purge Cache」のページ（one.one.one.one/purge-cache）を公開しています。急ぎの場合は利用できますが、他のリゾルバのキャッシュには影響しません。次回の変更に備えて、作業の前日までにTTLを短くしておくのが有効な予防策です。

原因4：権威DNSサーバー側の不調

権威DNSサーバーが一部の問い合わせ元にだけ応答しない、応答が遅い、ネームサーバーの一部が停止している、といった場合も1.1.1.1で SERVFAIL になります。

dig +trace example.com A

+trace でルートから順にたどり、どのネームサーバーで止まるかを確認します。NSレコードに登録されたサーバーを一台ずつ dig @サーバー名 example.com A +norecurse で問い合わせ、応答しないものや、違う内容を返すものがないかを見ます。登録されているのに応答しないネームサーバー（いわゆるlame delegation）は、レジストラ側のNS設定を見直して取り除きます。

その他の確認ポイント

• 1.1.1.2 や 1.1.1.3 を使っている場合、これらはマルウェアや成人向けサイトを遮断するファミリー向けの設定で、遮断対象には 0.0.0.0 を返します。意図した設定か確認します。
• ブラウザやOSでDNS over HTTPS（DoH）や Cloudflare WARP を有効にしていると、OSのDNS設定とは別経路で問い合わせます。どちらの経路で失敗しているかを分けて確認します。
• 1.1.1.1はプライバシーの観点からEDNS Client Subnetを送らないため、CDNによっては利用者から遠い拠点のIPが返ることがあります。名前解決の失敗ではありませんが、表示が遅い原因になり得ます。
• Cloudflare側の障害もゼロではありません。複数のドメインで同時に失敗するならCloudflareのステータスページを確認し、端末やルーターのセカンダリDNSには別事業者のリゾルバを設定しておくと影響を抑えられます。

まとめ

• まず「すべての名前で失敗」か「特定ドメインだけ失敗」かを、別のリゾルバと比べて切り分ける。
• 特定ドメインだけの SERVFAIL は、+cd で回答が返ればDNSSECの不整合。DNSサービス移行後の古いDSレコードがよくある原因で、直すのはドメインの管理者。
• すべてタイムアウトするなら、53番の遮断やDNSの転送など、1.1.1.1までの経路を調べる。
• 古い応答はTTLの残りを確認し、権威DNSと比べる。急ぎならPurge Cacheも使えるが、事前にTTLを短くしておくのが予防になる。
• 権威DNSの不調は dig +trace とネームサーバーの個別確認で見つける。

• DNSSECを有効にする手順
• ネームサーバー変更時の注意点