DNS アンプ攻撃（DNS amplification attack、DNS リフレクション攻撃とも呼ばれます）は、送信元を被害者の IP アドレスに偽装した小さな DNS 問い合わせを大量の DNS サーバーに送り、何倍にも膨らんだ応答を被害者に集中させる DDoS 攻撃です。攻撃者が直接被害者を狙うのではなく、インターネット上の DNS サーバーを「反射板」兼「増幅器」として使う点に特徴があります。この記事では、攻撃の仕組みを短く整理したうえで、VPS などで DNS ソフトウェアを動かしている人が「自分のサーバーを踏み台にさせない」ための確認方法と設定を解説します。
仕組みを3ステップで理解する
ステップ1：送信元IPアドレスを偽装する
DNS の問い合わせは主に UDP で送られます。UDP には TCP のような接続確立の手順が無いため、パケットの送信元 IP アドレスを書き換えて送っても、そのまま相手に届いてしまいます。攻撃者はこの性質を利用し、送信元を被害者の IP アドレスにした問い合わせを作ります。
ステップ2：応答が大きくなる問い合わせを選ぶ
問い合わせは数十バイト程度でも、応答は数千バイトになることがあります。たとえば、多数のレコードを持つ名前や、DNSSEC の署名が付いた大きな応答、TXT レコードが多いドメインなどです。EDNS(0) によって UDP で大きな応答を返せるようになったことも、増幅の余地を広げました。かつてよく使われた ANY 型の問い合わせについては、応答を最小限にする運用（RFC 8482）が広まり、以前ほどの増幅は得にくくなっています。
ステップ3：多数のDNSサーバーに一斉に送る
攻撃者はボットネットなどから、誰の問い合わせにも答えてしまう「オープンリゾルバー」や、大きな応答を返す権威 DNS サーバーへ、偽装した問い合わせを一斉に送ります。各サーバーは正しく動作しているつもりで、膨らんだ応答を送信元、つまり被害者に返します。条件によっては送った量の数十倍の通信が被害者に届くことがあり、回線や機器が飽和してサービスが止まります。
被害者・踏み台・攻撃者の関係
この攻撃には3者が登場します。
- 攻撃者：偽装パケットを送る側。自分の IP アドレスは表に出にくい
- 踏み台（反射・増幅役）：問い合わせに答えてしまう DNS サーバー。設定の不備があるだけで、管理者に悪意は無いことがほとんど
- 被害者：大量の応答を受け取る側
ここで重要なのは、自分のサーバーが「踏み台」になる可能性がある点です。踏み台になると、自分の回線や CPU が消費されるだけでなく、プロバイダやデータセンターから不正通信の発信元として連絡を受けたり、IP アドレスがブロックリストに載ったりすることがあります。WordPress を動かしている VPS で、検証のために入れた DNS ソフトウェアが外部に開いたままになっている、というのはありがちな状況です。
自分のサーバーが踏み台にならないか確認する
53番ポートで何が待ち受けているか
まずサーバー上で、DNS のポート（53番）を待ち受けているプロセスを確認します。
sudo ss -lunp | grep ':53 '
sudo ss -ltnp | grep ':53 '127.0.0.53 や 127.0.0.1 だけで待ち受けているなら、外部からは届きません。Ubuntu などの systemd-resolved は既定でローカルのアドレスだけを使います。一方、0.0.0.0:53 やグローバル IP アドレスで BIND、Unbound、dnsmasq などが待ち受けている場合は、次の確認に進みます。DNS サーバーとして使う予定が無いなら、サービスを停止・無効化するのがもっとも単純な対策です。
外部から再帰問い合わせに答えるか
自分のサーバー以外の端末（自宅の PC や別の VPS）から、自分が管理していないドメインを問い合わせます。
# 203.0.113.10 は自分のサーバーのIPアドレスに置き換える
dig @203.0.113.10 example.org A結果のヘッダー部分に status: REFUSED と出る、またはタイムアウトするなら、外部の再帰問い合わせは受け付けていません。status: NOERROR で ANSWER セクションに答えが返り、flags に ra が含まれる場合は、オープンリゾルバーになっています。早めに次の設定で利用者を限定してください。なお BIND は、許可範囲を書かない場合の既定値がローカルのネットワークに限られていますが、設定を引き継いだサーバーでは明示しておくほうが安全です。確認は自分が管理するサーバーに対してだけ行います。
踏み台にさせないための設定
設定変更の前には、設定ファイルのバックアップを取り、文法チェックをしてから再読み込みします。リモートのサーバーでは、変更が原因で自分の名前解決が止まっても SSH で戻れるよう、手順を確認してから作業してください。
キャッシュDNS（リゾルバー）は利用者を限定する
BIND で社内や自分のサーバーだけにキャッシュ DNS を提供する場合は、再帰問い合わせを許可する範囲を明示します。
acl "trusted" {
127.0.0.1;
::1;
192.0.2.0/24; // 自分のネットワークに置き換える
};
options {
recursion yes;
allow-recursion { trusted; };
allow-query-cache { trusted; };
};sudo named-checkconf && sudo systemctl reload namedサービス名はディストリビューションによって named または bind9 です。Unbound の場合は access-control で許可範囲を指定します。Unbound は既定ではローカルホスト以外を拒否するため、外部に開いてしまうのは、許可範囲を広げすぎた設定のときです。
server:
interface: 0.0.0.0
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: 192.0.2.0/24 allowsudo unbound-checkconf && sudo systemctl restart unbound権威DNSは再帰を切り、応答レートを制限する
自分のドメインを公開する権威 DNS は、世界中からの問い合わせに答える必要があるため、オープンリゾルバーのように利用者を絞ることはできません。そのかわり、再帰問い合わせを無効にし、同じ相手への同じ応答を短時間に大量に返さないよう制限します。BIND では Response Rate Limiting（RRL）を次のように設定できます。
options {
recursion no;
rate-limit {
responses-per-second 10;
};
};数値は一例です。正規の利用者への影響が出ないか、ログを見ながら調整してください。NSD や Knot DNS など他の権威 DNS ソフトウェアにも同様の制限機能があります。手間をかけたくない場合は、自前の権威 DNS をやめて、Cloudflare DNS や Amazon Route 53 などのマネージド DNS に任せるのも現実的な選択です。
ネットワーク側の対策
送信元 IP アドレスの偽装そのものを防ぐには、ネットワークの出口で「自分のネットワークに属さない送信元アドレスのパケットを外に出さない」フィルタリング（BCP 38 として知られる送信元アドレス検証）が有効です。これは主にプロバイダやデータセンター側の対策ですが、自社でルーターを運用している場合は設定を確認しておく価値があります。
被害者側になったときの対策
自分のサイトが攻撃を受ける側になった場合、サーバー単体での対策には限界があります。応答パケットが回線を埋めてしまうと、サーバーの手前で通信が詰まるためです。CDN や DDoS 対策サービスで通信を受け止める、データセンターやプロバイダに相談して上流で遮断してもらう、といった対応が中心になります。対策サービスの機能や提供範囲は事業者や契約によって異なるため、各社の資料で確認してください（2026年10月現在）。
まとめ
- DNS アンプ攻撃は、送信元を偽装した小さな問い合わせで大きな応答を被害者に送りつける DDoS 攻撃
- UDP であること、応答が問い合わせより大きくなることが、反射と増幅を可能にしている
- 自分の DNS サーバーが外部の再帰問い合わせに答えていないかを、
ssと外部からのdigで確かめる - キャッシュ DNS は利用者を限定し、権威 DNS は再帰を切って応答レートを制限する
- 使っていない DNS サービスは止めるのがもっとも単純で効果の高い対策で、権威 DNS はマネージドサービスに任せる選択肢もある