kledgeb Ubuntuの使い方や日本語化、アプリの使い方を紹介しています。

ローカルDNSリゾルバー

「Ubuntu 16.10」では、現在のローカルDNSリゾルバーに代わり新しいローカルDNSリゾルバーが採用されます。


DNSリゾルバーとは

DNSリゾルバーとは、ホスト名をIPアドレスに変換するサービスのことです。

例えばこのサイトにアクセスする場合、ブラウザーに「http://kledgeb.blogspot.com/」を入力します。

この時URLのホスト名は「kledgeb.blogspot.com」です。

ホスト名が文字列のままではサイトにアクセスできません。
サイトにアクセスするにはIPアドレスが必要です。

そこでブラウザーはDNSサーバーにホスト名に対応したIPアドレスを問い合わせます。
URLのホスト名の部分をDNSサーバーから取得したIPアドレスに置き換えます。
するとURLは、「http://192.168.0.1/」のようになります。

これでようやくこのサイトにアクセスできるようになります。

名前解決

ホスト名をIPアドレスに変換する一連の流れを「名前解決」といいます。

ローカルDNSリゾルバー

現在「Ubuntu Desktop」及び「Ubuntu Touch」では、ネットワークマネージャーが「dnsmasq」を起動し、ユーザーのPCにDNSサーバーを構築します。
ユーザーのPCで起動しているDNSサーバーなので、ローカルDNSリゾルバーと呼ばれています。

本来DNSサーバーは、ISPなど外部の事業者が提供するDNSサーバーを利用します。
ホスト名とIPアドレスの対応表をユーザーが自分で用意することも不可能ではないですが、非現実的です。

ローカルDNSリゾルバーは何をしているのか?

ユーザーのPCで起動したローカルDNSリゾルバーは、ブラウザーなどのソフトウェアから名前解決の要求があると、本物のDNSサーバーにホスト名に対応したIPアドレスを問い合わせます。

本物のDNSサーバーから取得したIPアドレスを、名前解決を要求したソフトウェアに返します。

もしローカルDNSリゾルバーが存在しなければ、名前解決の要求は直接本物のDNSサーバーに行われます。
本物のDNSサーバーとは、ユーザーが指定したDNSサーバーか、DHCPで取得したDNSサーバーのことです。

従ってソフトウェアと本物のDNSサーバーのやり取りを、ローカルDNSリゾルバーが仲介しているということになります。

結果的に本物のDNSサーバーにアクセスする

ネットワークマネージャーは、ユーザーが指定した本物のDNSサーバーやDHCPで取得した本物のDNSサーバーを知っています。


ですので、結果的に本物のDNSサーバーにアクセスすることになります。

ローカルDNSリゾルバーがなぜ必要なのか

ローカルDNSリゾルバーである「dnsmasq」は、ソフトウェアから名前解決の要求があった時に、複数のDNSサーバーを循環的にアクセスし、もしサービスが停止していたり応答に時間がかかるDNSサーバーがあっても、他のDNSサーバーにアクセスし名前解決を行います。

こうすることで複数のDNSサーバーを効果的に活用でき、名前解決のパフォーマンスの向上や改善を行うことができます。

つまりアクセスしたDNSサーバーが停止していたとしても、長時間タイムアウトを待つ必要がなくなります。
DNSサーバーから応答を待っている間、他のDNSサーバーにアクセスし名前解決ができれば、「dnsmasq」はその情報をソフトウェアに返します。(フォールバック)
ソフトウェアやユーザーはタイムアウトを待つ必要が無くなります。

DNSサーバーの設定は常にローカルDNSリゾルバーを指定する

上記のようにソフトウェアが参照すべきDNSサーバーは、ローカルDNSリゾルバーになります。
つまり「/etc/resolv.conf」ファイルに指定するDNSサーバーは、必ずローカルホストを示すIPアドレスになります。(nameserver 127.0.0.1)

