Public DNS の設定を整理する

本稿は、DNS の基本から、公開 DNS （Public DNS）と家庭用ルーターを窓口にする構成の違い、プライバシーとセキュリティの考え方、Linux における確認方法、そして NetworkManager を使って接続プロファイルを切り替える実務までを、一つの流れとして整理するものである。単に 8.8.8.8 や 1.1.1.1 のような数字を覚えるだけでは、なぜその設定を選ぶのかが見えない。逆に、仕組みと責任分界を整理すると、家庭用途、個人サーバー用途、本格運用用途で何を選ぶべきかがかなり明確になる。 ここでは家庭用ルーターの代表例として 192.168.0.1 のような一般的なプライベートアドレスを用いる。特定の家庭や機器に固有の事情には立ち入らず、広く再利用できる説明をする。

1. DNS とは何か

DNS は、インターネット上の「名前」と「住所」をつなぐ仕組みである。人間は example.com のような文字列なら覚えやすいが、コンピューターは最終的に IP アドレスで通信する。そのため、通信を始める前には「この名前はどの IP アドレスなのか」を調べる必要がある。この変換作業が名前解決であり、その中心にあるのが DNS である。この仕組みはふだん意識されにくいが、実際には非常に重要である。電話帳が壊れていると相手の番号が引けないのと同じで、DNS が不安定になると、ネットワーク機器そのものは動いていても目的の相手に到達できない。したがって DNS は、通信速度の補助設定ではなく、通信成立そのものを支える前提条件と理解した方がよい。 [1] [2]

2. 8.8.8.8 や 1.1.1.1 とは何か

8.8.8.8 や 1.1.1.1 のような数値は、公開 DNS サーバーの住所そのものである。つまり、端末はそこへ問い合わせを送り、「このドメイン名に対応する IP アドレスを教えてほしい」と依頼する。したがって、これらの数字は単なるおまじないではなく、「名前解決をどこへ委ねるか」という運用判断を表している。ここで重要なのは、公開 DNS は世界中の利用者が直接使えるように設計されているという点である。家庭用ルーターや契約している回線事業者の DNS を使う代わりに、端末やサーバーから直接これらへ問い合わせる構成も取れる。その結果、管理のしやすさ、障害時の切り分け、プライバシーの帰属先などが変わってくる。 [3] [4] [5] [6] [7]

また、多くの公開 DNS は冗長化のために複数のアドレスを提供している。通常はプライマリとセカンダリを組み合わせて設定し、片方の DNS サーバーが利用できない場合にはもう一方へ問い合わせが切り替わる。このように複数の DNS を設定することで、名前解決の停止を防ぐ構成が取られる。

3. DNS はなぜ複数設定するのか

DNS は 1 台だけ設定するとは限らない。多くの環境では複数の DNS サーバーを設定し、先頭の候補が使えなかったときに次を使う。これは名前解決が通信全体の入口にあるためであり、ここが 1 か所だけに依存していると、その 1 台の不調でネットワーク利用全体が止まり得るからである。このとき「主 DNS」や「副 DNS」という言い方がされるが、実際の設定では特別なラベルがなくても並び順そのものが優先順位になっていることが多い。したがって、ただ数字が並んでいるだけに見えても、内部的には優先順位つきの候補一覧である。DNS の複数設定は、複雑さを増やすためではなく、止まりにくい構成を作るための基本的な考え方である。 [1] [2]

4. 同一事業者のペアと異なる事業者の組み合わせ

公開 DNS の説明では、しばしば 8.8.4.4 のような「もう一つの代表アドレス」が登場する。これは同じ事業者が複数の入口を用意しているケースであり、同一サービス内での冗長化と考えると理解しやすい。Google なら 8.8.8.8 と 8.8.4.4、Cloudflare なら 1.1.1.1 と 1.0.0.1 のような形である。一方で、Google、Cloudflare、Quad9 のように異なる運営主体を混ぜる構成もある。これは同一サービス内での冗長化ではなく、事業者自体の分散を重視する考え方である。どちらにも合理性はあるが、前者は構成ポリシーが揃いやすく、後者は単一事業者障害への耐性が高い。したがって、DNS を複数設定するときには、単に数を増やすのではなく、どの層を分散したいのかを意識した方がよい。 [3] [6] [8]

5. すでに複数の公開 DNS があるなら同一事業者の別アドレスは必要か

