DNSで名前解決できないができない原因と対処法について

DNSで名前解決ができないとは、ドメイン名をIPアドレスに変換できない状態 のことです。

通常、Webサイトにアクセスするとき、PCやスマホはまずDNSに問い合わせて、ドメイン名に対応するIPアドレスを調べます。

たとえば、以下のような変換が行われます。

example.com → 93.184.216.34

この変換がうまくいかないと、ブラウザは接続先のサーバーを見つけられません。

その結果、Webサイトが表示されなかったり、メールの送受信ができなかったりします。

ブラウザでは、以下のようなエラーが表示されることがあります。

DNS_PROBE_FINISHED_NXDOMAIN
DNS_PROBE_FINISHED_BAD_CONFIG
ERR_NAME_NOT_RESOLVED
server IP address could not be found
名前解決に失敗しました
このサイトにアクセスできません

ただし、これらのエラーが出たからといって、必ずしもドメイン側のDNS設定だけが原因とは限りません。

端末のDNSキャッシュ、ルーター、VPN、プロキシ、社内DNS、DNSサーバー、ドメインの有効期限、DNSSEC、Webサーバー側の設定など、さまざまな要因が関係します。

この記事では、DNSで名前解決ができない主な原因と、実務で使える確認方法・対処法を詳しく解説します。

DNSで名前解決ができない状態とは

DNSはドメイン名をIPアドレスに変換する仕組み

DNSは、Webサイトやメールサーバーなどに接続するために、ドメイン名をIPアドレスへ変換する仕組みです。

人間にとっては、以下のようなドメイン名の方が覚えやすいです。

example.com
google.com
example.co.jp

しかし、実際に通信するときは、コンピューターはIPアドレスを使います。

93.184.216.34
142.250.xxx.xxx
203.0.113.10

そのため、ブラウザでURLを入力すると、端末はDNSに問い合わせて「このドメインはどのIPアドレスですか？」と確認します。

この問い合わせに失敗すると、接続先が分からず、Webサイトを表示できません。

名前解決できないと起きる症状

DNSで名前解決できない場合、主に以下のような症状が起きます。

Webサイトが開かない
特定のサイトだけ表示できない
メールが届かない
メールを送信できない
サブドメインだけアクセスできない
社内システムだけ開けない
VPN接続中だけ名前解決できない

ブラウザでは、以下のようなメッセージが表示されることがあります。

このサイトにアクセスできません
サーバーのIPアドレスが見つかりませんでした
DNS_PROBE_FINISHED_NXDOMAIN
ERR_NAME_NOT_RESOLVED

ただし、Webサイトが表示されない原因はDNSだけではありません。

DNSでIPアドレスが取得できていても、Webサーバー側の障害、SSL証明書エラー、リダイレクト設定ミス、アプリケーションエラーなどで表示できないこともあります。

そのため、まずは「本当にDNSの問題なのか」を切り分けることが重要です。

DNSで名前解決ができない主な原因

ドメイン名やURLの入力ミス

最も基本的な原因は、ドメイン名やURLの入力ミスです。

たとえば、以下のような間違いがあると、正しく名前解決できません。

example.com
exmaple.com
example.co.jp
example.jp

ドメインのスペル、トップレベルドメイン、サブドメインの有無が違うだけでも、別のドメインとして扱われます。

また、以下のような見えにくいミスもあります。

https:// example.com
https://example.com　
ｈｔｔｐｓ://example.com

半角スペース、全角スペース、全角英数字、不要な記号などが混ざっていると、正常にアクセスできない場合があります。

確認するポイントは以下です。

確認項目	内容
スペル	ドメイン名の綴りが正しいか
TLD	.com、.jp、.co.jp などが正しいか
サブドメイン	www の有無が正しいか
空白	URLの前後や途中に空白が入っていないか
全角文字	全角英数字や全角スペースが混ざっていないか
記号	不要な /、.、- などが入っていないか

特に独自ドメインを設定した直後は、example.com は開くのに www.example.com は開かない、またはその逆のケースがよくあります。

DNSキャッシュが古い

DNSにはキャッシュがあります。

一度取得したDNS情報は、端末、ブラウザ、ルーター、DNSリゾルバーなどに一時保存されます。

これにより、毎回DNSへ問い合わせる必要がなくなり、アクセスが速くなります。

しかし、サーバー移転やDNSレコード変更の直後は、古いキャッシュが残っていて、正しいIPアドレスに向かわないことがあります。

たとえば、以下のような状態です。

新しいIPアドレス：203.0.113.10
古いキャッシュ：198.51.100.20

この場合、他の人は新しいサイトを見られるのに、自分のPCだけ古いサーバーやエラー画面を見てしまうことがあります。

特に以下のタイミングでは、DNSキャッシュが原因になりやすいです。

サーバー移転後
DNSレコード変更後
CloudflareなどCDN導入後
wwwあり・なしの設定変更後
メールサーバー変更後
ネームサーバー変更後

利用中のDNSサーバーに問題がある

端末が問い合わせているDNSサーバーに問題があると、名前解決に失敗します。

