SS 研究会 セキュリティガイド②
DNS の運 用 にまつわる問 題
について
2006 年 5 月 12 日発行
第1版
付録
bind 9 系のインストール
サイエンティフィック・システム研究会
セキュリティガイド委員会
http://www.ssken.gr.jp/
本ガイドのご利用にあたって
1. ご利用範囲
• 本ガイドは、サイエンティフィック・システム研究会(SS 研)の会員に限らず、どなた
でもご利用いただけます。
2. 免責事項
• 本ガイドは、予告もなく改版される場合がございます。
最新版は SS 研ウェブサイトにて公開しておりますので、ご利用者の責任において、
常に最新版をダウンロードしご利用いただきますよう、お願いいたします。
• 本ガイドに記載された情報の正確性については万全を期しておりますが、誤解を生み
やすい記載や誤植を含む可能性があります。
その際に生じたいかなる損害に関して、当研究会（委員会）は責任を負いません。
3. お願い
• 本ガイドの内容についてのお問合せには一切応じませんので、予めご留意ください。
• 本ガイドのご利用後は、アンケートにご協力をお願いいたします。
アンケートは、SS 研ウェブサイトにて公開しております。
アンケートからいただいたご意見・ご要望は、今後の企画・改版の参考にさせていた
だきます。
SS 研ウェブサイト
http://www.ssken.gr.jp/
発行：サイエンティフィック・システム研究会
セキュリティガイド委員会
サイエンティフィック・システム研究会 セキュリティガイド②
目 次
1 はじめに............................................................................................................................ 1
2 ドメイン名や DNS に関係する問題................................................................................... 1
2.1 ドメイン名の更新忘れもしくは失効 ........................................................................... 1
2.2 ドメイン情報の登録や更新時のミス ........................................................................... 2
2.3 ネームサーバの管理の問題 ......................................................................................... 3
2.3.1 サーバソフトウェアの選択、キャッシュの毒入れ ............................................... 3
2.3.2 コンテンツサーバとキャッシュサーバの分離の必要性 ........................................ 3
2.3.3 コンテンツサーバ設定の一般的注意 .................................................................... 4
2.3.4 コンテンツサーバ設定時のタイプミスの恐怖 ...................................................... 5
2.3.5 日々の管理............................................................................................................ 5
2.4 もうひとつのドメイン名失効問題............................................................................... 5
3 クライアントの問題.......................................................................................................... 6
4 おわりに............................................................................................................................ 6
付録：bind 9 系のインストール .......................................................................................... 8
1. 概要.................................................................................................................................. 8
2. 準備.................................................................................................................................. 8
3. ソースの入手 ................................................................................................................... 8
4. プログラムの構築 ............................................................................................................ 9
5. インストール ................................................................................................................... 9
6. 設定.................................................................................................................................. 9
6-1. conf ファイルの作成 ................................................................................................ 10
6-2. 順引きファイルの作成 ............................................................................................ 14
6-3. 逆引きファイルの作成 ............................................................................................ 16
6-4. ローカルホスト定義ファイルの作成 ....................................................................... 17
6-5. cache ファイルの作成.............................................................................................. 17
6-6. キャッシュサーバとコンテンツサーバの分離について .......................................... 20
6-7. 起動スクリプトの設定 ............................................................................................ 20
7. クライアントとしての設定 ............................................................................................ 21
7-1. /etc/resolv.conf の作成 ............................................................................................. 21
7-2. /etc/nsswitch.conf の修正 ........................................................................................ 21
8. named の起動................................................................................................................. 22
i
サイエンティフィック・システム研究会 セキュリティガイド②
目 次
9. 動作確認......................................................................................................................... 22
ii
サイエンティフィック・システム研究会 セキュリティガイド②
DNS の運用にまつわる問題について
第 1 版 2006/05/12 公開
中京大学生命システム工学部
長谷川
明生
1 はじめに
DNS は、インターネットの運用に日常的に利用され重要な位置をしめているのですが、
あまり日常化しすぎて運用者側にも利用者側にも危機意識がなく、大きな問題があっても
見過ごしにされている場合があるようです。
昨今の M&A や組織の合併といった動きの中で、過去に取得利用していたドメインの管理
の不徹底による失効を狙った phishing の可能性、紛らわしいドメイン名での phishing 事
例やドメイン名登録時のタイプミス等々、ドメイン名や DNS 管理にまつわるさまざまな問
題が指摘されています。
この文書では、DNS にまつわる問題点を整理し、それに対する対処法も簡単に紹介しま
す。この文書により、DNS 運用に関する問題を減らせれば幸いです。
DNS の動作原理等については、「DNS&BIND」
（オライリー・ジャパン）等を参照くだ
さい。
2 ドメイン名や DNS に関係する問題
現在のところよく知られている問題を以下に列挙してみます。
2.1 ドメイン名の更新忘れもしくは失効
ドメイン名は、期限内の更新手続きを忘れると自動的に失効します。失効させてしま
うと、jp であれば jp のネームサーバから抹消され、ドメインが外部から検索できなくな
ります．その結果、外からのメールが届かなくなったり、外部から Web サーバを参照で
きなくなったりします。また、時には外部の人にメールを送ることができなくなります。
しかしながら、ふだん、電子メールをあまり使わない人にとっては迷惑メールが減って
よかったという程度の問題にしか見えません。ドメイン名を失効させても外部にメール
は届いてしまうこともあります。
では、ドメイン名の失効はどうして発生するのでしょう。
①担当者の異動等による更新忘れ
1
更新期限前には、ドメイン名登録代行業者からメールで案内が送られてくるはずで
す。それが正しい担当者にわたらないとドメイン名を失効させることになります。
担当者の異動がなくても、通知を見落とすといった担当者のうっかりミスにも、も
ちろん注意が必要です。
②組織の合併にともなうドメイン名変更等
昨今の情勢で、M&A や企業合併で社名変更にともなってドメイン名も変更になった
のに全社的に正しく伝わらず、失効したもしくは廃止したつもりの古いドメイン名が
使い続けられるといったケースが想定されます。このようなケースが大銀行の合併に
あたって実際に発生しています。
失効させたドメインも、汎用 jp ドメインでは失効後 1 ヶ月、地域型属性型 jp ドメインで
は 6 ヶ月後の月末までは他への再割り当てがなされないので、その範囲内であれば復活の
可能性があります。com 等の gTLD や他国の ccTLD などでは、再割り当てまでの猶予期間
が jp の規約とは異なる可能性がありますから注意が必要です。
このような期間を過ぎてしまうと、原則として失効させたドメインは誰でも取得可能な
ドメインとなります。失効ドメインばかりを狙って取得し、高い手数料でドメイン委譲を
狙う業者もいないわけではありません。しかし、失効ドメインや廃止したドメインが悪意
を持った人に取得され、phishing といった不正に利用されたり、失効や廃止を知らない取
引先からの重要なメールが盗み取られたりするといった危険はもっと認識されるべきです。
2.2 ドメイン情報の登録や更新時のミス
ドメイン名登録や更新手続き時のタイプミスには最新の注意が必要です。ドメイン名の
登録申請やドメイン情報更新時にタイプミスが発生して、間違ったドメイン名や IP アドレ
スで登録されてしまうと、ドメインが外部から見えなくなるといった不便だけでなくドメ
イン乗っ取りといった問題も発生します。
システムの更新やネットワークの更新の際に、レジストリのデータベース更新の手続き
を忘れるとそのドメインがインターネットから見えなくなってしまいます。これも、やは
り気づきにくい問題です。
管理者等が変更された場合は、whois 情報につながる情報の更新手続きが必要です。でな
いと各種のドメイン管理に必要な書類や情報が不達になることになります。新規登録の際
は、登録しないと使えないために登録を急ぎますが、担当者の異動や組織変更による担当
者情報の更新はインターネットの使用には直接影響しないので、つい忘れがちです。注意
しましょう。
2
2.3 ネームサーバの管理の問題
ここでは、ネームサーバを管理する上で注意しなければならないことがらについて整理
してみます。
2.3.1 サーバソフトウェアの選択、キャッシュの毒入れ
ネームサーバのソフトウェアとして BIND が広く利用されています。BIND は、機能が
豊富なのですが、その分バグも多いと考えられます。BIND を利用する場合には、極力新し
いバージョンを用いる必要があります。キャッシュの毒いれ問題やセキュリティバグ問題
を考えると、バージョン８や４は、すみやかに９に変更すべきです。djbdns システムの利
用も一考に価します。現在使っているキャッシュサーバにキャッシュ毒入れの問題がある
かどうかは、例えば http://ketil.froyn.name/poison.html にアクセスして調べることができ
ます。
キャッシュの毒入れ（cache poisoning）の典型的なものは以下のようです。
なんらかの方法で www.example.com をアクセスするように利用者を誘導します。これ
は普通 HTML メールを潜在的な被害者に送りつけることで行います。利用者が HTML 中
のリンクをクリックしたり、MUA のプレビュー機能や画像表示機能を有効にしていたりす
ると、クライアントは www.example.com のアドレスを検索するために example.com のネ
ームサーバに問い合わせをします。問題の example.com のサーバでは、つぎのような設定
をしておきます。
example.com.
IN
NS ns.example.com.
IN
NS online.goodbank.com.
IN
A
192.168.10.1
online.goodbank.com IN
A
192.168.10.2
ns.examle.com
すると example.com のネームサーバは ns.example.com の名前と IP アドレスとともに、
もうひとつのネームサーバ名 online.goodbank.com の名前も返します。そのついでに、そ
の IP アドレスとして偽の値 192.168.10.2 を教えます。問題のあるキャッシュサーバは、こ
の偽の値をキャッシュしてしまいます。このような準備の上で、利用者を
online.goodbank.com をアクセスするように誘導します。するとクライアントは、キャッシ
ュされた間違った情報によって phishing サイトに誘導されてしまいます。この種類の毒い
れには、たとえば MTA にメールを送りつけて、MTA の逆引きを利用した毒入れもありま
す。このような問題を避けるためにも古い BIND やそれから派生したソフトウェアの使用
は中止すべきです。
2.3.2 コンテンツサーバとキャッシュサーバの分離の必要性
管理するドメインの情報を外部に伝えるためのネームサーバの機能（コンテンツサーバ
3
機能）と、ネットワーク内のクライアントにインターネットの情報を検索してサービスす
る機能（キャッシュサーバ機能）には独立のプロセスを割り当てることが重要です。コン
テンツをサービスするプロセスと情報を検索するためのプロセスが一体で動作し、キャッ
シュ毒入れの問題を持ってると自ドメインの情報まで汚染されてしまいます。
キャッシュサーバ機能とコンテンツサーバ機能を独立に動作させるためには、コンテン
ツサーバとキャッシュサーバ用に２台のコンピュータを用意するのが簡単確実です。
そして、コンテンツサーバの IP アドレスをクライアントに設定させない（たとえば
resolv.conf に書かせない）ということが重要です。
キャッシュサーバ機能とコンテンツサーバ機能を独立のコンピュータ上に配置すること
で、どちらかの機能のトラブルが他の機能に影響するといった問題が排除できます。たと
えば、ネットワーク上のコンピュータがウィルス感染して大量のウィルスメールを発信し
た場合、キャッシュサーバ機能に負荷がかかりますが、コンテンツサーバの応答性能に影
響するといったことが防げます。
コンテンツサーバでは、再帰的検索機能をはずして、コンテンツへの問い合わせに対す
る応答を返すように設定します。また、ゾーン転送はセカンダリのコンテンツサーバのみ
にアクセス制限します。当然ながらセカンダリのコンテンツサーバもキャッシュサーバを
かねていてはいけません。
キャッシュサーバでは、アクセス制御によりドメイン外のクライアントに検索サービス
機能を提供しないように設定します。だれでもが利用可能なキャッシュサーバは、クラッ
カがアクセスの痕跡を隠すために役立ったり、DNS による DDoS（例えば、送信元を詐称
した検索パケットを大きなパケットを返す DNS サーバに投げつけると何がおきるか考えて
みてください？）の踏み台になります。
また、メールサーバや Web サーバ類が使うキャッシュサーバと、一般ユーザが利用する
キャッシュサーバをわけて設置します。共用していると、たとえばメールサーバに不正な
差出人のアドレスを持ったメールを送りつけることによって、メールサーバに DNS を検索
させ共用のキャッシュサーバに誤った情報を注入することも可能となります。分離するこ
とによって、キャッシュサーバに問題があっても一般利用者に被害がおよぶことを防止で
きます。すなわち、毒入れ問題等のリスクや不正なアクセスによる負荷の局所化がはかれ
ます。
2.3.3 コンテンツサーバ設定の一般的注意
ネームサーバやメールサーバの名前には CNAME を使ってはいけません。また、その他
のホストに対しても極力 CNAME を使わないように設定すべきです。逆引きの設定も正し
く設定しておかないと spam 対策によって差し出したメールが届かないという事態が発生
します。
新規にネームサーバを設定する場合に、使っている OS によってはネームサーバ用のポー
4
ト（53/udp,tcp）が IP フィルタ機能によりフィルタされていることがあります。この点を
忘れるとトラブルシューティングに手間取ることがあります。
コンテンツサーバのアドレス変更やネットワークの大規模な変更を計画している場合に
は TTL の値を事前に短くしておくことを忘れないようにしてください。これを忘れるとキ
ャッシュされた古い情報が参照されてアクセスできないとかアクセスしにくくなる期間が
長くなり、利用者に迷惑をかけます。また、逆に、新サーバに移行した後には、短くした
TTL を元に戻すことを忘れないようにしてください。これを忘れるとサーバの負荷を上げ
ることになります。サーバの IP アドレスやサーバ名を変更する場合には、レジストリへの
手続きも忘れないようにします。
2.3.4 コンテンツサーバ設定時のタイプミスの恐怖
コンテンツサーバの設定にあたってはゾーンファイル上でのタイプミスに注意が必要で
す。IP アドレスやホスト名のタイプミスは、よくあることです。しかし、ミスをした箇所
によっては、小さなミスと無視できない問題を引き起こします。特に NS レコード上のネー
ムサーバ名のタイプミスやネームサーバの IP アドレスのタイプミスにはドメイン名の乗っ
取りにつながる危険があります。
たとえば、example.ac.jp ドメインのネームサーバ ns.example.ac.jp を ns.exampleac.jp
とタイプミスすると exampleac.jp という別の汎用ドメインとなり、だれでもが取得できま
す。IP アドレスのタイプミスの場合も、同じ組織内ならアクセスできないといった不便で
すみますが、まったく関係ない組織のアドレスだとネームサーバのドメイン部分のタイプ
ミスと同様な問題があります。
2.3.5 日々の管理
サーバホストでの IP フィルタ設定ミスも問題ですが、ファイアウォールの設定ミスとい
ったこともあります。末端では、P2P ソフトウェアによる 53 番ポートの無断使用やサーバ
IP アドレスをクライアントにつけてしまうという事故もあります。
サーバ移行時や故障修理時に重複してアドレスをつけてしまうというミスにも注意が必要
です。
2.4 もうひとつのドメイン名失効問題
案外気づきにくくて重大な問題がセカンダリのネームサーバを委託した先のドメインの
失効問題です。これは、鈴木常彦氏が visa.co.jp のネームサーバの設定に関して指摘した問
題で、詳細は http://www.e-ontap.com/に解説があります。この例のように、セカンダリネ
ームサーバを委託している先のドメインが失効してしまうと、そのドメイン名は誰でもが
取得でき、セカンダリネームサーバと同名のコンテンツサーバを起動できます。利用者か
ら見た場合、プライマリとセカンダリは応答としては区別がつきません。それが phishing
5
等に利用される危険性は無視できません。セカンダリサーバを外部に委託した場合、その
サーバがキャッシュ毒入れの問題を持っていないかという検査も重要ですが、それ以上に、
そのサーバのドメイン名が失効していないか定期的に注意を払う必要があります。このよ
うな問題を避ける点からもネームサーバは自己の管理の及ぶ範囲内におくことが重要にな
ります。
3 クライアントの問題
ネットワークに接続されたコンピュータは、なんらかの形で参照すべきキャッシュサー
バの情報を記録しています。このキャッシュサーバの情報は、ISP の指定によって利用者が
手動で設定するか、DHCP による自動設定が普通です。そして、ドメイン名から IP アドレ
スを検索する必要が生じた場合には、クライアント PC は設定されているサーバに問い合わ
せます。コンピュータによっては、特定の少数のホストについて、名前と IP アドレスの対
照表をホストファイルという固有のファイルに持っていて、名前から IP アドレスの変換に
利用することもあります。このような仕組みを逆手にとって、これらの情報を書き換えて、
誤った URL にコンピュータの利用者を誘導するような手口が流行しています。このような
書き換えは、ウィルスを電子メールに添付して送るといった手法で行われます。
もうひとつ忘れてはならない問題があります。これは利用者のタイプミスにつけこむも
のです。
ある大学 example.ac.jp で Web による計算サービスを提供しているとしましょう。この
サーバの名前を login.example.ac.jp とします。ここで login.example.ac というドメイン名
を手に入れて、login.example.ac.jp と類似画面のサーバを用意すると、タイプミスをした
利用者の ID とパスワードを堂々と手にできます。ここで国別コードトップレベルドメイン
（ccTLD）のひとつである ac は誰でも取得可能なドメインです。日本の属性型ドメインと
一致する ccTLD には ne や co があります。属性型ドメイン ac.jp に対する ac ドメインを利
用した phishing 事例や大学のパロディ Web ページの存在が報告されています。ドメイン
名の最後の ccTLD である jp を付け忘れても見慣れた画面が提示されると気づきにくいもの
です。電子メールのあて先のタイプミスもミスした本人では発見が困難です。このミスに
よりメールが無関係な他人に届く可能性も考えられます。有名な大学については、ac ドメ
インは取得されており、Web サーバやメールサーバが設定されているケースもあります。
一度、各自確認してみることをお勧めします。
4 おわりに
ここにあげた DNS やドメイン名にまつわる問題は奥が深く、ここで示した問題は全体の
ごく一部分にしかすぎません。筆者は spam 対策にネームサーバの逆引きを利用しようとし
て、多くのネームサーバに単純な誤りや悪意のある設定を見ました。現状では、ネームサ
ーバは信用にたる情報を返してくれません。これは spam 発信に関係したドメインについて
6
ネームサーバで検索してみると容易にわかります。また、これらのドメインの登録情報も
あてになりません。
インターネットの普及が進んだにもかかわらずネームサーバの管理技術者不足は深刻で
す。利用者への安全教育も十分ではありません。技術者養成とともに利用者教育のさらな
る充実が望まれます。
この文書をまとめるにあたって中京大学の鈴木常彦先生および愛知県立大学の山口榮作
先生より貴重なコメント頂戴したことに感謝します。
以上
7
付録
bind 9 系のインストール
(bind-9.3.0/Solaris9)
1. 概要
bind は、DNS サーバを構築するためのソフトウェアです。
最近 bind の脆弱性やメンテナンス不備を悪用したトラブルが増えています。以下の
サイトなどを参考に、十分な注意を行うことが重要となっています。
http://jprs.jp/tech/
この中でも、以下はコンテンツサーバとキャッシュサーバの分離に触れていて特に重
要です。
http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html
ここに書いてある程度のことが普通に設定できない SI や ISP は、信用をなくすよう
な時代が来るかもしれません。
以降、 bind-9.3.0 をインストールする手順を説明します。説明の都合上、bind ソー
スを展開したディレクトリを$BIND とします。
2. 準備
イ ン ス ト ー ル に 必 要 な パ ス が 通 っ て い る か 確 認 し ま す 。（ /usr/local/bin
/usr/ccs/bin 等）
3. ソースの入手
公式サイト または 手近なミラーからソースをダウンロードします。
[例]
ftp://ftp.isc.org/isc/bind9/9.3.0/bind-9.3.0.tar.gz
/usr/local/src に入手したソースを解凍します。
以下、"%"プロンプトは一般ユーザー、"#"プロンプトは root で実行するものとしま
す。）
ディレクトリを作成してから解凍します。
% mkdir bind-9.3.0
% cd bind-9.3.0
% gzip -dc bind.src.tar.gz ¦ tar xvf -
8
4. プログラムの構築
※デフォルトでは/usr/local/sbin にインストールされます．設定を変更したい場合
には，$BIND/src/port/solaris 配下の Makefile.set ファイルを編集します．
Makefile.set
（抜粋）
'CC=gcc'
'CDEBUG=-g -O2'
'DESTBIN=/usr/local/bin' ・・・ nslookup,dnsquery,host などのインストール先
'DESTSBIN=/usr/local/sbin' ・・・ named などのシステムバイナリのインストール先
'DESTEXEC=/usr/local/sbin' ・・・ named-xfer などのバイナリのインストール先
'DESTMAN=/usr/local/share/man' ・・・ マニュアルのインストール先
'DESTHELP=/usr/local/lib' ・・・ ライブラリのインストール先
'DESTETC=/usr/local/etc' ・・・ 設定ファイル（named.conf）を配置する場所
・
・
なお、変更したら、インストールする前に
い。
%
%
%
%
$BIND/src/.settings を消去して下さ
cd $BIND/src
make clean
make depend
make all
5. インストール
インストール先ディレクトリがない場合はそのディレクトリを作成します
# mkdir /usr/local/sbin
インストールします
%
%
%
%
#
#
cd $BIND
./configure --prefix=/usr/local/bind --disable-threads
make
su cd $BIND
make install
6. 設定
今回は DNS マスターサーバとしての例を挙げて説明します。
以下のような環境での設定をもとに説明します。
ドメイン名
対象ドメイン
対象ドメインの上位ドメイン
sub.example.org
example.org
対象ドメイン内サーバおよび関連サーバ
9
ネットワーク
192.168.10.0/24
192.168.1.0/24
サーバ
DNS プライマリサーバ
DNS セカンダリサーバ
メールサーバ
その他のホスト 1
その他のホスト 2
上位 DNS プライマリサーバ
上位 DNS セカンダリサーバ
ホスト
ns1.sub.example.org
ns2.sub.example.org
mail.sub.example.org
host1.sub.example.org
host2.sub.example.org
ns1.example.org
ns2.example.org
IP アドレス
192.168.10.1
192.168.10.2
192.168.10.5
192.168.10.11
192.168.10.12
192.168.1.1
192.168.1.2
また、今回は定義ファイルを /var/named 配下に置くことにします。
6-1. conf ファイルの作成
named.conf には、管理するドメイン名や資源レコードを記述するデータファイルを指
定します。
あらかじめ、ホストの構成（IP アドレス、ホスト名）を準備し、以下のように記述し
ます。
/usr/local/etc/named.conf
acl allow-query-list {
192.168.10.0/24;
localhost;
};
acl allow-transfer-list {
192.168.10.2;
};
options {
directory "/var/named" ;
allow-query { allow-query-list; } ;
allow-transfer { allow-transfer-list; } ;
forwarders { 192.168.1.1; 192.168.1.2; } ;
version "sub DNS Server" ;
};
// comment : for rndc
key "rndckey" {
algorithm hmac-md5;
secret "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndckey"; };
};
// comment : for zone-file
zone "sub.example.org" {
type master ;
file "sub.zone" ;
} ;
10
zone "10.168.192.in-addr.arpa" {
type master ;
file "sub.rev" ;
} ;
zone "localhost" {
type master ;
file "localhost.zone" ;
} ;
zone "0.0.127.in-addr.arpa" {
type master ;
file "localhost.rev" ;
};
zone "." {
type hint ;
file "named.ca" ;
} ;
解説：
まず、後に設定する項目のリストを定義しています。
これは、「アドレスマッチリスト」と呼び、1 つまたは複数の IP 等を指定する際に、
ひとつのカテゴリとしてまとめることができます。
acl allow-query-list
以下で説明する allow-query の制限する IP アドレスを記述します。
acl "allow-transfer-list"
以下で説明する allow-transfer の制限する IP アドレスを記述します。
「options」は、DNS に関するオプションを記述します。
上記例をもとに、よく使用されるオプションについて、以下に説明します。
これら options は、実際のネットワーク環境をよく考慮して設定してください。
また、その他 option につきましては、BIND 付属のドキュメントを参照してください。
「directory」
まず、このオプションでホスト情報ファイルの場所を指定します。
上記では、DNS 情報（以降で説明するゾーンファイルなど）が/var/named のディレク
トリに収められていることを指定しています。
「allow-query」
このオプションを用いることによって、クライアントが、本 DNS サーバに対して名前
解決の問い合わせ（つまり DNS 参照）を行うマシンの許可／不許可を指定できます。
この場合、上記 allow-query-list に記述してあるネットワーク(192.168.10.0/24)や
ホスト(localhost)以外からの問い合わせは許可しません。
なお、外部からの参照も受ける DNS サーバの場合は、本オプションで設定する「DNS
全体としての参照制限」は変更せず、各ゾーンの設定において、個別に、全てからの
参照を許可するよう設定することを推奨します。
11
/usr/local/etc/named.conf （外部からの参照も受ける場合の例。太字が追加部分。）
acl allow-query-list {
192.168.10.0/24;
localhost;
};
（略）
options {
（略）
allow-query { allow-query-list; } ;
（略）
// comment : for zone-file
zone "sub.example.org" {
type master ;
file "sub.zone" ;
allow-query { any ; } ;
} ;
zone "10.168.192.in-addr.arpa" {
type master ;
file "sub.rev" ;
allow-query { any ; } ;
} ;
（略）
} ;
補足）allow-query 制限方法のコツ
allow-query 制限方法については、以下のようなポリシーで行うことを推奨します。
・ 自己の管理するコンテンツ（ゾーン）に関しては any に対して allow
・ 自己の管理するコンテンツ以外へのアクセス（キャッシュアクセス）について
は、ＩＰアドレスで制限する。（自組織内のみアクセス可能とし、他人に自由
にアクセスさせない）
「allow-transfer」
このオプションを用いることによって、ゾーン転送の許可／不許可の指定ができます。
セカンダリ DNS がある場合、ここで指定することによって不要なゾーン転送を行わな
くて済みます。この場合、上記 allow-transfer-list に記述してある 192.168.10.2（セ
カンダリ DNS）以外にはゾーン転送を許可しません。
「forwarders」
このオプションを用いることによって、DNS に関する外部への全ての問い合わせを、
指定した forwarder サーバに送ります。
これによって、forwarder サーバの持つ情報（キャッシュ）が蓄積されます。その結
果、リモートドメインへの問い合わせに対してその答えをキャッシュで見つけられる
可能性が高くなり、外部への DNS トラフィックを抑えることができます。この場合、
外 部 へ の 全 て の 問 い 合 わ せ は 上 位 DNS サ ー バ 、 ns1.example.org ま た は
ns2.example.org に送られます。
「version」
12
このオプションを用いることによって、使用している bind のバージョンを非表示す
ることができます。
デフォルトでは、外部からでも簡単にバージョンを参照できてしまい（例えば、以下
のようなコマンドで確認ができます）、バージョン特有の脆弱性を攻撃される可能性
があるため、意図的にバージョンを隠ぺいまたは置き換えることを推奨します。
% dig @対象の DNS サーバ version.bind chaos txt
なお、指定する文字列は任意ですが、一般的に「xxx の DNS サーバ( xxx DNS server)」
程度の記述にします。
「//」
コメント行の先頭に「//」をつけることによってそれ以降はコメントとみなされます。
「key」および「controls」
この２つの行は、rndc コマンド（BIND 8 の ndc コマンドに相当）により、named の起
動・停止などの制御を行えるようにする設定です。key 行では、rndc を利用するため
のキーを設定し、control 行では、制御を許可するサーバなどを指定します。
BIND 9 では設定ファイルの作成を支援する rndc-confgen コマンドが用意されていま
す。以下それを利用して作成する手順を示します。
①/usr/local/sbin/rndc-confgen > /etc/rndc.conf
ファイル名やパスは必要の応じて変更します。
②上記実行後、/etc/rndc.conf の以下の行以降を、コメントを解除（#を外す）した
上で、named.conf に追加します。
# Use with the following in named.conf
上記例では、この手順で作成した設定を追加しています。
ただし、「secret "XXXXX∼"」の"XXXXX∼"部分については、実際は別の文字列にな
ります。
「zone "sub.example.org" { }」
ドメイン sub.example.org に対するデータを格納するファイルの指定をします。設定
内容は、「 { } 」で閉囲みます。
「type master;」
ゾーンタイプを指定します。ここではゾーンタイプが master であるこ
とを表しています。なお、セカンダリ DNS の場合、type は slave になり、
さらにその中で masters（プライマリ DNS）のアドレスを指定します。
「file "sub.zone";」
ゾーンファイルのファイル名を指定します。ここでは sub.zone という
名前のファイルであることを表しています。
以下、同じように記述していきます。
13
「zone "10.168.192.in-addr.arpa" { }
192.168.10 のゾーンに対する逆引きの指定します。
「zone "." {
type hint; }
ルート（「.」で表現）サーバをみつけるための hint となるデータベースフ
ァイルを指定します。
補足：
conf ファイルにおいて、bind 4.X 系は named.boot というファイルを用いており、
named.conf とはまったく記述形式が異なります。named.boot ファイルから named.conf
ファイルを作成するには、named-bootconf を使用します。
# /usr/local/sbin/named-bootconf < named.boot > named.conf
上記のコマンドで、named.boot から named.conf に変換したファイルが作成さ
れます。
6-2. 順引きファイルの作成
まず、順引きファイルを作成します。
/var/named/sub.zone
;
; /var/named/sub.zone
;
$TTL 86400
@
IN SOA ns1.sub.example.org. root.ns1.sub.example.org. (
200603011
; serial yyyymmddn
10800
; refresh 3 hour
3600
; retry 1 hour
604800
; expire 7 days
86400 )
; minimum 24 hour
IN
NS
ns1.sub.example.org.
IN
NS
ns2.sub.example.org.
IN
MX 10 mail.sub.example.org.
;
ns1
IN
A
192.168.10.1
ns2
IN
A
192.168.10.2
mail
IN
A
192.168.10.5
host1
IN
A
192.168.10.11
www
IN
CNAME
host1.sub.example.org.
host2
IN
A
192.168.10.12
;
解説：
「；」
「；」から始まる行は、コメントとして認識されます。コメント記入や区切りに使用
14
します。
「@」
現在のゾーンまたは原点を示します。
「IN」
インターネットを意味します。
「SOA」
ゾーンの先頭を表します。次の SOA が来るまで同一資源という意味になります。
「root.ns1.sub.example.org.」
ドメイン管理者のメールアドレスを記載します。ここでは「@」を使用せずに上記よ
うに「.」で 記述をします。
最後の「.」も忘れずに記述します。
「200603011」
データファイルのシリアル番号を表しています。通常は、西暦-月-日-通し番号で記
載します。
bind はこのシリアル番号でゾーンデータの更新を認識します。
「10800」
セカンダリサーバがゾーンデータの更新チェックを行う間隔を表しています。
秒単位で表記し、この場合は 3 時間で更新チェックを行います。
「3600」
プライマリサーバが応答しない場合に再度参照する間隔を表しています。秒単位で表
記し、この場合は 1 時間で再度参照します。
「604800」
セカンダリサーバが、ここで設定した時間に達してもプライマリサーバへのアクセス
に成功しないとき、元の情報を破棄するまでの時間を表しています。秒単位で表記し、
この場合は 1 週間で破棄します。
「86400」
キャッシュした情報の生存時間（TTL）のデフォルト値を表しています。
秒単位で表記し、ここでは 24 時間キャッシュします。
「IN
「IN
NS
ns1.sub.example.org.」
NS
ns2.sub.example.org.」
NS（Name Server）レコードを表します。自ドメインにおける関連する DNS サーバを
表記します。
（プライマリサーバやセカンダリサーバなどを記述します。）
「IN
MX
10 mail.sub.example.org.」
自ドメイン関係あるメールの MX（Mail eXchanger）レコードを表します。
「ns1
IN
A
192.168.10.1」
15
ホスト「ns」における A（Adress）レコードを表します。
以下、同じようにドメインに属するホスト名とその IP アドレスを記述します。
「www
IN
CNAME
host1.sub.example.org.」
ホストの CNAME（Canonical NAME-別名）レコードを表します。
この場合は host1 に www という別名を定義しています。
注）CNAME では、以下のような設定は行えませんのでご注意ください。
その１）以下のように、同じ名前(www)で、別々のホスト(host1,host2)に CNAME を使用
www
www
host1
host2
IN
IN
IN
IN
CNAME
CNAME
A
A
host1.sub.example.org.
host2.sub.example.org.
192.168.10.11
192.168.10.12
その２）以下のように、NS や MX などの資源レコードに CNAME を使用
;
ns1
host1
IN
NS
ns1.sub.example.org.
IN
IN
CNAME
A
host1.sub.example.org.
192.168.10.11
6-3. 逆引きファイルの作成
/var/named/sub.rev
;
; /var/named/sub.rev
;
$TTL 86400
@
IN SOA ns1.sub.example.org.
root.ns1.sub.example.org. (
200603011
; serial yyyymmddn
10800
; refresh 3 hour
3600
; retry 1 hour
604800
; expire 7 days
86400 )
; minimum 24 hour
IN
NS
ns1.sub.example.org.
IN
NS
ns2.sub.example.org.
;
1
IN
PTR
ns1.sub.example.org.
2
IN
PTR
ns2.sub.example.org.
5
IN
PTR
mail.sub.example.org.
11
IN
PTR
host1.sub.example.org.
12
IN
PTR
host2.sub.example.org.
解説：
「1
IN
PTR
ns1.sub.example.org.」は named.conf で指定した、
「192.168.10.」
以下（4 オクテット目）の IP アドレスに対する PTRPointer）レコードを表しま
16
す。 この場合、192.168.10.1 のホストは ns1.sub.example.org であるということ
を表します。
以下、2 は ns2、5 は mail、11 は host1 というように PTR レコードを記述していきま
す。
6-4. ローカルホスト定義ファイルの作成
順引き、逆引きファイルを作成したのと同じように、ローカルホストに対する順引き
逆引きファイルを作成します。
表記方法は同じです。
/var/named/localhost.zone
;
; /var/named/localhost.zone
;
$TTL 86400
@
IN SOA ns1.sub.example.org.
root.ns1.sub.example.org. (
200603011
; serial yyyymmddn
10800
; refresh 3 hour
3600
; retry 1 hour
604800
; expire 7 days
86400 )
; minimum 24 hour
IN
NS
ns1.sub.example.org.
;
localhost.
IN
A
127.0.0.1
/var/named/localhost.rev
;
; /var/named/localhost.rev
;
$TTL 86400
@
IN SOA ns1.sub.example.org.
root.ns1.sub.example.org. (
200603011
; serial yyyymmddn
10800
; refresh 3 hour
3600
; retry 1 hour
604800
; expire 7 days
86400 )
; minimum 24 hour
IN
NS
ns1.sub.example.org.
;
1
IN
PTR
localhost.
6-5. cache ファイルの作成
cache ファイルは、初めてサーバのシステムが起動したときに、最初にキャッシュデ
ータとして読み込まれるデータファイルです。初期値として、ルートドメインの情報
を定義しておく必要があります。
ドメインによって幾つか違った構成のファイルがありますが、一般的にはドメインあ
るいは上流ドメインから配布されているファイルを使用します。
17
まず、内部 DNS 情報のみを参照する場合の記述例を記載します。
/var/named/named.ca（内部 DNS 情報のみを参照）
;NAME
.
ns1.sub.example.org.
TTL
99999999
99999999
CLASS
IN
IN
TYPE
NS
A
DATA
ns1.sub.example.org.
192.168.10.1
解説：
1 行目はコメントです。
2 行目先頭の「.」は、ルートドメインの DNS サーバを識別しており、ドメイ
ン は DATA フィールドで定義します。
3 行目では、2 行目のドメインのサーバの IP アドレスを表し、TTL(Time To Live)に
99999999 を記述することによってこのデータがキャッシュから永久に削除されな｢こ
とを示します。（Max 値）
以下は、外部のアドレスを問い合わせることができる例として INTERNIC からダウン
ロードしたファイルを記述します。（ftp://rs.internic.net/domain/named.root）
/var/named/named.ca
;
This file holds the information on root name servers needed to
;
initialize cache of Internet domain name servers
;
(e.g. reference this file in the "cache . <file>"
;
configuration file of BIND domain name servers).
;
;
This file is made available by InterNIC
;
under anonymous FTP as
;
file
/domain/named.root
;
on server
FTP.INTERNIC.NET
;
-ORRS.INTERNIC.NET
;
;
last update:
Jan 29, 2004
;
related version of root zone:
2004012900
;
;
; formerly NS.INTERNIC.NET
;
.
3600000 IN NS
A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.
3600000
A
198.41.0.4
;
; formerly NS1.ISI.EDU
;
.
3600000
NS
B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.
3600000
A
192.228.79.201
;
; formerly C.PSI.NET
;
18
.
3600000
C.ROOT-SERVERS.NET.
3600000
;
; formerly TERP.UMD.EDU
;
.
3600000
D.ROOT-SERVERS.NET.
3600000
;
; formerly NS.NASA.GOV
;
.
3600000
E.ROOT-SERVERS.NET.
3600000
;
; formerly NS.ISC.ORG
;
.
3600000
F.ROOT-SERVERS.NET.
3600000
;
; formerly NS.NIC.DDN.MIL
;
.
3600000
G.ROOT-SERVERS.NET.
3600000
;
; formerly AOS.ARL.ARMY.MIL
;
.
3600000
H.ROOT-SERVERS.NET.
3600000
;
; formerly NIC.NORDU.NET
;
.
3600000
I.ROOT-SERVERS.NET.
3600000
;
; operated by VeriSign, Inc.
;
.
3600000
J.ROOT-SERVERS.NET.
3600000
;
; operated by RIPE NCC
;
.
3600000
K.ROOT-SERVERS.NET.
3600000
;
; operated by ICANN
;
.
3600000
L.ROOT-SERVERS.NET.
3600000
19
NS
A
C.ROOT-SERVERS.NET.
192.33.4.12
NS
A
D.ROOT-SERVERS.NET.
128.8.10.90
NS
A
E.ROOT-SERVERS.NET.
192.203.230.10
NS
A
F.ROOT-SERVERS.NET.
192.5.5.241
NS
A
G.ROOT-SERVERS.NET.
192.112.36.4
NS
A
H.ROOT-SERVERS.NET.
128.63.2.53
NS
A
I.ROOT-SERVERS.NET.
192.36.148.17
NS
A
J.ROOT-SERVERS.NET.
192.58.128.30
NS
A
K.ROOT-SERVERS.NET.
193.0.14.129
NS
A
L.ROOT-SERVERS.NET.
198.32.64.12
;
; operated by WIDE
;
.
M.ROOT-SERVERS.NET.
; End of File
3600000
3600000
NS
A
M.ROOT-SERVERS.NET.
202.12.27.33
6-6. キャッシュサーバとコンテンツサーバの分離について
DNS サーバはその機能から、キャッシュサーバ (Recursive Server) とコンテンツサ
ーバ (Authoritative Server)、 およびその両機能を兼ね備えたキャッシュ・コンテ
ンツ兼用サーバに分けられます。
以下の URL でも注意喚起されているとおり、BIND のキャッシュサーバは、DDoS 攻撃
の踏み台となる可能性がありますので、下記 URL を参照し、キャッシュサーバとコン
テンツサーバの分離を行うことを強く推奨します。
http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html
なお、各サーバの概要は以下のとおりです。
①キャッシュサーバ
クライアントからの問い合わせ要求を受けると、コンテンツサーバに対して再帰的に
問い合わせを行い、結果をクライアントに返す DNS サーバです。PC などがインター
ネットに接続する際に設定する DNS サーバであり、DHCP や PPP などで自動的に設
定される場合もあります。
②コンテンツサーバ
管理するドメインの情報 (ゾーン情報) を持ち、キャッシュサーバからの問合せに回
答する DNS サーバです。
③キャッシュ・コンテンツ兼用サーバ
名前の通り、1 台の DNS サーバでキャッシュサーバとコンテンツサーバの両方を兼
用するものです。インターネットで利用されている DNS サーバの多くが、この兼用
型であるという統計があります。
6-7. 起動スクリプトの設定
設定ファイルが作成できたら、サーバ起動時に named が起動するようにスクリプトを
作成します。
/etc/rc2.d/S72named
#!/bin/sh
NAMED="/usr/local/sbin/named"
CONF="/usr/local/etc/named.conf"
NDC="/usr/local/sbin/rndc"
USER=named
case "$1" in
20
'start')
if [ -f $NAMED -a -f $CONF ]; then
echo 'starting internet domain name server.'
$NAMED -u $USER -c $CONF
fi
;;
'stop')
if [ -f $NAMED -a -f $NDC -a -f $CONF ]; then
$NDC stop
exit 0
fi
;;
'reload')
if [ -f $NAMED -a -f $NDC -a -f $CONF ]; then
echo 'reloading internet domain name server.'
$NDC reload
fi
;;
*)
echo "Usage: $0 { start ¦ stop ¦ reload }"
exit 1
;;
esac
7. クライアントとしての設定
7-1. /etc/resolv.conf の作成
/etc/resolv.conf ファイルでは、自マシンの所属ドメイン名及び所属ドメインのネー
ムサーバの IP アドレスを指定します。
/etc/resolv.conf
Domain
nameserver
nameserver
sub.example.org
192.168.10.1
192.168.10.2
7-2. /etc/nsswitch.conf の修正
nsswitch.conf では、ホスト名を IP アドレスに変換する手段の設定をします。
/etc/nsswitch.conf の hosts: で始まる行に "dns"を追加します。
/etc/nsswitch.conf
hosts:
files
dns
21
上記の設定は、ホスト名をまず /etc/hosts で検索します。ホスト名が /etc/hosts
に存在しない場合は、DNS を参照します。
8. named の起動
全て設定が整ったら、named を起動します。
# /etc/rc2.d/S72named start
9. 動作確認
named が正しく動作しているかを調べるには、nslookup コマンドを使用します。
詳細は、オンライマニュアルを参考にしてください。
まず、nslookup を起動します。
% nslookup
Default Server: ns1.sub.example.org
Address: 192.168.10.1
>
と出力されて、入力待ちになります。
簡単なコマンドオペレーションは、help と入力すれば見られます。
> host1.sub.example.org
と入力してみます。
Name: host1.sub.example.org
Address: 192.168.10.11
と結果が返ってくれば A レコードは、うまく引けています。
次に逆引きのテストです。
> 192.168.1.12
と入力してみます。
Name: host2.sub.example.org
Address: 192.168.1.12
と結果が返ってくれば PTR レコードはうまく引けています。
次に MX レコードを引いてみます。
> set q=mx
> sub.example.org
まず、Query Type を MX に変更します。上記の 1 行目の入力がその変更を意味してい
ます。
次にメールアドレスの@より右（上記例は、user@sub.example.org を想定）を入力し
ます。
22
sub.example.org
preference = 10, mail exchanger = mail.sub.example.org
と結果が返ってくれば MX レコードはうまく引けています。
以上の動作が確認できれば、DNS サーバは完了です。
23
サイエンティフィック・システム研究会 セキュリティガイド②
DNS の運用にまつわる問題について
著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。
本資料に関するお問合せは、下記へお願いします。
SS 研究会事務局
東京都港区東新橋 1-5-2 汐留シティセンター (〒105-7123)
富士通株式会社 カスタマーリレーション部内 SS 研究会事務局
TEL：03-6252-2582(直通)
FAX：03-6252-2934
Email：ssken@ssken.gr.jp
2006 年 5 月 12 日発行
禁無断転載
© Copyright 2024 Paperzz
