RRLとは？ わかりやすく10分で解説

UnsplashのGrowtikaが撮影した写真      

DNS（Domain Name System）は、ドメイン名とIPアドレスを対応させる仕組みです。DNSが攻撃対象になると、Webサイト、メール、クラウドサービスなどの利用に影響が出ます。特にDNS増幅攻撃では、DNSサーバーが第三者へのDDoS攻撃に悪用される場合があります。RRL（Response Rate Limiting）は、DNSサーバーの応答頻度を制御し、増幅攻撃の影響を抑えるための対策です。

DNS攻撃とRRLの関係

DNS攻撃には、利用者を偽の宛先へ誘導する攻撃と、DNSの応答を悪用して大量の通信を発生させる攻撃があります。RRLが主に対象とするのは後者です。キャッシュポイズニングのような誤誘導対策ではなく、DNSサーバーが増幅攻撃の送信元として悪用されるリスクを下げるために使います。

DNSの基本

DNSは、example.comのようなドメイン名を、通信に必要なIPアドレスへ変換する仕組みです。利用者がWebサイトにアクセスするとき、メールサーバーの配送先を確認するとき、クラウドサービスの接続先を解決するときにも使われます。

DNSは、同じ問い合わせを何度も繰り返さないように、問い合わせ結果を一定時間キャッシュします。キャッシュにより応答は速くなりますが、誤った情報がキャッシュに保存されると、利用者が正規サイトではない宛先へ誘導される可能性があります。

DNS障害の影響は、Webサイトの閲覧不能だけにとどまりません。メール配送、認証連携、業務アプリケーション、外部クラウドサービスへの接続などにも波及します。そのため、DNSは公開サービスを支える基盤として、可用性と改ざん耐性の両面で管理する必要があります。

DNS攻撃の主な種類

DNSを狙う攻撃は複数あります。代表例は、DNSキャッシュポイズニングとDNS増幅攻撃です。両者は目的も対策も異なるため、同じ「DNS攻撃」として一括りにしない方が判断しやすくなります。

DNSキャッシュポイズニングは、DNSリゾルバに偽の応答を信じ込ませ、キャッシュへ不正な情報を保存させる攻撃です。成功すると、正規ドメインへアクセスした利用者が偽サイトへ誘導される場合があります。認証情報の窃取、マルウェア配布、ブランド毀損などにつながるリスクがあります。

DNS増幅攻撃は、送信元IPアドレスを偽装したDNS問い合わせを大量に送り、DNSサーバーからの応答を被害者へ集中させる攻撃です。小さな問い合わせに対して大きな応答が返る性質を悪用するため、攻撃通信が増幅されます。DNSサーバー側から見ると、自組織が直接攻撃を受けていなくても、第三者攻撃の中継点として使われる可能性があります。

DNS増幅攻撃では、外部から再帰問い合わせを受け付けるオープンリゾルバが悪用されることがあります。一方、権威DNSサーバーも、大きな応答を返す公開サーバーとして悪用される場合があります。オープンリゾルバ対策とRRLは役割が異なるため、DNSサーバーの用途に合わせて対策を分ける必要があります。

DNS攻撃が業務へ与える影響

DNS攻撃の影響は、単なるアクセス不能では終わりません。Webサイトの停止は販売機会の損失につながります。ログイン、決済、問い合わせ、資料請求などがDNSに依存している場合、顧客接点そのものが止まります。

キャッシュポイズニングのように誤誘導が起きると、情報漏えい、不正送金、マルウェア感染などの被害につながる場合があります。利用者から見ると、DNSの仕組みではなく「そのサービスで起きた事故」と認識されやすいため、信頼低下にも直結します。

また、DNS障害は切り分けに時間がかかることがあります。Webサーバーやメールサーバー自体は稼働していても、名前解決が失敗すれば利用者はサービスへ到達できません。復旧が長引くほど、業務継続、顧客対応、対外説明の負担が増します。

DNS攻撃への主な防衛策

DNS攻撃への対策は、想定する攻撃とDNSサーバーの役割を分けて整理します。

RRLは、DNS攻撃全般を防ぐ仕組みではありません。増幅攻撃でDNSサーバーが応答を大量に返し続ける状態を抑えるための対策です。DNSSEC、アクセス制御、監視、上流のDDoS対策と組み合わせて運用します。

RRLとは

RRL（Response Rate Limiting）は、DNSサーバーが返す応答の頻度を制御する仕組みです。特に、DNS増幅攻撃でDNSサーバーが第三者攻撃の中継点として悪用されるリスクを下げるために使われます。

RRLの考え方

