更新間隔と非更新間隔
さきほどの項でも触れたが、DNSレコードの「更新」リクエストのソースは複数あるが、更新されるかどうかはDNSサーバの判断によることになる。その判断基準のお話。
これから述べるDNSレコードの清掃の基本的なパラメータは２つで、「非更新間隔」と「更新間隔」である。
非更新はともかくこの「更新間隔」というのも日本語として適切さを欠いており、理解の妨げになっている感がある。あえて言えば「更新許可間隔」ぐらいの意味と言えばよいだろうか。さらに言えば、それぞれの間隔の説明も非常に分かりにくい。
Technet Library の後半に実例が出ているが、もう少し具体的に例示してみることにする。
以下は、2/1 0:00 にWindowsPCがDHCPでアドレスを取得したケースを考えている。このPCは以後、2/18まで月曜から金曜までずっと付けっぱなしと仮定している。クライアントDDNSもDHCP-DDNSもともに有効だと仮定し、DHCPスコープのリース期限はデフォルトの8日、清掃パラメータはデフォルトの非更新＝7日、更新＝7日で、と仮定している。
DHCPクライアントサービスはクライアント-DDNS、DHCPサーバサービスはDHCP-DDNSである。
2/1に端末が起動しDHCPでアドレスを取得する。この時にクライアント-DDNS、DHCP-DDNSともにDNS更新に成功（○）としているが、実際には早い方だけが成功するはずである。
クライアントDDNSは1日1回、DHCPサーバサービスはリース期間の半分で更新リクエストを送信する。が、最初にDDNS登録されてから以後7日間は非更新なので、更新リクエストが来ても無視（×）される。
この例では非更新が解けてから最初に更新に成功するのは2/8のクライアント-DDNSリクエストである。そうするとここから再び7日間は非更新に設定される。
次に更新が行われたのは16日であり、18日にネットワークから外されたという状況である。DHCPサーバは18日に外されたことを知る由がないので、リース期間の半分で更新を試みるが非更新期間なので無視（×）される。これが最後の更新の試みになっている。
23日に非更新が解けて、7日間は更新が許可される期間となり、それが終わる3/1以後は清掃が実行されれば消去される状態になる。ただし更新期間を過ぎても清掃前に更新リクエストが来れば、再びそこから7日間の非更新期間に入る。いわばグレーゾーン期間である。
では、たとえばDHCPスコープが３日間で非更新を1時間に設定するとどうなるか見てみる。
DHCPクライアントサービスが1日おきに更新リクエストを発行するが、ほぼこれが実際にDDNS更新処理が行われる。
ここではPCの上げ下ろしのことは考慮していないが、通常PCが起動するとクライアント‐DDNSの更新が実行されるが、1時間以内に再起動した場合以外はDDNSの更新が行われることになり、さらに負荷が高くなることがお分かりいただけると思う。
更新を受けたレコードは他のドメインコントローラへレプリカされることになるため、結局DNSレプリケーションスコープ（ドメイン全体とかフォレスト全体とか指定した範囲)で負荷が上がることが想像できる。
負荷が上がって正常に「更新」処理ができなくなると、タイムスタンプ値が古いまま残ってしまい、運悪く「更新期間」中に一度も「更新」処理がされないまま清掃が実行されるとレコードが消えてしまう可能性はある。特にクライアントDDNSを使えないNASやプリンタは「更新」機会がDHCPリース期間の半分で、クライアントDDNSの「最悪でも1日1回」より少ないため、このような現象が顕著に発生すると思われる。
もう１つ重要な注意は、DHCP-DDNSを利用する場合、「非更新期間と更新期間の合計は、DHCPリースの最長の期間の半分より短くしてはいけない」。
これまでの説明でお分かりいただけると思うが、クライアントDDNSが利用できない機器の場合、DHCPサーバサービスから更新要求が来る前に清掃対象（グレーゾーン）に入ってしまい、DNSレコードが消えてしまう危険性が出てくるからである。できればもう少し余裕を持って設定する方がよい。