Ubuntu 12.04 Desktopのdnsmasq

4月27日にUbuntu 12.04がリリースされた。Desktopでも5年間サポートのLTSだ。

諸事情によりLinux desktop機のUbuntuを再インストールする必要があったので、Beta2の頃から色々試していた。初体験のUnity desktopには相当戸惑いつつ「へぇ～、こんなことができるんだぁ」と感心しきり。未だに新発見がある。当分楽しめるだろう。
その一方でdnsmasqには悩んでしまった。ローカルドメイン内がホスト名で参照できなくなってしまったのだ。結局dnsmasqを無効化してしまった。そんなに多くは無いと思うが、同じようなことを経験された方の参考になれば幸いである。

/*******  *******/

現象はネットワーク環境依存

私のネットワーク環境は概ね下の図のとおりだ。説明が容易になるようホスト名やアドレスをアレンジしているが、概念的に重要な部分は合わせたつもりである。
割合しっかりしたDNS機能がBB（ブロードバンド）ルーターに備わっていることが、平均的な「家庭内LAN」との違いだと思う。このDNS機能は正引き・逆引きレコードを手動で設定できて（実はMXレコードなども設定できるのだが、使っていない）、該当するDNS要求に対してはその設定内容を返し、該当しなければISPから提供されているDNSに代理要求をしてその結果を要求元に返すようになっている。

問題は、上の図で「ubuntu02」と表示したコンピュータのUbuntuを12.04にしたところ、「nas03」の管理画面が見られなくなったこと。従来とおりwebブラウザで「http://nas03/」と指定すると「・・・このページは表示できません」と言われる。「nas03」の代わりにIPアドレスを指定（例えば「http://192.168.0.123/」）すれば、見られる。それ以外目立った問題は見当たらない。

どうやらBBルーターの内向きDNS機能だけが使えなくなった模様だ。特にこれと言った原因に思い当たらないので、LinuxのDNS利用関連トラブル対応の定石に従い、/etc/resolv.confの中身を確認してみた;

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search mydomain

Desktop機ではDHCPを利用するのが一般的であり、私の場合もそうなっている。この場合resolv.confは動的に生成されるのが普通だが、それを行っているのが「resolvconf」だったり「nameserver 127.0.0.1（DNSは自分自身）」となっているのは初めて見る内容だ。
こうなるとGoogleするのが手っ取り早い。「ubuntu 12.04 resolvconf」で検索したら、Ubuntu開発サイドの人によると思われる解説が見つかった。
http://gihyo.jp/admin/clip/01/ubuntu-topics/201203/02 （日本語）
http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ （英語）

要は、DNSプロキシとでも言うべきdnsmasqプロセスが立ち上がり、複数DNSとのやり取りの交通整理をしてくれる、と言うことらしい。どんな「交通整理」をしてくれるのか、もう少し調べてみよう。

「交通整理」の具体的な内容は、2011/10/20付けの Ubuntu Blueprint: Improvement to DNS resolving in Ubuntu （英語）に在った。中盤の「For example in the following scenario:」以降がわかりやすい、と言っても英語なので、要訳を記載しておく。

例えば以下のようなシナリオで:
- ドメインblah.comならびにDNS 1.1.1.1と有線接続
- ドメインexample.comならびにDNS 2001::2と無線接続
- ドメインubuntu.comならびにDNS 2.2.2.2とVPN接続

従来のネットワークマネージャは全てのDNS要求を2.2.2.2に送ってしまい、この接続の遅延が多ければ全てが遅くなってしまう。またblah.comおよびexample.comに関する要求も2.2.2.2に送られるが、このDNSはそれらのドメインについて知っているとは限らない（もし全てがプライベートドメインだったとしたら）。
新しいリゾルバーは、要求のドメインに基づき適切なDNSに振り分けることで遅延を抑えDNSの信頼性の向上を図るものである。

確かに、このシナリオには効果がありそうだ。開発関係者で本当に困った人が居たんじゃあないかと思う。でもこれに該当する場合って、そんなに一般的ではないと思うし、少なくとも今の私の場合は該当しない（将来的に該当する可能性は残る）。

完全に老婆心、余計なおせっかいだが、上記シナリオの3つの接続先の内どれかが私の環境のようにインターネットにつながっている場合を想定すると、インターネット上のホストに関するDNS要求を送る宛先を正しく選べるのだろうか。「最初に確立した接続のDNSを選ぶ」と言うルールが多くの場合正しそうだが、例外的な場合に対処するには任意に設定できる必要がありそうだ。しかしUbuntu 12.04 Desktopのそのような設定項目は調べた範囲では見つけられなかった。

残念ながら、ここまで判っても私の内向きDNSが参照できない理由が見つからない。つまり、これまでの説明とおりなら、「nas03」に関するDNS要求は内向きDNSに送られなければならないはずだ。dnsmasqをもう少し調べる必要がある。

dnsmasqって何だぁ？

「dnsmasq」も初見なので、即Google。これも簡単に見つかった。
http://sourceforge.jp/magazine/08/12/16/0010251 

Desktop機上の機能と思って読んでいると、どうも話がかみ合わない。独立した「dnsmasqサーバー機」のようなものを想定しているのだと気付くのに少し時間がかかった。前出の図のBBルーターの、DHCPとDNSの代わりに使うとちょうど良さそうな機能である。

Ubuntu 12.04 Desktopでは、ネットワークマネージャを構築する手段としてdnsmasqの一部機能を「組み込み」しているようだ。独立型dnsmasqで、はdnsmasq-baseパッケージと dnsmasqパッケージがセットで利用されるはずだが、前者だけしか利用していない。そのため独立型では存在しているはずの設定ファイル/etc/dnsmasq.confが無いし、hostsやresolv.confファイルの扱いも全く異なっている。

