ホーム テクノロジー LINUX Linux 上でローカル DNS キャッシュ サーバーをセットアップするにはどうすればよいですか?

Linux 上でローカル DNS キャッシュ サーバーをセットアップするにはどうすればよいですか?


DNS ルックアップは通常、心配する必要はありません。時にはそうすべきです!

自宅やオフィスの ISP のネームサーバーが遅い場合、またはサーバーが大量の検索を実行している場合は、ローカル キャッシュ DNS サーバーが必要です。

キャッシュ DNS サーバーはどのように役立ちますか?

キャッシュ DNS サーバーは、システムが行うすべての DNS クエリを実行し、その結果をメモリに保存またはキャッシュすることによって機能します。ドメインに対して重複したリクエストを行うたびに結果がメモリにキャッシュされると、結果はメモリからほぼ瞬時に提供されます。

これはそれほど重要ではないように思えるかもしれませんが、ISP の DNS サーバーの応答に時間がかかると、インターネットの閲覧が大幅に遅くなります。たとえば、米国のニュース チャンネル MSNBC のホームページを正しく読み込むには、100 を超える一意のドメイン名にアクセスする必要があります。 ISP のネーム サーバーの応答に通常よりも 10 分の 1 秒でも時間がかかる場合は、ページの読み込みが完了するまでに 10 秒長くかかることを意味します。

ローカル キャッシュ DNS サーバーは、自宅やオフィスで役立つだけでなく、サーバーでも役立ちます。大量の DNS ルックアップを行うアプリケーション (たとえば、スパム対策ソフトウェアを実行している多忙な電子メール サーバー) がある場合、ローカル キャッシュ DNS サーバーから速度が向上します。

最後に、 systemd-resolved 、最新の安全な DNS 標準 DNSSEC と DNSoverTLS ( DoT)をサポートします。これらは、オンラインでの安全性を確保し、プライバシーを維持するのに役立ちます。

どのローカル キャッシュ DNS を使用しますか?

このガイドで有効にして構成するローカル キャッシュ DNS サーバーは systemd で解決されます。このツールは、システム管理ツールの systemd スイートの一部です。システムが systemd を使用しており、主要な Linux ディストリビューションのほぼすべてが systemd を使用している場合は、systemd-resolved がすでにインストールされていますが、実行されていません。ほとんどのディストリビューションでは、systemd-resolved が存在してもそれを使用しません。

systemd-resolved起動時に開始するように構成する小さなローカル キャッシュ DNS サーバーを実行することによって機能します。次に、システムの残りの部分を再構成して、DNS クエリをローカル キャッシング systemd で解決された DNS に送信します。

すでに systemd-resolved を使用しているかどうかを確認するにはどうすればよいですか?

Ubuntu 19.04 など、一部の Linux ディストリビューションでは、デフォルトで systemd-resolved がすでに使用されています。

すでにsystemd-resolvedを実行している場合は、それを有効にしたり、それを使用するようにシステムを設定したりする必要はありません。ただし、NetworkManager などのネットワーク管理ツールはシステムのネットワーク構成を無視する可能性があるため、正しく構成されていることを確認する必要がある場合があります。

次のセクションに進む前に、次のコマンドを実行して、systemd-resolved がすでに実行されているかどうかを確認します。

 $ resolvectl status

メッセージが表示された場合:

 $ resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

systemd-resolved を実行していないため、次のセクションに進む必要があります。代わりに、次のような内容で始まる出力が表示される場合:

 Global
       LLMNR setting: yes
MulticastDNS setting: yes
  DNSOverTLS setting: opportunistic
      DNSSEC setting: allow-downgrade
    DNSSEC supported: no
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
                      1.0.0.1

その場合、すでに systemd-resolved が実行されているため、有効にする必要はありません。

systemd-resolved の有効化と構成

すでに systemd の一部として組み込まれている systemd-resolved をインストールする必要はありません。必要なのは、これを起動して DNS キャッシュ サーバーを実行し、起動時に起動できるようにすることだけです。