たとえば Google、Cloudflare、Quad9 のように、すでに異なる事業者の公開 DNS を複数使っているなら、さらに同じ事業者の別アドレスを足す必要性は高くない。理由は、すでに運営主体が分散されているからである。ある会社の DNS 全体に障害が起きても、別会社の DNS へ逃げられるという意味では、この方が分散の質は深い。もちろん、同一事業者のペアを揃えること自体が悪いわけではない。挙動やフィルタ方針を揃えたいなら、その方が見通しはよい。ただし、個人の Linux サーバーや家庭内の技術検証という文脈では、まず運営主体の分散ができていれば十分に合理的である。したがって、同一事業者の別アドレスを必ず追加しなければならないと考える必要はない。 [8] [9]

6. 複数の公開 DNS を使うメリット

複数の公開 DNS を使う最大の利点は、単一障害点を減らせることである。名前解決は通信全体の入口にあるため、ここが止まると Web 閲覧や更新作業、パッケージ取得など多くの操作が同時に詰まる。したがって、1 つの DNS に全面依存しないことは運用上かなり意味が大きい。さらに、公開 DNS を直接使うと、問い合わせ先が明確になる。家庭用ルーターや ISP の DNS を経由する構成では、その途中で何が行われているかを利用者が把握しづらいことがある。公開 DNS 直指定は、設定の手間は少し増えるが、経路と責任分界が見えやすくなる。技術者やサーバー管理者がこれを好むのは、単に速いからではなく、説明可能性が高いからである。 [3] [5] [7]

7. 複数の公開 DNS を使うデメリット

異なる公開 DNS を混ぜる構成には、分散という強みがある一方で、応答内容が常に完全一致するとは限らないという注意点がある。大規模サイトや動画配信サービスは、利用者の場所や DNS 事業者の見え方に応じて最適な接続先を返すことがある。そのため、問い合わせる DNS が変わると、接続先の IP アドレスや CDN の誘導先が少し変わる場合がある。また、Quad9 のようにセキュリティを重視する DNS は、悪性ドメインの遮断を行うことがある。これは防御の観点では利点だが、別の DNS では解決できるのに、特定の DNS では解決できないという差の原因にもなる。したがって、複数の公開 DNS を混ぜるときは、冗長化だけでなく、各事業者のポリシー差も同時に持ち込むことになる。 [8] [9]

8. ルーターのアドレスを DNS にするとはどういうことか

DNS に 192.168.0.1 のようなプライベートアドレスが設定されている場合、多くは家庭用ルーター自身が DNS の窓口になっている。端末は直接インターネット上の公開 DNS へ問い合わせるのではなく、まずルーターへ問い合わせ、ルーターが必要に応じて外部 DNS へ転送する。これを DNS フォワーダーや DNS プロキシと呼ぶことがある。この方式は、家庭全体の管理を簡単にするという意味では非常に合理的である。各端末はルーターだけ見ていればよく、その先を意識しなくて済む。しかし同時に、名前解決の途中にルーター固有の処理が 1 層増えることも意味する。したがって便利さと引き換えに、中間層の挙動を利用者が見えにくくなるという側面も持つ。 [4] [15]

9. ルーター DNS のメリット

ルーターを DNS の窓口にする方式は、一般家庭では非常に実用的である。スマートフォン、タブレット、ノート PC、テレビ、ゲーム機など、多数の機器が混在する環境で、各端末へ公開 DNS を手動設定するのは手間が大きい。ルーターに任せておけば、DHCP を通じて一括で配布でき、管理負荷を大きく減らせる。また、家庭内だけで使う機器名や、ルーター側で一括して扱いたいネットワーク設定と相性がよいこともある。一般利用では、細かい制御よりも「難しいことを考えなくてよい」ことの価値が大きい。ルーター DNS はまさにその方向に最適化された方式であり、家庭用途では十分に合理的な選択肢である。 [15] [16]

10. ルーター DNS のデメリット

ルーター DNS の弱点は、仕組みが単純であるがゆえに、内部で何が起きているかを利用者が把握しにくい点にある。端末の問題なのか、ルーター内部のキャッシュなのか、さらにその先の外部 DNS なのかを切り分ける必要が出るため、技術的な調査では一段階余計に考えることになる。また、家庭用ルーターは便利さを優先して作られているため、高機能な DNS ソフトウェアほど詳細な制御や可視化ができないことが多い。一般家庭ではそれで十分だが、個人サーバーや検証環境では、この「中間層が見えない」こと自体がストレスになる。したがって、ルーター DNS は簡単さと引き換えに、説明可能性と制御性を下げる方式でもある。 [15] [17]

