Ubuntu 26.04 で名前解決を確認する場合、単に /etc/resolv.conf を見るだけでは足りません。Netplan、systemd-resolved、interface ごとの DNS server、search domain、stub resolver の関係を分けて見る必要があります。
この記事では、Ubuntu 26.04 Server の systemd-resolved を前提に、DNS 設定の確認方法、Netplan の nameservers との関係、内部 DNS と外部 DNS の切り分け、resolvectl や getent の使い分けを整理します。
Ubuntu 26.04 の DNS は systemd-resolved を前提に見る
Ubuntu Server では、名前解決の入口として systemd-resolved が使われます。/etc/resolv.conf は実体ファイルではなく、systemd-resolved が管理する stub resolver への symlink になっていることがあります。
| 要素 | 役割 | 確認方法 |
|---|---|---|
| Netplan | interface ごとの DNS 設定を書く | /etc/netplan/*.yaml |
| systemd-resolved | 名前解決の状態を管理する | resolvectl status |
/etc/resolv.conf | resolver の入口 | readlink -f /etc/resolv.conf |
| NSS | 名前解決順序を決める | /etc/nsswitch.conf |
そのため、DNS 設定を直したい時に /etc/resolv.conf を直接編集するのは基本的に避けます。まず Netplan と systemd-resolved の状態を確認します。
現在の名前解決状態を確認する
最初に、resolved の状態、/etc/resolv.conf の向き先、NSS の設定、実際の名前解決結果を確認します。
resolvectl status
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
getent hosts example.comresolvectl status では、global DNS、link ごとの DNS server、search domain、DNSSEC、LLMNR、mDNS などを確認できます。複数 NIC の環境では、どの interface にどの DNS が付いているかを見ることが重要です。
Netplan で DNS server を設定する
Netplan では、interface の nameservers に DNS server と search domain を書きます。次は固定 IP の interface に DNS を設定する例です。
sudo tee /etc/netplan/00-main.yaml >/dev/null <<'EOF'
network:
version: 2
ethernets:
enp1s0:
addresses:
- 10.0.10.20/24
routes:
- to: default
via: 10.0.10.1
nameservers:
search:
- example.internal
addresses:
- 10.0.10.53
- fd00::53
EOF
sudo chmod 600 /etc/netplan/00-main.yamlここで設定した DNS server は、Netplan の renderer を通じて systemd-resolved に渡されます。設定ファイル上は Netplan に書き、確認は resolvectl status で見る、という分担になります。
設定を反映する
Netplan の変更後は、構文確認と反映を行います。DNS 設定だけの変更でも、networkd / resolved の状態に影響するため、反映後の確認まで行います。
sudo netplan generate
sudo netplan try
sudo netplan apply
resolvectl status反映後に resolvectl status を確認し、対象 interface に DNS server と search domain が入っているかを見ます。/etc/resolv.conf の中身だけを見ても、interface ごとの状態は分かりません。
名前解決コマンドを使い分ける
DNS の切り分けでは、どの経路で名前解決しているかを意識します。dig、getent、resolvectl query は似ていますが、見るものが違います。
| コマンド | 見るもの | 用途 |
|---|---|---|
getent hosts | NSS 経由の名前解決 | アプリケーションに近い確認 |
resolvectl query | systemd-resolved 経由の問い合わせ | resolved の動作確認 |
dig | DNS server への問い合わせ | DNS server 自体の確認 |
getent hosts server.example.internal
resolvectl query server.example.internal
dig server.example.internal
dig @10.0.10.53 server.example.internalgetent hosts で引けないが dig @DNSサーバー では引ける場合、NSS や systemd-resolved 側の問題かもしれません。逆に dig @DNSサーバー でも引けない場合は、DNS server、zone、network reachability を疑います。
内部 DNS と外部 DNS を分けて確認する
内部 DNS と外部 DNS を混ぜて考えると、切り分けが難しくなります。内部名が引けないのか、外部名が引けないのか、DNS server へ到達できないのかを分けます。
resolvectl query server.example.internal
resolvectl query www.example.com
dig @10.0.10.53 server.example.internal
dig @1.1.1.1 www.example.com
ping -c 3 10.0.10.53
ip route get 10.0.10.53複数 NIC や policy based routing を使っている場合、DNS server への経路が想定と違うことがあります。名前解決の問題に見えて、実際には route や firewall の問題であることもあります。
search domain の注意点
search domain は便利ですが、意図しない問い合わせを増やすことがあります。短い host 名を使う場合は、どの domain が補完されるのかを確認します。
resolvectl status
resolvectl query server
resolvectl query server.example.internalサーバー管理では、曖昧な短縮名だけに頼るより、重要な設定では FQDN を使う方が切り分けしやすくなります。特に複数の内部 domain がある環境では、search domain の順序も運用上の意味を持ちます。
DNS 障害時に見るポイント
resolvectl statusに DNS server が表示されているか/etc/resolv.confが systemd-resolved の管理下にあるか- Netplan の
nameserversが対象 interface に書かれているか - DNS server へ IP で到達できるか
dig @DNSサーバーで直接問い合わせできるかgetent hostsとdigの結果がずれていないか- nftables や PBR が DNS 通信を止めていないか
DNS 障害は、アプリケーション障害、認証障害、外部接続障害のように見えることがあります。まず IP で到達できるのか、名前で到達できるのかを分けて確認します。
参考書籍
関連する記事
まとめ
Ubuntu 26.04 の DNS 設定は、/etc/resolv.conf を直接編集するのではなく、Netplan と systemd-resolved の関係で見ると整理しやすくなります。設定は Netplan、状態確認は resolvectl status、実際の解決確認は getent、resolvectl query、dig を使い分けます。
名前解決の問題は、DNS server、route、firewall、search domain、NSS のどこでも起きます。IP で到達できるのか、名前で到達できるのかを分けて確認することが、Ubuntu 26.04 の DNS 障害切り分けの基本です。