DNS増幅攻撃では、攻撃者が被害者のIPアドレスを送信元として偽装し、DNSサーバーへ問い合わせを送ります。DNSサーバーは問い合わせに応答し、その応答が被害者へ届きます。この処理が大量に繰り返されると、被害者側の回線や設備に負荷が集中します。

RRLは、同じような応答が短時間に大量発生した場合に、応答を間引く、破棄する、または簡略化した応答にすることで、増幅効果を抑えます。問い合わせを完全に止めるのではなく、応答の出し方を調整する点が特徴です。

RRLは、主に権威DNSサーバーでの利用が想定されます。リゾルバ側では、まず再帰問い合わせを許可する範囲を制限し、外部から誰でも使えるオープンリゾルバにしないことが基本です。

RRLが主に対象とする攻撃

RRLが主に対象とするのは、DNS増幅攻撃またはリフレクション型DDoSです。攻撃者は、送信元IPアドレスを偽装してDNS問い合わせを送り、DNSサーバーからの応答を被害者へ集中させます。

この攻撃では、DNSサーバー自体が侵害されていなくても、公開DNSとして応答を返す性質が悪用されます。RRLを設定すると、同種の応答が一定時間内に過剰に発生した場合に制限がかかり、踏み台として利用される影響を小さくできます。

一方、RRLはキャッシュポイズニングやドメイン乗っ取りを直接防ぐ仕組みではありません。DNS応答の正当性を検証するにはDNSSEC、管理画面やレジストラアカウントの保護には認証管理や権限管理が必要です。

RRLの機能

RRLは、一定時間内に発生するDNS応答の数や種類を基準に制御します。実装や製品によって詳細は異なりますが、一般には以下の要素を組み合わせます。

• 一定時間内の応答数が閾値を超えた場合に制限をかける
• 同一または類似の問い合わせ、応答種別、送信元範囲などを基準に集計する
• 応答を破棄する、間引く、または切り詰めた応答にする
• 制限が発動した状況をログや統計で確認できるようにする

RRLの設計目的は、通常利用への影響を完全になくすことではなく、増幅攻撃でDNSサーバーが応答を大量に返し続ける状態を抑えることです。閾値が厳しすぎると正規利用者の名前解決に影響が出ます。緩すぎると攻撃抑制の効果が弱くなります。

RRLの効果と限界

RRLを導入すると、DNSサーバーが増幅攻撃の踏み台として利用されるリスクを下げられます。大量の応答による回線圧迫やサーバー資源の消費を抑え、第三者への影響も減らしやすくなります。

ただし、RRLだけで大規模DDoSを完全に処理できるとは限りません。攻撃が分散された場合、攻撃パターンが変化した場合、またはDNSサーバーそのものへ大量の問い合わせが集中する場合には、上流ISPやDDoS対策サービス、ネットワーク側のフィルタリングと組み合わせる必要があります。

RRLは、DNS基盤の防御策の一部です。公開DNSの役割、通常時のトラフィック、監視体制、障害時の切り替え手順まで含めて設計すると、運用上の効果が出やすくなります。

RRLの設定と運用

RRLを設定する際は、利用しているDNSサーバー製品、権威DNSかリゾルバか、通常時の問い合わせ量、監視体制を確認します。製品ごとに設定項目や推奨値が異なるため、公式ドキュメントに基づいて設計します。

RRL対応のDNSサーバー

RRLを使うには、対応するDNSサーバーソフトウェアまたはDNSサービスが必要です。BIND、Knot DNS、商用DNS製品などでは、RRLまたは類似の応答制御機能を利用できる場合があります。ただし、対応状況、設定項目、推奨される適用先は製品ごとに異なります。

導入前に確認すべき点は次の通りです。

• 対象サーバーが権威DNSか、リゾルバか
• RRL機能が対象バージョンで有効か
• 制限対象、閾値、ログ出力、例外設定をどこまで制御できるか
• 設定変更時に再起動が必要か、設定再読み込みで反映できるか
• 既存の監視基盤でRRL発動状況を確認できるか

特に、リゾルバを公開している環境では、RRL以前に再帰問い合わせの公開範囲を見直す必要があります。外部から無制限に再帰問い合わせを受け付ける構成は、増幅攻撃の悪用対象になりやすいためです。

RRLの基本設定

RRLの基本設定では、制限対象、閾値、制限時の挙動を決めます。短時間に同種の応答が増えたとき、どの程度まで応答を許容し、どの時点から抑制するかを設計します。