通常、DNSサーバーは以下のいずれかを利用しています。

プロバイダのDNS
ルーターから配布されたDNS
社内DNS
学校や組織のDNS
Google Public DNS
Cloudflare DNS
Quad9 DNS
VPN経由のDNS

利用中のDNSサーバーが一時的に不安定な場合、複数のWebサイトで名前解決に失敗することがあります。

また、社内DNSやVPN経由のDNSを使っている場合、外部サイトや社内システムの名前解決が特殊な挙動になることもあります。

インターネット接続自体に問題がある

DNSエラーに見えても、実際にはインターネット接続そのものに問題があるケースもあります。

たとえば、以下のような状態です。

Wi-Fiには接続しているがインターネットに出られない
ルーターは動いているが回線が切れている
ONUやモデムに問題がある
VPN接続が不安定
プロキシ設定が間違っている
スマホのテザリングが不安定

この場合、DNSだけでなく、IPアドレスへの通信も失敗することがあります。

ただし、ping などの疎通確認は、環境によってはICMPがブロックされる場合があります。

そのため、ping の結果だけで完全に判断せず、nslookup、dig、curl なども併用すると正確です。

DNSレコードの設定が間違っている

Webサイト運営者側で多い原因が、DNSレコードの設定ミスです。

DNSレコードには、主に以下のような種類があります。

レコード	役割
Aレコード	ドメインをIPv4アドレスに向ける
AAAAレコード	ドメインをIPv6アドレスに向ける
CNAMEレコード	別のドメイン名に向ける
MXレコード	メールサーバーを指定する
TXTレコード	SPF、DKIM、認証情報などを設定する
NSレコード	権威DNSサーバーを指定する
SOAレコード	DNSゾーンの基本情報を定義する

Webサイトが開かない場合は、Aレコード、AAAAレコード、CNAMEレコードの設定ミスが多いです。

たとえば、以下のような設定が必要になることがあります。

example.com      A      203.0.113.10
www.example.com  CNAME  example.com

しかし、IPアドレスが間違っていたり、サブドメインのレコードが未設定だったりすると、名前解決に失敗します。

よくある設定ミスは以下です。

設定ミス	起きる症状
AレコードのIPアドレスが違う	違うサーバーに接続される
Aレコードが未設定	ルートドメインが開かない
CNAMEの向き先が違う	サブドメインが開かない
www のレコードがない	www.example.com だけ開かない
AAAAレコードが古い	IPv6環境で接続が遅い、または失敗する
MXレコードが違う	メールが届かない
TXTレコードが不足	メール認証やサービス認証に失敗する
TTLが長い	変更後もしばらく古い情報が残る

ネームサーバーの設定が間違っている

DNSレコードを正しく設定していても、ネームサーバーの設定が間違っていると、その変更は反映されません。

ネームサーバーとは、そのドメインのDNS情報を管理しているサーバーです。

たとえば、以下のようなケースがあります。

ドメイン取得：お名前.com
サーバー：Xserver
DNS管理：Cloudflare
メール：Google Workspace

このように複数のサービスを使っている場合、どのDNS管理画面が実際に使われているのか分からなくなることがあります。

よくある失敗例は以下です。

実際のネームサーバー：お名前.com
編集しているDNS管理画面：Cloudflare

この場合、Cloudflare側でAレコードを変更しても、ドメインはお名前.com側のDNSを見ているため、変更は反映されません。

現在使われているネームサーバーは、以下のコマンドで確認できます。

dig NS example.com

Windowsでは以下でも確認できます。

nslookup -type=NS example.com

返ってきたネームサーバーが、実際に有効なDNS管理先です。

DNS変更直後で反映待ちになっている

DNSレコードを変更しても、すぐに全員の環境で新しい結果になるとは限りません。

よく「DNSの浸透」と呼ばれますが、実際には主にDNSキャッシュやTTLの影響です。

TTLとは、DNS情報をどれくらいの時間キャッシュしてよいかを示す値です。

TTL 300秒    = 5分
TTL 3600秒   = 1時間
TTL 86400秒  = 24時間

TTLが長い状態でDNSを変更すると、古いDNS情報がしばらく残ることがあります。

たとえば、サーバー移転時は以下のような流れが理想です。

移転前にTTLを短くする
↓
DNSレコードを新サーバーへ切り替える
↓
動作確認する
↓
問題がなければTTLを適切な値に戻す

ただし、DNSの反映時間はTTLだけで決まるわけではありません。

リゾルバー側のキャッシュ方針、ネガティブキャッシュ、ネームサーバー変更、DNSSECのDSレコード変更などにより、想定より時間がかかることもあります。

ドメインの有効期限が切れている

ドメインの有効期限が切れていると、DNSが正常に応答しなくなることがあります。

以下のような症状が出る場合があります。

Webサイトが開かない
メールが届かない
NXDOMAINのようなエラーになる
レジストラのパーキングページに表示が変わる
WHOISで期限切れや保留状態になっている

ただし、有効期限切れ時の挙動はレジストラやドメインの状態によって異なります。