11. ルーター DNS と公開 DNS の比較

ルーター DNS と公開 DNS 直指定の違いは、単に「どちらが速いか」という話ではない。実際には、どこまでを家庭用ルーターへ委ね、どこからを自分で明示的に管理するかという設計思想の違いである。ルーター DNS は一括管理に向いており、公開 DNS 直指定は透明性と切り分けのしやすさに向いている。このため、一般家庭ではルーター DNS が自然であり、技術者の個人サーバーや検証環境では公開 DNS 直指定が好まれやすい。どちらが絶対に正しいかではなく、用途ごとに重視する価値が違うと考えた方が無理がない。重要なのは、自分が今どの方式を使っているのかを曖昧にしないことである。 [15] [17]

12. プライバシーの観点で見る DNS

DNS は「どこへ通信しようとしたか」を含むため、どの DNS を使うかはプライバシーとも関係する。ルーター DNS を使う場合、問い合わせは家庭内ルーターを経由し、その先の回線事業者側 DNS や設定済み外部 DNS へ届く。したがって、ログがどこに集まりやすいかは、ルーターの設計と回線事業者の構成に左右される。一方、公開 DNS を直接使う場合は、問い合わせ先が Google、Cloudflare、Quad9 のような公開 DNS 事業者へ移る。ここで重要なのは、「DNS を変えれば完全に匿名になる」という理解は誤りだという点である。実際には、誰に問い合わせ履歴を見せやすい構成になるかが変わるだけである。したがって DNS のプライバシー論は、「隠せるかどうか」よりも、「誰へ委ねるか」を考えるべき問題である。 [5] [7] [8]

13. セキュリティの観点で見る DNS

セキュリティ面で重要なのは、DNS が「正しい名前解決を返すこと」である。もし DNS が改ざんされれば、本来とは別の接続先へ誘導される可能性がある。これは、正しい住所の代わりに偽の住所を教えられるのと同じであり、通信の前提が崩れる。ここで、公開 DNS には大きく二つの方向性がある。一つは、できるだけ中立的に応答し、勝手な介入を減らす方向である。もう一つは、マルウェアやフィッシング関連のドメインをブロックし、防御を重視する方向である。前者は再現性と予測可能性に強く、後者は事故防止に強い。したがって DNS の選定は、速度比較だけではなく、「中立性を優先するか、防御性を優先するか」というポリシーの選択でもある。 [7] [8] [13]

14. 平文 DNS と暗号化 DNS

従来の DNS は長く平文で使われてきた。平文であるということは、途中経路の機器や事業者から問い合わせ内容が比較的見えやすいということである。これを改善する仕組みとして、近年は DNS over TLS や DNS over HTTPS が使われるようになっている。ただし、暗号化 DNS は「誰にも見えなくなる」仕組みではない。途中経路には見えにくくなるが、最終的な問い合わせ先である DNS 事業者には内容が届く。したがって、暗号化 DNS は万能な匿名化技術ではなく、「どこまでを途中経路に晒すか」を改善する技術である。この区別を曖昧にすると、期待と実態のずれが生じやすい。 [10] [11]

15. ブラウザが独自に DNS を使う問題

近年のブラウザは、OS が持つ DNS 設定とは別に、独自に DNS over HTTPS を使うことがある。これにより、見かけ上は同じ DNS を使っているように見えても、実際にはブラウザだけ別の DNS 事業者へ問い合わせていることがある。結果として、コマンドラインでの名前解決とブラウザ上の名前解決が一致しないことがある。この点は、現代の DNS をやや複雑にしている。以前は /etc/resolv.conf を見ればおおよその実態がわかったが、現在はアプリケーション側が OS の設定を迂回する場合もある。したがって、DNS 設計や障害調査を行うときは、「OS の DNS 設定」と「ブラウザやアプリの実際の問い合わせ先」を分けて考える必要がある。 [11] [12]

16. Linux における DNS の基本構造