設定時には、平常時のDNSトラフィックを先に把握します。通常のピーク、バッチ処理、監視システム、メール配信、CDN連携などにより、正規問い合わせが一時的に増えることがあります。これを確認せずに閾値を設定すると、正規利用まで制限してしまう可能性があります。

初期導入では、いきなり厳しい制限をかけるより、ログや統計で発動状況を確認しながら調整する方が安全です。攻撃時の抑制と通常利用の可用性の両方を確認し、段階的に設定値を詰めます。

RRL導入後の確認項目

RRL導入後は、設定しただけで終わらせず、発動状況と正規通信への影響を確認します。確認項目は次の通りです。

• RRLがどの条件で発動しているか
• 特定の送信元範囲やクエリ種別だけが過剰に制限されていないか
• 正規利用者から名前解決の不安定化が報告されていないか
• NXDOMAINやエラー応答の増加が業務上の通信に影響していないか
• 攻撃時に上流ISPやDDoS対策サービスと連携できる手順があるか

RRLは、環境ごとのトラフィック特性に合わせて調整する機能です。設定値を固定したまま放置すると、利用状況の変化に追従できません。新サービス公開、DNSレコード追加、メール基盤変更、CDN利用開始などのタイミングでは、DNSトラフィックの変化を確認します。

RRLのトラブルシューティング

RRL導入後に、特定利用者の名前解決が不安定になる、監視でDNSエラーが増える、特定レコードの応答が遅い、といった兆候が出る場合があります。この場合は、RRLが発動している条件をログと統計で切り分けます。

よくある原因は、閾値が低すぎる、監視システムや内部システムの問い合わせを攻撃的なパターンとして扱っている、特定レコードに問い合わせが集中している、といったものです。必要に応じて閾値を調整し、業務上必要な通信を例外扱いにする設計も検討します。

ただし、例外設定を広げすぎるとRRLの効果が弱くなります。例外は、監視システム、内部の正規処理、既知の連携先など、根拠を持って限定します。設定変更後は、通常時と高負荷時の両方で確認します。

RRLと併用すべきDNSセキュリティ対策

RRLは増幅攻撃対策として有効な選択肢ですが、DNS全体の安全性を単独で担保するものではありません。DNSSEC、アクセス制御、監視、冗長化、インシデント対応を組み合わせて、攻撃の種類ごとに対策を分担させます。

オープンリゾルバ対策

リゾルバを運用している場合、外部から誰でも再帰問い合わせできる状態を避けます。再帰問い合わせは、社内ネットワーク、契約利用者、許可した送信元などに限定します。

オープンリゾルバは、DNS増幅攻撃の悪用対象になりやすい構成です。RRLを検討する前に、再帰問い合わせの公開範囲を確認し、不要な公開を止める必要があります。

DNSSECによる改ざん対策

DNSSECは、DNS応答に電子署名を付け、応答が正当な情報であることを検証できるようにする仕組みです。キャッシュポイズニングやDNS応答の偽装に対する対策として検討されます。

一方で、DNSSECはDDoSを止める仕組みではありません。また、署名鍵の管理、ロールオーバー、期限切れ監視など、導入後の運用が欠かせません。DNSSECを導入する場合は、技術的な設定だけでなく、継続管理の体制も決めます。

監視と障害対応

DNSの監視では、単にサーバーの死活を見るだけでなく、問い合わせ量、応答時間、エラー率、NXDOMAIN率、応答サイズ、特定レコードへの集中を確認します。攻撃時には、短時間で傾向が変わるため、平常時の値を把握しておくことが前提になります。

障害対応では、セカンダリDNS、外部DNSサービス、上流ISP、DDoS対策サービスとの連携手順を準備します。DNSは多くのサービスの前段にあるため、復旧手順が曖昧だと影響範囲の把握が遅れます。

参考資料

• ISC Knowledgebase：Using Response Rate Limiting (RRL)
• ICANN：DNSSEC – What Is It and Why Is It Important?
• CISA：DNS Amplification Attacks

まとめ

DNSは、Web、メール、クラウドサービスの利用を支える基盤です。DNSが攻撃対象になると、サービス自体が稼働していても、利用者が到達できない状態になります。DNSキャッシュポイズニングは誤誘導を狙い、DNS増幅攻撃はDNS応答を悪用してDDoSを発生させます。

RRLは、DNSサーバーの応答頻度を制御し、増幅攻撃の踏み台として悪用されるリスクを下げる仕組みです。ただし、RRLはDNS攻撃全般への万能策ではありません。リゾルバのアクセス制御、DNSSEC、監視、上流のDDoS対策、障害時の切り替え手順と組み合わせて、DNS基盤を継続的に管理する必要があります。

よくある質問（FAQ）