たとえば、以下のような状態になることがあります。

DNS応答が止まる
ネームサーバーが差し替わる
広告ページに転送される
clientHoldやserverHoldになる
メールだけ停止する

確認すべき項目は以下です。

確認項目	内容
ドメイン有効期限	期限切れになっていないか
自動更新	有効になっているか
支払い状況	クレジットカード期限切れなどがないか
ドメインステータス	clientHold、serverHold などになっていないか
登録者情報	メール認証が未完了になっていないか

特に、登録者情報のメールアドレス認証を放置すると、ドメインが一時停止される場合があります。

DNSSECの設定に問題がある

DNSSECは、DNS応答が改ざんされていないか検証するための仕組みです。

セキュリティを高められる一方で、設定を間違えると名前解決に失敗することがあります。

よくあるのは、DNSサーバーを移行した後に、古いDSレコードが親ゾーン側に残っているケースです。

DNSSECを有効化
↓
DNSサーバーを別サービスへ移行
↓
古いDSレコードがレジストラ側に残る
↓
DNSSEC検証に失敗
↓
SERVFAILになる

この場合、DNSSECを検証するDNSリゾルバーでは名前解決できず、検証しない環境では解決できることがあります。

DNSSECが原因の場合は、以下を確認します。

DNS事業者側のDNSSEC設定
レジストラ側のDSレコード
KSKやZSKの状態
DNSSECを無効化した場合のDSレコード削除状況

DNSSECを無効化する場合も、DNS管理画面でオフにするだけでは不十分なことがあります。

親ゾーン側に登録されているDSレコードの削除が必要になる場合があるため、レジストラ側の設定も確認してください。

IPv6関連の設定に問題がある

Aレコードが正しくても、AAAAレコードが間違っていると、IPv6環境で接続が遅くなったり、失敗したりすることがあります。

たとえば、以下のような状態です。

Aレコード：正しいIPv4アドレス
AAAAレコード：古いIPv6アドレス

この場合、IPv6を優先する環境では、古いIPv6アドレスへ接続しようとして失敗することがあります。

ただし、近年のOSやブラウザでは、IPv6で接続できない場合にIPv4へ切り替える仕組みがあるため、必ず失敗するとは限りません。

そのため、環境によって「開ける人」と「開けない人」が分かれることがあります。

AレコードとAAAAレコードは、それぞれ以下のように確認します。

dig A example.com
dig AAAA example.com

AAAAレコードが不要であれば削除し、必要な場合は正しいIPv6アドレスを設定します。

VPN・プロキシ・社内DNSの影響を受けている

会社や学校のネットワークでは、独自のDNS、プロキシ、VPN、セキュリティ製品を利用していることがあります。

そのため、以下のような症状が出ることがあります。

会社のネットワークだけ開けない
自宅では開けるが社内では開けない
VPN接続中だけ名前解決できない
VPNを切ると開ける
社内システムだけ名前解決できない
特定の外部サイトだけブロックされる

社内DNSでは、外部ドメインだけでなく、社内専用のドメインを名前解決していることがあります。

例：

intranet.local
server.internal
dev.example.local

このような環境でDNSサーバーをGoogle Public DNSやCloudflare DNSに変更すると、社内システムへ接続できなくなる場合があります。

業務端末では、自己判断でDNSやプロキシ設定を変更せず、情報システム部門に確認するのが安全です。

セキュリティソフトやファイアウォールがDNS通信を妨げている

セキュリティソフト、ファイアウォール、広告ブロッカー、VPNソフト、Webフィルタリング製品などがDNS通信を制御している場合があります。

DNSは通常、以下のポートを使います。

UDP 53
TCP 53

また、近年は以下のような方式も使われます。

DNS over HTTPS
DNS over TLS

セキュリティ製品がDNSリクエストをブロックしたり、別のDNSへ転送したり、危険と判断したドメインへのアクセスを止めたりすることがあります。

確認するポイントは以下です。

DNS保護機能
Web保護機能
広告ブロック機能
VPN機能
フィルタリング機能
ファイアウォール設定
ブラウザのセキュアDNS設定

原因切り分けのために設定を変更する場合は、セキュリティソフト全体を停止するのではなく、関連しそうな機能単位で確認する方が安全です。

業務端末では、管理者に確認してから対応してください。

hostsファイルに古い設定が残っている

端末のhostsファイルに手動でドメインとIPアドレスを設定していると、DNSよりもhostsファイルの内容が優先されることがあります。

たとえば、以下のような記述が残っているケースです。

192.0.2.10 example.com

この場合、DNS上では正しいIPアドレスに変更されていても、自分のPCだけ古いIPアドレスを見続ける可能性があります。

hostsファイルの場所は以下です。

OS	hostsファイルの場所
Windows	C:\Windows\System32\drivers\etc\hosts
Mac	/etc/hosts
Linux	/etc/hosts

不要な設定がある場合は、削除するかコメントアウトします。

# 192.0.2.10 example.com

変更後は、OSのDNSキャッシュを削除すると確実です。

