!!!DNSの反映時間の例外
DNS関連の変更がネット全体に行き渡るまでの時間は、最大48時間とか72時間と説明されることが多いが、これには例外がある。当該ドメインを最終的に管轄する''DNSサーバ自体が応答しない状態から回復する場合''だ。

先日、猫科研究所の入っているサーバにて長時間（4日程度）の停止があった。そのときに某掲示板を見ていて知った情報を元に調査したメモ。

!!名前解決失敗の原因とBINDの動作
あるドメインのDNSが引けなかった場合に、その原因には、当該ドメイン（ゾーン）を最終的に管轄するDNSサーバが…
+応答を返したがその内容が「該当なし」の場合
+ダウンしているなどで''DNSサーバ自体が「応答なし」の場合''
が考えられる。

この時、DNSサーバによく使用されるBINDの8/9ではそれぞれのケースに対して以下のように動作する、らしい。
+「該当なし」→該当なしのキャッシュ（''ネガティブキャッシュ''）を保持する
+「応答なし」→'''何もキャッシュしない'''
後者のケースがキャッシュしないために例外ケースとなる。

!!実際の動作例を考える
up-cat.netの場合、
*上位である.netの管理サーバへのup-cat.netの登録ミス(Lame Delegation)
*up-cat.netを管轄するDNSサーバ自体のダウン
などにより「DNSサーバの応答なし」になった場合、クライアントマシンが直接問い合わせる先であるところのISPなどのDNSサーバ（キャッシュサーバ）には、''ネガティブキャッシュは残らない''。

このとき、クライアントマシンでup-cat.netの名前解決を行おうとすると、その問い合わせは毎回up-cat.netを管轄するDNSサーバまで到達しようとしている（が、できないでいる）。
結果としてup-cat.netのDNSサーバが回復すれば、''即座に回復する''はずだ。

このように、DNSサーバ自体がおかしい場合には、その回復は速やかに反映される。

!!例外の例外
クライアントマシンから見た場合、上記の例外に当てはまるにも関わらず、即座に反映しないように''見える''場合がある。これは名前解決の問い合わせの経路上に「応答なし」を「該当なし」と同様に''キャッシュしてしまうDNSサーバがある場合''に発生する。
具体例としては、
*家庭内において、BB回線＋ルータ＋DHCP等の標準的な構成で、ルータがDNSの一次問い合わせ先となっており、かつそのルータが「応答なし」をキャッシュする場合。
*ISP等のDNSサーバ（キャッシュサーバ）が「応答なし」をキャッシュする場合。（BIND8/9ではないなど？）
といったケースが考えられる。

このために筆者の家庭内LANではルータのDNSサーバ機能は使用していない。
ルータのDHCP機能設定で、ISP(@nifty)のDNSサーバのIPアドレスを直接配布するように設定している。
幸いにも@niftyのDNSサーバは「応答なしをキャッシュしない」ようで、助かっている。

注意：このような設定は名前解決のたびにISPまで問い合わせが行くため、無駄なトラフィック増加と応答速度低下に繋がる。''サーバを持たない一般の方には何の得もない''ので注意。また、家庭内のルータが「応答なし」をキャッシュしないのであればルータのDNSサーバ機能を使用していても問題はない。

参考：
http://jprs.jp/tech/notice/2003-05-20-dnsqc-lame-delegation.html