Linux では、アプリケーションが直接 DNS サーバーへ問い合わせるとは限らない。多くの場合は OS 側のリゾルバを経由し、その先で /etc/resolv.conf やローカルの DNS 管理機構が参照される。このため、Linux の DNS は単にどの nameserver が書かれているかだけでなく、その前後に何が存在しているかまで含めて見ないと実態がつかみにくい。ここを理解しておくと、「設定ファイルにはこう書かれているのに、実際の動作が違う」という現象が起きても驚かなくなる。Linux の DNS は一枚岩ではなく、ネットワークマネージャー、ローカルキャッシュ、スタブリゾルバなどが重なって構成されることが多い。したがって、確認手順も 1 つでは足りない。 [13] [14] [15]

17. systemd-resolved、unbound、BIND の役割

Linux の DNS を深く理解するには、systemd-resolved、unbound、BIND の役割を混同しないことが重要である。systemd-resolved は主にクライアント側の DNS 管理と簡易キャッシュを担う。unbound は本格的な再帰リゾルバであり、外部公開 DNS へ丸投げせず、自分で DNS の階層をたどる構成も取れる。BIND は特に権威 DNS サーバーとして歴史が長く、自分のドメインの正式な回答を公開する側で強い。つまり、三者は似て見えて役割が違う。一般的な Linux デスクトップやノート PC では systemd-resolved が自然であり、独立性を高めたいサーバーでは unbound が有力であり、自前ドメインの外部公開では BIND が候補になる。DNS は一つの技術名に見えても、実際には複数の責務が分かれていると考えた方が理解しやすい。 [13] [18] [19] [20]

18. 現在の DNS 設定を正確に確認する方法

現在の DNS 設定を正確に確認したいなら、1 つのコマンドだけで判断しない方がよい。Linux では /etc/resolv.conf の見た目と実際の有効経路が一致しないことがあるためである。まず確認すべきなのは、/etc/resolv.conf の実体が何を指しているかである。単なるテキストファイルなのか、systemd-resolved のスタブを指すシンボリックリンクなのかで、読み方が変わる。

次に、systemd-resolved が動いている環境では resolvectl status を見る。これにより、現在どのリンクにどの DNS サーバーが紐づいているか、どの検索ドメインが使われているかを、実際の運用状態として確認できる。これは単に設定ファイルを見るだけよりも、現在の有効状態を確認するという意味で正確である [4] [5]。

さらに、NetworkManager を使っている環境では、device と connection の両方を見る必要がある。device は現在の実デバイス状態を示し、connection はプロファイルとして保存されている設定を示す。したがって、現在つながっているデバイスがどの接続プロファイルを使っているか、そしてそのプロファイルに DNS がどう定義されているかを両面から確認するのが正確である [1] [2]。

特定のインターフェースだけ見たい場合は、次のように絞り込むとよい。ここではインターフェース名の例として enp0s31f6 を用いるが、実際には各環境の名称へ置き換える。

確認の要点は、/etc/resolv.conf、resolvectl、nmcli の三つを突き合わせることである。どれか一つだけを見ると、保存設定だけを見て現在状態を見落としたり、逆に現在状態だけを見て永続設定の位置を見失ったりする。正確な確認とは、複数レイヤーを照合して矛盾がないかを見る作業である。 [13] [14] [15] [16]

19. NetworkManager の GENERAL.CONNECTION をどう理解し、どう変更するか

nmcli device show の GENERAL.CONNECTION は、今そのデバイスでどの接続プロファイルが有効になっているかを示す状態表示である。したがって、これを「設定項目」と見て直接書き換えようとすると混乱しやすい。実際には、GENERAL.CONNECTION という欄そのものを直接編集するのではなく、別の接続プロファイルをアクティブにすることで結果として変わると理解するべきである [1] [2]。

まず、現在そのデバイスがどのプロファイルを使っているかは次のように確認できる。

次に、利用可能な接続プロファイル一覧を確認する。

別の接続プロファイルへ切り替えたい場合は、そのプロファイルを対象デバイスへ対して有効化する。これにより、GENERAL.CONNECTION の表示は結果として新しいプロファイル名へ変わる。

もし特定のインターフェースへ明示的に結び付けたい場合は、接続プロファイル側の connection.interface-name を設定する。これは「このプロファイルはこのデバイスで使う」という永続設定であり、GENERAL.CONNECTION のような状態表示とは層が違う。

