こんにちは、滝澤です。
みなさん、提供しているサービスの外形監視を行っていますか。 DNSレコードの変更ミスやドメイン名の失効などを起因とする障害に早く気づけるようになっていますか。
ということで、今回は外形監視におけるフルリゾルバー（キャッシュDNSサーバー）のキャッシュ保持期間について考えてみます。
外形監視とフルリゾルバーについて
外形監視とは何かを一言でまとめると、「システムの外部から、システムが提供していサービスが正常に動作しているかを監視する」ことです。 このとき、「ユーザーと同じような方法でアクセスする」ことが重要となります。
アプリケーションのサービスへのアクセス方法
ウェブブラウザーのようなユーザー側のアプリケーションがサービスに接続するときには、次の図のようにサービスのドメイン名の名前解決を行い、取得したIPアドレスに対して接続を行います。
このとき、名前の解決は次のように行われます。なお、「スタブリゾルバー」はOS側の名前解決用のAPIやサービスのことです。説明の簡略化のため、IPv4アドレスのみで説明します。
- [アプリケーション]→[スタブリゾルバー]: ①example.comのIPアドレスは何？
- [スタブリゾルバー]→[フルリゾルバー]: ②example.comのAレコードは何？
- [フルリゾルバー]→[権威DNSサーバー]: ③example.comのAレコードは何？
- [権威DNSサーバー]→[フルリゾルバー]: ④example.comのAレコードは"192.0.2.1"
- [フルリゾルバー]→[スタブリゾルバー]: ⑤example.comのAレコードは"192.0.2.1"
- [スタブリゾルバー]→[アプリケーション]: ⑥example.comのIPアドレスは"192.0.2.1"
フルリゾルバーがexample.comのAレコードの期限切れしていないキャッシュを持っていれば、権威DNSサーバーに問い合わせをせずに、キャッシュから回答を行います。そのため、③と④は省略され、⑤に進みます。
このキャッシュの保持期間はDNSレコードのTTLの値に基づいています。 例えば、次のようなリソースレコードがあるとします。
example.com. 86400 IN A 192.0.2.1
これは、example.com.のAレコードの値が"192.0.2.1"で、TTLが86400であることを示しています。 このとき、フルリゾルバーはこのレコードの回答を取得した後に、最大86400秒（1日）の間、キャッシュを保持してもよいことになります。 そのため、フルリゾルバーがこのレコードのキャッシュを持っているときに問い合わせがあった場合は、TTLの秒数が経過して期限切れになるまでは、回答としてこのキャッシュの値を使います。
監視サーバーのサービスへのアクセス方法
次に、外形監視を行う監視サーバーについてもアクセス方法を考えてみましょう。
監視サーバーのサービスへのアクセス方法は、アプリケーションの場合と同様に次の図のようになります。「アプリケーションソフトウェア」が「監視サーバー」に置き換わっただけです。
そのため、サービスのドメイン名の名前解決についても同様な処理を行います。
サービスのドメイン名に問題が発生したときにどうなるか
サービスのドメイン名に問題が発生したときに何が起こるかを考えてみましょう。
次のような問題が発生することがあります。
- リソースレコードの記述ミス
- 権威DNSサーバーの移転ミス
- ドメイン名の失効（レジストラへの更新依頼忘れ）
このような問題が発生したときに、フルリゾルバーがキャッシュしているレコードはTTLの期間が経過するまで保持し続けるため、次のようなことが生じます。
- アプリケーション側
- フルリゾルバーがキャッシュしているため、すぐには影響を受けない。
- キャッシュが期限切れになったフルリゾルバーを利用しているユーザーから影響を受け始める。
- 監視サーバー側
- フルリゾルバーがキャッシュしているため、すぐには異常を検出できない。
- フルリゾルバーのキャッシュが期限切れになってから、異常を検出する。
監視サーバーとしては、すぐに異常を検出できないことが問題となります。
例えば、監視対象のドメイン名のAレコードのTTLが86400であるとします。フルリゾルバーがこのレコードをキャッシュすると、最大で86400秒（1日）の間はこのレコードをキャッシュすることになります。
監視サーバーによる定期的な監視アクセスにより、監視サーバーが利用しているフルリゾルバーは通常はこのレコードをキャッシュしています。このとき、ドメイン名が失効してしまったとします。こうなると、最大86400秒（1日）の間、監視サーバーはこの障害を検出することができません。 最悪、サービスの利用者からの問い合わせでやっと障害に気づくといったことになります。
このような問題に対する対策として、監視サーバーが利用するフルリゾルバーのキャッシュ保持期間を短くすることを検討します。
フルリゾルバーにおけるキャッシュ保持期間の制御
監視サーバーが利用するフルリゾルバーのキャッシュ保持期間を短くすることについて考えてみましょう。
そもそも、フルリゾルバーのキャッシュ保持期間を短くしてよいのかという点について確認してみます。
まず、TTLの定義について確認します。
DNSの基本仕様のRFCである RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION の "3.2.1. Format"のTTLの定義（Errataページにより"signed"を"unsigned"に修正）には次のように記述されています。
a 32 bit unsigned integer that specifies the time interval that the resource record may be cached before the source of the information should again be consulted.
邦訳: その情報源が再び参照される前に、そのリソースレコードがキャッシュされてもよい（may）時間間隔を指定する32ビットの符号なし整数
DNSの仕様で不明確な箇所を明確化するRFCである RFC 2181 Clarifications to the DNS Specification の"8. Time to Live (TTL)"には次のように記述されています。
Implementations are always free to place an upper bound on any TTL received, and treat any larger values as if they were that upper bound. The TTL specifies a maximum time to live, not a mandatory time to live.
邦訳: 実装は、受け取ったTTLに上限を設置し、それより大きい値をその上限であるかのように扱う自由が常にあります。 TTLは強制的な生存期間ではなく、最大の生存期間を指定します。
まとめると、TTLはリゾルバーがリソースレコードをキャッシュしてよい期間であり、受け取ったTTLに対して上限を設定することができます。そのため、キャッシュ保持期間の短くすることは可能です。
実際にフルリゾルバーのキャッシュ保持期間を短くしてみる
DNSの仕様上、フルリゾルバーのキャッシュ保持期間を短くしてもよいことがわかりました。 それでは、実際にフルリゾルバーのキャッシュ保持期間を短くしてみましょう。
まず、監視サーバー専用のフルリゾルバーを用意しましょう。監視サーバー専用にすることで、次の利点があります。
- 共用のフルリゾルバー起因による障害の誤検知を回避できる。
- 自由にキャッシュ保持時間を短くできる。
特に後者について、他のサーバーと共用のフルリゾルバーでキャッシュ保持期間を短くすることはキャッシュポイズニング攻撃への耐性が下がるため、好ましくありません。そのため、監視サーバー専用とすることで、そのような弊害を回避させます。
監視サーバー専用のフルリゾルバーとしては、監視サーバー上にフルリゾルバーのソフトウェアを導入するとよいでしょう。 ハートビーツでは監視サーバー上にフルリゾルバーのソフトウェアとしてUnboundを導入しています。
Unboundでは設定オプション"cache-max-ttl"によりキャッシュの保持期間の上限値を設定することができます。Unbound - unbound.confには次のような記述があります。
cache-max-ttl: <seconds>
Time to live maximum for RRsets and messages in the cache. Default is 86400 seconds (1 day). If the maximum kicks in, responses to clients still get decrementing TTLs based on the original (larger) values. When the internal TTL expires, the cache item has expired. Can be set lower to force the resolver to query for data often, and not trust (very large) TTL values.
キャッシュ保持期間
キャッシュ保持時間をどれくらいにすればよいでしょうか。
異常を早急に検出する目的からは、監視間隔以下に合わせるのが理想です。
しかし、対象のレコードがキャッシュされていないときに名前解決を行うと、名前解決の時間的コストが発生し、外形監視の応答時間を構成する遅延の要素となります。この点を考慮する必要があります。
なお、フルリゾルバーのソフトウェアにはプリフェッチ機能を持っているものがあります。このプリフェッチ機能を併用すると、キャッシュ保持時間の期限に近くなるとプリフェッチを行うため、外形監視の応答遅延を緩和することができます。 しかし、プリフェッチ機能を有効にしていると、親ゾーンの委任情報が変更・削除されても、子ゾーンのNSレコードで指定された権威DNSサーバーを見続けてしまい、障害を検知できない可能性があります。そのため、プリフェッチ機能を使うのは好ましくありません。
参考までに、ハートビーツではキャッシュ保持時間を監視間隔の時間に合わせるようにしています。
最後に
今回は、外形監視においてドメイン名を起因とする障害を早く検知するために、フルリゾルバーのキャッシュ保持期間を短くする方法について説明しました。
サービスのドメイン名のゾーンを自前で管理している場合は、権威DNSサーバに対して、対象のレコードが意図した値であるかを直接監視することもできます。 必要に応じて合わせて実施するとよいでしょう。
参考文献
- RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION (IETF tools)
- RFC 2181 Clarifications to the DNS Specification (IETF tools)
- Unbound (Unbound)
- Unbound - unbound.conf(5) (Unbound)
