タグ「BIND」が付けられているもの

bindのゾーン委任

明けましておめでとうございます。

年始早々くだらないことでハマってしまったので。

ラボ環境を作って内部だけのDNSゾーンを作ろうとしていたところ、bind9.10.3でゾーン委任がうまく動かない。

ラボ環境のDNSドメインをlab.localとして
委任する側のzoneファイル

$TTL 60
@ IN SOA local. root.local. (
1000 ; Serial
600 ; Refresh
120 ; Retry
600 ; Expire
60 ) ; Negative Cache TTL
;
@ IN NS ns.local.
@ IN A 10.0.1.1
ns IN A 10.0.1.1

lab.local. IN NS ns.lab.local.
ns.lab.local. IN A 10.1.1.1
委任される側のzoneファイル
$TTL 60
@ IN SOA lab.local root.ns.lab.local (
10 ; Serial
300 ; Refresh
300 ; Retry
300 ; Expire
60 ) ; Negative Cache TTL
;
@ IN NS ns.lab.local.
@ IN MX 10 ns.lab.local.
@ IN A 10.1.1.1
ns IN A 10.1.1.1

普通にサブドメインのゾーン委任しているだけなのに動かない・・・

と思ったのですが、委任する側のDNSサーバにクエリを投げると、上位側のDNSサーバがforwardersで指定したサーバに聞きに行っていることがわかりました。
サブドメインだから検索するときに先にforwardersで指定したサーバを見に行ってしまうことがアカンのかと思って、STUBゾーンにいてみたりしましたが意味なし。

zone "lab.local" {

type stub;
masters { 10.1.1.1; };
file "db.lab.local.stub";
};

結局、サブドメインのゾーンをforwardしない設定にしてあげると、ゾーンファイル側を見てくれるようになりました。

zone "lab.local" {

type stub;
masters { 10.1.1.1; };
file "db.lab.local.stub";
forwarders {};

};

結論：サブドメインをStubで定義して、forwarders {}；を入れておく。

尤も、サブドメインを委任するということは通常その上位のドメインの権威あるサーバということですから、フォワードしないというか自身の持っているゾーン以外の問い合わせに応答させることはないはず。ですので特に問題にならないかと思うのですが、今回の場合あくまでラボ環境ですので外部へのクエリをフォワードする役割と、ゾーンを持っているサーバを兼務させていることが事の原因かと。

bind 9.6.1-P1リリース

bind　9.6.1-p1がリリースされています。
緊急度：高となっているDynamic Update機能の脆弱性のパッチが当てられています
Dynamic Updateを利用していなくても、Masterとして稼働させているゾーンがあれば対象となる・・・ということで（セカンダリDNSであってもlocalhostと127.0.0.0はMasterゾーンとして設定されていると考えられるため）、適用は必須のようです。


BIND 9のDynamic Update機能の脆弱性を利用したDoS攻撃について



US CERT VU#800113

DNSの脆弱性の件。なんだか大ごとになってますね。。

http://itpro.nikkeibp.co.jp/article/NEWS/20080725/311531/

今回の脆弱性を発見したのは、セキュリティ研究者のダン・カミンスキー氏。同氏は、2008年8月に開催されるセキュリティ会議「Black Hat」において、今回の脆弱性を発表する予定で、それまでは脆弱性の詳細を公表しない予定だった。

　しかしながら2008年7月22日、脆弱性の詳細が予定外に公開されてしまった。そして今回、この脆弱性を悪用するためのプログラム（攻撃コード）も公 開されたという。このプログラムを使えば、キャッシュポイズニング攻撃が容易に行えるとされている。実際、米サンズ・インスティチュートによれば、今回の 脆弱性を悪用した攻撃が既に確認されているという情報もあるという。

　同じくサンズ・インスティチュートによれば、7月24日に開催されたBlack HatのWebセミナーにおいてカミンスキー氏は、本来はBlack Hat本番で明らかにする予定だった脆弱性の詳細を発表。カミンスキー氏の実験では、今回の脆弱性を突けば、5秒から10秒でDNS情報を改ざんできたと している。

という事で正式発表前に脆弱性の詳細が漏れてしまったことから、攻撃ツールが出回ってしまい、、、大慌てという感じ。

脆弱性については、DNSクエリのID長が16ビットしかないというプロトコル上の脆弱性に加え、DNSサーバとして動作させている場合にクエリに利用するソースポートを53/udpに固定してしまう事で、キャッシュポイズニングの危険性が高くなるというもの。加えて、ポートが固定されていなくても、ソースポートの利用がランダムに行われない場合はクライアントでもその危険性が高くなる・・・とされている。サーバもクライアントも対策が必要となると、かなり大がかりな変更が必要になると言うことで、、あちこちでかなりの大慌てという状況らしい。

ダン・カミンスキー氏のサイトにDNSチェッカーが設置されていて、今回の脆弱性が該当するかのチェックが行えるようになっています。