サブドメインの設定が漏れている

メインドメインは開くのに、サブドメインだけ開かない場合は、サブドメインのDNSレコードが未設定の可能性があります。

例：

example.com は開く
www.example.com は開かない

または、

example.com は開く
shop.example.com は開かない

この場合、www や shop のAレコード、CNAMEレコードが設定されているか確認します。

dig www.example.com
dig shop.example.com

よくある設定例は以下です。

example.com       A      203.0.113.10
www.example.com   CNAME  example.com
shop.example.com  CNAME  shops.example-service.com

また、DNSで名前解決できても、Webサーバー側がそのサブドメインを受け付ける設定になっていなければ、サイトは正しく表示されません。

そのため、サブドメインでは以下も確認します。

DNSレコード
Webサーバーのドメイン設定
SSL証明書の対象ドメイン
リダイレクト設定
CDNやWAFの設定

CNAMEの設定ルールに違反している

CNAMEレコードには重要なルールがあります。

同じホスト名にCNAMEレコードと、Aレコード、AAAAレコード、MXレコード、TXTレコードなどを同時に設定することは、原則としてできません。

悪い例は以下です。

www.example.com  CNAME  example.com
www.example.com  A      203.0.113.10

また、以下のような設定も避けるべきです。

www.example.com  CNAME  example.com
www.example.com  TXT    v=spf1 include:example.com ~all

CNAMEは、その名前を別名として扱うため、同じ名前に他のレコードがあるとDNS仕様上の矛盾が生じます。

また、example.com のようなゾーンapexには、通常CNAMEレコードを設定できません。

ゾーンapexにはSOAレコードやNSレコードが必要であり、CNAMEは同じ名前に他のレコードを共存させられないためです。

ルートドメインを外部サービスへ向けたい場合は、DNS事業者が提供する以下のような機能を使うことがあります。

ALIAS
ANAME
CNAME flattening

Shopify、Vercel、Netlify、Cloudflareなどを使う場合は、各サービスが指定するDNS設定方法に従ってください。

権威DNSサーバーに問題がある

権威DNSサーバーとは、そのドメインの正式なDNS情報を持っているDNSサーバーです。

この権威DNSサーバーに障害があると、名前解決できなくなります。

特に以下のようなケースでは注意が必要です。

ネームサーバーが1台しかない
複数のネームサーバーが同じ障害影響範囲にある
一部の権威DNSだけ古い情報を返している
ゾーン転送や同期に失敗している
DNS事業者側で障害が発生している

まずNSレコードを確認します。

dig NS example.com

そのうえで、各権威DNSサーバーへ直接問い合わせます。

dig @ns1.example-dns.com example.com A
dig @ns2.example-dns.com example.com A

複数の権威DNSサーバーが異なる結果を返す場合、DNSゾーンの同期不整合が起きている可能性があります。

Webサーバー側の問題をDNS問題と勘違いしている

名前解決ができていても、Webサイトが表示されないことがあります。

この場合、DNSではなく、Webサーバー側の問題である可能性があります。

たとえば、以下のような原因です。

Webサーバーが停止している
SSL証明書が正しくない
NginxやApacheのVirtualHost設定が間違っている
server_nameの設定が漏れている
80番・443番ポートが閉じている
WAFでブロックされている
CDN設定が間違っている
リダイレクトループが起きている
アプリケーションで500エラーが出ている

DNSが正しく引けているかは、以下で確認できます。

dig example.com

または、

nslookup example.com

IPアドレスが返っている場合、名前解決自体は成功している可能性が高いです。

その次に、Webサーバーの応答を確認します。

curl -I https://example.com

ただし、現在のWebサイトはHTTPSやSNI、名前ベースのバーチャルホストを使っていることが多いため、IPアドレスをブラウザに直接入力しても正しいサイトが表示されるとは限りません。

DNSで名前解決できないときの確認手順

自分だけの問題か、全員の問題か確認する

まず確認すべきなのは、問題が自分の環境だけで起きているのか、他の環境でも起きているのかです。

以下のように複数の環境で確認します。

自分のPC
別ブラウザ
シークレットウィンドウ
スマホのWi-Fi
スマホの4G/5G回線
別のPC
外部DNSチェックツール

結果によって、原因を大まかに切り分けられます。

状況	原因候補
自分のPCだけ失敗	DNSキャッシュ、hosts、ブラウザ、端末設定
同じWi-Fi内だけ失敗	ルーター、プロバイダDNS、回線
会社のネットワークだけ失敗	社内DNS、プロキシ、VPN、フィルタリング
スマホ回線では開ける	Wi-Fi側、ルーター、プロバイダDNSの問題
どこからでも失敗	ドメイン側DNS、NS、DNSSEC、ドメイン失効
一部地域や一部ユーザーだけ失敗	DNSキャッシュ、CDN、IPv6、権威DNSの不整合

最初にこの切り分けを行うことで、無駄な設定変更を避けられます。

IPアドレスへの通信とドメイン名での通信を分けて確認する