非 root ユーザーが systemd-resolved を起動できるようにsudo有効にして、シェル プロンプトから次のコマンドを実行します。

 $ sudo systemctl start systemd-resolved.service

次に、次のコマンドを実行して、システム起動時に systemd-resolved を開始します。

 $ sudo systemctl enable systemd-resolved.service

残っている構成の最後の項目は、systemd-resolved が解決されたドメインにクエリを実行する DNS サーバーを設定することです。ここには多くのオプションがありますが、次のペアはいずれも無料で高速で、両方とも DNSSEC と DoT をサポートしています。

GoogleパブリックDNS

  • 8.8.8.8
  • 8.8.4.4

CloudflareパブリックDNS

  • 1.1.1.1
  • 1.0.0.1

systemd で解決されたメインの設定ファイルをお気に入りのテキスト エディタで開きます。ここでは nano を使用しています。

 $ sudo nano /etc/systemd/resolved.conf

行頭の編集

#DNS=

IP アドレスのペアがリストされるようにします。ここでは、Cloudflare DNS サーバーが示されています。

 DNS=1.1.1.1 1.0.0.1

保存してテキスト エディタを終了します。次に、systemd-resolved を再起動して、ネームサーバーの使用を開始する必要があります。

 $ sudo systemctl restart systemd-resolved.service

systemd-resolved は現在実行中であり、システムを構成して使用を開始するとすぐに、DNS クエリの高速化とセキュリティ保護を開始できるようになります。

systemd-resolved を使用するようにシステムを構成する

systemd-resolved を使用するようにシステムを構成するにはいくつかの方法がありますが、ここではほとんどのユースケースをカバーする 2 つの構成を見ていきます。 1 つ目は推奨構成で、2 つ目は互換構成です。 2 つの違いは、 /etc/resolv.confファイルの管理方法です。

/etc/resolv.conf ファイルには、システム上のプログラムがクエリするネームサーバーの IP アドレスが保持されます。 DNS クエリを実行する必要があるプログラムは、このファイルを参照して、クエリを実行するためにどのサーバーに接続する必要があるかを調べます。

systemd-resolved の 2 つのモードは、このファイルの内容がどのように管理されるかに重点を置いています。推奨モードでは、/etc/resolv.conf が /run/systemd/resolve/stub-resolv.conf へのシンボリックリンクになります。このファイルは systemd-resolved によって管理されるため、systemd-resolved はシステム上の他のすべてのプログラムの DNS 構成情報を管理します。

これにより、他のプログラムが /etc/resolv.conf の内容を管理しようとするときに問題が発生する可能性があります。互換モードでは、/etc/resolv.conf がそのまま残り、systemd-resolved がその DNS 情報を使用している間、他のプログラムがそれを管理できるようになります。このモードでは、/etc/resolv.conf を管理する他のプログラムは、/etc/resolv.conf のシステム ネームサーバーとして 127.0.0.53 を設定するように構成する必要があります。

推奨モードの設定

このモードを設定すると、 systemd-resolved /etc/resolv.confを /run/systemd/resolve/stub-resolv.conf へのシンボリックリンクにして管理します。これは自動的に構成されないため、手動で行う必要があります。

まず、既存の /etc/resolv.conf ファイルを削除するか、名前を変更します。名前を変更しても同じ効果が得られるため、削除するよりも良いオプションですが、元の情報が必要な場合はいつでも元のファイルを参照できます。ここでは、mv コマンドを使用して /etc/resolv.conf の名前を変更します。

 $ sudo mv /etc/resolv.conf /etc/resolv.conf.original

次に、シンボリックリンクを作成します。

 $ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

最後に、systemd-resolved を再起動します。

 $ sudo systemctl restart systemd-resolved.service

互換モードの設定

このモードでは、systemd-resolved が起動したローカル ネームサーバーがシステム サービスによってクエリされるようにする必要があります。テキスト エディタで /etc/resolv.conf を開きます。ここでは nano エディタが使用されています。

 $ sudo nano /etc/resolv.conf

