タグ「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;
と書いて、チェックを緩くするといいらしい・・・。