投稿日:2004年07月25日 作成鷹の巣

No.16852 外引き専用DNSでキャッシュ期間の変更は可能?



外引き専用DNSでキャッシュ期間の変更は可能?

No.16852 投稿時間:2004年07月25日(Sun) 21:29 投稿者名:yokoyama URL:

自宅サーバ内に外部ドメインをひく為だけのDNSを構築した場合、
キャッシュとして残しておける期間は自分では変更できますか?

それとも、
そのドメインに対して権限を持っているDNSサーバで設定されたTTLが、
相手先のDNSのキャッシュの期間を決定できる唯一の項目ですか?

もし、このような事が可能ならば設定方法は自分で調べてみます。
BIND・MS-DNSのどちらで構築するかをまだ決めていませんので・・・。

よろしくお願いします。


キャッシュ情報はメモリ上に保存されます。

No.16853 投稿時間:2004年07月25日(Sun) 22:14 投稿者名:stranger URL:

> 自宅サーバ内に外部ドメインをひく為だけのDNSを構築した場合、
> キャッシュとして残しておける期間は自分では変更できますか?
> > それとも、
> そのドメインに対して権限を持っているDNSサーバで設定されたTTLが、
> 相手先のDNSのキャッシュの期間を決定できる唯一の項目ですか?
> > もし、このような事が可能ならば設定方法は自分で調べてみます。
> BINS・MS-DNSのどちらで構築するかをまだ決めていませんので・・・。
> > よろしくお願いします。

bind9では
$TTL 604800 ;7days (;以降はコメント)
のように 自前のDNSのゾーンファイルにキャッシュの期間を設定できます
キャッシュ情報はメモリ上に保存されます
キャッシュの内容は 同時にインストールされるrndcコマンドでファイルに
出力できます
例は linuxで /var/namedディレクトリがbindのデータディレクトリの場合
# rndc dumpdb
# less /var/named/named_dump.db


訂正。

No.16859 投稿時間:2004年07月26日(Mon) 11:35 投稿者名:stranger URL:

> > 自宅サーバ内に外部ドメインをひく為だけのDNSを構築した場合、
> > キャッシュとして残しておける期間は自分では変更できますか?
> > > それとも、
> > そのドメインに対して権限を持っているDNSサーバで設定されたTTLが、
> > 相手先のDNSのキャッシュの期間を決定できる唯一の項目ですか?
> > > もし、このような事が可能ならば設定方法は自分で調べてみます。
> > BINS・MS-DNSのどちらで構築するかをまだ決めていませんので・・・。
> > > よろしくお願いします。

訂正
$TTL 604800 ;7days (;以降はコメント)
これは自分のzoneファイルのキャッシュ期間でした


目的がわからないと答えにくい質問です。

No.16856 投稿時間:2004年07月26日(Mon) 09:10 投稿者名:しも鴨 URL:

目的がわからないと答えにくい質問です。

単に sakaguch.com 203.212.55.105 のキャッシュを自分なりに決めたいなら
sakaguch.com のゾーンファイルを定義してください。

DDNSを除きキャッシュがあろうが無かろうが同じ値しか返さないのだから
意味が無いと思うのが一般人でして、何の為にそんな事をやるのか不思議。
キャッシュをクリアしたいならrestartして下さい。


粗雑な表現ですが、IEの履歴のような目的です。

No.16865 投稿時間:2004年07月26日(Mon) 15:08 投稿者名:yokoyama URL:

strangerさん、しも鴨さん、回答ありがとうございます。

当方の実現したい事は、ニュアンスとしてはIEの履歴のような機能です。
IEの履歴では、表示したWebサイトのURLをキャッシュとして残しておけ、
さらに残しておく期間も自分で決定できますが、
それと同じようにDNSでもひいたレコードをキャッシュしておく期間を、
自分で決定したいと思っています。

自宅内のDNSで外部のドメインをひいた際に残るキャッシュには、
相手先が設定したTTLがレコードに適用され、
期間が過ぎるとキャッシュが消えてしまうので、
それを消えないようにしたいのです。

消えないようにといっても恒久的に消さない訳ではなく、
10日ほどにキャッシュの期間を延ばしたいと思っています。

自分のDNSに溜まったキャッシュの期間を延ばすという機能は、
DNSには実装していないのでしょうか?

よろしくお願いします。


相手のTTLを変更することはできないと思います。