実行結果
Your name server, at 133.205.66.14, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).
Requests seen for 2d1b6b972008.doxdns5.com:
133.205.66.14:3539 TXID=24954
133.205.66.14:46741 TXID=42778
133.205.66.14:24932 TXID=50670
133.205.66.14:29625 TXID=10359
133.205.66.14:10335 TXID=13083
↑OKですね。

英語ですが、こんな感じで利用中のDNSサーバをチェックしてくれます。




あと、情報は以下のサイトで。

日経

US-CERT VU#800113

JPCERT/CC JPCERT-AT-2008-0014

JPRS 複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

JVN JVNVU#800113

ISC BIND Vulnerabilities

マイクロソフト セキュリティ情報 MS08-037





ちなみに自分の管理してるところはとっくに対策済み。結局BINDも9.5.0-P1ではパフォーマンス低下の問題が出たようで、すぐさま9.5.0-P2が出されるなど、いつものグダグダっぷりが発揮されたようだけど。

BINDバージョンアップ絡み

BINDのバージョンアップ時・・・
BINDは動くけれども、自分で持っているハズのzoneが返ってこないという症状に。
Aug  6 23:26:40 dns named[5248]: [ID 873579 daemon.error] dns_rdata_fromtext: 192.168.100.rev:15: near '100_254.hogehoge.co.jp.': bad name (check-names)
Aug  6 23:26:40 dns named[5248]: [ID 873579 daemon.error] zone 100.168.192.in-addr.arpa/IN: loading from master file 192.168.2.rev failed: bad name (check-names)
こんなログが吐かれていました。

・・・で調べたのですが、エイジの気まぐれ日記　BINDで名前解決ができないに同じ話がありました。

BIND9.3.1以降はRFC952に書かれている通りというか、ホスト名に「_」（アンダーバー）が使えない・・・がデフォルトになっているようです。
named.confのzoneの定義部分に
check-names ignore;
と書いて、チェックを緩くするといいらしい・・・。



bindのバージョンアップ

CERT VU#800113 DNS Cache Poisoning Issueの件があったので、BINDのバージョンアップを行った。（検証とか、評価とか・・・もろもろの意味合いを含む）

まぁ、普通にインストールして
$ ./configure --prefix=/usr/local --enable-threads --enable-largefile
$ make
# make install

起動したら・・・syslog（messages）にこんなん吐く。
named[9811]: [ID 873579 daemon.error] /usr/local/etc/named.conf:20: unknown key 'rndc-key'
rndc-key知らないって・・・どういう事？まさかバージョンアップでまた仕様変更あった？
一瞬恐ろしくなったけど、結局named.confに一行追加して動くようになった。
include "/usr/local/etc/rndc.key";

で、ログに気になるWarningが・・・
named[10086]: [ID 873579 daemon.warning] checkhints: view internal: L.ROOT-SERVERS.NET/A (199.7.83.42) missing from hints
named[10086]: [ID 873579 daemon.warning] checkhints: view internal: L.ROOT-SERVERS.NET/A (198.32.64.12) extra record in hints
何？ルートサーバどした？と思ったら、きっちりアナウンス(速報) L.root-servers.net の IP アドレス変更についてが出てました。

 2007 年 10 月 24 日(米国西部時間)、ルートネームサーバの一つである
 L.root-servers.net の IP アドレスが 2007 年 11 月 1 日に変更されるこ
 とが、ICANN から発表されました。

  Advisory - "L Root" changing IP address on 1st November
  October 24th, 2007 by Kim Davies
  http://blog.icann.org/?p=227

 L.root-servers.net の新しい IP アドレスは 199.7.83.42 となります。現
 在既に新しい IP アドレスは運用可能な状態となっており、11 月 1 日のルー
 トゾーンにおける変更作業をもって、正式運用が開始されることになります。

 発表では、現在の IP アドレス 198.32.64.12 は今後少なくとも 6 ヶ月間に
 渡り引き続き参照可能とするとのことですが、移行完了後、最終的にはサー
 ビスを終了する予定であるため、11 月 1 日のルートゾーンにおける情報変
 更後に各 DNS キャッシュサーバのルートヒントファイルを更新する等の、適
 切な対応が必要になります。

 新しいルートヒントファイルは 11 月 1 日の正式運用開始後に、以下のURL 
 から入手できます。

   - ftp://rs.internic.net/domain/db.cache
   - ftp://rs.internic.net/domain/named.cache
   - ftp://rs.internic.net/domain/named.root
   - ftp://ftp.internic.net/domain/db.cache
   - ftp://ftp.internic.net/domain/named.cache
   - ftp://ftp.internic.net/domain/named.root

 なお、JPRS では引き続き本 Web を通じて本件に関する情報提供を行う予定です。

ついでにインストール先とかも変更したので、色々シンボリックリンク張り直したり、旧バージョンのファイルを消したり、そんなもん。
案外あっさりいったほうかな。

