DYNDNSサービスのTTL値の最適化
私はついに自分のDYNDNSが機能するようになりましたが、それを最適化するためのアドバイスを探しています。
編集：基本的に、私は自分のレコードを保持している自分のネームサーバーを指すドメインをレジストラで取得しました。 nsupdateを使用してレコードを更新しています。ユーザーが登録できるようにし、動的IPを取得したデバイスを指すことができるサブドメインを取得して「静的」にする必要があります。
動的更新の例 http://ip.seveas.net/dnsgraph/png/client1.epnddns.com/?skip_.=on&show_A=Show
基本的には、それと呼べるなら、最速の解決を達成したいと思います。これは、ユーザーがサブドメインを更新してから実際に使用/解決できるようになるまで待機する必要がある最小の時間を意味します。サーバーを停止せずに、+ 1000ユーザーを考えてください。それが理にかなっているなら？
そのため、SOAのTTL値、ネームサーバー、およびユーザーが頻繁に更新する可能性のある動的に作成されたサブドメインに何を与えるかについて疑問に思っています。
もう1つの質問は、client1についての例です。他のデバイスや他のユーザーにとっては問題なく解決するようですが、レコードの更新にも使用したIPを使用している自宅からは、接続するかどうかはかなりランダムに見えます。それは私のセットアップでファンキーなものでしょうか、それとも自宅のIPからレコードを更新したことと関係がありますか？
私の最初のネームサーバー値
$Origin .
$TTL 38400 ; 10 hours 40 minutes
mydomain.com IN SOA ns3.mydomain.com. admin.mydomain.com. (
2880848856 ; serial
28800 ; refresh (8 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS ns3.mydomain.com.
NS ns4.mydomain.com.
A 66.33.x.x
$Origin mydomain.com.
$TTL 10 ; 10 seconds
client1 A 75.119.x.x
$TTL 38400 ; 10 hours 40 minutes
ns3 A 64.111.x.x
ns4 A 67.205.x.x
www A 66.33.x.x
私の2番目のネームサーバーの値
$Origin .
$TTL 38400 ; 10 hours 40 minutes
mydomain.com IN SOA ns4.mydomain.com. admin.mydomain.com. (
2006071806 ; serial
28800 ; refresh (8 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS ns3.mydomain.com.
NS ns4.mydomain.com.
A 66.33.x.x
$Origin mydomain.com.
$TTL 10 ; 10 seconds
client1 A 75.119.x.x
$TTL 38400 ; 10 hours 40 minutes
ns3 A 64.111.x.x
ns4 A 67.205.x.x
www A 66.33.x.x
それ以外に、それを最適化する他の方法はありますか？
洞察やアドバイスを与えてくれてありがとう！
あなたが書いた：
サービスをあまりプッシュせずに最速の解決策を得るためにそれを最適化するためのいくつかの指針を私に与えることができる誰かがそこにいるのだろうかと思っていました。
TTLの値を調整することで、達成しようとしていることについてもう少し明確にできますか？
ご存知だと思いますが、TTLは、リソースレコードが権限のないネームサーバーのキャッシュにとどまることができる期間を制御します（または制御する必要があります-すべてのネームサーバーが実際にそれを正しく尊重するわけではありません）。
レコードのクエリを解決しようとしているクライアントは、ローカルの再帰リゾルバーのキャッシュから回答を取得できれば、より高速な解決を受け取ることができます（「より良い方法」である可能性があります）。したがって、その意味で、TTLを長くすると、他のネームサーバーがRRデータをより長くキャッシュできるようになり、クエリを実行するクライアントがキャッシュからクエリを満足できる可能性が高くなります。この意味で、高いTTLは、クライアントクエリの解決速度を向上させる傾向があります。
ただし、これと、権限のないサーバーが誤ったデータをキャッシュする問題とのバランスを取る必要があります。データが変更された場合（たとえば、別のIPアドレスに移動した、またはレコードのターゲットを変更したため）、他のネームサーバーは最大TTL秒）の間、古いデータをキャッシュできます。データを頻繁に変更する場合（たとえば、新しいIPアドレスに頻繁に移動する場合、またはゾーンのコンテンツを変更する場合）、TTLを下げる必要があります。
現在指定されているように、あなたの質問はデータの変化の速さに関するガイダンスを実際には提供しないため、TTL値が適切であるかについてより具体的にアドバイスすることはできません。それらは非常に依存しますあなたの使用パターンに。
これは比較的少量の場合だと思います。大量の信頼できるDNSルックアップを必要とするサーバーは、静的IPアドレスに属します。もしそうなら、TTLの調整はそれほど重要ではないはずです。
部分的な情報で良いアドバイスをするのは難しいです。次の応答は私のために働いた。情報が限られているので、あなたの場合は答えが適切でないかもしれません。
この場合、TTL）を選択する際に、IPアドレスの送信元でTTLを確認します。DHCPを使用してリースがオーバーの場合1〜2分a TTL 10秒は極端な場合があります。
DHCPクライアントに内部DYNDNSサービスを提供している場合、a TTLリース時間の半分または4分の1。外部向けサービスのTTL動的にアドレス指定する場合は、TTLを短くする必要があります。
考慮すべき要素は、データがキャッシュされる場所、アドレス変更が発生する頻度、およびサービスの中断がないことの重要性です。また、誤った方向の接続がどこに到達する可能性があるかについても考慮する必要があります。組織の内部またはデッドアドレスは、制御できないインターネット上のサーバーよりも問題が少ない可能性があります。
編集:: TTL一部のDNSサーバーが独自のTTLのキャッシュを無視するように指定した場合、これはTTLが短いほど発生する可能性が高いと思います。数年前に高速フラックスDNSを使用して検出を回避しようとするボットネット。短いTTLを無視し、長時間キャッシュすることが、これらのサーバーを処理するために使用される1つのアプローチであるという報告を目にしました。
また、ネガティブキャッシングに対処する必要があります。バインド9は、最小のTTLを負のキャッシュ期間として使用します（あなたの場合、これは正のTTLよりはるかに長い10h40のように見えます）。同じ。
私はあなたのクライアントが3つのクラスに分類されることを期待します（彼らは異なるニーズを持っているかもしれません）：
- かなり安定したIPアドレスを持ち、動的IPでパブリックサービスを実行しているユーザーは、DNSクエリが比較的頻繁に発生します。
- かなり安定したIPアドレスを持ち、サーバーにリモートでアクセスすることがあるユーザー。
- しばしば切断されているが、接続されたときに到達可能であることを望んでいるロードウォリアー。
あなたが持っているユーザーのタイプを決定することは私の監視クエリとあなたのDNSへの更新を行うことができます。この種のデータを決定するには時間がかかります。 TTLを決定する上で重要なのは、最後のクエリから更新が発生するまでの時間を決定することです。この値を経時的に調べると、妥当なTTLを決定するのに役立ちます。クエリの頻度とソースIPの分布と更新の頻度を調べることもできます。これは、時間の経過とともにTTL値）を調整するために使用できるデータです。