No.16868 投稿時間:2004年07月26日(Mon) 18:55 投稿者名:stranger URL:

> strangerさん、しも鴨さん、回答ありがとうございます。
> > 当方の実現したい事は、ニュアンスとしてはIEの履歴のような機能です。
> IEの履歴では、表示したWebサイトのURLをキャッシュとして残しておけ、
> さらに残しておく期間も自分で決定できますが、
> それと同じようにDNSでもひいたレコードをキャッシュしておく期間を、
> 自分で決定したいと思っています。
> > 自宅内のDNSで外部のドメインをひいた際に残るキャッシュには、
> 相手先が設定したTTLがレコードに適用され、
> 期間が過ぎるとキャッシュが消えてしまうので、
> それを消えないようにしたいのです。
> > 消えないようにといっても恒久的に消さない訳ではなく、
> 10日ほどにキャッシュの期間を延ばしたいと思っています。
> > 自分のDNSに溜まったキャッシュの期間を延ばすという機能は、
> DNSには実装していないのでしょうか?
> > よろしくお願いします。

bind9の場合
こちらから、相手のTTLを変更することはできないと思います
メモリ上のキャッシュデータをファイルに保存してbindの再起動後に
再利用することもできないようです
キャシュをクリーニングする間隔を変更することはできると思うけど?
cleaning-intervalオプション(デフォルトは60分?)
TTLの切れた古いデータを消去する間隔

bind cleaning-interval
等で検索してみて下さい

IEと違いキャッシュデータはメモリ上に蓄積されるので注意
メモリがキャッシュデータに喰いつぶされたらどうしようもないので
現状で問題なければ、変更しない


クリーニングをしなければTTLの切れた後もそのキャッシュは使えますか?

No.16889 投稿時間:2004年07月27日(Tue) 23:57 投稿者名:yokoyama URL:

strangerさん、ありがとうございます。

> IEと違いキャッシュデータはメモリ上に蓄積される
ハードディスク上には残らないのですね。

> キャシュをクリーニングする間隔を変更することはできると思うけど?
> TTLの切れた古いデータを消去する間隔
という事は、
自動・手動問わず、キャッシュのクリーニングさえしなければ、
TTLの切れた後もそのキャッシュを使い続けられるという意味ですか?

キャッシュのクリーニング機能とは関係なく、
TTLが切れるとキャッシュは個別且つ自動的に消えるのだと思い込んでいました。

キャッシュの自動クリーニングをする間隔を延ばし、
メモリ使用量とバランスの取れる日数に変更すれば、
相手のTTLを実質的に自分の希望する期間に変更できるという解釈で合っていますか?


古いキャッシュが何に有効なのか私には解からない。

No.16894 投稿時間:2004年07月28日(Wed) 05:44 投稿者名:stranger URL:

> strangerさん、ありがとうございます。
> > > IEと違いキャッシュデータはメモリ上に蓄積される
> ハードディスク上には残らないのですね。
> > > キャシュをクリーニングする間隔を変更することはできると思うけど?
> > TTLの切れた古いデータを消去する間隔
> という事は、
> 自動・手動問わず、キャッシュのクリーニングさえしなければ、
> TTLの切れた後もそのキャッシュを使い続けられるという意味ですか?
> > キャッシュのクリーニング機能とは関係なく、
> TTLが切れるとキャッシュは個別且つ自動的に消えるのだと思い込んでいました。
> > キャッシュの自動クリーニングをする間隔を延ばし、
> メモリ使用量とバランスの取れる日数に変更すれば、
> 相手のTTLを実質的に自分の希望する期間に変更できるという解釈で合っていますか?

bind cleaning-interval
等で検索してみて下さい

TTLのきれた古いデータが残っている場合、
クエリを発行したときに新しく置き換えられます
キャッシュされた時刻などが更新されるのではないか?

クリーニングをしている間はbindは無反応になるらしいので
クエリ数の多い大規模なDNSサーバの場合、
バランスをとることが必要でしょうけど
個人の場合、そんなにクエリ数も多くないので、変更しないで良いのでは?

IEの履歴は 再度アクセスするときに有効だけど
DNSサーバの古いキャッシュが何に有効なのか私には解からない
アクセスした記録をのこしたいならクエリログを取れば良い


ゾーンサーバへの問い合わせ回数を減らす効果がある気がします。

