ISPのDNSのキャッシュ書き換え時間について

ＩＰアドレス変更に伴う、プロバイダのＤＮＳキャッシュ書き換えは、どれくらいの時
間がかかるのか？
インターネットを利用してサービスを提供する側にとっては、サーバ切替やドメインの
移動などの事態が発生した場合、頭を悩ますことのひとつではないでしょうか？
私の会社では先日、複数存在したＩＤＣの移設統合を行いました。
この時利用顧客に割り当てたドメイン名に対するＩＰアドレスの変更が発生しましたが
、インターネット上の各プロバイダーのＤＮＳへの新ＩＰアドレス反映の時間は、主要
なプロバイダで平均２日〜３日以内であると予測して移行計画を立てました。
しかしこれには具体的な根拠が無く、インターネット上の掲示板などを調査した結果か
ら、一般的にＤＮＳのキャッシュの保持時間が、多くの場合86400秒（１日）に設定されている場合が多いということで、早いプロバイダでは４８時間以内、遅くとも７２時間
以内には９０％以上のプロバイダのＤＮＳは更新されるものと予測しました。
しかしこの時間は保障できるものではないため、ＩＤＣ利用者にはにＤＮＳ反映が遅れ
る可能性を伝え、事前了解を得て作業を実施しています。（これはＤＮＳ反映まで一時
的に接続できなくなる状況を考慮して、利用者に対しては当然行っておくべきことです
。）
ＤＮＳを新ＩＰアドレスに切替後から、主要なプロバイダー数社へのＤＮＳ反映状況を
モニターした結果を参考までに掲載します。ただしこれは我々の環境における実測結果
であり、利用環境により変化することは言うまでもありません。またある特定のドメイ
ン名でのモニター結果であり、同じプロバイダでもドメインによって反映経過時間が最
大５日間も異なる結果が出ています。従ってあくまで目安の時間としてご覧ください。

プロバイダ 種別 ＤＮＳ反映経過時間
大手プロバイダＡ社 第１種 10
大手プロバイダＢ社 第２種 10
中堅プロバイダＣ社 第２種 10
大手プロバイダＤ社 第２種 42
中堅プロバイダＥ社 第２種 42
中堅プロバイダＦ社 第２種 42
大手プロバイダＧ社 第２種 42
大手プロバイダＨ社 第２種 42
中堅プロバイダＩ社 第２種 42
大手プロバイダＪ社 第２種 42
中堅プロバイダＫ社 第２種 72
地方プロバイダＬ社 第２種のＯＥＭ 120
地方プロバイダＭ社 第２種のＯＥＭ 132
地方プロバイダＮ社 第２種のＯＥＭ 144

※ある特定のドメイン名の反映経過時間を示します。
※反映経過時間の単位は「時間」です。
※反映経過時間はあくまで目安としてご覧ください。
※環境や状況により各プロバイダの反映経過時間は変わります。
従って各プロバイダのサービスの評価では、決してありません。

>>1
TTLという言葉を知ってるかい？
TTLを10〜20分にしておけば、普通はあっという間に変わるよ

そもそも計画ミス

>>2
禿同。
こういう作業の前にはTTLを一時的にでも短くしておくのが
一般的じゃないか？(漏れはいつも忘れるが)

>>2-3に激しく同意。
こんな人に作業された顧客がかわいそう。
TTLを事前に短くして、短いTTLに切り替わった後、実際に切り替える
のが常識。

禿同なんだけど、でも、某プロバイダのDNSサーバが腐ってるのか、
TTLを無視してキャッシュしてる様で、しかも、たまたま得意の
担当者がそのプロバイダを使ってて、切り替わってないぞって
文句言われて困ったことがあたよ。

>5

そうそう、たまにそういうことがある。


ちなみに、IPヘッダのTTLが短すぎて問題起きた問題の例http://www.ocn.ad.jp/abuse/20001001b.html

>>1
商用サービスでないことを祈る
うちの会社でそんなことやったら、作業責任者は始末書程度じゃすまんぞ
作業ミスじゃなく計画段階のミスだからな

>>6
お前DQNか？
その例はaolのDNSサーバのパケットのTTLが小さかったって事だろ。
全然関係ない。

このスレの話題はDNSのリソースレコードの生存期間のことだ。

うちはそーいう作業するときは前もってTTLを5分とかにしておくよ。
お約束だね。