DNSの問題か、ネットワーク全体の問題かを切り分けるために、IPアドレスとドメイン名で確認します。

たとえば、以下を実行します。

ping 8.8.8.8
ping google.com

結果の目安は以下です。

結果	考えられる原因
8.8.8.8 は成功、ドメイン名は失敗	DNSの問題
両方失敗	ネットワーク接続の問題
ドメイン名は引けるがWebが開かない	WebサーバーやSSLの問題
特定ドメインだけ失敗	対象ドメインのDNS設定問題

ただし、ping はICMPを使うため、ネットワークやサーバーによっては応答がブロックされることがあります。

ping だけで断定せず、DNS確認には nslookup や dig を併用しましょう。

nslookupでDNSの応答を確認する

WindowsでもMacでも使いやすいのが nslookup です。

基本的な確認は以下です。

nslookup example.com

正常に名前解決できている場合は、IPアドレスが返ります。

Name: example.com
Address: 203.0.113.10

特定のDNSサーバーを指定して確認することもできます。

nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

複数のDNSサーバーで結果が異なる場合、DNSキャッシュや反映待ちの可能性があります。

NSレコードを確認する場合は以下です。

nslookup -type=NS example.com

MXレコードを確認する場合は以下です。

nslookup -type=MX example.com

digでDNSレコードを詳しく確認する

MacやLinuxでは、dig を使うとDNSレコードを詳しく確認できます。

Aレコードを確認する場合は以下です。

dig A example.com

AAAAレコードを確認する場合は以下です。

dig AAAA example.com

CNAMEレコードを確認する場合は以下です。

dig CNAME www.example.com

NSレコードを確認する場合は以下です。

dig NS example.com

MXレコードを確認する場合は以下です。

dig MX example.com

結果を簡潔に見たい場合は、+short を付けます。

dig +short example.com
dig +short A example.com
dig +short NS example.com
dig +short MX example.com

DNSサーバーを指定して確認する場合は以下です。

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @9.9.9.9 example.com

権威DNSまでの流れを確認する場合は、以下を使います。

dig +trace example.com

dig +trace は、ルートDNSからTLD、権威DNSへ順番に問い合わせるため、どの段階で名前解決が失敗しているかを確認するのに役立ちます。

NXDOMAIN・SERVFAIL・NOERRORの違いを確認する

DNSのエラーには種類があります。

代表的なものは以下です。

状態	意味	主な原因
NXDOMAIN	問い合わせた名前自体が存在しない	入力ミス、サブドメイン未作成、ドメイン失効
SERVFAIL	DNSサーバー側で解決に失敗	DNSSECミス、権威DNS障害、NS不整合
REFUSED	DNS問い合わせが拒否された	DNSサーバーの設定、アクセス制限
TIMEOUT	DNSサーバーから応答がない	DNSサーバー停止、ネットワーク障害
NOERROR + Answerなし	名前は存在するが該当レコードがない	Aレコード未設定、AAAAレコード未設定など

特に、NXDOMAINとNOERROR + Answerなしは区別が重要です。

NXDOMAINは、その名前自体がDNS上に存在しないことを示します。

一方、ドメイン名は存在しているがAレコードだけがない場合は、NOERRORだがAnswerなしになることがあります。

たとえば、以下のようなケースです。

example.com は存在する
しかし Aレコードは設定されていない

この場合、必ずしもNXDOMAINになるわけではありません。

端末側でできる対処法

ブラウザを変えて確認する

まず、別のブラウザでアクセスしてみます。

Chrome
Edge
Firefox
Safari

特定のブラウザだけで問題が起きている場合、ブラウザキャッシュ、拡張機能、セキュアDNS設定、プロキシ設定などが原因の可能性があります。

シークレットウィンドウで確認する

ブラウザのキャッシュや拡張機能の影響を避けるため、シークレットウィンドウやプライベートブラウズで確認します。

シークレットウィンドウで開ける場合は、以下が原因の可能性があります。

ブラウザキャッシュ
Cookie
拡張機能
広告ブロッカー
ログイン状態
ブラウザ設定

DNSキャッシュを削除する

端末に残っている古いDNSキャッシュを削除します。

Windowsでは、コマンドプロンプトを開き、以下を実行します。

ipconfig /flushdns

Macでは、以下のコマンドを使うことが多いです。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

macOSではバージョンによってDNSキャッシュ削除コマンドが異なる場合があります。

うまくいかない場合は、利用中のmacOSに対応したコマンドを確認してください。

ブラウザを完全終了して再起動する

OSのDNSキャッシュだけでなく、ブラウザ側にキャッシュが残っていることもあります。

Chromeなどでは、バージョンによって以下のページからDNS関連のキャッシュやソケットをクリアできる場合があります。

chrome://net-internals/#dns
chrome://net-internals/#sockets

ただし、Chromeの仕様変更により画面構成が変わることがあります。

そのため、基本的にはブラウザを完全終了して再起動する、必要に応じて端末を再起動する方法も有効です。

ルーターを再起動する