No.16947 投稿時間:2004年08月02日(Mon) 04:47 投稿者名:yokoyama URL:

strangerさん、ありがとうございます。

> TTLのきれた古いデータが残っている場合、
> クエリを発行したときに新しく置き換えられます

この時のDNSの動作について調べていましたので、
返信が遅れてしまいました。
しかし結局、その際の動作について言及しているサイトを探しきれませんでした。
度々申し訳ありませんが、もう少し教えて下さい。

例えば、
Webサーバ www.abc.co.jp(111.111.111.111)
DNSサーバ dns.abc.co.jp(222.222.222.222)
上記問い合わせデータのTTLが切れて且つクリーニングをしない状態で、
自分のキャッシュサーバ(DNS)に残っていたとします。

この場合、
自分のキャッシュサーバに対して『abc』についての問い合わせをすると、
abcのTTLは切れているので『co』のゾーンサーバまで問い合わせに行くのですか?

それとも、
TTLが切れてはいるもののクリーニングはしておらず、
『abc』のゾーンサーバである dns.abc.co.jp(222.222.222.222)のデータが、
キャッシュとして残っている(IPアドレスを知っている)ので、
直接 dns.abc.co.jp(222.222.222.222)に問い合わせに行くのですか?

稚拙な説明で申し訳ありません。
上手く伝わると良いのですが(^_^;)


> DNSサーバの古いキャッシュが何に有効なのか私には解からない

確かにTTLが切れているので問い合わせに対してキャッシュによる即答は出来ません。
しかし、例えTLL切れのキャッシュだとしても残ってさえいれば、
『co』のゾーンサーバまで行かずに済むので1回分の問い合わせを減らせる気がします。
自分のキャッシュサーバで再帰が有効の場合は、再帰の1回分を減らせる気がします。


この辺に関して自分なりに少し理解したつもりですが、
もしかしたら根本的に間違った解釈をしているのかも知れません。
その際は、是非ご指摘下さい。よろしくお願いします。


TTLの切れていない上位のサーバへ問い合わせするのではないか?

No.16952 投稿時間:2004年08月02日(Mon) 11:41 投稿者名:stranger URL:

例 www.abc.co.jp として
キャッシュ情報には
jpを解決するDNSサーバの情報
coを解決するDNSサーバの情報
abcを解決するDNSサーバの情報
wwwを解決するDNSサーバの情報
(例 dns.abc.co.jp)
が存在していると思います
www.abc.co.jpのTTLが切れている場合、
dns.abc.co.jpのTTLが切れていなければ、そこに問い合わせをし、
dns.abc.co.jpのTTLが切れていれば、さらに
TTLの切れていない上位のサーバへ問い合わせするのではないか?

開発者でないので詳しくはわかりません


キャッシュのクリーニングをやめる事にしました。

No.16977 投稿時間:2004年08月04日(Wed) 22:27 投稿者名:yokoyama URL:

strangerさん、ありがとうございます。

> TTLが切れていれば、さらに
> TTLの切れていない上位のサーバへ問い合わせするのではないか?

そうですね。この部分のDNSの動作が詳しく分かると解決できそうですね。

とりあえず現状での解決策として、
キャッシュのクリーニングを自動・手動共にやめる事にしました。
理由は以下のような感じです。

TTLが切れている場合は直接上位のゾーンサーバへ問い合わせると仮定すると、
上位・下位と2段階の手順を踏む事になり、
キャッシュが存在しなかった場合の動作と同じになると思います。
この場合はキャッシュをクリーニングしてもしなくても同じという事だと思います。

次に、TTLが切れている場合は一旦同じゾーンサーバへ問い合わせると仮定すると、
上位へは行かないので1段階の手順で済む事になり、
キャッシュが存在したが故の動作という事になると思います。
この場合はキャッシュをクリーニングしない方が手順が少ないという事だと思います。

実際のDNSの動作がどちらなのか現段階で確証がありませんので、
私の目的に沿う形でどちらの場合にも対応できるようにするには、
『キャッシュのクリーニングをしない』という選択肢が最善だと思います。
もちろん恒久的という訳ではなく、メモリやその他の環境とのバランスは取りますが。


おかげさまで解決に至りました。
またDNSに関してstrangerさんとのやり取りはとても勉強になりました。
幾度も回答をして頂きまして、ありがとうございました(^O^)


常に最新のデータに保って置く方が良いように思います。

