## page was renamed from DNS/基礎知識/TTL
## page was renamed from DNS/用語/TTL
## page was renamed from DNS/TTL
DNS/TTLについて、ここに記述してください。

<<Navigation(children,1)>>

<<TableOfContents()>>

http://www.zytrax.com/books/dns/apa/ttl.html
   Time-to-Live (TTL) Values:  The $TTL directive is defined in RFC 2308.

== TTL とは ==
time to live (賞味期間） のこと。 
 DNS問い合わせの返事には有効期限があり、返事の各レコードは受け取ってからTTL(秒）時間たったら、無効であると宣言するもの。

Improving DNS Service Availability by Using Long TTL Values
  http://tools.ietf.org/html/draft-pappas-dnsop-long-ttl-04


DNS設定側からみると、変更を行っても、TTL時間内は古い内容をもつクライアントが残っている期間といえる。

このTTLが存在するため、NSレコード関連の変更には注意が必要である。
　すなわち、古いDNSサーバに問い合わせる可能性のある期間がTTLであり、
　この”古いDNS(コンテンツ）サーバ”に”古い設定が残ったまま”だと、サーバは古い設定を返事することになる。
　その結果、いつまでも、新しい設定を受け取ることができないクライアントが発生するのである。

== NSレコードのTTL ==
NSレコードと付随するAレコードのTTLは十分長くしてください。
　短いと上位サーバに頻繁に問い合わせが送られることになり、上位サーバの負荷を増やします。

昔は１週間くらいに設定されていたようだし、今でも一週間くらいが妥当だと思うが、
現実には１日か２日くらいのところが多い。(.com, .jp など）
    最近はNSレコードの重要性を理解していないのか、短く(1時間)設定しているところが多い。
       ひどいのは120秒というのもある。

したがって、手元でTTLを短くすることの効果を期待するのは間違いだ。
　DNS移転のときにTTLを縮めよという記述があるのは古い情報を引き継いでいるだけのような気がする。
　　そういう記述は理解不足かと疑ってかかるのがよい。


=== TTL調査 ===
JPに登録されているドメインのうち約１０万ドメインについて調査しました。
　JPサーバからの返事ではNSレコードのTTLは1日になっています。
　* 1時間以下のドメインが約3万８０００
　* うち、１時間に設定されたドメインが約2万２０００
　*  同、 30分に設定されたドメインは約１０００
　*  残りは 30分未満（20, 15, 10. 5 など）
　*  1 分のドメインが 620 もありました。

ドメインの使用頻度が分かりませんので、JPサーバにどれくらいの負荷になっているかは不明です。
{{{
アクセスの多いドメインはNS(+A)レコードのTTLを長くしていただくよう、お願いいたします。
}}}

[[DNS/短かすぎるTTL]] [[/10分以下]]

== 設定 ==
djbdns 内の[[/tinydns-dataでのdefault]]  [[/BINDでの設定]]

== SOAレコード ==
[[/negative-caching]] 関係