DNSデータ更新伝播遅延

基盤:delegate9.org 引越し後のサーバの動作も問題無いようですので、delegate.org もこのアマゾンLightsailに向けたいと思います。

開発:完全移転しましょう。アデュー Azure。

基盤:それで、delegate.org は NSO の DNS サーバにあるのですが、大変こざっぱりとしたUIになっています。もちろん、コピペもできるので設定も簡単。ただちょっと困るのが、TTLが7200秒になっていることです。

基盤:この点、XSOはTTL 300秒がデフォなので、まあいかにもらしい感じはします。実際、昨日のdelegate9.orgの変更でも、数分内に各所観測地点に反映されたことを確認しました。

開発:今回の更新には仕方ないですが、次回以降のために短くして置きたいですね。

基盤:ところが、TTLを短くしようとすると、3600秒以上にしろと怒られてしまいました。

開発:そのへんは社会に対して誠実と言うべきか、事なかれ主義というか、頑迷というべきか、ただの時代錯誤というべきか、ですね。今のHTTPの世界を考えれば、DNS程度データのTTLなんてデフォルト10秒で楽勝にも思うのですが。

基盤:ライブドアの1円株式を思い出します。

開発:まあDNSのTTLって、データ転送の負荷を減らすためなのか、名前世界の安定を求めるためなのか、イマイチ位置づけがわからないんですが。

社長:これって、HTTPのリクエストと同じように「キャッシュを使わない」でリロードするオプションがあればいいのにと25年前から思っているのですが。

開発:データアップロードのメカニズムを別にすれば、ダウンロード側には特殊なメカニズムは要らないはずですね。というか、途中の配達経路はHTTPにして、サーバエンドとクライアントのエンドだけDNSのプロトコルにするというのでも良いかもしれません。

基盤:ただ今回観察して気づいたのですが、dig で見ているとTTLがビシバシ不思議な値に変化するんです。10秒間隔でdigした結果がこれです。

基盤:これはどういう意味なのかなと思ったのですが、どうも中間のレゾルバが設定している値のように思われます。あるいは dig 自身のキャッシュかも知れませんが。

AWS$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
nameserver 172.26.0.2
search ap-northeast-1.compute.internal

開発:しかしなかなか更新後のほうに落ち着きませんね。

社長:これって、オリジナルのタイムスタンプを見れば、古いデータを復活させることは無いと思うんですが、DNSってそうなって無いんでしたっけね?

基盤:ネームサーバが多重化されていることの副作用かとは思いますが。そもそもの発信地である2つのDNSサーバがちゃんと同期していたのかとか。確認していませんが。

基盤:例えば、ns58.worldnic.com を直接サーバ指名して dig を続けた結果がこんな有様なんです。

開発:あー、これはもう末期的ですね。やはり自社のDNSサーバをメインにしましょう。この人達は最後の最後のリザーブで結構。

社長:いやあ、自分とこでDNSサーバを維持し続けるよりは安心できていいかなって、移行したんですが。当時、NSOがベリサインに買われた頃でしたが、すごいプッシュにも負けて。

基盤:一方我社MacMiniですが、こういうところから始まりまして、

基盤:ただいまこういう状況です。

開発:あと10分待つのだぞってところですね。でも、一瞬値が古くなってるのはなんでしょうね?これも冗長DNSのせいかな。

社長:これ、DNSのキャッシュを強制的にサラにする方法無いんですかね。まあ、Mac とルータをリブートすればよいのでしょうけど。

基盤:と噂をしていたのが聞こえたのか、ついに我社にも新アドレスが到達しました。

開発:お約束どおりの7200秒てとことですね。

基盤:亡霊が最後のあがきをしているようではあります。

基盤:ついに亡霊が消えたかなと思ったら、もうひとつ亡霊が (^-^;

基盤:さすがにこれで名前の問題は解決ですかね。

開発:完全かつ不可逆的な感じですね。

基盤:delegate.org のほうも、まれに旧サーバに来ますが、ほぼ新サーバに切り替わりました。

社長:ではこの問題は集結ということで。さて、問題は iMac をどこにお迎えするかなのですが…

基盤:その件、現在の作業エリアを整理してからというのは色々大変ですので、この際に新しいエリアに引っ越すのが良いのでは、と思いました。

社長:うーん確かに。夏季作業用エリアを作るというのも手ですね…

-- 2020-0627 SatoxITS

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です