No.16978 投稿時間:2004年08月05日(Thu) 07:51 投稿者名:stranger URL:


> > 次に、TTLが切れている場合は一旦同じゾーンサーバへ問い合わせると仮定すると、
> 上位へは行かないので1段階の手順で済む事になり、
> キャッシュが存在したが故の動作という事になると思います。
> この場合はキャッシュをクリーニングしない方が手順が少ないという事だと思います。
> > 実際のDNSの動作がどちらなのか現段階で確証はありませんが、

bind9の場合は
名前解決ができない場合、negative(否定)キャッシュされ、一定時間そのドメインにたいして
名前解決をしなくなるので、注意が必要
ですから、常に最新のデータに保って置く方が良いように思います


ネガティブキャッシュについてもクリーニングをやめる事にしました。

No.16984 投稿時間:2004年08月07日(Sat) 03:50 投稿者名:yokoyama URL:

stranger さん、ありがとうございます。

そうですね。ネガティブキャッシュの事も考慮しなければなりませんね。
ネガティブキャッシュについて少し調べてみました。
その結果、結論から言いますとネガティブキャッシュのクリーニングもやめる事にしました。
理由は以下の通りです。

> 名前解決ができない場合、negative(否定)キャッシュされ、一定時間そのドメインにたいして
> 名前解決をしなくなるので、注意が必要
> ですから、常に最新のデータに保って置く方が良いように思います

ネガティブキャッシュの場合は、
通常のキャッシュのようにTTLが切れた後も保存しておく事は避けた方が良いという事ですよね。
そうなるとやはりここでもTTLが切れた時のDNSの動作がポイントになるみたいですね。


ネガティブキャッシュのTTLが切れている場合の問い合わせは、
一旦同じゾーンサーバへは行かずに直接上位のゾーンサーバへ問い合わせると仮定すると、
上位・下位と2段階の手順を踏む事になり、
ネガティブキャッシュが存在しなかった場合の動作と同じになると思います。
この場合はキャッシュをクリーニングしてもしなくても同じという事だと思います。
更に今度の場合はネガティブキャッシュですので、
問い合わせ先のゾーンサーバ等の修正がされて応答が肯定応答になっていれば良いですが、
否定応答のままだと2段階の手順をかけて否定応答のキャッシュのTTLを伸ばしただけになります。


次に、
ネガティブキャッシュのTTLが切れている場合は一旦同じゾーンサーバへ問い合わせると仮定すると、
上位へは行かないので1段階の手順で済む事になり、
ネガティブキャッシュが存在したが故の動作という事になると思います。
この場合はキャッシュをクリーニングしない方が手順が少ないという事だと思います。
問い合わせ先のゾーンサーバ等の修正がされて応答が肯定応答になっていた場合も、
否定応答のキャッシュのTTLを伸ばすだけの結果に終わった場合も、
もどちらも1段階の手順で済ます事ができると思います。



結局、実際のDNSの動作がどちらなのか未だに確証がありませんので、
私の目的に沿う形でどちらの場合にもより効率よく対応させるという選択肢としては、
『ネガティブキャッシュのクリーニングもしない』という選択肢が最善だと思います。
もちろん恒久的という訳ではなく、メモリやその他の環境とのバランスは取りますが。


調べ方が悪いらしく、なかなかTTLが切れた際のDNSの詳細な動作について見つかりません。
DNSの解説のサイトではなくBINDの直接の文献等が載っているサイトを見れば分かるのかも知れませんが、
難解そうで近寄りがたいです(^_^;)
今後、時間をかけて調べてみたいと思います。


TTLを超えてcacheを保持するのは無理だと思います。

No.16986 投稿時間:2004年08月07日(Sat) 19:55 投稿者名:かつ URL:http://www.kkoba.com/

yokoyamaさんへ


【cacheとbind9の動作】
bind9なら、strangerさんが書いたように、rndc dumpdbで見ることができます。
www.isc.orgを検索した後、関連するcache情報を見ると、
以下のようになっていました。
(わかり易くするために、NSはcacheの一番最初のものだけ記述しています)

情報                                 cacheされる秒数
-----------------------------------  ---------------------
.のNS=a.root-servers.net.            518397
a.root-servers.net.=198.41.0.4       604797

org.のNS=tld1.ultradns.net.          172797
tld1.ultradns.net.=204.74.112.1      172797