実は設定ファイルの内容からdnsmasqの挙動がわかるだろうと期待していたのだが、それは見事に打ち砕かれてしまった訳だ。またしても苦しい時のGoogle頼み、インターネットでdnsmasqの設定ファイルのサンプルが見つかった。
http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example

多少順序が前後するが、関連する設定を見てみよう。

# Add other name servers here, with domain specs if they are for
# non-public domains.
#server=/localnet/192.168.0.1

この設定を活かす（行頭の#を削除する）と、ローカルドメイン「localnet」に関する正引き要求は192.168.0.1のDNSサーバーに送る。（「Add other name servers...」とあるのは、独立型dnsmasqではディフォルトでresolv.confに設定されたDNSを使い、この設定はそれに追加する形になるから）

# Example of routing PTR queries to nameservers: this will send all
# address->name queries for 192.168.3/24 to nameserver 10.1.2.3
#server=/3.168.192.in-addr.arpa/10.1.2.3

同様、「192.168.3.0/24」に関する逆引き要求は10.1.2.3に送る設定。

Ubuntu 12.04 Desktopでは、ネットワークに接続するたびにDHCPから得た情報に基づいて、これらの設定情報を動的に生成することで機能を実現しているのではないかと思う。またBBルーターの内向きDNS機能が使えなかったのは、以下の設定が常に活きた状態になっているためではないだろうか。

# Never forward plain names (without a dot or domain part)
#domain-needed
# Never forward addresses in the non-routed address spaces.
#bogus-priv

前段は、インターネット上のDNSに投げても「存在しないドメイン」と返されることが明らかな正引き要求は転送せずに答えを返してしまう設定。後段は、プライベートIPアドレス範囲に関する逆引き要求は転送せずに「存在しないドメイン」と応える設定。

今回の私の問題では、ホスト「nas03」は完全修飾して「nas03.mydomain」としても、トップレベルドメインを欠いているのでインターネット上に存在しないことが明らかである。そのため、上記設定が効いた形になっていてブロックされてしまった可能性が考えられる。

問題回避

前出のStéphane Graberの記事 に載っていた「dnsmasqをオフする方法（I really don’t want a local resolver, how can I turn it off?）」を実施した。

具体的には、ネットワークマネージャの設定ファイル/etc/NetworkManager/NetworkManager.confの中の1行dns=dnsmasqをコメントアウトするだけである。

sudo gedit /etc/NetworkManager/NetworkManager.conf

この後、ネットワークマネージャを再起動が必要。

sudo restart network-manager

これにより、見慣れた内容のresolv.confが生成される。

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.1
nameserver ISPのDNSアドレス1
nameserver ISPのDNSアドレス2
search mydomain

悩み事 – ローカルドメイン名のベストプラクティス？

今回の問題は、ローカルドメイン名を「mydomain.com」や「mydomain.jp」にすれば解決した可能性が高い。またUbuntuのこの部分を開発した人たちは、そうするのが当然だと考えているように思える。しかし私には、これが良い考えだとは思えない。むしろ避けるべき事だと考えている。

ローカルドメイン名を「google.com」にするのが良い考えだと思う人は稀だろう。このローカルドメイン名を敢えて使うなら、Googleの提供するサービスが利用できない場合を覚悟しておく必要がある。さらに何かの拍子、例えばBBルーターの設定変更を間違えたときなどに、webブラウザがnas03の管理画面に自動ログオンしようとして管理者idとパスワードをGoogleに送ってしまうかもしれない。

それでは「mydomain.com」や「mydomain.jp」ならどうだろう。調べてみると、偶然かもしれないが、これら2つとも既に登録済みである。Googleの様に便利なサービスを提供している訳ではないが、「このドメインを利用したい方に格安（？）でお譲りします」と言うことらしい。ほとんどの「ありがちな」ドメイン名はこうなっているのかもしれない。その辺の事情がどうであれ、これらをローカルドメイン名に利用した場合、「google.com」の場合の懸念事項の前半は心配の必要が無さそうだが、後半については依然としてリスクが残るだろう。

インターネット上のドメインとして登録可能な形式のドメイン名をローカル用に使っている限り、予め登録されていないと確認しても、気付かない内に登録されている場合が無いとは言えない。従って、ローカルのつもりで外部の第三者と通信してしまうリスクを防ぐため、インターネット上のドメイン名としては成立し得ない形式として、トップレベルドメインを持たないローカルドメイン名を使うのはかなり有効なはずだ。

もしインターネットに登録され自分が管理しているドメインがあるなら、ファイアーウォールに内外を区別するルールをしっかり設定した上で、それをローカルネットワークにも使うと一番問題が少ないのかもしれない。しかし家庭内LANのために、新規にドメインを登録・維持するのは現実的でない。

まとめ

Ubuntu 12.04 Desktopのディフォルト設定で、私のローカルドメインの内向きDNSが引けない正確な原因は明らかではない。dnsmasqの挙動を制御する手段が無い限り、今のネットワーク環境または運用方法を変えずにそれを利用するのは難しいと思われる。ただし、これは不幸な例外と言うべきだろう。もしかするとちゃんと動作させる設定方法があるのだが、それが私に伝わっていないコミュニケーションの問題である可能性も考えられる。

目指したシナリオでdnsmasqは有効に働きそうである。また大多数の利用者には邪魔にならない（ちょっとイヤミな言い方をすると毒にも薬にもならない）し、私のように副作用が出たとしても簡単に無効化できるのだから、一応の成功だと言うべきなのだろう。

将来、私のUbuntu機から現状のネットワークに加えてVPNを同時に利用する必要が発生した場合を考えると、少々憂鬱である。その頃には設定項目などが整備され、もっと使い易くなっていることを期待したい。