DNSラウンドロビンで複数台構成にしてるサーバを一台引っこ抜いて
ハード交換なんて時にも使える。
（シビアなサービスならその前段にロードバランサー入れてるけど）

DNSラウンドロビン使ってるとこってまだあるのか、、、
バランサ高いもんな、変な動作もするし

>8

それぐらい知ってますよ。だから「ちなみに」とか「IPパケットの」
って書いてあるでしょ。

1はここまで叩かれるとは思ってなかっただろうな。

なんかコメントしてよ>>1

refreshはいじらなくて良いのでしょうか？
うちの場合、ttl 900 にしたとき、
refresh も 300 とかにしてるんですが。。。

>>13
最近のBINDはマスタがスレーブにゾーンの更新を
通知(notify)するので、ネームサーバをすべてBINDで
構成している場合はrefreshの値にかかわらず
ほとんど直ちにスレーブが更新されるはず。

でも、DNS notifyのパケットが途中で落ちたらどうするんだろう。
あきらめてrefresh時間経つまで待ちなさい、なのかな。

>>9

そうか〜、そうなんだよなー、サーバー動かすときはTTLを前もって短くするんだー
長年この世界に携わってきたが、こういう場合にどう対処するか思いつかなかった世。
自分の浅はかさをつくづく感じるね・・・

>>13
14の言う通りなんだけど、セカンダリをプロバイダ等に
お願いしてる様な場合、そのネームサーバが、notify
を受け付けない設定になってたり、あるいはそもそも
notifyを解さない古いネームサーバをとかを使ってたり
して、効かない時もあるので、そう言う場合にはrefresh
も小さくすべきと思われ。事前にセカンダリ側がどう言う
反応をするのか、テストしたほうが良いと思われ。
昨日は某プロバイダのネームサーバが腐ってて、ゾーン情報
がセカンダリに転送されなくて困ったよ（直してくれたけど）。

>>14 さん
>>16 さん

経験事例まで教えてくれて、ありがとうございます。
今まで効果のほどをテストするまでにはいかなくて、
ただ漠然と設定していましたが、refreshについて
理解できたような気がします。早速digを使って
いろいろ試してみます。

>>13,>>14
セカンダリが内部ならリロードすればいいだけ
notifyは信用したらアカン

セカンダリが外部だったら、
"namedリロードしろｺﾞﾗｱ"
とISPにゴリおす

ISP へのごり押しって、どの程度まで有効なんでしょう？
refresh いじっておくのが無難な気がしますが。

>>19
冗談だったんだけど、、、
でも、企業向けのサービスならある程度は利くかも

まあ、要請する分にはタダだから

ネタだったんですね・・・。

とりあえず引けるし、捨ててくれてるみたいなのですが、
（対slaveはともかく）これってやっていいことなんでしょうか。

% host -t SOA foo.com
foo.com start of authority ns1.foo.com postmaster.ns1.foo.com(
2001120503 ;serial (version)
1 ;refresh period
1 ;retry refresh this often
1 ;expiration period
1 ;minimum TTL
)

>>22
いい遊びだね
TTLの方は大規模サイトでなければこれでも問題ないよ
問題はexpire-timeだろうな
セカンダリは何台あるの？

こいつの上位のスイッチでトラフィックでも計ってたら、
どれくらい変わったかをレポートしてくれ
ちょっと興味ある

便乗して質問させてください。

自ドメインのDNSサーバA,Bを上位のDNSサーバCに
ＮＳレコードで複数書いた場合、他DNS Ｄから
A,Bにはどのように問い合わせが割り振られるのでしょうか。

�@Ａ，Ｂにラウンドロビンする。
�A通常Ａに問い合わせる。キャッシュが消えればまた取り直してAに投げる。
�B通常Ａに問い合わせる。キャッシュが消えれば今度はBへと変則ラウンドロビン。
�CそんなのＤのＤＮＳのモノ次第だからわからん。

個人的には�Aか�Cかと思うのですが・・・
付け焼刃知識での質問なので意味不明な記述があればご容赦下さい。

>>24
問い合わせ側の実装依存。
複数のNSどう使うかは使う側の勝手。

確か、NSレコードを問い合わせたサーバは、全てをいったんキャッシュして、
キャッシュがある間は、そのキャッシュにあるサーバに対してラウンドロビンするって感じだったと思う

