インフラ作業支援ラボInfra Support Lab ← ガイド一覧← 戻る
トップ > ガイド > トラブル解決 > dig resolv.conf parse failed
トラブル解決ガイド｜更新日：2026年10月11日

dig: parse of /etc/resolv.conf failed の原因と確認手順

dig実行時に parse of /etc/resolv.conf failed が出たとき、resolv.confの実体・構文・不可視文字・管理元を確認し、DNS応答エラーとは分けて原因を切り分けます。

このページの目的

digが/etc/resolv.confの読み取り・解析で失敗する特定エラーだけを対象にします。DNS応答のNXDOMAINやSERVFAILとは分けて確認します。

最初にやること

/etc/resolv.confを直接書き換える前に、ls -lとreadlink -fで実体と管理方式を確認し、次に構文と不可視文字を確認します。

トラブル

DNS名前解決できない原因を切り分ける

dig以外も含む名前解決障害を、OS側・DNS応答・設定の順で切り分けます。

全体を切り分ける →設定ガイド

systemd-resolvedとresolv.conf

resolv.confの実体、127.0.0.53、resolvectl、設定の管理元を確認します。

resolver設定を確認 →dig結果

digのstatusの見方

NXDOMAIN・SERVFAIL・REFUSED・timeoutなどDNS応答の意味を確認します。

statusを確認 →
このページの対象：エラー文にparse of /etc/resolv.conf failedが含まれる場合です。名前解決全般はDNS名前解決できないガイド、digのNXDOMAINやSERVFAILはdig statusガイドへ分けています。

最初にresolv.confの実体と内容を保存して確認

ls -l /etc/resolv.conf readlink -f /etc/resolv.conf sed -n '1,120p' /etc/resolv.conf

/etc/resolv.confは通常ファイルとは限らず、systemd-resolvedなどが管理するファイルへのsymlinkになっている場合があります。管理元を確認せずに直接上書きすると、再起動・DHCP更新・VPN接続などで戻ることがあります。

いきなり書き換えない：まず現在の内容とsymlink先を確認し、必要ならバックアップや構成管理の変更手順を用意します。

nameserver・search・optionsの行を確認

resolv.confはキーワードと値を行単位で記述します。よく使われるnameserverではIPアドレス、searchでは検索ドメイン、optionsではresolverオプションを指定します。

# 例 nameserver 192.0.2.53 search example.internal options timeout:2 attempts:2

キーワードの綴り、値の不足、不正な区切りやコピペ由来の文字がないか確認します。コメントは通常#または;から始まる行として扱われます。

見た目で分からない文字はエスケープ表示で確認

sed -n 'l' /etc/resolv.conf file /etc/resolv.conf

全角スペース、CRLF、制御文字などが混ざると、画面上では正常に見えても解析に失敗することがあります。特にWindows上で編集したファイルやテンプレートから生成したファイルでは確認しておくと安全です。

systemd-resolvedやNetworkManagerなどの管理元を確認

readlink -f /etc/resolv.conf systemctl is-active systemd-resolved 2>/dev/null || true resolvectl status 2>/dev/null || true nmcli device show 2>/dev/null | grep -i 'DNS' || true

systemd-resolved、NetworkManager、DHCPクライアント、VPNクライアント、コンテナ環境などがDNS設定を生成する場合があります。修正先は環境によって異なるため、生成後のresolv.confだけ直して終わりにしないようにします。

127.0.0.53だから異常、ではありません：systemd-resolvedのstub resolverを使う構成では正常な場合があります。値だけで異常判定せず、symlink先とresolvectl statusを合わせて確認します。

systemd-resolvedを使わない既存環境もある

古いディストリビューションや既存運用では、/etc/resolv.confを直接管理したり、NetworkManager・DHCPクライアントが生成したりする構成があります。resolvectlがないこと自体を異常と判断しません。

cat /etc/os-release command -v resolvectl || true command -v systemd-resolve || true ls -l /etc/resolv.conf

旧systemd環境ではsystemd-resolveを見かけることがあります。現行コマンドへの置換を先に行うのではなく、その環境でDNS設定を誰が管理しているかを確認します。

確認結果から修正方法を決める

確認結果対処
不正な行・不可視文字・CRLF等がある管理元を確認したうえで不正部分だけを修正します。自動生成ファイルの場合は生成元の設定を直し、/etc/resolv.confを直接恒久編集しません。
/etc/resolv.confがsystemd-resolvedのsymlinkresolvectl statusでリンク別DNS設定を確認し、NetworkManager・networkd・DHCP/VPNなど実際の設定元を修正します。
NetworkManager管理接続プロファイル側のDNS設定を確認・修正し、接続の再適用後に/etc/resolv.confが期待どおり再生成されたか確認します。
静的管理の既存環境バックアップを取ってからnameserver等の必要行だけを修正し、構文エラーが消えたことを確認します。
構文エラーは消えたが名前解決は失敗問題は別段階です。DNSサーバー到達性・応答コード・NSS経路をDNS名前解決トラブルで切り分けます。

修正後は「解析できる」「名前解決できる」を別々に確認

dig example.com getent hosts example.com resolvectl query example.com 2>/dev/null || true

digが起動できても、DNSサーバーからNXDOMAIN・SERVFAIL・REFUSEDなどが返る場合は別の問題です。その場合はdig statusガイドで応答コードを切り分けます。