ローカル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」等も含まれます。
参考
- Ubuntu 16.10 (Yakkety Yak) Switches to a Universal Local DNS Resolver Service
- ANN: DNS resolver changes in yakkety