家庭やオフィスのルーターがDNS情報をキャッシュしていたり、DNSサーバーとして動作していたりすることがあります。

その場合は、ルーターを再起動します。

ルーターの電源を切る
↓
30秒ほど待つ
↓
再度電源を入れる

ONUやモデムが別にある場合は、それらも含めて再起動することで改善することがあります。

DNSサーバーを変更する

利用中のDNSサーバーに問題がある場合は、別のDNSサーバーに変更することで改善することがあります。

代表的なパブリックDNSは以下です。

DNSサービス	優先DNS	代替DNS
Google Public DNS	8.8.8.8	8.8.4.4
Cloudflare DNS	1.1.1.1	1.0.0.1
Quad9	9.9.9.9	149.112.112.112

ただし、会社や学校のネットワークでは、独自DNSを使って社内システムを名前解決している場合があります。

そのような環境でDNSを変更すると、社内システムへ接続できなくなる可能性があります。

業務端末では、自己判断で変更せず、管理者に確認してください。

VPNやプロキシを一時的に確認する

VPNやプロキシを使っている場合、それらがDNS解決に影響していることがあります。

以下を確認します。

VPNを切ると開けるか
別のVPNサーバーに接続すると変わるか
プロキシ設定が有効になっていないか
社内ネットワーク専用のDNSを使っていないか
セキュアDNS設定が影響していないか

VPNを切ると名前解決できる場合、VPN側のDNS設定、スプリットトンネル設定、社内DNS、セキュリティポリシーなどが原因の可能性があります。

hostsファイルを確認する

サーバー移転や検証作業を行ったことがある場合は、hostsファイルに古い設定が残っていないか確認します。

Windowsのhostsファイルは以下です。

C:\Windows\System32\drivers\etc\hosts

MacやLinuxでは以下です。

/etc/hosts

不要な設定があれば削除するか、コメントアウトします。

# 192.0.2.10 example.com

その後、DNSキャッシュを削除して再確認します。

サイト管理者側で確認すべき対処法

ドメインの有効期限と状態を確認する

まず、ドメインが有効な状態か確認します。

確認すべき項目は以下です。

ドメインの有効期限
自動更新の設定
支払い状況
登録者情報のメール認証
ドメインステータス
レジストラロック
clientHoldやserverHoldの有無

ドメインが停止状態になっている場合、DNSレコードを修正しても名前解決できません。

まずはレジストラの管理画面で、ドメインが正常に利用できる状態か確認してください。

現在のネームサーバーを確認する

次に、現在どのネームサーバーが使われているか確認します。

dig NS example.com

または、

nslookup -type=NS example.com

返ってきたNSレコードが、実際に使われているDNS管理先です。

たとえば、以下が返った場合はCloudflare側でDNSを管理しています。

xxxx.ns.cloudflare.com
yyyy.ns.cloudflare.com

以下が返った場合は、Xserver側でDNSを管理している可能性があります。

ns1.xserver.jp
ns2.xserver.jp

DNSレコードを編集している管理画面と、実際のネームサーバーが一致しているか確認してください。

Aレコード・AAAAレコード・CNAMEレコードを確認する

Webサイトの名前解決では、主にAレコード、AAAAレコード、CNAMEレコードを確認します。

dig A example.com
dig AAAA example.com
dig CNAME www.example.com
dig A www.example.com

確認するポイントは以下です。

項目	確認内容
Aレコード	正しいIPv4アドレスを指しているか
AAAAレコード	正しいIPv6アドレスを指しているか
CNAMEレコード	正しい向き先になっているか
www	www あり・なし両方で想定通りか
TTL	変更後の反映に影響しないか
不要なレコード	古いAレコードやAAAAレコードが残っていないか

特にサーバー移転後は、Aレコードだけ新しいIPに変更し、AAAAレコードが古いまま残っているケースがあります。

IPv6環境でだけ不具合が出る場合は、AAAAレコードも必ず確認してください。

DNSを編集している場所が正しいか確認する

DNSトラブルで非常に多いのが、使われていないDNS管理画面を編集しているケースです。

たとえば、以下のような構成があるとします。

ドメイン管理：お名前.com
レンタルサーバー：Xserver
DNS管理：Cloudflare
メール：Google Workspace

このとき、実際のネームサーバーがCloudflareであれば、DNSレコードはCloudflare側で編集する必要があります。

一方、実際のネームサーバーがお名前.comであれば、Cloudflareで編集しても反映されません。

「DNSを変更したのに反映されない」と感じた場合は、まずNSレコードを確認し、編集しているDNS管理画面が正しいか見直してください。

DNSSECの設定を確認する

名前解決がSERVFAILになる場合は、DNSSECの設定ミスも疑います。

以下を確認します。

DNSSECが有効になっているか
レジストラ側にDSレコードが登録されているか
現在のDNS事業者のDNSSEC情報と一致しているか
古いDNS事業者のDSレコードが残っていないか
DNSSEC無効化時にDSレコードも削除されているか

DNSSECの状態を確認するには、以下のようなコマンドを使います。

dig +dnssec example.com

