ドメイン名とIPアドレスの変換-DNS
皆さんは既にトランスポート層のTCPとUDPを学んでインターネットの通信はソケット通信であることを理解していると思います。ソケット通信はIPアドレスとポート番号の組で相手と自分を識別しています。また、ルーティングを学んで、宛先のIPアドレスが分かれば、パケットを宛先のコンピュータまで送り届けることができることも学びました。
コンピュータはIPアドレスがないと通信ができません。このIPアドレスは誰かが指定してやらないといけません。毎回同じ相手と通信をする場合には設定ファイルの中に書き込んどおけばいいでしょう。しかし、通信の度に教えてやらないといけないばあいもあるでしょう。いずれにしても、コンピュータに宛先のIPアドレスを教え込む人は最終的には人間であるユーザです(少なくとも今のところは?)。
人間もIPアドレスを使えばいいのですが、なかなかそうもいきません。IPアドレス、特に2進表示のIPアドレスはコンピュータが使うのに便利なようにできていますが、人間に対する使いやすさは全く考慮されていません。ドット区切りの10新表示に直すと多少分かりやすいのですが、これでも人間には扱いにくいものではありません。それに、IPアドレスは実際のネットワークと密接に関係しています。ネットワークが変わるとIPアドレスも変わらざるを得ません。引越しをしてコンピュータの設置位置が変わるとIPアドレスも変わってしまいます。これではインターネット上でサービスを提供するには不都合です。
そこで必要なのが人間に扱い易い名前です。この名前をコンピュータに分かるようにIPアドレスに変換する仕掛けも必要です。それから、この名前は物理ネットワークと直接的に関連していないほうがより好都合です。もちろん全く関連付けられていないということでは役に立ちませんが、直接関連付けられていて、コンピュータを別の場所に移すと名前も変わってしまうというのでは困ります。そこで考えられたのがDNSです。
DNS(Domain Name System)はインターネット上のホスト(コンピュータ)に人間に分かりやすい名前を付け、その名前とIPアドレスを対応付けるシステムです。
ホストにつけられる名前はドメイン名といいます。ドメイン名はインターネット上に存在するコンピュータやネットワークを識別するための名前で、ドメイン名空間の中で明確に位置づけられています。ドメイン名空間はドメインと密接に関連しています。ドメイン名空間と、ドメインについては後で詳しく説明します。
DNSができる前はネットワーク情報センタ(NIC)が管理するHOST.TXTというファイルにホスト名とIPアドレスの対応を記述して、これを世界中のホストに配っていました。しかし、この方法では更新ファイルの配布方法が難しくなります。インターネット上で日々更新されているドメインを記述したHOST.TXTを即時に広報するのは至難の業でいくつものバージョンが存在してしまうことになり、その結果、正確な名前解決ができなくなってしまいます。
※Windowsでは今でもC:\windows\system32\drivers\etc\hostsというファイルがあってドメイン名解決の機能を果たすことが可能です。
そこで考えられたのがDNSというサーバを立てて、その中にドメイン名とIPアドレスを対応付けたファイルを置き、この対応関係を尋ねてきたものに回答するという手法です。この手法ではクライアントサーバシステムが採用されています。DNSクライアントは通常リゾルバ(resolver)と呼ばれます。DNSリゾルバはWebブラウズ(Webクライアント)などのクライアントアプリケーションに含まれていて、ユーザがWebクライアントにドメイン名を入力すると、WebクライアントはDNSクライアントに尋ね、DNSクライアントはDNSサーバに尋ねるというという方法をとります。
IPアドレスはIPネットワークの物理的な場所に左右されるので、アプリケーションサーバの位置を変えるとIPアドレスが変わらざるとえませんでした。例えば、Webサーバの位置を変えると、そのサーバ上で運用していたWebサイトのユーザ全員に何らかの方法で新しいIPアドレスを知らせる必要があります。クライアントの方ではプログラムの修正、リンクの貼り直しなどの作業が必要となります。しかし、DNSを利用すると、データベースのファイルの中でドメイン名とIPアドレスの対応関係の部分を書き直すだけで十分です。ユーザはIPアドレスが変更されたことにも気づかず以前のようにWebサイトにアクセスすることができます。
リゾルバからアドレス解決の要求を受けたDNSサーバは自分が持っているデータベースを確認しますが、聞かれたことに関して情報を持っていない場合はどうしたらいいでしょうか?そのようなことがないように世界中のドメインについて対応表を用意すべきであると思う方もいるかもしれませんね?しかし、この考え方はうまく機能するでしょうか?世界中にある何十億というDNSクライアントからの問い合わせを効率的に捌くことができるDNSサーバの姿は想像できません。多分、ひっきりなしにダウンしてまともに機能しないのではないかと危惧されます。
DNSは集中処理方式ではなく、分散処理方式を採用しています。この分散方式では、個々のDNSサーバは自分の管理ドメインを明確にして、その中の情報を責任をもって管理しています。このようなドメインは通常ゾーンと言われています。自分が管理しているゾーンに関しては自分で責任をもって名前解決をします。しかし、自分の管理しているゾーン以外の問い合わせについてはどうしたらいいでしょうか。この場合はそのゾーンを責任をもって管理しているサーバに問い合わせをします。この問い合わせはどのようにするのかがまた問題です。聞かれたDNSサーバが自分で、問い合わせをしてあげるという方法と、知っていそうなDNSサーバをDNSクライアントに教えてあげるだけという方法があります。聞かれたDNSサーバがクライアントに代わって知っていそうなDNSサーバに問い合わせをする方法を「再帰的問い合わせ」、知っていそうなDNSサーバを「あの人なら知っているかも知れないよ」という感じで教えてあげる方法を「繰り返し問い合わせ」といいます。
※DNSサーバは、DNSクライアントから問い合わせを受けた場合、自分が管理しているゾーンに関しては回答するが、自分が管理していない場合は、そのゾーンを管理しているサーバに聞くといいましたが、少し正確ではありません。DNSサーバはDNSクライアントから聞かれた場合に自分で知っていれば自分で回答し、そうでない場合には知っていそうなサーバに尋ねます。DNSサーバは自分の管理しているゾーンの中のドメイン以外にも知っている場合があります。これにはキャッシュが関係します。DNSサーバはせっかく手に入れたドメイン名情報はキャッシュという仕組みを使って一時的に記憶しています。DNSサーバはDNSクライアントからの問い合わせに対して自分の管理しているゾーンに関する質問か、あるいはキャッシュに保存している情報に関する質問ならば、自分で回答するということになります。
このような分散処理の仕組みを実現するためには、DNSはどのようなものでなければならないでしょうか。まずDNSサーバ同士が連携して働く仕組みが必要でしょう。ではどのように連携させるべきでしょうか?
クライアントからの問い合わせに対してサーバは自分で答えられない場合は、更に自分で聞いてあげるか、あるいは知っていそうなサーバを紹介してあげるという行動を素早くとる必要があります。そのためには何については誰が知っているということを素早く察知できなくてはなりません。そこで採用されたのがツリー構造にドメイン名空間を割り当てるという方法です。ツリーは根っこ(ルート、root)を上にした逆ツリー構造です。
ツリー構造の枝分かれの付け根部分(ノード、node、結節点、節点)と葉(リーフ、leaf)部分にドメインを割り当てていきます。ツリー構造では各ノードが親子関係になっていますので、各ドメインにも親子関係を持たせます。逆ツリーのルートからドメインの親子関係を辿って下がるときに、各ドメイン名をドットでつなぐとドメインの正式なドメイン名が出来上がります。これを完全ドメイン名と呼びます。各ドメインを完全ドメイン名で考えると親子関係がハッキリします。
各ドメインにDNSサーバを置き、そのサーバにはドメイン内の名前解決の責任を持たせることにします。しかし、場合によってはドメインにDNSサーバを置くことができない場合もあります。そこで、ドメインに対して管理責任を持ったDNSサーバを置くときはその範囲をゾーンという名前で呼ぶことにします。こうするとどういう名前のDNSサーバはどのゾーンについて管理責任を持っているかが分かります。名前解決の問い合わせに対してそれが自分が管理しているゾーンに対する問い合わせなのか、あるいは親ドメインに対する問い合わせなのか、子ドメインに対する問い合わせなのか、あるいはそれ以外のドメインに対する問い合わせなのか直ぐに分かります。その場合にどのDNSサーバに対して問い合わせをすればいいかも一目瞭然です。
※ドメインにそのドメインに管理責任を持つDNSサーバを置くといいましたが、正確にはそのドメインに置く必要はありません。ゾーンに管理責任を持つDNSサーバはそのゾーンとは別のところに置くことも可能です。
どのDNSサーバに対して問い合わせをすればいいか分かっても、そこにすぐにつながるかはまた別の問題です。何故かといえばここでDNSの仕組みに頼ることはできないからです。この関係はDNSの仕組みを使わずに解決できるようにしておかなければなりません。DNSの仕組みを成り立たせるために、DNSに頼ることはできないからです。DNSではここで委任という考え方を使っています。本来ならばルートに位置するDNSが全てを知っていなければならないが、これでは効率的に機能できないので、親子関係を利用して、子ドメインの管理は子ドメインのDNSサーバに委任します。
ゾーンの中にあるのは1つのDNSサーバだけでしょうか?ゾーンの中のDNSサーバがダウンしてしまうと、そのゾーン内では名前解決ができなくなります。従って、通常は万が一の時のためにゾーン内では複数のDNSサーバが稼働しているのが普通です。この場合には、DNS同士のデータベースを同期させる必要が出てきます。情報を同期させるためには複数のDNSサーバ間でメインのサーバとセカンダリーのサーバを決めておいた方がよさそうです。メインのDNSサーバはプライマリーDNSサーバ、マスタDNSサーバなどと呼ばれます。セカンダリなDNSサーバはスレーブDNSサーバ、あるいはセカンダリDNSサーバなどと呼ばれます。プライマリサーバとセカンダリサーバ間ではゾーン転送という方式の通信を行い、データベースの同期化を行っています。これによってゾーン内のどのサーバに問い合わせても同じ回答を得ることが可能となります。
ドメイン名空間は逆さの木構造(ツリー構造)をしていて、最上位のルートを頂点として下の階層へと空間が広がっています。ツリーの各ノード(節点)、各リーフ(頂点、葉)には名前が付けられています。これをラベルと呼びます。ルートに付けられたラベルは"
"です。
ルート(" ")の下の階層をトップレベルドメインといいます。その下が第2レベルドメイン、その下が第3レベルドメインとなります。あるドメインの直下の階層に複数のドメインを配置する場合は、必ず異なるラベルを付けなくてはなりません。これによってドメイン名空間を構成する全てのドメイン名は一意に表現できます。
ドメイン名空間の部分木をドメインといいます。部分木の一番上のノード名がそのままドメイン名となります。上の図では緑色のドメインは"co.jp"ドメインとなります。
co.jpドメインの部分木は部分ドメインと呼ばれます。abc.co.jpはco.jpの部分ドメインとなります。
あるノードからルートに辿り着くまでに経由するノードのラベルをドット(".")で結んだものは、そのノードの完全ドメイン名(full
domain name)と呼ばれます。上のツリー構造上で、engというノードの完全ドメイン名は"eng.abc.co.jp."となります。"eng.abc.co.jp."は最後がドットで終わっているように見えますが、実際はルートノードで終わっています(ルートは空ラベル" ")。ルートノード(つまり、ドット)で終わっているドメイン名は絶対ドメイン名とも呼ばれます。絶対ドメイン名を使うとノードを木構造の中で一意に指定できますので、完全に限定されたドメイン名(fully
qualified domain name、通称FQDN)とも呼ばれます。
では次にインターネットのドメイン名空間はどうなっているのかを見ていくことにしましょう。
ルートの直下のドメインはトップレベルドメインと呼ばれています。トップレベルドメイン(Top Level Domain、TLD)は基本的には米国の組織に割り当てられています。インターネットは元を辿れば米国の国防総省のサポートによって開発されたものであり、当初は米国の組織(大学、研究所等)を結んだネットワークでした。従って、開発当初は米国の組織以外がドメイン名を持つことは想定外だったといっていいでしょう。
トップレベルドメインはIANAが関していますので、詳しくはIANAの公式リストをご覧ください。2015年11月現在で1000を超すトップレベルドメインが存在していますが、そのうちのいくつかは使われていません。
4.1 ジェネリック・トップレベルドメイン(gTLD、generic top level domain)
次に示すのは、インターネット開発の当初に作られたドメインです。
ドメイン名 |
説明 |
com |
当初は営利(COMmercial)目的の企業用のドメインだったが、現在はどんな個人や団体でも利用が可能。 |
edu |
教育(EDUcational)目的の組織(小学校、中学校、高校、大学)用。ただし、2001年以降は制限が厳しくなり、現在はほぼアメリカの大学のみに利用されている。 |
gov |
アメリカ合衆国の政府(GOVerment)機関および州・郡・地方自治体機関に利用が限定されている。 |
mil |
アメリカ軍(MILitary)の利用に限定されている。 |
net |
当初はコンピュータの分散ネットワークを指すドメインや、Webサイトの入り口の働きをするサイトでの使用を目的としていたが、現在は一般に公開されている。ネットワークインフラ関連の会社に使用されている。 |
org |
当初は非営利(ORGanizational)活動をする組織を対象としていた。現在は一般に開かれたドメインとなっているが、利用者は依然として非営利団体が多い。 |
int |
2つ以上の国の間の条約によって設立された組織・機関・運動に利用が限定されている。国際的な(INTernational)機関が利用。 |
4.2 ドメイン名の開放
インターネットの発展のためにはアメリカの組織以外でも利用可能なドメインが必要となりました。gTLDのうち、"com""net""org"などがよく利用されますが、2000年代に"biz""info""name"などが追加され、2012年には新設が原則自由となり、企業名や都市名、一般名詞などを冠する新しいトップレベルドメインが大量に登録されています。
4.3 国別コード・トップレベルドメイン(Country Code TLD、ccTLD)
インターネットの国際化のためには分野別のドメインだけでなく、国別ドメインも必要となります。
国名 |
ドメイン名 |
備考 |
アルゼンチン |
ar |
|
オーストリア |
at |
|
オーストラリア |
au |
|
ベルギー |
be |
|
ブラジル |
br |
|
カナダ |
ca |
|
スイス |
ch |
ラテン語のConfoederatio Helveticaから |
チリ |
cl |
|
中国 |
cn |
|
キューバ |
cu |
|
ドイツ |
de |
ドイツ語のDeutschlandから |
デンマーク |
dk |
|
スペイン |
es |
Espana |
欧州連合 |
eu |
|
フィンランド |
fi |
|
フランス |
fr |
|
イギリス |
gb |
Great Britain ※あまり利用されていない→uk |
インド |
in |
|
イタリア |
it |
|
日本 |
jp |
|
韓国 |
kr |
|
メキシコ |
mx |
|
オランダ |
nl |
Nederland |
ノルウェー |
no |
|
ニュージーランド |
nz |
|
フィリピン |
ph |
|
ロシア |
ru |
|
スウェーデン |
sd |
|
イギリス |
uk |
イギリスではgbよりもukがよく使われている |
アメリカ合衆国 |
us |
|
コード体系は原則としてISO 3166規格による2文字コードに基づいていますが、一部例外もあります。割り当て業務やDNSサーバの管理は、レジストリ(ICANNの認定を受けた組織)が行います。日本のJPドメインを管理するレジストリはJPRS(株式会社日本レジストリサービス)です。ccTLDの取得要件はそのドメインのレジストリが決めています。世界中の誰でも取得できるgTLDとちがい、その国/地域に存在(在住)する団体(個人)でないと取得できない場合もあります。発展途上国の中にはgTLDのように誰でも取得できるようにして外貨を稼ごうとしている国もあります(例、トンガの「.to」やツバルの「.tv」など)。
4.4 インフラストラクチャ・トップレベルドメイン
"arpa"というトップレベルドメインは、初期のインターネットでは高等研究計画局(ARPA)に割り当てられていましたが、現在はDNSの逆引きなど指定されたインフラ用途にのみ利用されています。
ドメインにはネームサーバ(DNS)サーバと呼ばれるサーバが設置され、そのドメインの名前の管理をしています。そのDNSサーバが責任をもって管理している領域をゾーンといいます。DNSサーバが責任をもってゾーンを管理することを「ネームサーバがゾーンに対して権威を持っている」といいます。
インターネット上の各ドメインに対して抜けなく名前解決を行おうとするなら、論理的にはルートドメインにあるDNSサーバが全部解決してしまうのがよさそうです。これならインターネット上のどのドメインに対する名前解決もルートドメインのDNSサーバ(ルートDNSサーバ)に依頼すれば全て解決できることになります。聞いた相手が悪くて回答がもらえなかったということはないはずです。しかし、実際はルートDNSサーバが何でも知っていて全ての質問に回答できるというのは無理な相談です。世界中の名前解決要求が1台の(あるいは数台の)DNSサーバに集中してしまうと、まるでそのサーバがDDOS攻撃を受けているのと同じ状態になってしまうでしょう。
※DOS攻撃(Denial Service Attack):サーバやネットワークリソースなどをサービス提供できない状態にすることを意図した攻撃。DDOS攻撃(分散DOS攻撃)は複数のネットワーク上の大量のコンピュータが標的ネットワークや、標的コンピュータに対して、同時に接続要求を出し、通信容量(トラフィック)を溢れさせ、機能停止に陥らせてしまう攻撃です。
そこで考えられたのが分散管理(管理の分散化)という考え方です。ルートドメインのDNSサーバは管理を直下のトップレベルドメインのDNSサーバに依頼します。ただし、ルートドメインはどんな質問にも回答できる体制だけは整えていなくてはなりませんので、どのドメインに関しては誰に委任(移管)したのかを覚えておかなくてはなりません。これはルートドメインのDNSサーバの設定ファイルに、トップレベルドメインのDNSサーバの名前を記録しておくということによって行います。より具体的にいえば、サブドメインを作成したときにサブドメインのDNSの管理者はサブドメインのDNSサーバを親ドメインの管理者に知らせます。そして、親ドメインの管理者は自分で管理しているDNSサーバの設定ファイルに子ドメインのDNSサーバを追加します。これで、親ドメインのDNSサーバは、子ドメインに関する名前解決の要求があったときにも回答できるという体制が整います。同様に、トップレベルドメインのDNSサーバは、その下の第2レベルドメインのDNSサーバに権限の委譲を行い、第2レベルドメインのDNSサーバは、第3レベルドメインのDNSサーバに権限の委譲を行うというように次々と権限委譲を行っていきます。このことを、DNSでは親ドメインがサブドメインの名前データの格納場所へのポインターを保持するという言い方で表現しています。
abc.co.jpが1つのゾーンであれば、このドメインのDNSサーバがドメイン内の管理を責任をもって行っていますが、fnc.abc.co.jpのDNSサーバに権限の委譲が行われると、この部分ドメインはゾーンとなります。このときabc.co.jpを管理するDNSサーバにはfnc.abc.co.jpという名前と、その(サブドメインの)DNSサーバのIPアドレスの対応関係が記載されます。
1つのDNSサーバが複数のゾーンに対して権威を持つこともあります。あるゾーンに対して権限を持つDNSサーバが実はそのゾーンには存在せずに違うドメインで稼働していることもあります。
7.1 プライマリマスタとスレーブ
今まではドメインあるいはゾーンには1台のDNSサーバがあるという前提で話をしてきました。しかし、複数のサーバが存在(稼働)しているのが普通です。こうするとDNSサーバの負荷を分散することができるという利点と、1台のDNSサーバがダウンしても名前解決ができるという利点があります。1台のDNSサーバに頼り切ってしまうと、そのDNSサーバがダウンすると、何もできないという状態になってしまいます。複数台のDNSサーバが同時に稼働していればDNSサーバが故障しても仕事がストップしてしまうことは回避できます。
7.2 ゾーン転送
同一のゾーンに複数台のDNSサーバが稼働している場合は複数あるDNSサーバのデータベースを同期させることが必要です。Aというサーバと、Bというサーバに問い合わせたときに回答が違っていては困ります。そのようなことがないように定期的にゾーン内にあるDNSサーバのデータベースを同期させます。これ処理をゾーン転送(DNS
zone transfer)といいます。
ゾーン転送では管理する情報を一括して他のサーバに転送するのが一般的です。この転送は信頼性を必要としますので、TCPを使って行われます(ポート番号は53)。
※ゾーン転送はTCPですが、クライアントからの問い合わせに対して、サーバから回答する仕組みはUDPを使います。名前解決は即時性が求められますので、UDPが適しています。
ゾーンの中のDNSサーバは当該ゾーンの情報(DNS zone)に関して他のサーバに依存しないサーバと依存するサーバに分かれます。他のサーバに依存しないサーバはプライマリマスタサーバと呼ばれます。これに対して当該ゾーンの情報に関して他に依存しているサーバはセカンダリ(あるいはスレーブ)サーバと呼ばれます。
※プライマリサーバもセカンダリサーバもゾーンに対して責任を持つという点では同じです。
ゾーン転送はセカンダリサーバからプライマリサーバへの情報要求によって行われます。セカンダリサーバは設定ファイルで指定された時間間隔で、プライマリサーバの情報の最新性をチェックし、プライマリサーバが新しい情報を持っていることが分かったときに、情報の転送を要求します。
ゾーンを更新した場合には必ずSOAレコードのシリアル値を増加させなくてはなりません。セカンダリサーバは定期的(設定ファイルのRefresh時間で定義)に、プライマリサーバにSOAレコードの問い合わせを行い、シリアル値が更新されている場合は、ゾーン転送の要求を行います。ゾーン転送は一般的には、一括転送(AXFR、Asynchronous xfer)ですが、負荷の軽減のために差分ゾーン転送(IXFR、Incremental xfer)を要求することもあります。
※xferはtransferの略語
名前解決はクライアントから問い合わされたドメイン名を名前空間から検索する処理です。ネームサーバは自分が権威を持つゾーンはもちろんそうでないドメインに対しても名前解決ができなくてはなりません。
8.1 ルートネームサーバ
木構造のドメイン名空間のトップに存在するルート(ネーム)サーバは現在13個が定義されています。これはルートサーバとして13のIPアドレスが定義されているという意味です。1つのIPアドレスに対応しているルートサーバは世界各所に何台もあります。これはルートサーバの負荷分散と、インターネット攻撃に対する備えという意味があります。
ルートネームサーバはトップレベルドメインのDNSサーバに権限を委譲し、トップレベルドメインのネームサーバは第2レベルドメインのネームサーバに権限を委譲しているというように、それぞれのドメインのネームサーバはそれぞれ自分の直下のドメインのネームサーバに権限を委譲しています。権限の委譲に際にポインタを維持していますので、権限移譲先のネームサーバがどれかは直ぐに分かります。
各DNSサーバはルートドメインのルートサーバの13個のIPアドレスを知っています(設定ファイルに記述されています)ので、最終的にはルートサーバに問い合わせをすれば名前解決に関するどのような問い合わせにも必ず回答を得ることができます。しかし、これは効率的な方法ではありません。これは答えば見つからない場合の最終手段としておいた方がよさそうです。
8.2 再帰的問い合わせと反復的問い合わせ
DNSサーバが権威を持つゾーンに対する問い合わせなら、そのDNSが責任をもって回答できます。この場合には指定された型のデータを返します。しかし、自分が権威を持たないドメインに対する問い合わせの場合はどうしたらいいでしょうか?名前解決の方法には再帰的問い合わせと反復問い合わせという2つの方法があります。
再帰的問い合わせとは「相手に責任を転嫁する形」での問い合わせです。再帰的問い合わせでは、問い合わせ自体を全部相手に任せて答えだけを要求します。再帰的問い合わせを受けたDNSサーバは、指定された型のデータを返すか、エラーメッセージを返すかしかできません。答えを知っていそうなDNSサーバを参照先として返すことはできません。
反復的問い合わせでは参照先を返すことができます。「私は知らないけどあの人なら知っているかも知れないから、聞いてごらんなさい」といってその人の住所、あるいは電話番号を教えてやるようなものです。通常の場合は、情報を知っていそうなDNSサーバのドメイン名とIPアドレスを返します。
次の例はルートサーバを経由して反復的問い合わせをして答えを得ている場合です。効率が悪そうなことは分かると思います。
8.3 効率的な名前解決
ルート経由で名前解決をしようとすれば、全ての名前解決が可能です。しかし、これは必ずしも得策ではありません。理由はいくつかあります。第一の理由は、ほとんどの名前解決はその要求が発生られたゾーンか、その配下のゾーンで解決できることです。また、何でもかんでもルートに聞いていてはルートの負荷が大変です。また、ルートネームサーバが故障すると、名前解決ができなくなってしまいます。
繰り返し問い合わせの方法で名前解決をする場合を例にとってどうすれば効率的に名前解決ができるか考えてみましょう。
DNSサーバは名前解決をするとその結果を一時的に保存しています(キャッシュ、cache)。キャッシュは問い合わせの結果得られたデータを後日の利用のために保存しておく技術です。従って、自分が責任をもって管理するゾーン以外の問い合わせの場合はまず最初にキャッシュを調べるべきです。
キャッシュにない場合でも、設定ファイルに直接記載されているかも知れません。親子関係、いとこ関係などのDNSサーバ、あるいは単によく利用するからという理由で記載されているサーバもあります。これらの中から、問い合わせ側が解決処理を続けるのに最適な情報を返します。最適な情報とは、知っている中で最も、問い合わせのドメイン名と近いネームサーバです。例えば、websv.edu.abc-u.ac.jpというドメイン名に対する問い合わせで近いサーバは、親の方に聞いていく場合は、順にedu.abc-u.ac.jp>abc-u.ac.jp>ac.jp>jpということになります。これらのいくつかを知っている場合は、近いほうのサーバに尋ねます。あるいは1つ知っている場合は、そのサーバに尋ねます。これらの何れも知らないという場合に初めてルートサーバに尋ねます。
認証システムなどではIPアドレスから名前へのマッピングも利用されています。認証システムの設定ファイルでは人間に対する分かり易さを考慮してドメイン名で記述されていることが多いためです。
IPアドレスからドメイン名を引き出す(逆引き名前解決)にはどのように登録しておくべきでしょうか。ドメイン名はeng.abc.co.jpのように大きなドメインがより右側に来るという並びになっています。これに対してIPアドレスの場合は、10.1.24.254などのように大きなネットワークが左にきて、右に行くほど小さなネットワークになっています。従って、これを逆ツリー構造にうまい具合に当てはめるには、大きなネットワークに該当する部分がよりルートに近くに来るように格納する必要があります。
※名前をIPアドレスに変換する方法を正引き名前解決といいます。
例えば、150.100.30.200というアドレスは逆引き用には200.30.100.150という形で保存しなくてはなりません。逆引きの場合には、in-addr.arpaというドメインに保存することになっていまので、200.30.100.150.in-addr.arpaというように管理されています。
BIND(バインド、Berkeley Internet Name Domain、以前の名前はBerkeley Internet Name Daemon)はインターネットで最も利用されているDNSサーバです。特にUNIX系(Linux等も含めて)ではBINDの利用が圧倒的です。
BINDは元々はDARPA(国防高等研究計画局、Defense Advaned Research Projects Agency)の資金を受けて(カリフォルニア大学バークリー本校で)開発されたものですが、後にDEC(Digital
Equipment Corporation、通称デック、かつて存在したアメリカ合衆国を代表するコンピュータ企業)の社員が開発を引き継ぎました。その中にポール・ヴィクシがいました。彼はDECを離れた後も開発を続けました。彼は後にISC(Internet
Systems Consortium)の立ち上げに関わることになり、そのISCがBINDのメンテナンスに責任を持つようになります。
BIND8までは多くの脆弱性を抱えていました。BIND8まではインターネットが性善説に基づいて運営されていた時代の遺物と言っていいかもしれません。このままではMicrosoft社のDNSとの競争に打ち勝つことはできません。そこで、セキュリティ機能の強化が急務となりました。BINDに残された道は、BIND8を修正することでセキュリティ機能を追加するという道と、新しくBIND9をゼロから書き起こすという道でしたが、後者が選択されました。
BIND9の開発は民間と軍の両方との契約を元に行われています。BIND9のほとんどの機能はUNIXベンダの出資で実現したものですが、セキュリティ機能(DNSSEC)はDNSのセキュリティを重視する米軍の出資によって実現したものです。
10.1 BIND9の特徴
BIND9の特徴としてはDNSSEC、TSIG、DNS notify、nsupdate、IPv6対応、rndc flush、view、マルチプロセッサのサポート、そしてアーキテクチャの移植性の向上などがあります。
● DNSSEC(DNS Security Extensions)
DNSサーバは通常キャッシュ機能を備えています。キャッシュ機能を備えていると名前解決をしたときに結果を一時保存し、再利用することができます。キャッシュ機能を備えたサーバはキャッシュサーバなどと呼ばれることもあります。キャッシュサーバは権威サーバへの問い合わせの際に、16ビットの識別子(ID)をDNSメッセージに格納します。権威サーバは応答にこのIDを使用します。そして、キャッシュサーバはIDが同じならば、自分の問い合わせに対する応答であると判断します。
IDは16ビットですので65,536通りしか値が使えませんので、偽造回答(Kaminsky氏の発見した方法によると繰り返し攻撃が可能なので、IDが不一致でも何度でも攻撃できる)を正当なものと勘違させて、キャッシュサーバのキャッシュに偽の名前情報を忍び込ませ、キャッシュサーバを使うクライアントを騙すという「DNSキャッシュポイズニング」という攻撃方法が可能となってしまいます。
キャッシュサーバが騙されると、このサーバを利用するクライアントは意図するサイトへ接続できず、通常は、攻撃者がコントロールする有害サイトに導かれてウィルスに感染するなどの被害を受けることになります。
※Kaminsky attack:Kaminsky氏が発見したDNSキャッシュポイズニング攻撃の方法。①攻撃者は標的とするキャッシュサーバに乗っ取りたいドメイン名と同じドメイン内の存在しないドメイン名を問い合わせます。例えば、www.example.comを乗っ取りたい場合は、12345thy.example.com(実際は存在しない)を問い合わせます。②問い合わせを受けたキャッシュサーバはキャッシュにないために権威サーバに問い合わせをします。③このタイミングで攻撃者は偽の応答として参照先を示す内容のパケットをターゲットのキャッシュサーバに返します。参照サーバとしては、攻撃者が用意した偽の権威サーバということになるでしょう。そして、偽の権威サーバに聞くと偽の回答を返します。この攻撃方法ではランダムなドメイン名をキャッシュサーバに問い合わせることで強制的に外部に問い合わせを行わせることができます。IDの不一致で攻撃が失敗してもドメイン名を変えてすぐに再試行できます。
DNSポイズニングによる危険は正当でないサーバ(権威サーバのふりをしたサーバ)から送られてくる偽装の回答が原因です。そこで、DNSSECではDNSキャッシュサーバからの問い合わせに対する回答が本来の権威サーバからのものであることを電子署名の仕組みを利用して検証することにしました。
DNSSECを利用するにはキャッシュサーバ、権威サーバをDNSSEC対応に変える必要があるとともに、電子署名に必要な鍵の管理方法や配布方法を確立するなどの課題があり、簡単ではありません。
● TSIG(Transaction Signature)
同じゾーンに複数の権威サーバがある場合には、マスタサーバとスレーブサーバの間でゾーン転送を行いデータベースの同期を図っています。この場合、スレーブサーバはIPアドレスだけで、マスタを識別しますので、マスタサーバのIPを偽造した「なりすましマスタ」サーバには無防備です。そこで、クライアントサーバの間で共通鍵を使って認証を行うTSIGが導入されました。TSIGではサーバとクライアントが共通鍵を持ち、DNSメッセージ全体に署名を行うことでメッセージの完全性保証やリクエスト認証を可能とします。
TSIGには認証の他に暗号化の機能もあります。また、定期的に共通鍵を交換するときには鍵の交換手段も必要となります。BIND9では共通鍵の交換を支援するTKEYも用意されています。
● DNS notify
DNS notifyは、ゾーン情報が更新された場合に、マスタからスレーブに報告をする方法です。ゾーン情報が更新されても、まだRefresh時間までに間があるときは、マスタが更新を知らせることに意味があります。ゾーン情報が更新されたことを、マスタからスレーブに知らせることで(Notifyの送信)、ゾーン転送が即時に開始されます。
● nsupdate
nsupdateコマンドはBIND9の中で動的DNSを使用するコマンドですので、まず初めに動的DNSについて説明をします。
動的DNS(Dynamic DNS、DDNS、正確にはDynamic Updates in the Domain Name System)は、動的に割り当てられるIPアドレスとそのホスト名の対応を、動的に登録・管理する仕組みです(RFC
2136)。TCP/IPでは元々IPアドレスは全て固定的に(静的に)割り当てるものでした。しかし、イントラネットが普及してくると組織内に急増するクライアントコンピュータ全てに固定IPアドレスを割り当て、それを管理することは大変な作業となってきました。そこで導入されたのがDHCPです。DHCPを導入することで、クライアントコンピュータにIPアドレスを自動的に割り当てることが可能となりました。
しかし、DHCPを使って自動でIPアドレスを割り当てると、そのIPアドレスとホスト名(ホストのドメイン名)の関係が流動的になってしまいます。一般のクライアントパソコンの場合にはこれでもあまり不都合はありませんが、このパソコンで情報公開をしようとするとちょっと困ります。公開用に使用しているドメイン名に対して常に新しいIPアドレスを対応させる必要があるからです(設定ファイルの中で当該ドメイン名に対応するIPアドレスを新しいものに書き換え)。しかも、設定ファイルを書き換えた後で、DNSプロセス(named)を再起動させなくてはなりません。これは組織のネットワーク管理者、あるいはISPのような接続業者の立場から考えると、大変手間のかかる仕事になります。
※企業や大学等で情報公開しようとする場合は固定アドレスを割り当てている場合がほとんどだとは思いますが、家庭内LAN上のコンピュータで情報公開をしようとする場合などには、このようなことが当てはまると思います。
※NATの内側で公開サーバを運用する場合は、ポートフォワーディングという手法が合わせて必要となります。
※設定ファイルは通常ゾーンファイルなどと呼ばれます。
そこで考案されたのがダイナミックDNSという考え方です。BIND9ではダイナミックDNSを利用する場合にはゾーンファイルの中でnsupdateコマンドを実行します。
● rndc flush
rndcはBIND9を制御するツールです。設定の再読み込み、DNSプロセス(named)の停止(起動はできない)、統計情報の表示、キャッシュのクリアなどを行うことができます。flushというオプションを使うと、メモリ上にあるキャッシュデータを全部削除することができます。DNSキャッシュポイズニングなどによって間違った情報がキャッシュされているような場合に対処ができます。
● view
viewは特定の条件に合致した問い合わせに対してのみ適用される設定を定義する手段です。
10.2 BIND9による設定例
BIND9を使った簡単な設定例について説明します。次に示すのは大学のある学部を想定した設定例です。OSはLinuxを想定しています。
種類 |
IPアドレス/ドメイン名 |
備考 |
プライマリDNSサーバ |
135.6.100.200 |
学部のDNSサーバ |
サブドメインのDNSサーバ |
135.6.110.200 |
権限委譲先の学科のDNSサーバ |
ドメイン名 |
se.abcd-u.ac.jp |
学部のドメイン名 |
ネットワーク |
135.6.100.0/24 |
学部のネットワーク |
MAILサーバ |
135.6.100.50 |
学部のメールサーバ |
Webサーバ |
135.6.100.51 |
学部のWebサーバ |
● BINDで最低限必要な設定ファイル
・ ブートファイルは/etc/named.conf
・ それ以外はデフォルトでは/var/namedディレクトリの直下に配置
説明 |
ファイル名 |
ブートファイル:システム起動時に参照する基本ファイル |
named.conf |
ヒントファイル |
named.ca |
se.abcd-u.ac.jp用の正引き参照ゾーン |
se.abcd-u.ac.jp.zone |
se.abcd-u.ac.jp用の逆引き参照ゾーン |
100.6.135.in-addr.arpa.zone |
ループバック正引き参照ゾーン |
localhost.zone |
ループバック逆引き参照ゾーン |
0.0.127.in-addr.arpa.zone |
ヒントファイルとループバック正引き参照ゾーンファイルは共通ファイルなので特に編集する必要はありません。
※ヒントファイルは13個のアドレスに対応するルートネームサーバ(セキュリティや負荷分散などの理由で特定のアドレスに対応するサーバは数台あるようです)の情報が記述されているので、時々最新情報を確認する必要があります。
自宅LANのような固定IPアドレスが1つというネットワーク環境では、逆引きの管理は通常ISPで行いますので、逆引きゾーンファイルも必要ありません。
● named.conf
BINDでは/etc/named.confがブートファイルになり、各ゾーンファイルを読み込むようになっています。
※named.confはOSによって、あるいはディストリビューションによって場所が異なりますので、find等を使って確認してください。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
control {
…
}
acl localnet {
135.6.100.0/24;
135.6.101.0/24;
127.0.0.1/8;
}; /* aclステートメントでは、アクセスを許可してよいネットワークを予め定義しておく。 */
options {
/* ゾーンデータファイルがどこにあるか指示 */
directory “/var/named”;
allow-transfer {
/* ゾーン転送を許可するサーバを記載。セカンダリサーバがある場合はここに書いておかないとアクセスを拒否される。ただし、allow-transferはゾーンセンテンスでも書くことができ、両方に書いている場合はゾーンセンテンスの記述が優先される。*/
local host;
135.6.100.210;
135.6.80.200;
};
version “no version”;
};
zone “.” {
type hint;
file “named.ca”
};
/* ループバックの正引き参照ゾーンのファイル */
zone “localhost” {
type master;
file “localhost.zone”;
allow-update { none; };
};
/* ループバックの逆引き参照ゾーンのファイル */
zone “0.0.127.in-addr.arpa” {
type master;
file “0.0.127.in-addr.arpa.zone”
};
/* se.abcd-u.ac.jp用の正引き参照ゾーンのファイル */
/* このホストで動くネームサーバ(named)が"se.abcd-u.ac.jp"ドメインのプライマリマスタサーバとして動作することを示す。*/
zone “se.abcd-u.ac.jp” {
type master;
file “se.abcd-u.ac.jp.zone”;
};
/* se.abcd-u.ac.jp用の逆引き参照ゾーンのファイル */
zone “100.6.135.in-addr.arpa” {
type master;
file “100.6.135.in-addr.arpa.zone”;
};
/* includeで指定したファイルは外部から読み込まれる。 */
include “/etc/rndc.key”;
|
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● セカンダリサーバ
"se.abcd-u.ac.jp"ドメインのセカンダリサーバにする場合は、正引き参照ゾーンの部分、逆引き参照ゾーンの部分が次のようになります。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
/* se.abcd-u.ac.jp用の正引き参照ゾーンのファイル */
/* このホストで動くネームサーバ(named)が"se.abcd-u.ac.jp"ドメインのセカンダリサーバとして動作することを示す。プライマリマスタサーバのIPアドレスは135.6.100.200となる。 */
zone “se.abcd-u.ac.jp” {
type slave;
file “se.abcd-u.ac.jp.zone.bak”;
masters {135.6.100.200;};
};
/* se.abcd-u.ac.jp用の逆引き参照ゾーンのファイル */
zone “100.6.135.in-addr.arpa” {
type slave;
file “100.6.135.in-addr.arpa.zone.bak”;
masters {135.6.100.200;};
}; |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
セカンダリサーバでもキャッシュ(named.ca)、ローカルゾーン、ローカルの逆引きの部分はプライマリマスタと同じように設定してください。ゾーン転送でプライマリマスタからコピーしたゾーンファイルは指定したように/var/namedに作成されるため、このディレクトリのnamedオーナーとグループで書き込みができるようにアクセス権(パーミッション)を変更しておいてください(chmod)。
※namedデーモンをnamedユーザで起動することを前提にしています。
※プライマリマスタの起動後、セカンダリサーバを起動し、うまくゾーン転送が行われるか確認してください。うまくいかない場合は、プライマリマスタの方でスレーブのアクセスを許可しているかどうか確認してください。optionsセンテンスのallow-transferの部分にセカンダリサーバのIPアドレスを書き込んでください(追加したい分だけ「;」で区切って書くことができます)。ゾーンセンテンスにもallow-transferを書くことができ、両方に書いた場合は、optionsセンテンスの記述よりもゾーンセンテンスの記述が優先されます。従って、ゾーンセンテンスにallow-transfer{ none; }と書くとこちらが優先され、ゾーン転送ができなくなりますので注意してください。
● リソースレコード
各ドメインはドメインに関連付けられたリソースレコード(resource record、資源レコード)を持ちます。リゾルバがサーバにドメイン名を与えると、返されるのはその名前に関連したリソースレコードです。リソースレコードにはドメイン名とIPアドレスの関係だけでなく、その他の情報も含まれます。
※ドメイン名システムは、複数の名前付けの階層を1つのシステムの中に埋め込む形式を採用しているので非常に汎用性があります。ドメイン名システムはいろいろの名前変換システムに対応するため、リソースコードの中に型を含みます。
● リソースレコードの型
クライアントが、ドメイン名システムに対して、型を指定して問い合わせをすれば、システムは型にマッチしたリソースコードを返します。型の例は次の通りです。
Type |
値 |
意味 |
内容 |
A |
1 |
Host Address |
ホストのIPアドレス |
NS |
2 |
Name Server |
そのゾーンに権威を持つネームサーバ |
CNAME |
3 |
Canonical Name |
既にAレコードで定義されているドメイン名の別名を定義 |
SOA |
4 |
Start of Authority |
権限の起点 |
PTR |
5 |
Pointer |
ドメイン名空間の他の部分へのポインタ |
HINFO |
13 |
Host CPU & OS Information |
ホストのCPUとOSに関する情報 |
MX |
15 |
Mail Exchager |
そのドメインのメールエクスチェンジャ |
● SOA
正引きゾーンファイル"se.abcd-u.ac.jp.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp. (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
/* “se.abcd-u.ac.jp”というドメインの、ネームサーバが”ns”で、そのドメインの管理者のメールアドレスが”root.se.abcd-u.ac.jp.”であることを示す */ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
・ $TTL:TTL(Time To Live)はゾーンに記述されている各レコードが、他のDNSサーバやクライアント機などにキャッシュされるときに、そのキャッシュをどれくらい保持すべきかの指定です。
・ $ORIGIN:対象としているドメインのドメイン名を補います。例えば、資源レコードで"www.se.abcd-u.ac.jp.
IN CNAME wbsv.se.abcd-u.ac.jp."を"www IN CNAME wbsv"のようにドメイン名を省略できます。
・ @:$ORIGINで定義したドメインに置き換えることができます。ここで@は"se.abcd-u.ac.jp."と同じ意味となります。
・ Serial番号:ゾーンデータを更新する度にカントアップする番号です。シリアル番号を更新し忘れると、DNS情報も更新されません(クライアントはデータが更新されたことに気が付かないので、ゾーン転送要求ができません)。
・ Refresh時間:セカンダリがデータの最新性をチェックする時間
・ Retry時間:ゾーン転送の再試行間隔の指定。Refresh時間で指定された間隔でマスタサーバのSOA確認を行おうとして、失敗した場合のリトライ時間。通常はRefreshよりも短く設定します。
・ Expire時間:セカンダリサーバのゾーンデータ保持時間。障害等の原因でプライマリDNSがゾーン情報を転送してこない場合に、セカンダリサーバがどれ位の時間、ゾーン情報を保持すべきかを指定します。
・ Minimum TTL:データをキャッシュに保存しておいていい時間。ネームサーバはデータの問い合わせに対して必ずこの時間を返さなくてはなりません。
● NSタイプソースレコードの例
正引きゾーンファイル"se.abcd-u.ac.jp.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
;Authoritative Name Servers
@ IN NS ns
/* “@ IN NS ns.se.abcd-u.ac.jp”は”se.abcd-u.ac.jp”ゾーンのネームサーバが”ns”であることを指示。 */ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● Aタイプソースレコードの例
正引きゾーンファイル"se.abcd-u.ac.jp.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
akagi IN A 135.6.100.100
/* “akagi.se.abcd-u.ac.jp. “という名前のホストのIPアドレス(A)が”135.6.100.100”であることを示す。 */
/* ”IN”はデータクラスがインターネットであることを示す。データクラスはIN以外も規定されているが、現在使用されているのはほとんどINのみ */
ns IN A 135.6.100.200
apsv IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● CNAMEタイプソースレコードの例
正引きゾーンファイル"se.abcd-u.ac.jp.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
www CNAME apsv
ftp CNAME apsv
/* “apsv.se.abcd-u.ac.jp.“はWebサーバ、Anonymous FTPサーバとして利用されているので、apsvの別名として、www、ftpという名前を与えた。 */
/* 別名を使うことで”se.abcd-u.ac.jp”ドメインをよく知らない人でもWebサーバ、FTPサーバを簡単に見つけることができる。*/ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● MXタイプソースレコードの例
正引きゾーンファイル"se.abcd-u.ac.jp.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
@ IN MX 10 mlsv
/* メールエクスチェンジサーバとして” mlsv.se.abcd-u.ac.jp.”を指定 */
/* メールエクスチェンジャ(Mail Exchanger)とはドメインに宛てたメールを処理または転送するホスト。メールエクスチェンジャが複数ある場合はMXの次の数字(プリファレンス値)の小さいものが優先される */ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● PTRタイプソースレコードの例
逆引きゾーンファイル"100.6.135.in-addr.arpa.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN 100.6.135.in-addr.arpa.
@ IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp.
・・・途中省略・・・
;Authoritative Name Servers
@ IN NS ns.se.abcd-u.ac.jp.
・・・途中省略・・・
;hosts
50 IN PTR mlsv.se.abcd-u.ac.jp.
51 IN PTR apsv.se.abcd-u.ac.jp.
100 IN PTR akagi.se.abcd-u.ac.jp.
|
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● ループバック正引き参照ゾーンの例
"localhost.zone"の例
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA localhost. root.localhost. (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
@ IN NS localhost.
1.0.0.127.in-add.arpa. IN PTR localhost.
/* 共通ファイルなので、デフォルトのまま使用可 */ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● notifyの例
Refresh時間等の関係で、セカンダリDNSが問い合わせてこない場合にプライマリDNSから更新を知らせる方法です。BINDではデフォルトでnotifyが有効になっていますが、これを明示的に有効にするにはnamed.confの中で"notify
yes"と指定します。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
・・・途中省略・・・
/* se.abcd-u.ac.jp用の正引き参照ゾーンのファイル */
zone “se.abcd-u.ac.jp” {
type master;
notify yes;
file “se.abcd-u.ac.jp.zone”;
};
/* 明示的にnotifyをyesに指定 */
・・・途中省略・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● サブドメインへの権限の委譲
"se.abcd-u.ac.jp"ドメインに、"sub.se.abcd-u.ac.jp"というサブドメインを作成し、このサブドメインにns1というDNSサーバを置き、これに権限を委譲することにします。
初めに示すのは権限を委譲する上位ドメインのネームサーバのゾーンファイルです。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp. (
2016042301 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
@ IN NS ns.se.abcd-u.ac.jp.
/* “IN NS ns.se.abcd-u.ac.jp”は”se.abcd-u.ac.jp”ゾーンのネームサーバが”ns”であることを指示 */
sub IN NS ns1.sub.se.abcd-u.ac.jp.
/* 委任先のゾーンを管理するネームサーバの情報を記述 */
ns1.sub IN A 135.6.110.200
/* ネームサーバが委任先のサブドメインに属する場合は、NSレコードとして委任先のネームサーバ名を指定するだけでなく、AレコードとしてそのネームサーバのIPアドレスも記述 */ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
委譲先のネームサーバのIPアドレスをAレコードとして記述しておかないと、上位ドメインのDNSサーバが委譲先のDNSサーバを見つけることができません。
権限の委譲を受けたゾーンのゾーンファイルの例は次の通りです。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN sub.se.abcd-u.ac.jp.
@ IN SOA ns1.sub.se.abcd-u.ac.jp. root.sub.se.abcd-u.ac.jp. (
2016042301 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
@ IN NS ns1
/* “IN NS ns1.sub.se.abcd-u.ac.jp.”は”sub.se.abcd-u.ac.jp.”ゾーンのネームサーバが”ns1”であることを指示 */
ns1 IN A 135.6.110.200
|
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● BINDの再起動
設定が終わったら、BINDを再起動してください。
/etc/init.d/named restart
10.3 BIND9の省略記法
namedのゾーンファイルは様々な省略記法が使われていて分かりにくいので、ここで簡単に説明しておきます。
省略記法の基本は「明示的に記述しない場合は直前の記述内容が設定されているとみなす」という考えに基づいています。
● $TTL
TTLはキャッシュの保持時間ですが、デフォルトでは1日(1D、または86400)となります。この値はDNS全体のパフォーマンスに多少影響を与えるかもしれませんが、不具合を生じさせるほどのことではありませんので、通常は全てのレコードに対して一律に設定しても構いません。こういう場合は、各ゾーンの先頭に"$TTL 86400"のように書いてしまいます。こうするとレコードごとにいちいち記述する手間が省けます。
≪省略前≫
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
se.abcd-u.ac.jp. IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp. (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
se.abcd-u.ac.jp. 86400 IN NS ns.se.abce-u.ac.jp.
akagi.se.abcd-u.ac.jp. 86400 IN A 135.6.100.100
ns.se.abcd-u.ac.jp. 86400 IN A 135.6.100.200
apsv.abcd-u.ac.jp. 86400 IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
≪$TTLで省略後≫
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
se.abcd-u.ac.jp. IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp. (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
se.abcd-u.ac.jp. IN NS ns.se.abce-u.ac.jp.
akagi.se.abcd-u.ac.jp. IN A 135.6.100.100
ns.se.abcd-u.ac.jp. IN A 135.6.100.200
apsv.abcd-u.ac.jp. IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● $ORIGIN [ゾーン名]
$ORIGIN [ゾーン名]をゾーンファイルの先頭に書いておくと、それがゾーンファイル全体でのデフォルトのゾーン名とみなされます。それ以降の、FQDNや、PTR形式のIPアドレスの記述を簡略化することができます。
≪$ORIGINで省略後≫
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA ns.se.abcd-u.ac.jp. root.se.abcd-u.ac.jp. (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
@ IN NS ns
akagi IN A 135.6.100.100
ns IN A 135.6.100.200
apsv IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● 末尾の"."
末尾の"."は省略記法を使っていないということを意味しています。末尾の"."を省略して記述すると、「その後に"."+デフォルトのゾーン名が付加している」とみなされます。$ORIGIN se.abcd-u.ac.jp.と定義すれば、"ns.se.abcd-u.ac.jp."は"ns"と表示できます。
≪"."のルールで省略後≫
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA ns root (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
@ IN NS ns
akagi IN A 135.6.100.100
ns IN A 135.6.100.200
apsv IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
● もっと省略したい
$OROGINという定義も省略可能です。
/* se.abcd-u.ac.jp用の正引き参照ゾーンのファイル */
zone “se.abcd-u.ac.jp” {
type master;
file “se.abcd-u.ac.jp.zone”;
};
/* se.abcd-u.ac.jp用の逆引き参照ゾーンのファイル */
zone “100.6.135.in-addr.arpa” {
type master;
file “100.6.135.in-addr.arpa.zone”; |
named.confの中で上の2つのパートが、それぞれ現在取り扱っているゾーンファイルを指し示すものだとすると、赤で示した「ゾーン名」の部分はそれぞれ対象となるゾーンファイルの中で、
zone "se.abcd-u.ac.jp" → "@"=デフォルトのゾーン名=se.abcd-u.ac.jp.
zone "100.6.135.in-addr.arpa" → "@"=デフォルトのゾーン名=100.6.135.in-addr.arpa.
と解釈されます。従って、ゾーンファイルの中での$ORIGINの記述も不要となります。
● 省略した場合は上の行と同じ
ゾーンファイルの中の各レコードの先頭の記述は、「省略した場合は上の行と同じ」とみなされますので、同じ設定対象を連続して記述する場合には、できるだけ続けて記述するようにすれば、記述はさらに簡素になります。
!!!###$$$%%%&&&ここから!!!###$$$%%%&&&
$TTL 86400
$ORIGIN se.abcd-u.ac.jp.
@ IN SOA ns root (
2014112701 ;Serial
10800 ;Refresh
3600 ;Retry
604800 ;Expire
86400) ;Minimum TTL
;Authoritative Name Servers
IN NS ns
akagi IN A 135.6.100.100
ns IN A 135.6.100.200
apsv IN A 135.6.100.51
・・・・・ |
///ENDEND%%%&&&ここまで///ENDEND%%%&&&
上のルールに沿って、NSの行の先頭の「@」は省略しました。
nslookupはネットワーク管理のためのコマンドラインツールです。ドメイン名とIPアドレスとの対応付け、その他DNSレコードを取得するためにDNSサーバに問い合わせをすることができます。Windowsの場合はpowershellから、あるいはコマンドプロンプトから利用できます。
nslookupコマンドは次のように使います。
nslookup <第1引数> <第2引数>
第1引数にはドメイン名(FQDN)か、IPアドレスを入れます。ドメイン名を使うと、IPアドレスに変換できるかどうかを確認できます。第1引数にIPアドレスを入れると、逆引きができるかどうかの確認ができます。
第2引数はDNSサーバを指定します。第2引数を指定しない場合は、デフォルトサーバへの問い合わせとなります。第2引数でDNSサーバを指定したい場合はIPアドレスあるいはドメイン名のいずれかで指定してください。
「権限のない回答」という表示がされる場合は、DNSキャッシュサーバがキャッシュ内容を回答している場合です。
nslookupには対話モードと非対話モードがあります。上に説明したのは非対話モードの例です。対話モードはnslookupを実行後にコマンドを入力して結果を得る方法です。
● 対話モード
対話モードで使う場合は、引数なしでnslookupコマンドを実行するか、第1引数として"-"を指定して、第2引数としてIPアドレスあるいはドメイン名を指定してください。第2引数としてDNSサーバを指定する場合に、第1引数に何も指定しないというわけにはいきませんので、"-"を指定します。対話モードに入るとプロンプトとして">"が表示されますので、このプロンプトに対して、ドメイン名、IPアドレスなどを何度でも入力することができます。次のような便利なコマンドも用意されています。例えば、"set
type=MX"を実行すると、MXレコードに対する問い合わせになります。
コマンド |
説明 |
set type=A |
Aレコードの問い合わせ |
set type=PTR |
PTRレコードの問い合わせ |
set type=MX |
MXレコードの問い合わせ |
set type=CNAME |
CNAMEレコードの問い合わせ |
server IPアドレス、またはFQDN |
問い合わせるサーバを指定のサーバに切り替え |
set debug |
DNSで問い合わせて得られる様々な情報を表示 |
>set type=MX
>aaa.bbb.ccc
を実行すれば、aaa.bbb.cccドメインのMXを問い合わせたことになります。
>set type=CNAME
>aaa.bbb.ccc
とすれば、aaa.bbb.cccドメインのCNAMEの問い合わせになります。
>set debug
>aaa.bbb.ccc
とすると、aaa.bbb.cccドメインに対する様々な情報が表示されます。
対話モードから抜ける場合は、"quit"コマンドを実行してください。
12.1 標準仕様(Standard)
■ DNSの基本仕様
RFC1034「Domain Names - Concepts and Facilities」(ドメイン名-概念と機能)、RFC1035「Domain Names - Implementation and Specification」(ドメイン名-実装と仕様)の2つが基本となる標準仕様です。DNSの考え方や、SOA、NS、A、PTR、MXなどのレコードや、in-addr.arpaの定義、DNSメッセージのフォーマット、ネームサーバやリゾルバの動作などについて規定しています。
これ以外に標準仕様として認められているのは、RFC1123「Requirements for Internet Hosts - Application
and Support」(インターネットホストへの要求条件-アプリケーションとサポート)(インターネットホストのDNS実装に関する要求事項について記述しています)、RFC5011「Automated
Updates of DNS Security (DNSSEC) Trust Anchors」、RFC6891「EXtension Mechanisms
for DNS(EDNS(0))」、RFC7218「Adding Acronyms to Simplify Coversations about
DNS-Based Authentication of Named Entities(DANE)」、RFC7477「Child-to-Parent
Synchronization in DNS」、RFC7671「The DNS-Based Authentication of Named Entities(DANE)
Protocol: Updates and Operational Guidance」、RFC7686「The ".onion"
Special-Use Domain Name」です。
■ DNSSECに関する標準仕様
RFC5011はDNSSECに関する標準仕様です。DNSSECはDNSポイズニング(DNS偽装)と呼ばれる攻撃を防ぐ手段として開発されています。DNSSECはドメイン登録情報にデジタル署名を付加することで正当な管理者によって生成された応答であること、応答が改ざんされていないことを保証するシステムです。DNSSECはリソースレコードの型を追加し、認証に必要な情報を追加リソースレコードとして扱います。DNSSECに対応していないクライアントは追加のリソースレコードを無視することで従来通りの照会が可能です。
RFC7218とRFC7671はDANE(DNS-based Authentication of Named Entities、発音はディーン?)について規定しています。DANEではDNSSECを使うことが前提となっています。Webサービスでは安全な通信を実現するためにTLS(Transport
Layer Security)が導入されています。TLSでは「信頼された認証局が発行した証明書は全てのドメインに対して有効である」という考え方が前提となっています。しかし、実際の認証局は審査の甘いところや脆弱性を持ったところが少なくありません。悪意を持った第三者はドメイン所有者の関知しないところで、そのドメインの証明書を不正に発行し、中間者攻撃に利用することができてしまいます(実際にそのような事件が起きています)。DANEは認証局ではなく、DNSを使って電子証明書を配送したり電子証明書とサーバの関連付けの正しさを確認したりできるシステムです。DNSのゾーン管理者がリソースレコードを登録するため、サーバのドメイン名の正しさを証明でき、認証局のような第三者機関を利用する必要がありません。ゾーンの管理者が登録するリソースレコード(TLSA、TLS
Association)には、証明書のフィンガープリント、証明書自体、証明書に含まれる公開鍵などがあります。
DANEは、最初RFC6698で提案され、RFC7671で改版されています。SMTP用にはRFC7672、サーバレコード用にはRFC7673が規定されています。
12.2 標準化提案(Proposed Standard)、標準化草案(Draft Standard)
標準化の過程にあるもの(Standards Truck)のうち、まだ標準化されていないもののうち主なものを次に示します(Proposed Standard、Draft
Standard、Standardの3つの段階をStandards Truckといいます)。
■ 基本仕様の修正、解説
RFC2181「Clarifications to the DNS Specification」(DNS仕様書の解釈)は、RFC1034、1035の記述誤り、分かりにくい説明に対して修正や、解説を行っています。
■ ゾーン転送
RFC1995「Incremental Zone Transfer in DNS」(DNS逐次的ゾーン転送)、RFC1996「A Mechanism
for Prompt Notification of Zone Changes (DNS NOTIFY)」(ゾーン変更の迅速な通知のためのメカニズム)、RFC5936「DNS
Zone Transfer Protocol (AXFR)」。RFC1995はゾーン転送における差分転送を規定しています。RFC1996はゾーン情報が変わったときにプライマリサーバからセカンダリサーバに知らせる方法について規定しています。BIND9ではnotifyとして実装しています。
■ DNS資源レコードタイプや特殊ドメインの追加
RFC1886「DNS Extensions to support IP version 6」(IPv6をサポートするためのDNS拡張)(Obsolete)、RFC3596「DNS Extensions to Support IP Version 6」(Draft)。これらはIPv6をサポートするための拡張です。
■ DNSレコードへの署名
RFC4033「DNS Security Introduction and Requirements」(DNS安全の紹介と必要条件)、RFC4034「Resource
Records for the DNS Security Extensions」(DNSセキュリティ拡張のための資源レコード)、RFC4035「Protocol
Modifications for the DNS Security Extensions」(DNSセキュリティ拡張のためのプロトコル修正)。
DNSセキュリティはデータの正当性を検証するための認証で、DNSレコードがゾーンの正しいレコードかを検証するためのDNSレコードへの署名と、DNSメッセージが改ざんされていないかを検証するためのメッセージ署名からなっていますが、上の3つはDNSレコードへの署名について規定しています。
DNSレコード署名については、最初にRFC2065(Obsolete)で提案され、その後、2535(Obsolete)、3008(Obsolete)、3090(Obsolete)、3445(Obsolete)、3655(Obsolete)、3658(Obsolete)、3755(Obsolete)、3757(Obsolete)、3845(Obsolete)によって修正されていますが、この全てを改版したのが上の3つの規定です。また、これに伴ってRFC3225「Indicating
Resolver Support of DNSSEC」(DNSSECリゾルバサポート表示)が改版されています。
■ DNSメッセージ署名
RFC2845「Secret Key Transaction Authentication for DNS (TSIG)」(DNSのための秘密鍵処理認証(TSIG)」、RFC2930「Secret
Key Establishment for DNS (TKEY RR)」(DNS(TKEY資源レコード)のための秘密鍵確立)、RFC2931「DNS
Request and Transaction Signatures (SIG(0))」(DNS問い合わせと処理署名(SIG(0)))、RFC3645「Generic
Security Service Algorithm for Secret Key Transaction Authentication for
DNS (GSS-TSIG)」(DNSのための秘密鍵取引認証のための一般的なセキュリティサービスアルゴリズム(GSS-TSIG))。この4つはメッセージ署名についての規定です。
■ デジタル署名アルゴリズム
RFC2536「DSA KEYs and SIG in the Domain Name System(DNS)」(ドメインネームシステムのDSA鍵と署名)、RFC2537「RSA/MD5
KEYs and SIGs in the Domain Name System(DNS)」(ドメインネームシステムのRSA/MD5鍵と署名」(Obsolete)、RFC2539「Storage
of Diffie-Hellman Keys in the Domain Name System(DNS)」(ドメインネームシステムでのDiffie-Hellman鍵の保管)、RFC3110「RSA/SHA-1
SIGs RSA KEYs in the Domain Name System(DNS)」(ドメインネームシステムのRSA/SHA-1署名とRSA鍵)。これらの4つはDNSSECで実際に使う個々のデジタル署名アルゴリズムの使い方を規定しています。RFC 2537は暗号強度が弱いためにRFC 3110で非推薦となっています。
RFC2538「Storing Certificates in the Domain Name System(DNS)」(ドメインネームシステム(DNS)での証明書の保管)(Obsolete)。署名の証明書の登録方法についての定義が規定されています。
■ ダイナミック更新
RFC2136「Dynamic Updates in the Domain Name System (DNS UPDATE)」、RFC2137「Secure
Domain Name System Dynamic Update」(安全なドメインネームシステムダイナミック更新)(obsolete)、RFC3007「Secure
Domain Name System (DNS) Dynamic Update」(安全なドメインネームシステム(DNS)ダイナミック更新)。RFC2137はDNSセキュリティをダイナミック更新で使う方法を初めて規定したものですが、RFC 3007で更新されました。
更新履歴
2016/04/24 作成
|