DNSは外部から見た場合はプライマリ、セカンダリという区別は無い

>25-26
その後調べてみたんですけどラウンドロビンが一般的？みたいですね。
でも実装依存てのも当然あるでしょうし、
一般的っていってもどのくらい一般的なのやら・・・
レスありがとうございました。

ドコモのDNSってなんかへんじゃない？

school2.2ch.net
food3.2ch.net
最近ドメイン追加したようですが、
ゾーンの更新がうまく行ってないようです。

2chの動作報告はここで。−32−
http://qb.2ch.net/test/read.cgi/accuse/1039618461/l50
food3につながらない！
http://qb.2ch.net/test/read.cgi/accuse/1040523178/l50

（＾＾）

>>20
最近の実感として、意外とごり押しもきくものだなぁと。

最近、六本木界隈をうろついていまつ。

ネタすれあげてすいません。

あぼーん

＜血液型Ｂ型の一般的な特徴＞（代表例：世直し一揆、小さな器、プチ人間）
●とにかく高慢でやることが陰険。自分勝手で了見が狭い(わがまま、自己中で人間性に欠けている。自分のペースを乱されると激しく反発する。）
●自分に出来ないことを他人に強要、判らないことは他人に丸投げする場合が多い、自分に甘く他人には厳しい。自分の発言に責任を持たない、正しい状況判断ができないので質問されてもピンボケした答えしか返ってこない場合が多い。
●他人の成果を自分のものにするのが上手。やり口が汚い。責任転嫁が多い。反省ができないので成長も無い。自分を正しく見つめることができないから、他人も正しく見れない。
●世界の中心は自分、周りの人間をゴミとしか思っていないので友達が居ない。居ても心のどこかでその友達をも馬鹿にしている場合が多い。
●本当は自分が一番嫌われているのに、全然気がつかない。周りが迷惑していることにいつまでたっても気がつかない。人を傷つけても、傷つけていることすら気がつかない。
●世界でも職場でも戦争を起こすのはいつもＢ型である。紛争が多い地域はＢ型人口が多い。http://www.abo-world.co.jp/databank/worldmap.html
●Ｂ型の多い職場はギクシャクして争いがたえない。排他的な人種が多い。人を上手に使うことを自分の配下、奴隷にすることだと勘違いしている場合が多い。
●人を信じているように見せかけておいて、実は裏で保険をかけている場合が多い。腹黒い。真っ黒。前世は犯罪者。常に誰かを虐めてないと気が済まない。
●自分が一番差別主義者なくせに、それを見透かされるのを極度に嫌う。偽善者、エゴイスト、ナルシストが多い。自分さえ良ければ他人がどうなってもいいと思っているヤシが多い。
●自分勝手な筋道を他人に強要すためなら何でもする。他人を蹴落としてでも正当化する。Ｂ型にあんまり偉いヤシいない。いても粗末な暴君でしかない。周りの人間を駄目にする輩が多い。
●学問的な裏付けの無い理論武装を展開する。本人は理論展開しているつもりでも自己完結して終わる場合が多い。Ｂ型のプレゼンは自己中でよくわからない、突飛な発言が多く誰もついていけない。思いこみが激しいので答えが狭い範囲にしか求められない。

あぼーん

あぼーん

（＾＾）

あぼーん

あぼーん

ＢＢ＠にふはどうも１日一回しかＤＮＳ情報を掃除してくれていないような... あくまで経験値。

>>31

>>39
AレコードのTTLが切れた場合に、普通は root DNS への問い合わせから
始めて、delegationされているネームサーバを見つける為に、glueを
辿ると思うんですがＢＢ@にふは、一度ネームサーバを見つけると
delegationを無視して動いている気がしまふ。

{www.ftp}.t.ring.gr.jp を観に行くと RingServer でネットワーク的に近いサーバに誘導されるんだが、
$ dnsqr a www.t.ring.gr.jp
1 www.t.ring.gr.jp:
50 bytes, 1+1+0+0 records, response, noerror
query: 1 www.t.ring.gr.jp
answer: www.t.ring.gr.jp 2 A 210.158.0.14

TTL が 2 秒になってるから、やはり DNS で動的に誘導してるんだな
Akamai も 20 秒で似たような仕組みか

age

DNSに詳しい方に質問です。

一部プロバイダで10日以上DNSの設定が更新されないのですが、どうにかする方法はないでしょうか?

状況は、
10日以上前にレンタルサーバA社からレンタルサーバB社に移行しました。
8割位は新鯖にアクセスできるのですが、一部プロバイダは接続できないのです。

これは、何が原因と考えられるでしょうか?

ちなみにA社のDNS鯖のTTLは一日です。

あぼーん

あげ

独自ドメインのネームサーバを変更して3週間経つのですが、
YahooBBでだけ、更新が反映されていません。
なんらかの原因で、YahooBBだけ更新が失敗したのかと思うのですが、
こういうことは、現実にあり得るのでしょうか？

サーバのキャッシュは、一定の間隔で更新し続けていると思うので
３週間も反映されないことはないとおもうのですが・・・。

>>47
ドメインはhogehoge.comで良いから、何処がどう反映されないのか
具体的に書いて美奈代。
力技で乗り切る方法ぐらいは出てくるかもしれないぞ。

hogehoge.comをDDNS(miniDNS)を利用して、
自宅サーバ(YahooBB)で運営していたのですが
３週間前にレンタルサーバに移行し、そのときにネームサーバも
レンタルサーバのものに書き換えました。

３日ほどで、DNSの伝播が大体終わったようで、
友人のパソコン（別プロバイダ）やプロキシを利用すると
アクセスできるようになりました。しかし、YahooBBからは
現在でもminiDNSにアクセスしてしまいます。

miniDNSで登録するIPアドレスを自宅サーバではなくレンタルサーバのものにして
何とか利用しているのですが、ずっとこれを続けるわけにもいかないので
どうにかして、YahooBBでも他のプロバイダのように
普通にレンタルサーバへアクセスできるようにしたいです。

解決策が分かる方、教えていただけないでしょうか？

>>49
問題のやふーBBのDNSキャッシュに残っている自分のドメインのttl確認してみたら？

>>50
YahooBBから、hogehoge.comにpingを打つと、TTLが52と出ました。

何がダメなのか、想像もつかない状況です･･･。
原因が分かる方がいらっしゃれば、よろしくお願いします。

あぼーん

>>51
Pingで出てくるTTLじゃないよ....
nslookupでデバッグモードにした状態で（プロンプトでset debugと入力)
自分のホストのipを解決させたときに表示されるttlを見ろ。