DNSSECの移行や無効化を行う場合は、DNS管理画面だけでなく、レジストラ側のDSレコードも確認してください。

権威DNSサーバーに直接問い合わせる

DNSキャッシュの影響を避けて確認したい場合は、権威DNSサーバーへ直接問い合わせます。

まず、NSレコードを確認します。

dig NS example.com

次に、表示された権威DNSサーバーへ直接問い合わせます。

dig @ns1.example-dns.com example.com A
dig @ns2.example-dns.com example.com A

複数の権威DNSサーバーで結果が異なる場合、ゾーン情報の同期不整合が起きている可能性があります。

Webサーバー側の設定を確認する

DNSで正しいIPアドレスが返っているのにサイトが開かない場合は、Webサーバー側を確認します。

以下のコマンドでHTTPレスポンスを確認できます。

curl -I https://example.com

確認すべき項目は以下です。

確認項目	内容
HTTPステータス	200、301、403、404、500など
SSL証明書	対象ドメインに対応しているか
VirtualHost	対象ドメインを受け付ける設定か
server_name	Nginxなどで正しく設定されているか
ポート	80番・443番が開いているか
リダイレクト	無限リダイレクトになっていないか
WAF・CDN	ブロックや設定ミスがないか

HTTPステータスが返っている場合、DNSではなくWebサーバーやアプリケーション側の問題である可能性が高くなります。

ケース別の原因と対処法

自分のPCだけ名前解決できない場合

自分のPCだけで問題が起きている場合、端末側の設定やキャッシュが原因の可能性が高いです。

主な原因は以下です。

OSのDNSキャッシュ
ブラウザキャッシュ
hostsファイル
VPN
プロキシ設定
セキュリティソフト
ブラウザのセキュアDNS設定

対処法は以下です。

別ブラウザで確認する
シークレットウィンドウで確認する
DNSキャッシュを削除する
ブラウザを完全終了して再起動する
端末を再起動する
hostsファイルを確認する
VPNやプロキシを確認する
DNSサーバーを変更する

同じWi-Fi内の端末すべてで名前解決できない場合

同じWi-Fiに接続している端末すべてで問題が起きている場合は、ルーターやプロバイダDNSが原因の可能性があります。

主な原因は以下です。

ルーターのDNS設定
ルーターの一時的不具合
プロバイダDNSの障害
回線障害
ONUやモデムの問題

対処法は以下です。

ルーターを再起動する
ONUやモデムを再起動する
スマホの4G/5G回線で確認する
DNSサーバーを変更する
プロバイダの障害情報を確認する

会社のネットワークだけ名前解決できない場合

会社や学校のネットワークだけで問題が起きる場合は、社内DNS、VPN、プロキシ、フィルタリングが関係している可能性があります。

主な原因は以下です。

社内DNSの設定
VPNのDNS設定
プロキシ設定
ファイアウォール
Webフィルタリング
ゼロトラスト製品
セキュリティポリシー

対処法は以下です。

VPN接続の有無で挙動を比較する
社外ネットワークで確認する
プロキシ設定を確認する
情報システム部門に確認する
社内DNSが正しく配布されているか確認する

業務端末では、自己判断でDNSやセキュリティ設定を変更しないようにしてください。

新しく設定した独自ドメインが開かない場合

新しく独自ドメインを設定した直後に開かない場合は、DNSレコード、ネームサーバー、サーバー側設定のいずれかに問題があることが多いです。

主な原因は以下です。

Aレコードが未設定
AレコードのIPアドレスが間違っている
CNAMEの向き先が違う
wwwあり・なしの片方しか設定していない
ネームサーバーが違う
DNS反映待ち
サーバー側にドメインを追加していない
SSL証明書が未発行
CDNやWAFの設定が不完全

対処法は以下です。

NSレコードを確認する
Aレコードを確認する
CNAMEレコードを確認する
wwwあり・なしを確認する
DNSを編集している管理画面を確認する
サーバー側のドメイン設定を確認する
SSL証明書を確認する
TTLとキャッシュを考慮して再確認する

メールだけ送受信できない場合

Webサイトは開くのにメールだけ届かない場合は、AレコードではなくMXレコードやTXTレコードを確認します。

主な原因は以下です。

MXレコードが未設定
MXレコードの向き先が間違っている
SPFレコードが間違っている
DKIMが未設定
DMARC設定が不適切
メールサーバー側でドメイン認証が完了していない

確認には以下のコマンドを使います。

dig MX example.com
dig TXT example.com

Google WorkspaceやMicrosoft 365などを使っている場合は、各サービスが指定するMXレコード、SPF、DKIM、DMARC設定と一致しているか確認してください。

一部のユーザーだけアクセスできない場合

一部のユーザーだけアクセスできない場合は、DNSキャッシュ、IPv6、CDN、地域差、セキュリティ製品の影響が考えられます。

主な原因は以下です。

DNSキャッシュが残っている
利用しているDNSリゾルバーによって結果が違う
AAAAレコードが誤っている
CDNのエッジサーバーに問題がある
WAFが一部IPをブロックしている
社内ネットワークやプロバイダ側で制限されている