「nameserver」で始まる行をすべて削除し、次の行を追加します。

 nameserver 127.0.0.53

この編集は、/etc/resolv.conf を管理している他のプログラムによって変更される可能性があります。この場合、編集を永続的にするには、このネームサーバーを使用するようにプログラムを構成する必要があります。

systemd 解決済みのデバッグ

これらの変更を行った後、システムがどのように DNS クエリを実行しているかを正確に検出するのは困難な場合があります。何が起こっているかを観察する最も効果的な方法は、systemd-resolved をデバッグ モードにしてログ ファイルを監視することです。

systemd-resolved は systemd サービスです。つまり、デバッグ設定を含むドロップイン サービス ファイルを作成することで、簡単にデバッグ モードに移行できます。次のコマンドは、正しい場所に正しいファイルを作成します。

 $ sudo systemctl edit systemd-resolved.service

次の行をエディタに貼り付け、保存して終了します。

 [Service]
Environment=SYSTEMD_LOG_LEVEL=debug

systemd-resolved サービスは、正常に保存して終了すると自動的に再ロードされます。

同じサーバーに対して 2 番目の端末を開き、systemd で解決されたサービスのジャーナル ログを追跡します。

 $ sudo journalctl -f -u systemd-resolved

「DNS サーバーの使用」で始まる行、例:

 Using DNS server 1.1.1.1 for transaction 19995.

DNS クエリにどの DNS サーバーが使用されているかを正確に示します。この場合、1.1.1.1 の Cloudflare DNS サーバーがクエリされました。

「キャッシュミス」となっている行は、ドメイン名がキャッシュされていないことを示します。例えば:

 Cache miss for example.com IN SOA

「ポジティブ キャッシュ ヒット」で始まる行、例:

 Positive cache hit for example.com IN A

systemd-resolved が以前にこのドメインをクエリし、その応答がローカル メモリのキャッシュから提供されたことを示します。

systemd-resolved の作業が終了したら、デバッグ モードを無効にする必要があります。これは、ビジー状態のシステム上に非常に大きなログ ファイルが作成されるためです。次のコマンドを実行すると、デバッグ ログを無効にできます。

 $ sudo systemctl edit systemd-resolved.service

追加した 2 行を削除し、保存してエディターを終了します。

安全な DNS クエリの使用

systemd-resolved は、DNSSEC と DNSoverTLS の両方をサポートする、現在利用可能な数少ない DNS サーバーの 1 つです。これらは両方とも、本物の DNS 情報 (DNSSEC) を受信して​​いることを保証し、インターネット上を通過する DNS トラフィックを誰も覗き見ることができないようにするのに役立ちます。 (ドット)。

これらのオプションは、systemd-resolved のメイン設定ファイルをテキスト エディタで開くことで簡単に有効にできます。

 $ sudo nano /etc/systemd/resolved.conf

そして、次の 2 行が設定されるようにファイルを編集します。

 DNSSEC=allow-downgrade
DNSOverTLS=opportunistic

保存してエディターを終了し、systemd-resolved をリロードします。

 $ sudo systemctl restart systemd-resolved.service

設定した DNS サーバーが DNSSEC と DoT をサポートしている限り、DNS クエリは保護されます。 Google と Cloudflare のパブリック DNS サーバーは両方ともこれらのプロトコルをサポートしています。

結論

これで、ISP の DNS サーバーが必要な速度で応答しない場合でも、DNS クエリを迅速かつ効率的に実行できるようにシステムが構成されました。さらに、最新の安全な DNS プロトコルを使用して DNS クエリを保護しているため、デジタル ライフはより安全になります。

Linux 愛好家でさらに詳しく知りたい場合は、この素晴らしいオンライン コースをチェックしてください。

「 Linux 上でローカル DNS キャッシュ サーバーをセットアップするにはどうすればよいですか?」についてわかりやすく解説!絶対に観るべきベスト2動画

Linux DNS サーバーのインストールと構成 | Linux DNS サーバー |パート1
【#62 応用情報 基本情報 高度共通試験午前1対策】DNSキャッシュポイズニング