2026年6月22日

Linuxのresolv.confの設定方法｜書き換えが消える原因と、DNS設定を固定する正しい手順

DNS・メールサーバー

/etc/resolv.conf は、Linux が名前解決に使う DNS サーバーなどを指定するファイルです。ただし、今の多くのディストリビューションでは systemd-resolved や NetworkManager が自動で生成しているため、直接書き換えても再起動や DHCP の更新で元に戻ります。設定を固定するには、まず「誰がこのファイルを管理しているか」を確かめ、その仕組みの設定ファイルで DNS を指定するのが正しい手順です。この記事では、resolv.conf の書き方、管理元の見分け方、Ubuntu と RHEL 系それぞれでの設定方法、WordPress サーバーで名前解決に失敗したときの確認方法を解説します。

resolv.confの役割と書き方

Linux のプログラムがホスト名を IP アドレスに変換するとき、標準の C ライブラリ（glibc）は /etc/nsswitch.conf の順序に従って /etc/hosts や DNS を参照します。DNS を使う場合に、問い合わせ先や動作を決めるのが resolv.conf です。

nameserver 192.0.2.53
nameserver 198.51.100.53
search example.internal
options timeout:2 attempts:2

主な項目は次のとおりです。

nameserver：問い合わせ先の DNS サーバーの IP アドレス。書いた順に使われ、glibc で有効なのは3件までです。1件目が応答しないときに2件目へ移るので、1件目に遅いサーバーを書くと名前解決全体が遅くなります
search：短い名前を補うドメインの一覧。search example.internal なら、db を引くと db.example.internal も試されます。domain という似た項目もありますが、search と domain は両方書くと後に書いた方が使われます
options：動作の調整。timeout:n（1回の待ち時間の秒数、既定は5秒）、attempts:n（試行回数、既定は2回）、rotate（サーバーを順番に使い分ける）、ndots:n（名前にドットがいくつ以上あれば先にそのまま問い合わせるか、既定は1）などがあります

timeout を短くすると障害時の待ち時間は減りますが、遠い DNS サーバーを使っている環境では、正常な応答まで失敗扱いになることがあります。変更する場合は少しずつ調整します。

まず管理元を確かめる

resolv.conf を編集する前に、ファイルの正体を確認します。

ls -l /etc/resolv.conf
head -n 5 /etc/resolv.conf

結果によって、設定すべき場所が変わります。

**/run/systemd/resolve/stub-resolv.conf へのシンボリックリンク**：systemd-resolved が管理しています。Ubuntu では既定の構成です（2026年10月現在）。中身は nameserver 127.0.0.53 になっていますが、これは正常で、ローカルの systemd-resolved に問い合わせ、そこから実際の DNS サーバーへ転送する構成です
**先頭に # Generated by NetworkManager**：NetworkManager が管理しています（RHEL、Rocky Linux、AlmaLinux などで多い構成）
resolvconf や cloud-init の案内がある：それぞれの仕組みが生成しています。クラウドの VM では、DHCP で配られた DNS が自動で入っていることが多いです
普通のファイルで、特に案内がない：直接編集して問題ない構成です

どの場合でも、変更前に sudo cp -a /etc/resolv.conf /root/resolv.conf.bak のように控えを取っておくと、戻すときに困りません。SSH で接続しているサーバーでは、DNS の設定を誤ってもすでに張っている接続は切れませんが、パッケージ更新などが止まるので、別のターミナルを開いたまま作業すると安心です。

Ubuntu（systemd-resolved・netplan）での設定

Ubuntu のサーバーでは、ネットワーク設定を netplan で書き、その内容が systemd-resolved に渡されます。インターフェースごとに DNS を指定する場合は、/etc/netplan/ の YAML ファイルを編集します。

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      dhcp4-overrides:
        use-dns: false
      nameservers:
        addresses: [192.0.2.53, 198.51.100.53]
        search: [example.internal]

dhcp4-overrides の use-dns: false は、DHCP で配られる DNS を使わず、ここに書いたものだけを使うための指定です。インターフェース名（eth0）は ip a で実際の名前を確認してください。反映は sudo netplan try で行うと、問題があったときに一定時間で元に戻せます。問題がなければ sudo netplan apply で確定します。

