MENU

DNSは引けるが通信できない時の切り分け

コマンド編
  • URLをコピーしました！

「名前解決はできているのに通信できない」
「digやnslookupは成功するが、curlやncが失敗する」
「pingは通るのにアプリ通信だけNG」

このトラブルは現場で非常に発生頻度が高く、かつ DNSに気を取られて本質的な原因を見落としやすいのが特徴です。

本記事では、「DNSは正常」な状態からどこをどう切り分けるかを、 レイヤ順・実務手順ベースで整理します。

目次

まず結論：DNSが引ける＝通信できる、ではない

DNSはあくまでIPアドレスを引くだけです。

  • IPに到達できるか
  • ポートが開いているか
  • 通信が途中で落とされていないか

はDNSとは別問題です。

切り分け全体フロー（最短ルート）

  1. 名前解決の結果確認（本当に正しいIPか）
  2. IPレベル疎通（ICMP）
  3. ポート疎通（TCP/UDP）
  4. クライアント側制御（FW / SELinux）
  5. 経路・LB・NAT
  6. サーバ／アプリ側制御

以下、この順で具体コマンド＋対策を解説します。

① DNS結果が「本当に正しいIP」か確認

まずはDNS結果を鵜呑みにしないことが重要です。

# DNS結果確認
dig example.com

# glibc経由での確認
getent hosts example.com

以下のポイントを確認します。

  • 期待しているIPか
  • LBのIPではないか
  • IPv6（AAAA）が優先されていないか

ありがちな落とし穴

  • 古いIPが返ってきている
  • IPv6が引けるが通信できない

対策

  • A / AAAA レコードを分けて確認
  • 一時的にIPv4指定で検証
curl -4 http://example.com

② IPレベル疎通（ping）が通るか

DNSが引けたIPに対して、まずICMP疎通を確認します。

ping 93.184.216.34

結果の解釈

  • 通る → 次へ
  • 通らない → 経路 or FWの可能性大

※ pingを落としている環境もあるため、通らない＝即NGではない点に注意。

③ ポート疎通確認（ここが一番重要）

pingが通っても、ポートが閉じていれば通信できません。

# TCP疎通確認
nc -vz 93.184.216.34 443

# curlで実通信確認
curl -v http://example.com

典型的な失敗パターン

  • 接続タイムアウト → FW / 経路
  • 即切断 → アプリ or LB

対策

  • ポート番号が正しいか再確認
  • サーバ側でLISTENしているか確認

④ クライアント側のFirewall確認

意外と多いのが送信側FWです。

# firewalld確認
firewall-cmd --list-all

# iptables確認
iptables -L -n

チェックポイント

  • OUTPUTが制限されていないか
  • 特定ポートだけ落としていないか

対策

  • 一時的にFW無効化して切り分け
systemctl stop firewalld

⑤ SELinuxによる通信ブロック

SELinuxはpingやDNSは通るがアプリ通信だけNGを引き起こします。

確認

getenforce

AVCログ確認

ausearch -m AVC -ts recent

対策

  • 一時的にPermissiveで確認
setenforce 0

Permissiveで通信できるならSELinuxが原因です。

⑥ 経路・NAT・LBの問題

DNSが引けても、経路が通っていないケースがあります。

# 経路確認
ip route get 93.184.216.34

# traceroute
traceroute 93.184.216.34

よくある原因

  • 戻り通信が別経路
  • NAT設定ミス
  • LBのidle timeout

対策

  • 送信・戻り経路の対称性確認
  • LB設定（idle timeout / health check）確認

⑦ サーバ・アプリ側で拒否されている

クライアント側が正常でも、サーバ側が拒否している場合があります。

確認

  • サーバFW
  • アプリのlistenアドレス
  • 最大接続数
# サーバ側LISTEN確認
ss -lntp

典型例

  • 127.0.0.1でのみLISTEN
  • 接続数上限で拒否

即解決につながるチェックリスト

  • DNS結果は正しいIPか
  • IPv6が優先されていないか
  • ポート疎通は通るか
  • 送信側FW / SELinux
  • 経路・LB・NAT
  • サーバ側LISTEN状態

まとめ

「DNSは引けるが通信できない」問題は、

  • DNSに原因はない
  • レイヤを順番に潰すのが最短

という特徴があります。

IP → ポート → 制御 → 経路の順で切り分ければ、 ほぼ確実に原因へ辿り着けます。

あわせて読みたい
Linuxで名前解決が不安定になる原因（resolv.conf以外） 「pingは通るのに名前解決だけ失敗する」「たまに名前解決できるが、再現性が低い」「resolv.confは正しいのにDNSエラーが出る」 このようなトラブルは、resolv.conf以…
あわせて読みたい
RSTが多発する時の原因と切り分け はじめに TCP通信において RST（Reset）パケットが多発する 状態は、「通信が強制的に切断されている」ことを意味します。 RSTは 正常系ではほぼ出ない ため、 アプリ障…
あわせて読みたい
LB idle timeoutとアプリKeepAlive設計の落とし穴 ロードバランサ（LB）配下のシステムで、「通信が突然切れる」「一定時間後にRSTが返る」「再接続が頻発する」といった問題が発生する場合、LBのidle timeoutとアプリの…
コマンド編
目次