逆に言えば「/etc/resolv.conf」ファイルを見ても、本物のDNSサーバーは分かりません。
本物のDNSサーバーの情報は、ネットワークマネージャーが持っているためです。
このことに不満を抱いているユーザーがいます。
これが今回仕組みを変更する理由の1つになっています。

ローカルDNSリゾルバーはDNSキャッシュサーバーではない

ローカルDNSリゾルバーはDNSキャッシュサーバーではありません。
そのためソフトウェアから名前解決の要求があるたびに、本物のDNSサーバーにアクセスします。
以前と同じ名前解決の内容でもキャッシュを行わないため、常に本物のDNSサーバーにアクセスします。

この状況を改善しようという試みが、「Ubuntu 16.10」でローカルDNSリゾルバーの仕組みを変える主な理由になります。

Ubuntu ServerやUbuntu Cloudでは

「Ubuntu Server」や「Ubuntu Cloud」では、ローカルDNSリゾルバーが存在していません。
従って、「/etc/network/interfaces」で指定したDNSサーバーの情報やDHCPで取得したDNSサーバーの情報が「/etc/resolv.conf」ファイルに反映されます。

ですのでソフトウェアが名前解決を行うと、「/etc/resolv.conf」ファイルに指定されているDNSサーバーに直接アクセスします。

ローカルDNSリゾルバーの利点が得られない

「Ubuntu Desktop」のようなローカルDNSリゾルバーの仕組みがデフォルトで提供されていないため、もし最初にアクセスしたDNSサーバーが停止していたり応答に時間がかかり、その後他のすべてのDNSサーバーの応答に時間がかかる場合、ネットワークのパフォーマンスが大幅に低下します。

この問題を解決しようという試みも、「Ubuntu 16.10」でローカルDNSリゾルバーの仕組みを変える主な理由になります。

ローカルDNSリゾルバーをsystemd-resolvedに変更

「Ubuntu 16.10」では、ローカルDNSリゾルバーが「dnsmasq」から「systemd-resolved」に変更されます。

「systemd-resolved」は小型で軽量なソフトウェアであり、すでに「systemd」パッケージの一部として提供されています。

D-Busが不要に

「systemd-resolved」は「dnsmasq」と異なり「D-Bus」を必要とせず、「DNSSEC」をサポートし、透過的なフォールバックを提供します。
もしローカルでの名前解決がうまくいかない場合は、本物のDNSサーバーにアクセスします。

/etc/resolv.confの問題が解決する

「/etc/resolv.conf」ファイルには、本物のDNSサーバが記述されるようになります。

libnss-resolveを経由して名前解決を行う

名前解決は「libnss-resolve」モジュールを経由して行います。
「libnss-resolve」モジュールは、「resolved」にアクセスし名前解決を行います。

複数のDNSサーバーを効果的に扱う

本来の目的である複数のDNSサーバーの効果的な活用も行われます。
サービスが停止しているDNSサーバーや応答に時間がかかるDNSサーバーがあっても、タイムアウトを待つこと無く他のDNSサーバーから情報を取得します。

DNSの情報をキャッシュする

今までローカルDNSリゾルバーは、DNSサーバーから取得した情報をキャッシュしていませんでしたが、これからはDNSサーバーから取得した情報がキャッシュされるようになります。

キャッシュにより、同じ内容の名前解決はDNSサーバーにアクセスすること無く名前解決が行われるようになり、パフォーマンスが向上します。

ネットワークマネージャーはdnsmasqを起動しない

もうネットワークマネージャーは、「dnsmasq」を起動しなくなります。

すべてのUbuntuでローカルDNSリゾルバーが有効になる

すべての「Ubuntu」で「systemd-resolved」によるローカルDNSリゾルバーが有効になります。
すべての「Ubuntu」とは、「Ubuntu Desktop」はもちろんのこと「Ubuntu Server」等も含まれます。

参考




関連コンテンツ
同一カテゴリーの記事
コメント
オプション