インターフェースに関係なく全体の DNS を指定したい場合は、systemd-resolved の設定に追加する方法もあります。本体の設定ファイルを直接書き換えるより、追加用のディレクトリにファイルを置く方が、パッケージ更新の影響を受けにくくなります。

# /etc/systemd/resolved.conf.d/dns.conf
[Resolve]
DNS=192.0.2.53 198.51.100.53
Domains=example.internal

sudo systemctl restart systemd-resolved で反映し、resolvectl status で、どのインターフェースにどの DNS サーバーが使われているかを確認します。実際の転送先の一覧は /run/systemd/resolve/resolv.conf でも見られます。

RHEL系（NetworkManager）での設定

NetworkManager が管理している場合は、nmcli で接続の設定として DNS を指定します。

# 接続名を確認
nmcli con show

# DNSサーバーを指定し、DHCPで配られるDNSを無視する
sudo nmcli con mod "System eth0" ipv4.dns "192.0.2.53 198.51.100.53" ipv4.ignore-auto-dns yes
sudo nmcli con mod "System eth0" ipv4.dns-search "example.internal"

# 接続を再適用して反映
sudo nmcli con up "System eth0"

接続名は環境によって異なるため、nmcli con show の表示に合わせて読み替えてください。nmcli con up は接続を張り直すので、リモートから作業する場合は設定内容をよく確認してから実行します。

直接編集してよい場合と、避けたい対処

管理する仕組みがない最小構成のサーバーやコンテナでは、resolv.conf を直接編集して構いません。一方、自動生成されているファイルに対して、chattr +i で書き換えを禁止して設定を残す方法が紹介されることがありますが、DHCP の更新やネットワーク設定の変更が反映されなくなり、後から原因が分かりにくい不具合を生みます。管理元の設定で指定する方法を優先してください。

設定が効いているか確認する

確認には、プログラムと同じ経路で名前解決する getent を使います。

# glibc の名前解決（/etc/hosts も含む）で確認
getent hosts api.wordpress.org

# systemd-resolved 経由で確認（どの DNS サーバーが答えたかも分かる）
resolvectl query api.wordpress.org

# 特定の DNS サーバーが答えるかを直接確認
dig @192.0.2.53 api.wordpress.org +short

dig は resolv.conf の nameserver を使いますが、/etc/hosts や nsswitch.conf の設定は見ません。「dig では引けるのにアプリでは引けない」場合は、getent の結果や /etc/hosts の内容を確認します。

WordPressサーバーで名前解決に失敗するとき

WordPress の管理画面で、プラグインの更新確認やダウンロードに「cURL error 6: Could not resolve host」のようなエラーが出る場合は、サーバーの名前解決が失敗しています。次の順で確認します。

サーバー上で getent hosts api.wordpress.org を実行し、IP アドレスが返るかを見る
返らなければ、ls -l /etc/resolv.conf と resolvectl status（または nmcli dev show）で、どの DNS サーバーを使っているかを確認する
そのサーバーに dig @IPアドレス で直接問い合わせ、応答があるかを確かめる。応答がなければ、別の DNS サーバーに切り替えるか、ファイアウォールで DNS の通信（53番ポート）が止められていないかを確認する
設定を直した後も PHP から引けない場合は、PHP-FPM などの長時間動くプロセスを再起動して、設定を読み直させる

Docker で WordPress を動かしている場合、コンテナはホストの resolv.conf を元にした設定を使いますが、ホストの 127.0.0.53 はコンテナ内からは使えないため、Docker が別の値に置き換えます。コンテナ内の名前解決の問題は、ホストとは分けて確認してください。

まとめ

resolv.conf は DNS の問い合わせ先・補完ドメイン・動作を決めるファイルで、nameserver は3件まで
多くの環境では自動生成されているため、ls -l と先頭のコメントで管理元を確かめてから設定する
Ubuntu は netplan または systemd-resolved の追加設定、RHEL 系は nmcli で DNS を指定する
chattr +i での固定は避け、管理元の設定で指定する
確認は getent と resolvectl query、DNS サーバー単体の確認は dig @IPアドレス
WordPress の更新エラー「Could not resolve host」は、サーバーの名前解決から順に調べる