って書いてわかってくれるかなあ？

大人の男だけ

QUESTIONS:
hogehoge.com, type = A, class = IN
ANSWERS:
-> hogehoge.com
internet address = 210.138.142.2
ttl = 464 (7 mins 44 secs)
AUTHORITY RECORDS:
-> hogehoge.com
nameserver = ns1.minidns.net
ttl = 86264 (23 hours 57 mins 44 secs)
-> hogehoge.com
nameserver = ns2.minidns.net
ttl = 86264 (23 hours 57 mins 44 secs)
ADDITIONAL RECORDS:
-> ns1.minidns.net
internet address = 202.64.51.214
ttl = 85609 (23 hours 46 mins 49 secs)

>>53
こんな風(>>55)に出ました。これで合ってるでしょうか？

>>47
すまん、最初に「server [yahooBBのdns］」と入力して（入力時に括弧 ［ と ］はいらない）
YhooBBのDNSに切り替えてくれ。
minidnsのDNSはちゃんとTTLが７分４４秒って出てる。

Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 3, additional = 3

QUESTIONS:
dns01.bbtec.net, type = A, class = IN
ANSWERS:
-> dns01.bbtec.net
internet address = 43.224.255.1
ttl = 61936 (17 hours 12 mins 16 secs)
AUTHORITY RECORDS:
-> bbtec.net
nameserver = dns04.bbtec.net
ttl = 86400 (1 day)
-> bbtec.net
nameserver = dns06.bbtec.net
ttl = 86400 (1 day)
-> bbtec.net
nameserver = dns03.bbtec.net
ttl = 86400 (1 day)
ADDITIONAL RECORDS:
-> dns03.bbtec.net
internet address = 43.224.255.3
ttl = 86400 (1 day)
-> dns04.bbtec.net
internet address = 43.224.255.4
ttl = 86400 (1 day)
-> dns06.bbtec.net
internet address = 43.231.251.96
ttl = 86400 (1 day)

これでいいでしょうか？何度もすみません・・・。