DNS 自体をその接続プロファイルへ設定したい場合は、ipv4.dns や ipv6.dns を編集する。たとえば IPv4 の DNS を明示し、自動取得 DNS を無視したいなら、次のような操作になる。

要するに、GENERAL.CONNECTION を変える方法とは、その文字列を直接編集することではない。NetworkManager が管理する接続プロファイルを理解し、どのプロファイルを編集し、どのプロファイルを有効化するかを操作することで、結果として GENERAL.CONNECTION の表示が変わる。ここを取り違えないことが、nmcli を使う上での重要な実務ポイントである。 [15] [16]

20. Linux サーバーで DNS 設計をどう考えるか

Linux サーバーで DNS をどう設計するかは、最終的には「どこまで自分で責任を持つか」という問題である。最も簡単なのはルーターや公開 DNS に任せる方式であり、最も独立性が高いのは自前の再帰リゾルバを持つ方式である。その中間に、公開 DNS を明示しつつ systemd-resolved や NetworkManager で整理する構成がある。個人サーバーや検証環境では、まず公開 DNS を明示的に設定し、現在の状態を resolvectl と nmcli で確認できるようにしておくのがわかりやすい。これだけでも、ルーター任せの構成より責任分界はかなり明確になる。さらに独立性を高めたくなった段階で unbound のような仕組みを導入すればよい。DNS 設計とは、最初から最強構成を選ぶことではなく、必要な透明性と管理負荷のバランスを取ることである。 [13] [15] [18]

21. 結論

DNS の話は、表面上は「どの数字を設定するか」という単純な話に見える。しかし実際には、どこへ名前解決を委ねるか、誰に問い合わせ履歴を寄せるか、どの程度の中立性と防御性を求めるか、そして障害時にどこまで自分で説明可能にしたいかという設計問題が含まれている。したがって DNS 設定は、速度比較の小手先ではなく、運用哲学に属する設定である。一般家庭では、ルーター DNS で十分な場合が多い。個人サーバーでは、公開 DNS を明示し、実際の状態をコマンドで追えるようにしておくと運用が整理しやすい。さらに独立性を求めるなら、unbound のような仕組みを導入する道がある。そして NetworkManager を使う環境では、GENERAL.CONNECTION を直接変えるのではなく、接続プロファイルの編集とアクティブ化によって結果として変わるものだと理解することが、混乱を避ける最短経路である。 [13] [15] [18]

参考文献

1. RFC 1034 – Domain Names – Concepts and Facilities.. https://datatracker.ietf.org/doc/html/rfc1034
2. RFC 1035 – Domain Names – Implementation and Specification.. https://datatracker.ietf.org/doc/html/rfc1035
3. Google Public DNS.. https://developers.google.com/speed/public-dns
4. Get Started | Public DNS.. https://developers.google.com/speed/public-dns/docs/using
5. Cloudflare 1.1.1.1 (DNS Resolver).. https://developers.cloudflare.com/1.1.1.1/
6. Cloudflare 1.1.1.1 IP addresses.. https://developers.cloudflare.com/1.1.1.1/ip-addresses/
7. Quad9 Documentation: Overview.. https://quad9dns.github.io/documentation/
8. Quad9 Service Addresses & Features.. https://quad9.net/service/service-addresses-and-features/
9. Quad9 FAQ.. https://quad9.net/support/faq/
10. RFC 7858 – Specification for DNS over TLS.. https://datatracker.ietf.org/doc/rfc7858/
11. RFC 8484 – DNS Queries over HTTPS (DoH).. https://datatracker.ietf.org/doc/html/rfc8484
12. Firefox DNS over HTTPS – Mozilla Support.. https://support.mozilla.org/en-US/kb/firefox-dns-over-https
13. systemd-resolved.service.. https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html
14. resolvectl(1).. https://man7.org/linux/man-pages/man1/resolvectl.1.html
15. NetworkManager Reference Manual – nmcli.. https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nmcli.html
16. NetworkManager Reference Manual – nm-settings-nmcli.. https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/nm-settings-nmcli.html
17. NetworkManager Reference Manual.. https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/index.html
18. Unbound documentation.. https://unbound.docs.nlnetlabs.nl/
19. BIND 9.. https://www.isc.org/bind/
20. BIND 9 documentation.. https://bind9.readthedocs.io/en/latest/