今更だけど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分くらいの停止なら許容されますし・・・）参考にはならないかも知れませんが・・・。