はい、承知いたしました。UbuntuにおけるDNS設定方法について、詳細な説明を含む約5000語の記事を作成します。
Ubuntu DNS 設定方法を徹底解説
はじめに:DNSとは何か、なぜ重要なのか
インターネットやローカルネットワークを利用する上で、DNS (Domain Name System) は不可欠な要素です。DNSは、人間が覚えやすいドメイン名(例: www.google.com
)と、コンピューターが通信に使うIPアドレス(例: 172.217.161.164
)を相互に変換する仕組みです。この変換プロセスを「名前解決 (Name Resolution)」と呼びます。
もしDNSが存在しなければ、ウェブサイトにアクセスしたり、ネットワーク上のコンピューターに接続したりする際に、常にIPアドレスを直接入力する必要が出てきます。これは非常に非現実的で、ネットワークの利便性を著しく損なうことになります。
Ubuntuを含むすべてのオペレーティングシステムは、この名前解決を行うための設定を持っています。具体的には、「どのDNSサーバーに問い合わせれば、特定のドメイン名に対応するIPアドレスを知ることができるのか」という情報です。この設定が正しく行われていないと、インターネット上のウェブサイトにアクセスできなかったり、ローカルネットワーク上の他のコンピューターの名前を解決できなかったりといった問題が発生します。
UbuntuのDNS設定は、過去のバージョンから現在のバージョンに至るまで、いくつかの変遷を経てきました。かつては/etc/resolv.conf
ファイルを直接編集するのが一般的でしたが、現在ではsystemd-resolved
やNetworkManager
、netplan
といったより高レベルなツールがDNS設定を管理しており、直接の編集は推奨されていません。
本記事では、Ubuntuの現在の主流バージョン(主に18.04 LTS以降)で採用されているsystemd-resolved
を中心としたDNS設定方法を詳細に解説します。加えて、デスクトップ環境で一般的なNetworkManager
、サーバー環境で一般的なnetplan
を使った設定方法、そして古いバージョンや特殊なケースで使われる可能性のあるresolvconf
や手動での/etc/resolv.conf
編集についても触れます。約5000語にわたる詳細な解説を通じて、UbuntuにおけるDNS設定の仕組みを深く理解し、様々な状況に対応できるようになることを目指します。
DNS設定の基本要素:/etc/resolv.conf ファイル
Ubuntuを含む多くのLinuxシステムにおいて、名前解決に関するクライアント側の設定情報は/etc/resolv.conf
というファイルに集約されています。このファイルは、システムが名前解決を行う際に最初に参照する設定ファイルであり、以下の情報を保持するのが一般的です。
- nameserver: 問い合わせるDNSサーバーのIPアドレスを指定します。複数指定可能で、リストの先頭から順に試行されます。
nameserver 8.8.8.8
nameserver 8.8.4.4
これは、Google Public DNSのサーバーを指定する例です。 - search: 名前解決時に補完するドメインサフィックス(検索ドメイン)を指定します。例えば、
search example.com internal.net
と設定されている場合、ユーザーがホスト名としてwebserver
と入力すると、システムはまずwebserver.example.com
の名前解決を試み、次にwebserver.internal.net
の名前解決を試みます。
search example.com internal.net
- domain:
search
と同様に検索ドメインを指定しますが、通常は一つだけ指定します。過去の互換性のために残されているオプションです。最近ではsearch
が推奨されます。 - options: 名前解決の動作に関する様々なオプションを指定します。例えば、
timeout
は問い合わせのタイムアウト時間、attempts
はリトライ回数を設定します。
options timeout:2 attempts:3
/etc/resolv.conf
の現状と注意点
現代のUbuntu(特に17.10以降)では、/etc/resolv.conf
ファイルは多くの場合、直接編集するべきファイルではありません。これは、systemd-resolved
やNetworkManager
、netplan
といったサービスがこのファイルを動的に管理しており、手動で加えた変更がネットワーク設定の変更(例えば、DHCPリース更新、ネットワークインターフェースの再起動、VPN接続など)によって上書きされてしまうためです。
現在のUbuntuのデフォルト構成では、/etc/resolv.conf
は実際のDNS設定ファイルを指すシンボリックリンクになっていることがほとんどです。
systemd-resolved
を使用している場合:/etc/resolv.conf
は通常/run/systemd/resolve/stub-resolv.conf
または/usr/lib/systemd/resolv.conf
を指します。/run/systemd/resolve/stub-resolv.conf
は、ローカルのスタブリゾルバーであるsystemd-resolved
のループバックアドレス (通常127.0.0.53
) をnameserver
として記述しています。システム内のアプリケーションは127.0.0.53
のsystemd-resolved
に問い合わせを行い、systemd-resolved
が実際のアップストリームDNSサーバー(DHCPで取得したサーバーや、手動設定したサーバー)に問い合わせを行います。/usr/lib/systemd/resolv.conf
は、アップストリームDNSサーバーを直接リストする形式で、特定のアプリケーションが直接アップストリームサーバーに問い合わせるために用意されています(これはあまり一般的ではありません)。
resolvconf
を使用している場合(古いバージョンや特別な構成):/etc/resolv.conf
は通常/run/resolvconf/resolv.conf
を指します。このファイルは、resolvconf
サービスによって管理される複数の設定ソース(DHCPクライアント、手動設定など)を統合して生成されます。- 手動管理の場合(非推奨): 例外的に、
/etc/resolv.conf
がシンボリックリンクではなく、プレーンなファイルとして存在し、手動で管理されている場合もあります。これは通常、特定の目的のためにデフォルトの管理を無効化している場合です。
したがって、DNS設定を変更する際は、/etc/resolv.conf
を直接編集するのではなく、システムが採用している適切なツール(systemd-resolved
、NetworkManager
、netplan
など)を通じて設定を行う必要があります。
主流のDNS管理方法:systemd-resolved (Ubuntu 18.04以降)
Ubuntu 18.04 LTS以降のバージョンでは、systemd-resolved
がデフォルトの名前解決サービスとして採用されています。これは、DNS、DNSSEC、LLMNR (Link-Local Multicast Name Resolution)、mDNS (Multicast DNS) を扱うためのサービスです。
systemd-resolved
の主な特徴は以下の通りです。
- スタブリゾルバー (Stub Resolver): ローカルで動作する軽量なリゾルバーを提供します。アプリケーションは通常、ローカルのループバックアドレス(デフォルトでは
127.0.0.53
)に対してDNSクエリを発行します。 - キャッシュ機能: 問い合わせたDNSレコードをキャッシュすることで、同じクエリに対して高速に応答し、外部DNSサーバーへの負荷を軽減します。
- 複数のDNSソースの統合: DHCPクライアント、手動設定 (
/etc/systemd/resolved.conf
)、ネットワーク設定ツール (NetworkManager
,netplan
) から受け取ったDNSサーバー情報を統合して管理します。 - DNSSEC検証: DNSSEC (Domain Name System Security Extensions) をサポートし、DNS応答の正当性を検証できます。
- DNS over TLS (DoT) / DNS over HTTPS (DoH): 暗号化された安全なDNS通信をサポートします。
- 柔軟なルーティング: 特定のドメインに対して、特定のDNSサーバーを使用するように設定できます(ドメインベースのルーティング)。
systemd-resolved
の設定方法
systemd-resolved
自体を設定する方法はいくつかありますが、通常は他のネットワーク設定ツールと組み合わせて使用します。
-
systemd-resolved
の設定ファイル (/etc/systemd/resolved.conf
)
このファイルは、systemd-resolved
のグローバルな設定を定義します。例えば、使用するアップストリームDNSサーバー、DNSSECの設定、キャッシュ設定などを指定できます。
ini
[Resolve]
#DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=
#DNSSEC=allow-downgrade
#DNSOverTLS=no
#Cache=yes
#DNSStubListener=yes
#ReadEtcHosts=yes
デフォルトでは多くの設定がコメントアウトされています。手動でDNSサーバーを指定したい場合は、DNS=
の行をアンコメントしてIPアドレスを記述します。
ini
[Resolve]
DNS=1.1.1.1 9.9.9.9 # 例: Cloudflare DNSとQuad9 DNS
設定変更後は、systemd-resolved
サービスを再起動する必要があります。
bash
sudo systemctl restart systemd-resolved
ただし、このファイルでDNSサーバーを指定しても、NetworkManager
やnetplan
がネットワークインターフェースに対して別のDNSサーバーを設定している場合、そちらの設定が優先されることが多いです。/etc/systemd/resolved.conf
は、主にフォールバックDNSやDNSSEC/DoT/DoHのような詳細設定、またはDHCPでDNS情報が提供されない場合のデフォルト設定として機能します。 -
ネットワーク設定ツール (
NetworkManager
,netplan
) を通じた設定
これが最も一般的で推奨される方法です。NetworkManager
やnetplan
は、ネットワークインターフェースの設定(IPアドレス、ゲートウェイ、DNSサーバーなど)を管理し、その情報をsystemd-resolved
に渡します。systemd-resolved
は受け取った情報をもとに、どのアップストリームサーバーに問い合わせるかを決定します。-
NetworkManager
(デスクトップ環境)
NetworkManager
は、GUIツールやnmcli
コマンドを使ってDNS設定を行います。設定は接続プロファイルごとに管理されます。後述の「デスクトップ環境での設定:NetworkManager」セクションで詳しく解説します。 -
netplan
(サーバー環境)
netplan
は、YAML形式の設定ファイルを読み込み、systemd-networkd
やNetworkManager
といったバックエンドに設定を適用します。DNS設定もnetplan
の設定ファイルに記述します。後述の「サーバー環境での設定:Netplan」セクションで詳しく解説します。
-
systemd-resolved
の状態確認とトラブルシューティング
systemd-resolved
の状態や設定を確認するには、resolvectl
コマンドを使用します。
-
現在の状態を確認:
bash
resolvectl status
このコマンドは、サービスの稼働状況、設定ファイルから読み込まれたグローバル設定、そして各ネットワークインターフェースに設定されているDNSサーバーや検索ドメインを表示します。Current DNS Server
やDNS Servers
の項目を確認し、意図したDNSサーバーが設定されているか確認できます。また、DNSSEC
やDNSOverTLS
の状態も表示されます。 -
特定のドメインやホスト名の解決をテスト:
bash
resolvectl query google.com
resolvectl query www.ubuntu.com AAAA # IPv6アドレスを問い合わせ
resolvectl query webserver.internal.net # ローカルホスト名/検索ドメイン
このコマンドは、systemd-resolved
を使って名前解決を実行し、結果(IPアドレス、問い合わせに使用したサーバーなど)を表示します。名前解決が失敗する場合、どのサーバーに問い合わせて失敗したのかなどの情報が得られます。 -
キャッシュの確認:
bash
resolvectl statistics
DNSキャッシュのヒット/ミス率などの統計情報を表示します。 -
/etc/resolv.conf
シンボリックリンクの確認:
ls -l /etc/resolv.conf
コマンドで、/etc/resolv.conf
が何を指しているか確認します。
bash
ls -l /etc/resolv.conf
# 出力例 (systemd-resolved の場合):
# lrwxrwxrwx 1 root root 39 日付 時刻 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
もしこれが/run/systemd/resolve/stub-resolv.conf
を指している場合、システム内のアプリケーションは127.0.0.53
(systemd-resolvedのスタブリゾルバー) に問い合わせを行います。もしこれが他のファイルを指していたり、シンボリックリンクでなかったりする場合は、DNS設定の管理方法がデフォルトから変更されている可能性があります。
トラブルシューティングのヒント (systemd-resolved
)
-
インターネットには繋がるが、特定のウェブサイトが見られない/ホスト名でアクセスできない:
resolvectl status
でDNS設定を確認します。表示されているDNSサーバーは正しいですか?到達可能ですか?resolvectl query <問題のホスト名>
で名前解決を試みます。エラーが表示される場合、原因を探ります(NXDOMAIN、SERVFAILなど)。ping <問題のホスト名>
を試します。もしIPアドレスではpingできるがホスト名ではできない場合、DNSの問題です。- ファイアウォール設定を確認します。UDP/TCPポート53 (DNS) がブロックされていませんか?特にローカルのスタブリゾルバー (
127.0.0.53
) やアップストリームDNSサーバーへの通信が許可されているか確認します。 /etc/nsswitch.conf
ファイルを確認します。hosts:
の行にresolve
が含まれているか確認します。これにより、システムが名前解決にsystemd-resolved
を使用するようになります。
-
/etc/resolv.conf
が意図しない内容になる:/etc/resolv.conf
がシンボリックリンクであることを確認します。もしプレーンなファイルになっている場合、何らかのサービスやスクリプトが勝手に編集している可能性があります。- シンボリックリンクが
/run/systemd/resolve/stub-resolv.conf
以外のファイルを指している場合、systemd-resolved
のリンクモードが変更されている可能性があります。これは/etc/systemd/resolved.conf
や/etc/netplan/*.yaml
,/etc/NetworkManager/conf.d/*.conf
などで設定できます。デフォルトに戻すには、/etc/resolv.conf
を削除し、sudo systemctl restart systemd-resolved
を実行します。多くの場合、/run/systemd/resolve/stub-resolv.conf
へのシンボリックリンクが自動的に再作成されます。
ネットワーク設定ツールを通じたDNS設定
前述の通り、現代のUbuntuではsystemd-resolved
がバックエンドとしてDNSを処理しますが、フロントエンドとしてユーザーや管理者が設定を行うのは、主にNetworkManager
(デスクトップ)またはnetplan
(サーバー)です。これらのツールは、DHCPで取得したDNS情報を利用したり、手動で指定したDNSサーバー情報をsystemd-resolved
に引き渡したりします。
デスクトップ環境での設定:NetworkManager
NetworkManagerは、有線、無線、モバイルブロードバンドなど、さまざまな種類のネットワーク接続を簡単に管理できるように設計されています。デスクトップ環境では、通常、画面右上のネットワークアイコンからGUIで設定できます。
GUIによる設定
- 画面右上のネットワークアイコンをクリックします。
- 接続中のネットワーク、または「ネットワーク設定」などの項目を選択します。
- 設定したいネットワーク接続(Wi-Fiまたは有線)の横にある歯車アイコンまたは設定ボタンをクリックします。
- 設定ウィンドウが開いたら、通常「IPv4」タブまたは「IPv6」タブを選択します。
- 「DNS」の項目を探します。
- デフォルトは「自動 (DHCP)」になっているはずです。これは、DHCPサーバーから受け取ったDNSサーバーを使用することを意味します。
- 手動で指定したい場合は、「自動」を無効にし、テキストボックスにカンマ区切りでDNSサーバーのIPアドレスを入力します(例:
8.8.8.8, 8.8.4.4
)。 - 検索ドメイン (Search Domains) を指定するオプションがあれば、必要に応じて入力します。
- 設定を保存または適用します。
- 設定を反映させるために、ネットワーク接続を一度切断して再接続する必要がある場合があります。
GUIでの設定は直感的で簡単ですが、複数のコンピューターに同じ設定を適用したり、スクリプトで自動化したりする場合には向いていません。
CLI (nmcli
) による設定
nmcli
コマンドを使うと、ターミナルからNetworkManagerの設定を操作できます。これは、CUI環境のデスクトップや、設定の自動化に便利です。
-
接続名の確認:
まず、設定したいネットワーク接続の名前を確認します。
bash
nmcli connection show
出力例:
NAME UUID TYPE DEVICE
MyWifi a1b2c3d4-e5f6-7890-g123-h4567890ijkl wifi wlp2s0
Wired connection 1 98765432-fedc-ba98-7654-3210fedcba98 ethernet enp3s0
ここで表示されるNAME
(例:MyWifi
,Wired connection 1
)を使用します。 -
既存のDNS設定を確認:
特定の接続のDNS設定を確認するには、connection show
コマンドに接続名と特定のプロパティを指定します。
bash
nmcli connection show "MyWifi" | grep dns
出力例:
ipv4.dns: 8.8.8.8, 8.8.4.4
ipv6.dns:
ipv4.dns-search: example.com
ipv6.dns-search:
ipv4.dns-options: rotate no-check-names
ipv6.dns-options:
ipv4.dns-priority: 0
ipv6.dns-priority: 0 -
DNSサーバーを設定 (静的指定):
特定の接続に対して、手動でDNSサーバーのIPアドレスを設定します。複数のアドレスはカンマ区切りで指定します。
bash
nmcli connection modify "MyWifi" ipv4.dns "1.1.1.1, 9.9.9.9"
nmcli connection modify "MyWifi" ipv6.dns "2606:4700:4700::1111, 2606:4700:4700::1001" # IPv6の場合
DHCPで取得したDNS設定を使わず、手動で指定したサーバーのみを使うようにするには、ipv4.dns-method
またはipv6.dns-method
をmanual
に設定します。通常、上記コマンドでipv4.dns
を設定すると自動的にmanualになることもありますが、明示的に指定することもできます。
bash
nmcli connection modify "MyWifi" ipv4.method manual # IPアドレスも手動設定の場合
# もしIPアドレスはDHCPで取得し、DNSだけ手動にしたい場合は、methodはautoのまま、dnsだけ設定します。
# NetworkManagerは、DHCPで取得したDNSと手動設定したDNSをどのように扱うか(優先順位など)を制御できます。 -
DHCPからDNSを取得する設定に戻す:
bash
nmcli connection modify "MyWifi" ipv4.dns "" # DNSアドレスをクリア
nmcli connection modify "MyWifi" ipv6.dns "" # IPv6 DNSアドレスをクリア
nmcli connection modify "MyWifi" ipv4.dns-method auto # DNS取得方法を自動に戻す (通常はIP methodに依存)
nmcli connection modify "MyWifi" ipv6.dns-method auto -
検索ドメインを設定:
bash
nmcli connection modify "MyWifi" ipv4.dns-search "internal.net, mycorp.local" -
設定の適用:
変更を反映させるには、接続を一度切断して再接続します。
bash
nmcli connection down "MyWifi"
nmcli connection up "MyWifi"
あるいは、システム全体の設定をリロードすることもできますが、接続の再起動が確実です。
NetworkManagerで設定されたDNSサーバーは、systemd-resolved
に渡され、/run/systemd/resolve/stub-resolv.conf
(127.0.0.53
)がアップストリームDNSサーバーとして使用するリストに追加されます。
サーバー環境での設定:Netplan
NetplanはUbuntu 17.10以降で導入されたネットワーク設定ツールで、特にサーバー環境でデフォルトとなっています。YAML形式の設定ファイルを/etc/netplan/
ディレクトリに配置し、netplan apply
コマンドで設定を適用します。Netplanはバックエンドとしてsystemd-networkd
またはNetworkManager
を使用し、低レベルな設定を行います。
Netplan設定ファイルによる設定
Netplanの設定ファイルは通常/etc/netplan/
ディレクトリにあります。ファイル名は.yaml
拡張子を持ちます(例: 50-cloud-init.yaml
, 01-netcfg.yaml
)。複数のファイルがある場合、ファイル名のアルファベット順/数字順に処理されます。
典型的なNetplan設定ファイルは以下の構造を持ちます。
yaml
network:
version: 2
renderer: networkd # or NetworkManager
ethernets:
enp3s0: # ネットワークインターフェース名
dhcp4: no
addresses: [192.168.1.100/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4] # DNSサーバーのIPアドレスリスト
search: [example.com, internal.net] # 検索ドメインリスト
enp4s0:
dhcp4: yes # DHCPでIPアドレスを取得
nameservers: # DHCPで取得したDNSサーバーを使わず、指定したサーバーを使う場合
addresses: [1.1.1.1]
wifis:
wlp2s0: # Wi-Fiインターフェース名
dhcp4: yes
access-points:
"YourSSID":
password: "yourpassword"
nameservers:
addresses: [9.9.9.9] # Wi-Fi接続でのみ有効なDNSサーバー
DNS設定に関連する主要な項目:
-
nameservers:
addresses:
: 使用するDNSサーバーのIPアドレスをリストで指定します。DHCP (dhcp4: yes
) を使用している場合でも、ここにアドレスを指定すると、DHCPで取得したDNSサーバーよりもこちらが優先されるか、DHCPのアドレスに追加/置換されます(バックエンドや設定による)。search:
: 検索ドメインをリストで指定します。
-
dhcp4:
:yes
またはno
。yes
の場合、DHCPサーバーからIPアドレス、デフォルトゲートウェイ、そしてDNSサーバーを取得します。no
の場合、手動でaddresses
,routes
,nameservers
などを指定する必要があります。
設定手順:
/etc/netplan/
ディレクトリに新しい.yaml
ファイルを作成または既存のファイルを編集します(例:sudo nano /etc/netplan/00-custom-config.yaml
)。ファイル名の先頭に数字を入れると、他のファイル(例:50-cloud-init.yaml
)よりも先に読み込まれるようにできます。- 上記の例を参考に、ネットワークインターフェースの設定と
nameservers
セクションを記述します。 - YAML構文が正しいか確認します。
bash
sudo netplan generate # 設定ファイルをバックエンドの設定に変換
エラーがなければ次に進みます。エラーが出る場合は、YAML構文が間違っています(インデント、コロン、ハイフンなど)。 - 設定をテスト適用します。問題が発生した場合に自動的にロールバックされます。
bash
sudo netplan try
テストが成功し、ネットワークが正常に機能していれば、「Press Enter to accept changes or wait 120 seconds to revert.」のようなメッセージが表示されるので、Enterキーを押して確定します。問題が発生した場合は、そのまま待つと自動的に設定がロールバックされます。 - テストせずに直接適用する場合は、
apply
コマンドを使用します。
bash
sudo netplan apply
apply
コマンドは自動ロールバック機能がないため、SSH接続などでリモートから実行する場合は注意が必要です。
Netplanによって設定されたDNSサーバーは、バックエンド(多くの場合systemd-networkd
)を経由してsystemd-resolved
に渡されます。systemd-resolved
はこれらのサーバーをアップストリームDNSサーバーとして使用します。
その他のDNS設定方法(古い方法や特殊なケース)
現代のUbuntuではsystemd-resolved
+ NetworkManager
/netplan
が主流ですが、過去のバージョンを使用している場合や、特定の理由でデフォルト構成を変更している場合、以下の方法が使われることがあります。
resolvconf (Ubuntu 14.04 – 17.10 で主流)
Ubuntu 17.10まで、多くのシステムではresolvconf
パッケージが/etc/resolv.conf
の管理に利用されていました。resolvconf
は、様々なプログラム(DHCPクライアント、VPNソフトウェアなど)からDNS情報を収集し、それらを統合して/etc/resolv.conf
ファイルを生成するフレームワークです。
/etc/resolv.conf
は通常/run/resolvconf/resolv.conf
へのシンボリックリンクになっていました。
resolvconf
は、/etc/resolvconf/resolv.conf.d/
ディレクトリ内のファイルを読み込んで最終的な/etc/resolv.conf
を生成します。
head
: ファイルの先頭に挿入される内容。通常、警告コメントなどが記述されます。base
: DHCPなどから情報が得られない場合にフォールバックとして使用される基本的な設定。tail
: ファイルの末尾に挿入される内容。手動で追加したいnameserver
やsearch
などを記述します。
手動で永続的なDNSサーバーを追加したい場合は、/etc/resolvconf/resolv.conf.d/tail
ファイルを編集するのが一般的な方法でした。
“`bash
/etc/resolvconf/resolv.conf.d/tail の例
nameserver 8.8.8.8
nameserver 8.8.4.4
“`
ファイルを編集したら、設定を反映させるためにresolvconf
サービスを更新します。
bash
sudo resolvconf -u
これにより、/run/resolvconf/resolv.conf
(つまり/etc/resolv.conf
)が再生成されます。
Ubuntu 18.04以降でも、resolvconf
パッケージをインストールすると、systemd-resolved
の管理を無効にしてresolvconf
が/etc/resolv.conf
を管理するモードに切り替わることがあります。しかし、これは非推奨であり、意図しない挙動を引き起こす可能性があるため、特別な理由がない限り避けるべきです。
/etc/network/interfaces によるDNS設定 (Legacy/Server)
ifupdown
パッケージがネットワーク設定を管理しているシステム(主に古いUbuntuサーバーや、MinimalインストールでNetplanやNetworkManagerが入っていない場合など)では、/etc/network/interfaces
ファイルで静的IP設定を行う際にDNSサーバーを指定できました。
“`ini
/etc/network/interfaces の例 (static IP)
auto enp3s0
iface enp3s0 inet static
address 192.168.1.100/24
gateway 192.168.1.1
dns-nameservers 8.8.8.8 8.8.4.4 # DNSサーバーのIPアドレス
dns-search example.com internal.net # 検索ドメイン
“`
この設定は、インターフェースが起動する際にresolvconf
(または互換レイヤー)に渡され、/etc/resolv.conf
に反映されます。
しかし、Ubuntu 18.04 LTS以降のサーバーデフォルトインストールではNetplanが使われるため、/etc/network/interfaces
を直接編集することは少なくなりました。Netplanはifupdown
をバックエンドとして利用することも可能ですが、通常はsystemd-networkd
を使用します。
/etc/resolv.conf を直接手動編集 (非推奨)
前述の通り、/etc/resolv.conf
ファイルを直接編集するのは、現代のUbuntuでは非推奨です。なぜなら、systemd-resolved
やNetworkManager
、netplan
などのサービスがこのファイルを管理しており、ネットワーク設定の変更によって手動での編集内容が簡単に上書きされてしまうからです。
ただし、一時的なテストや特定のデバッグ目的であれば、直接編集することも不可能ではありません。
“`bash
/etc/resolv.conf を一時的に手動編集する例
元のファイルがシンボリックリンクの場合は、まず削除または移動
sudo rm /etc/resolv.conf
新しくファイルを作成し、設定を記述
sudo nano /etc/resolv.conf
“`
ファイル内容例:
nameserver 1.1.1.1
nameserver 9.9.9.9
search mylocal.domain
注意点: この方法は、システムがネットワーク設定を変更(再起動、DHCPリース更新、VPN接続など)するたびにリセットされる可能性が非常に高いです。恒久的な設定変更には絶対に使用しないでください。
また、ファイルを変更されないようにロックする方法としてchattr +i /etc/resolv.conf
というコマンドが紹介されることがありますが、これは非常に危険で避けるべきです。これにより/etc/resolv.conf
が変更できなくなり、systemd-resolved
やNetworkManagerなどが正しく動作できなくなるため、予期しない問題を引き起こす可能性があります。ロックを解除するにはchattr -i /etc/resolv.conf
が必要です。
高度なDNS設定と機能
DNS検索ドメイン (Search Domains)
nameserver
の他に重要な設定としてsearch
オプションがあります。これは、単一のホスト名(ドットを含まない名前、例: webserver
)が指定された際に、どのドメインサフィックスを補完して名前解決を試みるかを定義します。
例えば、/etc/resolv.conf
または対応する設定ツールでsearch example.com internal.net
と設定されているとします。
ユーザーがping webserver
と入力した場合:
- システムはまず
webserver.example.com
の名前解決を試みます。 - もし失敗した場合、次に
webserver.internal.net
の名前解決を試みます。 - もし成功すれば、そのIPアドレスを使用します。
- 両方とも失敗した場合、システムはホスト名をそのまま(
webserver
として)名前解決しようと試みる場合がありますが、通常は失敗します。
検索ドメインは、ローカルネットワーク内でFQDN (Fully Qualified Domain Name) を入力せずにホスト名だけでアクセスしたい場合に非常に便利です。DHCPサーバーから自動的に提供されることもありますし、NetplanやNetworkManagerで手動設定することも可能です。
ローカルDNSキャッシュ
DNSクエリはネットワークを介した通信であり、多少のオーバーヘッド(遅延)が発生します。同じドメイン名を何度も問い合わせる場合、その都度外部のDNSサーバーに問い合わせるのは非効率です。
systemd-resolved
はデフォルトでDNSキャッシュ機能を持っています。これにより、一度解決した名前とIPアドレスの対応関係を一定期間保持し、同じ問い合わせが来た際にはキャッシュから即座に応答を返します。これにより、名前解決の高速化と、外部DNSサーバーへの負荷軽減が実現されます。
resolvectl statistics
コマンドでキャッシュの統計情報(キャッシュサイズ、ヒット数、ミス数など)を確認できます。
より高度なキャッシュやローカルでの名前解決(例: 内部ネットワークのホスト名)を行いたい場合は、dnsmasq
やBIND
といった専用のDNSサーバー/フォワーダーソフトウェアをローカルにインストールして設定することも可能です。これらをインストールした場合、多くは自身をループバックアドレス(例: 127.0.0.1
)で待ち受け、/etc/resolv.conf
のnameserver
をそのループバックアドレスに設定することになります。これにより、システムやアプリケーションからのDNSクエリはまずローカルのキャッシュサーバーに到達し、キャッシュがあれば応答を返し、なければ設定されたアップストリームDNSサーバーに問い合わせを行う、という流れになります。
DNS over TLS (DoT) および DNS over HTTPS (DoH)
従来のDNSクエリは暗号化されず、通信経路上で覗き見られたり改ざんされたりする可能性があります。DNS over TLS (DoT) と DNS over HTTPS (DoH) は、DNSクエリと応答をTLS/SSLで暗号化することで、プライバシーとセキュリティを向上させる技術です。
systemd-resolved
はDoTとDoHをサポートしています。/etc/systemd/resolved.conf
ファイルで設定できます。
“`ini
[Resolve]
DNS=…
FallbackDNS=…
DNSSEC=allow-downgrade # DNSSECを試みるが、失敗しても名前解決は続行
DNSOverTLS=yes # 可能であればDoTを使用 (yes/no/opportunistic)
DNSOverHTTPS=yes # 可能であればDoHを使用 (yes/no/opportunistic) – DNSOverTLSと排他
“`
DNSOverTLS=yes
: 設定されたDNSサーバーがDoTに対応している場合、DoTを使用します。対応していない場合は名前解決が失敗します。DNSOverTLS=opportunistic
: 設定されたDNSサーバーがDoTに対応していればDoTを使用し、対応していなければ通常のUDP/TCP DNSを使用します。これがデフォルトに近い動作で、多くの環境で推奨されます。
同様にDNSOverHTTPS
も設定できますが、通常はDoTかDoHのどちらか一方を使用します。これらの機能を利用するには、使用するDNSサーバーがDoT/DoHに対応している必要があります(例: Cloudflare (1.1.1.1), Google Public DNS (8.8.8.8), Quad9 (9.9.9.9) などは対応しています)。
設定変更後はsudo systemctl restart systemd-resolved
が必要です。resolvectl status
でDoT/DoHの状態を確認できます。
DNS設定のトラブルシューティング
DNS関連の問題は、ネットワーク接続や名前解決ができなくなるという形で現れるため、ユーザーにとって非常に困る問題の一つです。ここでは、一般的なトラブルシューティングの手順と役立つツールを紹介します。
-
基本的な接続確認:
- そもそもネットワークに接続できていますか? (
ping 8.8.8.8
のように、有名なDNSサーバーのIPアドレスや、インターネット上の有名なIPアドレスにpingしてみてください。これが成功すれば物理的な接続はできています。) - デフォルトゲートウェイに到達できますか? (
ping <ゲートウェイのIPアドレス>
)
- そもそもネットワークに接続できていますか? (
-
DNS設定の確認:
resolvectl status
(systemd-resolvedを使用している場合) またはcat /etc/resolv.conf
を実行し、設定されているDNSサーバーのIPアドレスを確認します。- 表示されているDNSサーバーは意図したものでしょうか? (
127.0.0.53
になっている場合は、systemd-resolvedのスタブリゾルバーを介しています。) - 設定されているDNSサーバーのIPアドレスに到達可能ですか? (
ping <DNSサーバーのIPアドレス>
)
-
名前解決のテスト:
以下のコマンドを使って、特定のホスト名の名前解決を試みます。dig <ホスト名>
: DNS問い合わせの詳細を表示します。名前解決に使用されたサーバーなども確認できます。
bash
dig www.google.com
dig www.internal.net @<特定のDNSサーバーIP> # 特定のサーバーに問い合わせ
dig webserver.internal.net +search # searchドメインを考慮して問い合わせるnslookup <ホスト名>
:dig
よりシンプルですが、名前解決をテストできます。
bash
nslookup www.ubuntu.com
nslookup myprinter 192.168.1.1 # 特定のサーバーに問い合わせhost <ホスト名>
: 簡単な名前解決情報を提供します。
bash
host example.comresolvectl query <ホスト名>
:systemd-resolved
を使用している場合に推奨されるコマンドです。どのサーバーを使って解決したかなどの詳細が表示されます。
-
ファイアウォールの確認:
システムやネットワークのファイアウォールが、DNSトラフィック(通常UDP/TCPポート53)をブロックしていないか確認します。sudo ufw status
(UFWを使用している場合)sudo iptables -L
またはsudo nft list ruleset
(iptables/nftablesを直接使用している場合)
特に、ローカルの127.0.0.53
への通信や、設定されているアップストリームDNSサーバーへの通信が許可されている必要があります。
-
DNSサービスの再起動:
DNS設定を変更したり、一時的な不具合が疑われる場合は、関連サービスを再起動してみます。sudo systemctl restart systemd-resolved
sudo systemctl restart NetworkManager
(デスクトップの場合)sudo netplan apply
(サーバーの場合)
-
/etc/nsswitch.conf
の確認:
システムが名前解決にどのソース(ファイル、DNS、mDNSなど)をどのような順番で使用するかは/etc/nsswitch.conf
で定義されています。hosts:
の行にresolve
やdns
が含まれているか確認します。
bash
cat /etc/nsswitch.conf | grep hosts
# 例: hosts: files resolve [!UNAVAIL=return] dns myhostname
resolve
が含まれていればsystemd-resolved
が使用されます。dns
が含まれていれば従来のCスタブリゾルバーが直接/etc/resolv.conf
を読み込んでDNS問い合わせを行います。 -
DHCPリース情報の確認:
DHCPでIPアドレスを取得している場合、同時にDNSサーバー情報も取得しています。DHCPクライアントの設定やログを確認することで、どのようなDNS情報を受け取っているか把握できます。 -
VPNやプロキシの影響:
VPNクライアントやプロキシツールは、独自のDNS設定を適用したり、システムの名前解決設定を上書きしたりすることがあります。VPNやプロキシを使用している場合は、それらを無効にして問題が解決するか試してみてください。
これらのステップを順に追うことで、DNS設定の問題箇所を特定し、解決に繋げることができます。
まとめとベストプラクティス
UbuntuにおけるDNS設定は、使用しているバージョンや環境(デスクトップかサーバーか)、そしてネットワーク設定ツール(NetworkManager, netplanなど)によって適切な方法が異なります。
現代のUbuntu (18.04 LTS以降) におけるベストプラクティス:
/etc/resolv.conf
を直接編集しない: このファイルはシステムによって管理されるため、手動変更は推奨されません。代わりに、以下のいずれかのツールを使用します。- デスクトップ環境の場合: NetworkManager のGUIまたは
nmcli
コマンドを使用して、接続ごとのDNS設定を行います。これは/etc/NetworkManager/system-connections/
ディレクトリ内の接続設定ファイルに保存されます。 - サーバー環境の場合: Netplan を使用して
/etc/netplan/*.yaml
ファイルにDNS設定を記述し、sudo netplan apply
で適用します。 - systemd-resolved の活用: これが名前解決のバックエンドサービスです。設定は主にNetworkManagerやNetplanから供給されますが、
/etc/systemd/resolved.conf
でグローバルな設定(DNSSEC, DoT/DoHなど)を行うことも可能です。resolvectl status
やresolvectl query
コマンドで状態確認やデバッグを行います。 - トラブルシューティングには専用ツールを使う:
dig
,nslookup
,host
,resolvectl
といったコマンドは、名前解決の問題を診断するのに非常に役立ちます。
古いUbuntuバージョンや特殊な構成の場合:
- Ubuntu 17.10以前では
resolvconf
が/etc/resolv.conf
を管理していました。手動設定は/etc/resolvconf/resolv.conf.d/tail
を編集し、sudo resolvconf -u
で反映させていました。 ifupdown
で設定されている場合、/etc/network/interfaces
ファイルにdns-nameservers
やdns-search
を記述しました。
DNS設定は、単にインターネットに接続できるだけでなく、ネットワーク通信の速度や安定性、そしてプライバシーやセキュリティ(DNSSEC, DoT/DoH)にも影響を与えます。お使いの環境に合った適切な方法でDNSを設定し、必要に応じてトラブルシューティングツールを活用することで、快適で安全なネットワーク環境を維持することができます。
本記事が、Ubuntuユーザーの皆様のDNS設定に関する理解を深め、様々な状況での設定や問題解決に役立つことを願っています。