isc.org.のNS=ns1.gnac.com.             3597
ns1.gnac.com.=209.182.216.75         172797
www.isc.org.=204.152.184.88             597

よって、www.isc.orgは以下のようにcacheが効きます。
(cache情報を見に行った時に、TTLを超えていればその情報は廃棄します)。
-597秒           外部に問い合わせしない
598-3597秒       ns1.gnac.com→www.isc.org
3598-172797秒    tld1.ultradns.net→ns1.gnac.com→www.isc.org
172798-518397秒  a.root-servers.net→tld1.ultradns.net→ns1.gnac.com→www.isc.org

yokohamaさんが書いている「TTLが切れた際の動作」とは、このことでしょうか?


【cacheとTTL】
私の知っている限りでは、bind9でTTLを超えた後もcacheを有効にする方法はありません。
また、TTLは「cacheの最大時間を指定」するものなので、これを超えてcacheする実装は
あり得ないのではないかと思います。
逆に、cacheが膨れ上がるのを防ぐための機能なら存在します。

max-cache-ttl, max-ncache-ttl
 相手に指定されたTTLよりもcache時間を短くして、cacheが膨れ上がるのを防ぐ。
cleaning-interval
 TTLを超えてcacheされている情報を、一定時間毎にクリアする


【TTLを超えてcacheを保持しておくとどうなるか】
当然のことなが、アクセスできないサイトが増えて来ます。
サーバのIPを変更する時は、一時的にTTLを減らして、cache情報が切れるのを待って
変更するのは良くあると思います。
また、サーバ構成を変更したサイト(例えば負荷分散のためにサーバを増やした)への
アクセスも変になるかも知れません。
また、私のように非固定IP+DynamicDNSのサイトには、直ぐにアクセスできなくなります。
2週間程度でIPが変わっていますので。
http://www.kkoba.com/cgi-bin/homeserver/iplog.cgi


【結論】
TTLを超えたcacheの保持は恐らくできないでしょうし、やらない方が良いでしょう。


ようやく理解できました。キャッシュはクリーニングします。

No.16991 投稿時間:2004年08月08日(Sun) 17:10 投稿者名:yokoyama URL:

かつ さん、ありがとうございます。


> (cache情報を見に行った時に、TTLを超えていればその情報は廃棄します)。

これです。この部分が私の一番知りたかった『TTLが切れた際の動作』です。
ようやく疑問が解けました。

キャッシュを見に行った時に、
TTLが切れていればそのキャッシュは『その場で』破棄するのですね。
そして、見に行かなかったTTL切れのキャッシュについては、
クリーニングをした時に破棄するという事ですね。

この、『その場で破棄』という事を知らなかったので、
私の考えがあさっての方向に行ってしまったのですね。

TTL切れのキャッシュは見に行った時にその場で破棄され、
キャッシュ自体がなくなるため同じデータへ問い合わせに行くという事はありえず、
必然的に上位のゾーンサーバへ問い合わせに行くという事ですね。

そう考えるとキャッシュを破棄する方法の中で、
『その場で破棄』という動作は、とても重要な事のように思えるのですが、
私が見たサイトには、そのような表現や説明は載っていませんでした。
特に設定する必要や項目がない、もしくは当たり前すぎて載っていなかったのでしょうか。
自動クリーニングや再起動等の方法しか見かけませんでした。
『その場で破棄』についての記述を私がもっと早く見つける事ができれば、
あさっての方向へ行かずに済んだのですが(^_^;)


納得できてスッキリしました。
分かりやすく説明して頂きまして、ありがとうございます。
よく理解できました。



stranger さん、大変失礼致しました。
私がキャッシュの破棄について勘違いしているのに気が付かなかったので、
strangerさんに何度も書き込みをさせてしまいました。

TTL切れの場合は上位のゾーンサーバへ問い合わせに行くというのは、
stranger さんのおっしゃっていた通りでした。


> DNSサーバの古いキャッシュが何に有効なのか私には解からない

という部分がありましたが、疑問が解けた今改めて読むと確かにそうですね。
TTL切れのキャッシュは、見ていくそばから順次破棄されるので、
キャッシュとしての有効な使い道は何もありませんね。
ようやく意味が判りました(^_^)


皆さん、ありがとうございました。
TTL切れのキャッシュは自動クリーニングする事にします。
ネガティブキャッシュも。


|目次|掲示板|過去ログ目次|▲頁先頭|