どっちかというと、うちのサーバが遅いのでコンパイル（make）に掛かった時間の方が長かった(^^;






# さて、この作業ボリュームをベースに工程表考えるか(^^;

■複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

■複数のDNSソフトウェアにおけるキャッシュポイズニングの脆弱性について

お。
久々来ました。

▼概要

複数のDNSソフトウェアにおいて、キャッシュポイズニングが成立する脆弱性
があり、各ソフトウェアベンダより対応するためのパッチがリリースされま
した。本脆弱性は危険度が高いため、該当するソフトウェアを利用している
ユーザは、関連情報の収集と適切な対応を取ることを推奨します。

なお、後述の通り本脆弱性はDNSプロトコル上の特性に起因するものであり、
パッチの適用により、キャッシュポイズニングが成立する確率を低くするも
のです。

▼詳細

本脆弱性は、DNSクエリのIDが16ビットしかないプロトコル上の制限に加え、
DNSソフトウェアがキャッシュサーバとして動作する際、問い合わせを送信す
る際のソースポートを固定している場合、キャッシュポイズニングが成立す
る確率が高くなる問題です。特に TTL が短いレコードが攻撃対象となった場
合、この脆弱性に対するリスクが増大します。

本脆弱性の詳細については、US-CERTからの脆弱性情報(*1) およびJANOG19
におけるJPRS発表資料(*2)をご参照ください。

(*1) US-CERT
Vulnerability Note VU#800113
Multiple DNS implementations vulnerable to cache poisoning
http://www.kb.cert.org/vuls/id/800113

(*2) JANOG19 JPRS 民田発表資料
これでいいのかTTL - 短いDNS TTLのリスクを考える
http://www.janog.gr.jp/meeting/janog19/files/DNS_Minda.pdf
・・・でも根本的には解決できなさそう。。。

複数の DNS 実装にキャッシュポイズニングの脆弱性
こちらでは緊急扱いになってますね。


でも、バージョンアップを気にするより、Allow-Queryやrecursionの設定をキッチリ見直した方が良さそうです。
根本的にOpenDNSになってなければ影響は受けにくくなるので。

今更だけどbind9

bind4の頃は平和じゃったのう・・・。という話は置いておいて

動的更新をサポートする以前のbind8までは
DNS設定変更→namedを再起動（killして、再起動）という手順が一般的でしたけど、
現在はrndcコマンドを利用するのが一般的です。

経験則になりますが、named.confを編集した後に誤動作するケースや、キャッシュが悪さをしていると推測される場合には再起動で復帰する確率よりもrndcコマンドで設定を読み返した方が、上手く動作します。

具体的には何も考えずに
rndc reconfig
rndc reload
rndc flush
を実行するほうが、上手くいくケースが多いです。
意味としては「コンフィグの読み返し→全てのゾーンファイルの読み返し→BINDキャッシュの削除」です。

但し要注意なのはbindのキャッシュはrndc flushを実行すると消えてしまうので、そこはケースバイケースで対応するのが良いかと思います。
とはいえ、rndc flushを実行して問題になるのは
  1. 超大規模のネットワークのbindである
  2. bindの構築（特にforwardとルート参照の関係）に問題がある
というケースしか思い当たりません。

理想論ではありますが、超大規模のネットワークであれば、DNSキャッシュサーバと（named.confの変更を必要とするような）ゾーンファイルを持たせるサーバは分離して配置すべきですから、1はあり得ない事になります。
従って、圧倒的に多いのは2となりますが、具体的にはFirewall等によってルートサーバへの参照が許可されていない状態であるにもかかわらず、optionsステートメントでforward onlyが指定されていないなどにより、不正なルートサーバへの参照が発生しているケースがほとんどです。
BINDの停止が致命的となるネットワーク（停止を許されない場合）に於いては特に注意を要します。

あまり超大規模のDNSサーバを取り扱った事はありませんので、（所詮8000クライアント程度・・・ISPとかでお仕事されている方から見るとゴミのような規模でしょう・・・1分くらいの停止なら許容されますし・・・）参考にはならないかも知れませんが・・・。

BIND8 開発終了

BIND 8 開発終了のアナウンスが。

思えば、BIND4からBIND8に移行した時は「判りやすいnamed.bootからC言語風なnamed.conf」になって、なんやねん。この複雑な書式は！！とか思ったものですが。
今となってはnamed.bootの書き方すら思い出せませんorz

セキュリティの概念すら無かった時代の産物ですが、[参考]旧形式のブートファイル /etc/named.bootの例を見ると、懐かしくて目からしょっぱいお水がｗｗｗｗｗ。

BIND9が出たときも、当初あまりにパフォーマンスが低下したせいで、色々と言われましたが今となってはBIND9で普通じゃね？という感覚もありますよね。

本当、この世界って日進月歩ですが、djbdnsって一部に熱狂的な信者が居る反面、PostfixのようにSendmailの寝首をかいてやるぜ！！的な伸びもありませんね。


副作用として、
"DNS & BIND"を手ばなせない
激しく同意しときますが。


ま、BIND8 Thank You And Goodnight！！って事で。