対処法は以下です。

複数のDNSサーバーで結果を比較する
AレコードとAAAAレコードを確認する
別回線で確認する
CDNやWAFのログを確認する
権威DNSサーバーごとの応答を確認する

DNSトラブルでよく使うコマンド一覧

Windowsで使うコマンド

DNSの基本確認です。

nslookup example.com

DNSサーバーを指定して確認します。

nslookup example.com 8.8.8.8

NSレコードを確認します。

nslookup -type=NS example.com

MXレコードを確認します。

nslookup -type=MX example.com

DNSキャッシュを削除します。

ipconfig /flushdns

Mac・Linuxで使うコマンド

基本的なDNS確認です。

dig example.com

Aレコードを確認します。

dig A example.com

AAAAレコードを確認します。

dig AAAA example.com

CNAMEレコードを確認します。

dig CNAME www.example.com

NSレコードを確認します。

dig NS example.com

MXレコードを確認します。

dig MX example.com

TXTレコードを確認します。

dig TXT example.com

DNSサーバーを指定して確認します。

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

簡潔に結果を表示します。

dig +short example.com

DNSの問い合わせ経路を確認します。

dig +trace example.com

WebサーバーのHTTP応答を確認します。

curl -I https://example.com

DNSで名前解決できないときのチェックリスト

閲覧者側のチェックリスト

自分のPCやスマホでサイトが見られない場合は、以下を確認します。

□ URLの入力ミスがないか
□ 別ブラウザで開けるか
□ シークレットウィンドウで開けるか
□ スマホの4G/5G回線で開けるか
□ DNSキャッシュを削除したか
□ ブラウザを完全終了して再起動したか
□ 端末を再起動したか
□ ルーターを再起動したか
□ DNSサーバーを変更してみたか
□ VPNを切ると開けるか
□ プロキシ設定が有効になっていないか
□ セキュリティソフトやDNS保護機能が影響していないか
□ hostsファイルに古い設定が残っていないか

サイト管理者側のチェックリスト

Webサイトやメールの管理者は、以下を確認します。

□ ドメインの有効期限は切れていないか
□ ドメインが停止状態になっていないか
□ ネームサーバーは正しいか
□ DNSを編集している管理画面は正しいか
□ Aレコードは正しいIPアドレスを向いているか
□ AAAAレコードは正しいIPv6アドレスを向いているか
□ CNAMEレコードは正しい向き先か
□ wwwあり・なしの両方を確認したか
□ MXレコードは正しいか
□ TXTレコードは正しいか
□ TTLが長すぎないか
□ DNSSEC設定に問題はないか
□ DSレコードが古くないか
□ 権威DNSサーバーごとの応答は一致しているか
□ サーバー側で対象ドメインを受け付けているか
□ SSL証明書は対象ドメインに対応しているか
□ CDNやWAFの設定に問題はないか

まとめ

DNSで名前解決ができない原因は、端末側からドメイン側まで幅広く存在します。

主な原因は以下です。

原因	対処法
URLの入力ミス	スペル、TLD、空白、サブドメインを確認
DNSキャッシュが古い	DNSキャッシュ削除、端末再起動
DNSサーバーの不調	別のDNSサーバーで確認
ネットワーク障害	ルーター再起動、別回線で確認
DNSレコード設定ミス	A、AAAA、CNAME、MX、TXTを確認
ネームサーバー違い	NSレコードを確認
DNS反映待ち	TTLとキャッシュを考慮する
ドメイン失効	レジストラ管理画面で確認
DNSSECミス	DSレコードとDNSSEC設定を確認
IPv6設定ミス	AAAAレコードを確認
VPN・社内DNSの影響	VPN、プロキシ、社内DNSを確認
hostsファイルの誤設定	hostsファイルを修正
Webサーバー側の問題	curl -I、SSL、サーバー設定を確認

重要なのは、いきなりDNS設定を変更するのではなく、まず問題の範囲を切り分けることです。

自分だけで起きているのか
同じWi-Fi内だけで起きているのか
会社のネットワークだけで起きているのか
特定のドメインだけで起きているのか
全員に起きているのか

この切り分けができると、原因をかなり絞り込めます。

DNSトラブルでは、以下の順番で確認すると効率的です。

1. URLやドメイン名を確認する
2. 別ブラウザ・別回線で確認する
3. DNSキャッシュを削除する
4. nslookupやdigで名前解決を確認する
5. 複数のDNSサーバーで結果を比較する
6. NSレコードを確認する
7. A・AAAA・CNAME・MX・TXTを確認する
8. DNSSECやドメイン状態を確認する
9. WebサーバーやSSL設定を確認する

DNSで名前解決できない場合でも、原因を順番に切り分ければ、端末側の問題なのか、DNSサーバーの問題なのか、ドメイン設定の問題なのか、Webサーバー側の問題なのかを判断しやすくなります。

以上、DNSで名前解決できないができない原因と対処法についてでした。

最後までお読みいただき、ありがとうございました。