フレッツADSL導入日誌
| 導入編 | ||
| FreeBSDルーター編 | ||
| ローカルDNSサーバー | ||
| フレッツADSLで固定IP | ||
| >>> | ドメイン取得とDNS運用 | |
| メールサーバー | ||
| Webサーバー |
| 05 Feb 2007 | ドメインを移管するを追加。 |
| 09 May 2004 | DNSを立てる(1)〜(4)を追加。DDNSについて言及。 |
| 07 Mar 2004 | 新規作成。 |
このページはDNSに関する話題を集めています。DNSを自分で立てて運用する方法についても言及していますが、Unixの管理者としてのスキルや、ネットワークに関する基礎的な知識を前提としています。人に聞かないと「ユーザーを追加する」「起動スクリプトを変更する」などの操作ができない人、「UDPポートって何？」という人は、まずはその辺りのスキルから磨いてください。
固定のグローバルIPさえあればドメイン取得は必須ではない。相手にIPアドレスを伝えればメールもWebも使用可能である。しかし、覚えやすい・使いやすいとは言い難いので、やはりここはドメインを取って運用してみる。先に述べたように仮想ドメインサービスと通常のドメイン登録があるが、もちろん通常のドメイン登録を使う。
インターネット接続にプロバイダ（ISP）があるように、ドメインにもレジストラという機関が存在する。一番偉いのはInterNIC。日本ではJPNICとJPRSが総元締。以前はJPNICでも登録できたが、現在では登録業務はJPRSに移管されている。
ドメインにもいろいろ種類がある。大きく分けるとgTLDと呼ばれるもの（.com・.netなど）と、ccTLD（.jp・.krなどの国名のドメイン）に分かれる。ちなみにTLDは「Top Level Domain」のこと。ドメイン名は一番最後に来る部分が「トップレベル」になる。gTLDはInterNICの管理下である。アメリカの管理下ではない。アメリカ合衆国にはちゃんと.usというccTLDがある。.jpはccTLDの一種でJPNICの管理下だが、JPNICはさらに「属性型ドメイン」「地域型ドメイン」「汎用JPドメイン」を定めている。
属性型ドメインは以前からある.co.jpや.gr.jpなど。地域型というのはあまり知られていないと思うが、都道府県名.jpで終わるドメイン。例えば、metro.tokyo.jpは東京都のドメインである。汎用JPドメインというのはそれ以外のもので、「ほにゃらら.jp」の「ほにゃらら」の部分をある程度自由に付けられる。最近ではローマ字ではなく日本語のドメイン名も使えるようになりつつあるが、まだ実験段階だと思ってよいだろう。
当然だが、既に登録されているドメインは登録できない。登録しようとするドメインが既に使われているかどうかは、レジストラのページで検索できる。以前はJPNICのwhoisゲートウェイは部分文字列を指定した検索が可能だったのだが、whoisゲートウェイの検索結果をSPAM送付に使うけしからん輩がいたせいで、現在は使えなくなっている。
以前は、例えば「Key:」に「da.tokyo.jp」を指定し「Search options」で「...Substring」を選んで検索を実行すると、「chiyoda.tokyo.jp」（千代田区）、sumida.tokyo.jp（墨田区）、machida.tokyo.jp（町田市）などで終わるドメインを見ることができたのだ。これは先ほど説明した地域型ドメインである。地域型ドメインは個人でも登録でき、登録数がかなり少ないので穴場である。ただし、「tsu.mie.jp」（三重県津市。一番短い地域型ドメインのような気がする）は短いが「aizuwakamatsu.fukushima.jp」（福島県会津若松市）は理不尽に長いという不公平もある（笑）。
部分一致検索は使えなくなったが、JPRSのサイトに短いドメイン名を調べるというのがあるので、参考にするとよいだろう。
実際の登録はJPRSでももちろん可能だが、JPRSの価格設定はかなりお高いので、他のレジストラを使うのが普通である。有名どころではYahoo!ドメインやお名前.com（どちらも同じサービス）があるが、価格や登録できるドメインの種類、管理方法や仮想ドメインサービス内容など、様々な特色を持つレジストラが存在する。ドメインゲッター（←なくなったらしい） JPRSの汎用JPドメイン名の登録サービス提供パートナー一覧あたりで探すとよいだろう。この一覧は登録ドメイン数順なので、先に出てくるレジストラ＝知名度の高いレジストラ、ということになるが、必ずしもサービス内容や値段を反映したものではないので注意。
いろいろ迷うと思うが、サイトの更新状況や管理ツールなどを見て決めよう。今回は本格的にDNSを立てて運用するので、仮想ドメインサービスではなく、NSレコードを簡単に登録できるレジストラを探すこと。お気に入りのドメインを登録できるレジストラを見つけたら早速登録。登録時点ではDNSは必須ではないので気軽に登録できる。私はDOMAIN 21で登録してみた（初年度5000円、以後年額4500円←潰れた）。以後取得できたドメインを example.jp ということにして話を進める。
ドメインの登録は基本的に1年単位である。また、登録後に他のレジストラに管理を移管することも可能である。もし、自分で各種サーバーを運用したいのに、NSレコードが登録できないレジストラで登録してしまった場合、管理を移管するとよいだろう。
なお、ダイナミックDNSを使う場合、DNSはDDNSサービスのものを使うので、自分でDNSを立てる必要はない（はず）。A・MXレコードが自由に登録できれば基本的に不自由はない（と思う）。この場合、ドメインを取得したレジストラにはDDNSサービスの指定するDNSを登録することになる（憶測）。最近ではドメイン登録を行うとダイナミックDNSサービスがもれなく付いてくるレジストラも存在する。まあ、使ったことがないので、自由研究とさせていただく。
汎用JPドメインの場合、移管には移管元レジストラの同意が必要になる。移管元が同意しなければ移管はできない。これは規約に書かれるべきもののようなので、登録前に確認する必要がある。登録したレジストラが潰れてしまった場合は移管するしかない。実際、DOMAIN 21サービスが潰れ、持っていた汎用JPドメインはまずヒューメイアに引き継がれ、さらにVALUE-DOMAINに移管することになった。今回は移管に際して料金は一切発生しなかったが、移管の際に料金を取られることもある。場合によっては移管元・移管先の両方から料金を請求されることもあるだろう（そして移管元に料金を払わないと移管に同意してくれないわけだ）。
移管にもいろいろあるようだが、料金が発生しなければドメインの有効期限はそのまま。元々の有効期限が到来する前に、新しいレジストラに更新料金を払わなければならない。ちなみに、汎用JPドメインの場合、総元締での更新は必ず1年単位である。レジストラが複数年単位契約で割引をしている場合、それはレジストラが1年毎に料金を納めているだけ。レジストラが何かの事故で更新を忘れればドメインは失効するし、複数年契約の途中でレジストラが潰れた場合、残りの期間についてドメインが有効である保障はない。
他のドメインは各種情報を参照のこと。gTDLの場合はロックとかキーとかいろいろあるらしい。
例えば example.jp というドメインを取ったとする。ドメインを取得したら、その下で使うサブドメイン・ホスト名を決める。NSレコードを登録する際にDNSのホスト名が必要になるので、外部公開DNSサーバーの名前は決めておく必要がある。通常、ns.example.jp のような名前を付ける。それ以外はあってもなくてもよい。
メールアドレスについても考えなければいけない。もちろん、メールアドレスのドメインに example.jp をそのまま使ってもよい。ホスト代表のアドレス、例えば、http://www.example.jp/ のWebマスターのアドレスには、webmaster@example.jp などを使うのが一般的だろう。それ以外の一般ユーザーにはサブドメインを作った方がよい。mail.example.jp などが一般的だろう。
メーリングリストなどもドメインを分けるとよい。例えば、てきとーにユーザー名を付けてメールを送るSPAMエンジンがあったとする（結構ある）。ドメイン部分は一般の目に触れるものから借用することが多く、先の webmaster@example.jp などが候補になる。このとき、メーリングリストがexample.jpドメイン直下だとモロに被害に遭うが、一段ドメインを掘って list.example.jp の下にしておけば大丈夫である。
メールアドレスで使うサブドメインと、メールサーバーのホスト名は必ずしも同じでなくともよい。メールアドレスのホスト名を示す部分は省略し、ドメインのみを書くことが多いので、大体の場合はメールアドレスとメールサーバーホスト名は異なることになる。一つのサーバーが複数のドメインを担当することもある。大規模なネットワークで、内部が複数のドメインに分かれている場合、内部へのメールを中継するサーバーは必ずそうなる。
ここまでは外から見たときに見えるホスト名・ドメイン名の話である。これとは別に、内部にあるホストたちについても考えなければならない。通常、セキュリティ上の都合から、内部で使うホスト名は外からは見えないようにすることが多い。特に、グローバルIPアドレスが1本しかなく、NATを用いている環境では、内部のローカルアドレスを外に教えるわけにはいかないから、内部空間の隠蔽は必須である。論理的なDNSゾーンサーバーは外部公開用のものと内部専用のものの二つとなる。内部についてはサブドメインを一段掘り下げれば設定が簡単になる。内部専用サーバーの設定についてはローカルDNSサーバーを参照のこと。以下に一例を示す。
| example.jp ドメイン | ||
| ns.example.jp | 外部公開ゾーンサーバー | 172.16.12.34 |
| www.example.jp | WWWサーバー | 172.16.12.34 |
| alpha.example.jp ドメイン（内部用ドメイン） | ||
| rat.alpha.example.jp | 192.0.2.1 | ゲートウェイ gw.alpha.example.jp |
| ox.alpha.example.jp | 192.0.2.2 | DNS ns.alpha.example.jp |
| tiger.alpha.example.jp | 192.0.2.3 | |
| hare.alpha.example.jp | 192.0.2.4 | |
| dns.alpha.example.jp | 192.0.2.53 | DNSキャッシュ |
| mail.example.jp ドメイン（メール専用） | ||
| list.example.jp ドメイン（メール専用） | ||
メール専用ドメインも一応載せたが、とりあえず以下では使わない。メール関係の設定（MXレコードの設定）はメールサーバー設定までおあずけである。
とりあえずDNS関連のホストについて考えると、外部公開サーバーはキャッシュを運用する必要がないから、ネームサーバーは非再帰に設定されたゾーンサーバー1台があればよい。内部用にはゾーンサーバー1台と、DNSキャッシュが必要になる。さらにゲートウェイ、場合によってはファイアウォールも関係してくる。最大で5台のホストの設定が関係する。家庭内LANの場合、5台のホストを常時ONにするのは難しいので、これらの機能をうまく割り振らなければならない。内部専用のサービスは常時ONのホストでなくても構わない。よくある構成はゲートウェイが専用機（いわゆるブロードバンドルーター）の場合と、汎用機にゲートウェイ・ファイアウォールをやらせている場合だろう。後者の場合、OSにWinを使うことも可能だが、ここでは割愛。
[ゲートウェイが専用機の場合]
ゲートウェイ以外のホストは全部NAT環境下のローカルアドレスで動く。ゲートウェイ（ルーター）で静的NAT設定を行い、ポート53を外部公開用マシンに向ける必要がある。ファイアウォールがある場合、外からポート53へのパケットを通すように設定しなければならない。内部専用DNS・DNSキャッシュは適当なホストへ割り当てればよい。外部公開DNSホストにやらせることもできる。
[ゲートウェイがUnixの場合]
ファイアウォールと外部公開DNSをゲートウェイホストにやらせてしまうのが簡単。内部専用DNS・DNSキャッシュはLAN内の適当なホストにやらせればよい。外部公開DNSと同じホストで運用することも可能である。
[ホスト割り当てのパターン]
| 外部 | 内部 | キャッシュ | 備考 |
| A | A | A | BIND9のみ、BIND9+dnscacheといった構成がよい。 |
| A | A | B | ゾーンサーバーにBIND9を使う場合によい。キャッシュはご自由に。 |
| A | B | A | この構成はあんまりメリットないかな。↓の方がよい。 |
| A | B | B | BIND8やtinydnsでも楽に運用できる。キャッシュはdnscacheでもよい。 |
| A | B | C | お好きなソフトをお好きなように。 |
二つのゾーンサーバーを同じホストで動かす場合、BIND9ならばview機能を使うと楽に運用できる。BIND8とtinydnsの場合はプロセスを分ける必要がある。tinydnsは元からプロセスを分けて使うことを考えてあるが、BIND8は少し面倒（ヒマがあれば説明するつもりだが、あまり期待しないように）。
ここではBIND9を使う。外部公開サーバーを立て、内部向けのゾーンとの整合をとるという手順になる。まず外部公開用のゾーンファイル。名前は example.jp.zone とする。
$TTL 432000
@ 3600 SOA ns.example.jp. dnsadmin.example.jp. (
2004050701 ; serial
10800 ; refresh
3600 ; retry
604800 ; expire
600 ) ; negative
NS ns
ns A 172.16.12.34
www A 172.16.12.34
TTLは432000秒＝5日になっているが、運用が安定しないうちはもっと短い値にした方がよいかもしれない。安定したら元に戻すのを忘れないように。ISPの変更などでIPアドレスが変わる場合も、事前にTTLを短くしておいた方がよい。あとはまあ見れば分かるだろう。
ローカルDNSサーバーのときは逆引きゾーンファイルも作った。しかし、よく考えてみると、正引きはドメインレジストラのサーバーにNSレコードを登録するが、逆引きはIPアドレスにくっついている。つまり、IPアドレスの供給者のDNSサーバーにNSレコードを登録する必要がある。IPアドレスの供給者＝ISPである。ISPにそういうサービスがない場合、逆引きゾーンファイルを作っても無駄である。サービスしている場合は逆引きファイルを作ってISPに登録を依頼するとよい。
次にnamed.confを作る。外部のみのゾーンサーバーとして設定する場合、以下のようになるだろう。
options {
directory "/var/named";
pid-file "/var/named/named.pid";
listen-on { 172.16.12.34; };
allow-transfer { none; };
notify no;
recursion no;
};
zone "example.jp" {
type master;
file "db/example.jp.zone";
};
外部公開サーバーが内部専用サーバーと別になっていればこれで一応動く（面倒も少ない）。ただし、キャッシュの設定によっては内部のホストから example.jp ドメイン直下の情報が得られないので、内部専用サーバーにも example.jp ゾーンを追加しておくか、キャッシュに対して（alphaの付いていない）example.jp の問い合わせの場合は外部公開サーバーを見に行くように（alpha.example.jp の時のみ内部専用サーバーを参照するように・・・ローカルDNSサーバーの例ではそうなっている）設定する。
内部専用と外部公開を1台で兼務している場合はこのままでは都合が悪い。BIND8だと2プロセスに分ける必要があったのだが、BIND9ではviewを使うと1プロセスで済む。とりあえず、内外サーバーを同じプロセスで動かすこと、内部専用の情報は外部には返さないこと（つまり、内部からのアクセスと外部からのアクセスでは回答内容が異なる）を目標に設定する。
acl internals {
127.0.0.1; 192.0.2.0/24;
};
options {
directory "/var/named";
pid-file "/var/named/named.pid";
listen-on { 192.0.2.1; 172.16.12.34; };
allow-transfer { none; };
notify no;
recursion no;
};
view internal_dns {
match-clients { internals; };
zone "example.jp" {
type master;
file "db/example.jp.zone";
};
zone "alpha.example.jp" {
type master;
file "db/alpha.zone";
};
zone "2.0.192.in-addr.arpa" {
type master;
file "db/192.0.2.zone";
};
};
view external_dns {
zone "example.jp" {
type master;
file "db/example.jp.zone";
};
};
aclというのはAccess Control Listの略で、IPアドレスを羅列してグループにし、名前を付けたようなものである。ここでは、内部向けのinternalsを定義している。optionsのlisten-onは外部も内部も問い合わせを受け付けるため、両方のインターフェースアドレスを書く。実はlisten-onを書かなければ全部のアドレスで受け付けるのだが、dnscacheなど他のDNSプロセスが同じサーバーで動いていると問題が起きるので、問い合わせを受けるアドレスを明示的に指定している。
次にviewが2つ書いてある。名前は適当である。viewの中にあるmatch-clientsで、このviewがどのクライアントからの問い合わせからで使われるかが決まる。internal_dnsのviewでは、match-clientsがinternalsであるから、内部のホストからの問い合わせの時にこのviewが使われる。中身はローカルDNSサーバーのゾーン指定と example.jp 直下のゾーン指定を足したものである。直下のゾーンを書いておかないと、内部から ns.example.jp などを問い合わせたときに「ない」という答えが返ってきてしまう。
次のexternal_dnsのviewにはmatch-clientsがないが、こうすると他のviewにマッチしなかったアクセスがこのviewを使うようになる。つまり、内部ではない＝外部からのアクセスのときに使われる。内容は兼務していない場合のゾーン指定と同じである。
これで一応動く。BIND9を再起動してみて、nslookupなりなんなりでテストする。ただし、内部からテストしていると必ず内部ゾーンのデータが返るので、外部ゾーンのテストをする場合はaclを適当に編集するなどしてテストする必要がある（親ゾーンにNSレコードを登録してしまえば、ISPのDNSに問い合わせることで間接的にテストできるようになる）。
細かいことを言うと、example.jp 直下のホスト名を問い合わせると、ローカルアドレスでアクセス可能なのにグローバルアドレスしか返さなかったりするのだが、これはこれでテストの時に便利だったりするので放っておくのもよいだろう。気になる場合は外部と内部で example.jp ゾーンファイルを別にすればよい。
このとき、内部のゾーンファイルから外部のゾーンファイルを$INLUCDEすると楽なのだが、$INCLUDEで指定するパス名は、ゾーンファイルの置かれている場所を基準とするのではなく、named.confのdirectoryオプションで指定した場所が基準となるようなので注意。つまり、この例だと$INCLUDE example.jp.zone ではだめで、$INCLUDE db/example.jp.zone としなければならない。$INCLUDEには他にも基点名の規則に混乱があったりするので注意。
サーバーを立てたら、親ゾーン＝レジストラにNSレコードの登録を依頼する。NSレコードはホスト名を指定するため、別にこのホスト名を解決するためのAレコードも必要になる（ホスト登録）。レジストラによって方法は違うので、各レジストラのマニュアルを参照のこと。この例では、ns.example.jp という名前のホストを 172.16.12.34 というIPアドレスで登録し、example.jp ドメインのネームサーバーとして ns.example.jp というホストを指定するような操作をすればよい（メールで依頼することもある）。無事に登録されればISPのDNS経由で自分のドメインが見えるようになるはずである（もしかすると登録まで多少（〜1日）時間がかかるかもしれない）。同時に、ISPのDNS経由で内部のドメインが見えないことも確認しておく。ヒマだったらルートサーバーから追いかけてみるのもよいだろう。
お疲れさま！ これで独自ドメインが動き出しました！
Copyright (C) 2004-2007 You SUZUKI
$Id: domain.htm,v 1.13 2011/08/29 13:23:40 you Exp $