さくらのオープンリゾルバが2013/09/05に停止とのこと。

何年も前から問題視されていて、JPRSからも4月にリリースされているオープンリゾルバの危険性（ http://jprs.jp/important/2013/130418.html ）に関連してです。

[note]
この資料もわかりやすいと思います。

オープンリゾルバーを用いたDNSリフレクター攻撃の概要と対策
～知らない間にあなたも加害者に～ http://iot.ipsj.or.jp/files/iot22-invited_talk
[/note]

※DNSについて。 http://wp.kaz.bz/tech/etc/dns-1#i-6 でもちょこっと触れています。

さくらが運用しているオープンリゾルバを停止するとのリリースがありました。

http://www.sakura.ad.jp/news/sakurainfo/newsentry.php?id=776

やっと、という感じがしますが、この調子でまっとうな運用のDNSキャッシュサーバが増えて、Google Public DNSも終了するといいなあ、という思いです。

が、共用DNSは残っています

詳しくは以下。
JPRS サービス運用上の問題に起因するドメイン名ハイジャックの危険性についてhttp://jprs.jp/tech/security/2012-06-22-shared-authoritative-dns-server.html

前野さんのWiki
https://moin.qmail.jp/DNS/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9#DNS_.2BMOwwszD8MMkw.2BzC1MPww0DBua2NfU2AnMG54uoqN-
https://moin.qmail.jp/DNS/脅威/共用ゾーンサービス/さくら

自分で調査したわけではないですが、これらの情報を見る限り危険な状態だと思います。

[warning]
共用権威DNSと共用キャッシュサーバが1台で提供されている組み合わせ（特にBINDで）は最悪です。

BINDは権威サーバでありつつキャッシュサーバとしても動作します。
自分の管理下にあるゾーンに対する問い合わせについては権威サーバ、管理外のゾーンについてはキャッシュサーバとして振る舞います。
が、名前解決の範囲で、クライアント側にとっては「問い合わせに対して答える」ことには変わりません。
その状態で例えば「google.com」ゾーンを作られてしまったとしたら、そのキャッシュサーバを利用している端末は全て偽の google.com に接続されることになります。
[/warning]

（本音）権威DNSサーバくらい、自前で運用しましょうよ。

だからと言って BIND を使うのはおすすめしませんが。

権威DNSには tinydns/axfrdns と NSD、キャッシュサーバには unbound を個人的には利用しています。
特に tinydns は、自分が何をやっているのかの理解にとても役に立つと思います。

CentOSの場合、tinydnsはソースインストール、NSD・unboundはEPELなどのリポジトリにパッケージがあるのでyumを利用してインストール可能です。