WEBサイトJPCERT/CCはオープンリゾルバー確認サイトの確認機能を2027年1月31日までの予定で休止した ── 確認サイトに頼らず、自分が管理するDNSサーバーとルーターが外からの問い合わせに答えていないかを確かめる13項目（2026年11月時点）
JPCERT/CCはオープンリゾルバー確認サイトの確認機能を2027年1月31日までの予定で休止した ── 確認サイトに頼らず、自分が管理するDNSサーバーとルーターが外からの問い合わせに答えていないかを確かめる13項目（2026年11月時点）
目次
- 01 何が書いてあるか — JPCERT/CCは、オープンリゾルバーの確認機能を2027年1月31日までの予定で休止した
- 02 なぜ・背景 — 確認サイトが休んでも、自分のサーバーの状態は変わらない
- 03 用語 — 出てくる言葉を、先にそろえる
- 04 型別 — 対象、確かめられないこと、確かめる手順
- 05 明日、担当サイトで確認できることチェックリスト
- 06 代替・他の選択肢 — 確認サイトが休んでいるあいだの、4つの方法
- 07 当サイトで確かめたこと — 当サイトのサーバーは、DNSの待ち受けが0で、外からの問い合わせにも答えなかった
- 08 このテーマは、ここまで — 外から確かめて、台帳に書く流れ
- 09 この記事のまとめ
01 何が書いてあるか — JPCERT/CCは、オープンリゾルバーの確認機能を2027年1月31日までの予定で休止した
引用について
この記事は、JPCERT/CCが2026年10月30日に更新した「オープンリゾルバー確認サイト長期メンテナンスのお知らせ」と、JPCERT/CC・JPNICの過去の公開資料を、2026年11月2日に開いて確かめた内容を書いている。お知らせの文は引き写さず、記事の筆者が日本語に直した要旨で書く。原文に書かれていない筆者の読みと案は、「筆者の読み」「筆者の案」と書いて分ける。原文にはチェックリストがない。05章の13項目は、筆者が整理したものである。
JPCERT/CCは2026年10月30日、オープンリゾルバーかどうかを調べられる確認サイトの機能を、一時的に休止すると知らせた。担当サイトのDNSサーバーやルーターを自分で管理している人は、これまで、このサイトにアドレスを入れて確かめてきたかもしれない。その確認が、約3か月のあいだ使えない。この記事では、お知らせが書いていることと書いていないことを分け、確認サイトに頼らずに、自分の手で「外からの問い合わせに答えていないか」を確かめる13項目をまとめる。
お知らせが書いていること
JPCERT/CCのお知らせは、最終更新が2026年10月30日である。休止するのは、オープンリゾルバー確認サイト（www.openresolver.jp）のオープンリゾルバー確認機能だけだと書かれている。期間は、2026年10月30日（金）から2027年1月31日（日）までの予定で、作業の状況によっては、予定より早く確認機能を再開する場合がある。理由は、システム構成の変更を含む移行作業のため、長い期間になる、という説明である。再開するときは、お知らせのページで知らせる、と書かれている。
お知らせが書いていないこと
お知らせには、代わりに使える確認サイトや、別の確認方法は書かれていない。休止の原因が、障害や攻撃であるとも書かれていない。オープンリゾルバーの数や危険度についても、触れていない。お知らせの本文の言い方は「一時休止」だが、期間は約3か月（開始日から終了予定日まで93日）に及ぶ。この記事では、お知らせが書いていないことを、理由として推測しない。
| 項目 | お知らせの記載 | 注意 |
|---|---|---|
| 休止するもの | オープンリゾルバー確認サイトの確認機能 | ほかのJPCERT/CCのサービスは対象外と読める |
| 期間 | 2026年10月30日（金）〜2027年1月31日（日）の予定 | 早く再開する場合がある。延びる場合の記載はない |
| 理由 | システム構成の変更を含む移行作業 | 原因が障害や攻撃だとは書かれていない |
| 代わりの確認方法 | 記載なし | この記事の05章は、筆者の案である |
| 再開の知らせ | お知らせのページで知らせる | 再開の通知を自動で受ける方法は書かれていない |
2026年11月2日の応答
お知らせを読んだ同じ日の10時台に、確認サイトのアドレスを開いた。http://www.openresolver.jp/は、301でhttpsのアドレスへ転送され、httpsの側は503（Service Temporarily Unavailable）を返した。503は「一時的に使えない」を表す番号で、お知らせの内容と矛盾しない。ただし、番号から休止の理由までは分からない。
02 なぜ・背景 — 確認サイトが休んでも、自分のサーバーの状態は変わらない
オープンリゾルバーとは
JPNICの注意喚起のページ（初版2013年4月18日、最終更新2014年7月25日）は、DNSの不特定の相手からの問い合わせに応答するサーバーやネットワーク機器を、オープンリゾルバーと呼ぶ、と説明する。対策が足りないオープンリゾルバーが踏み台として使われ、国内外のサーバーへの大規模なDDoS攻撃が行われている、という報告を受けた注意喚起である。ページは、デフォルトの設定のままであるなどの理由で、本来はDNSサーバーを意図したものではないのに、管理者や利用者が気づかないうちにDNSの応答機能が有効になっている機器がある、とも書く。
なぜ踏み台になるのか
JPCERT/CCの注意喚起（2013年4月18日、JPCERT-AT-2013-0022）によれば、攻撃者は、攻撃対象のIPアドレスを送信元に偽装した再帰的な問い合わせを、オープンリゾルバーに送る。すると、オープンリゾルバーは、大量の応答や巨大な応答を、攻撃対象へ送りつける。外部からの再帰的な問い合わせを受け付けるサーバーは、こうしてDDoS攻撃に使われる可能性がある。ネットワーク機器やソフトウェア製品にDNSサーバーが組み込まれていて、利用者が知らないうちにオープンリゾルバーとして使われている可能性もある、と同じ注意喚起は書く。
踏み台にされた側の影響
JPNICのページは、踏み台を利用したDDoS攻撃では、送信元がその踏み台のホストになるので、そのサーバーや機器が攻撃をしているように見えてしまう、と書く。送信元に連絡を取って止めるよう求められることが多く、海外への攻撃に悪用された場合には、外国語で対応する必要があることが報告されている、とも書く。自分のサイトが攻撃を受けなくても、自分の機器が相手に迷惑をかける側になるという話である。
確認サイトは「道具」であって、状態そのものではない
確認サイトが休んでも、自分の機器が外からの問い合わせに答えるかどうかは、変わらない。答える状態のままなら、確認サイトが再開するまでの約3か月のあいだ、気づかずに過ぎる可能性がある。だから、確認サイトを待つのではなく、確認の手順を自分の手元に置いておく価値がある。筆者の読みでは、今回の休止は、手順を持つきっかけになる。
古い注意喚起も、今の確認に使える
JPCERT/CCの注意喚起と、JPNICのページは、どちらも10年以上前の公開である。製品の設定画面や初期設定は、その間に変わっている可能性がある。一方で、「再帰的な問い合わせを受け付ける範囲を必要最小限にする」という考え方は、2013年の注意喚起から変わっていない。この記事は、考え方は古い資料から借り、手順の中身は、読む人が自分の機器の説明書で確かめる前提で書く。
注意
JPNICのページは、確認の方法を示した箇所で、多くのオープンリゾルバーを探す目的には使えず、そのような疑いのある操作は、セキュリティインシデントとして扱われる可能性がある、と書く。確かめる相手は、自分が管理するアドレスだけにする。他人のアドレスを順に試す使い方はしない。
03 用語 — 出てくる言葉を、先にそろえる
再帰的な問い合わせ（リゾルバー）
用語
再帰的な問い合わせは、DNSの利用者が、ドメイン名のIPアドレスを調べるために、キャッシュサーバー（リゾルバー）に頼む問い合わせである。JPNICのページは、この問い合わせを受けたリゾルバーが、複数のネームサーバーに問い合わせを行い、その結果を問い合わせた側に返す仕組みだと説明する。
キャッシュサーバーと、権威サーバー
JPRSの2006年の文書は、DNSサーバーを、キャッシュサーバー（再帰的な問い合わせを処理するもの）と、コンテンツサーバー（管理するドメインの情報を持ち、キャッシュサーバーの問い合わせに答えるもの）の2つに分ける。この記事で「権威サーバー」と書くものは、後者のコンテンツサーバーのことである。両方を1台でこなす兼用型もある、とその文書は書く。
DNSアンプ攻撃（DNSリフレクション攻撃）
用語
DNSアンプ攻撃は、送信元を偽装した問い合わせで、大量の応答や巨大な応答を相手に向けて送らせる攻撃である。JPCERT/CCの注意喚起は、これをオープンリゾルバーを使ったDDoS攻撃の手口として挙げる。JPNICのページは、同じ手口をDNSリフレクション攻撃とも書く。
送信元アドレスの偽装と、その対策
JPNICのページは、ネットワーク機器の側の対策として、本来は経由するはずのないIPアドレスのパケットをフィルタリングする設定を挙げる。この設定は、BCP38やSource Address Validationと呼ばれる、とも書かれている。インターネット接続の事業者側の対策に近いので、この記事の手順では扱わない。
CPE（利用者の宅内に置く機器）
JPNICのページには、ブロードバンドルーターやケーブルテレビのセットトップボックスを、CPE（利用者の宅内に置かれる機器）と呼ぶ箇所がある。家庭や小さな事務所のルーターが、オープンリゾルバーになっている可能性があるので、メーカーの製品アップデート情報を確かめてほしい、とそのページは書く。
04 型別 — 対象、確かめられないこと、確かめる手順
🅰 適用範囲 — この記事が役に立つ人
対象は、次のどれかに当てはまる人である。自分でDNSサーバーを立てている、またはそれを委託先に任せている。事務所や店舗のルーターの設定を管理している。仮想サーバーやレンタルサーバーに、DNSの機能を持つソフトウェアを入れている。JPCERT/CCの注意喚起が書くとおり、ソフトウェア製品の一部は、インストールのときに自動でDNSサーバーが入ることがある。一方、DNSの運用を事業者に任せていて、自分では何も立てていないサイトは、手順の前半で「立てていない」と確認できれば足りる。
🅱 この情報が測っていないこと
この記事は、次のことを確かめていない。休止の本当の理由。openresolver.jp自体の中身（応答を確認しただけで、機能は使っていない）。再開の時期が予定より早まるか、延びるか。日本国内のオープンリゾルバーの現在の数。JPNICのページが挙げる、ほかの確認サイトが今も使えるか。ほかの確認サイトを11月2日に開いたところ、1つは403、1つは404を返したが、これは筆者の環境からの応答であり、サイトの状態を決められる材料ではない。
🅲 手順1 — 自分が管理する「DNSに答えうるもの」を書き出す
メモ帳に、自分が管理するサーバー、ルーター、ネットワーク機器を1行ずつ書く。そのうち、DNSの問い合わせに答えうるもの、つまりDNSサーバーのソフトを入れたもの、ルーターのDNSの機能を使っているもの、製品に組み込まれたDNS機能のあるものを、印をつけて分ける。印がつく行が0なら、手順2〜4は短くて済む。印がつく行ごとに、外から見えるIPアドレスを書く。
🅲 手順2 — 機器の中で、待ち受けているかを確かめる
サーバーに入れる人は、機器の中で、DNSの待ち受け（通常は53番）があるかを確かめる。Linuxなら、ss -lnuでUDP、ss -lntでTCPの待ち受けの一覧が出る。一覧の中に「:53」で終わる行があるかを探す。Windowsなら、netstat -anを使う。行が無ければ、その機器はDNSの問い合わせを受け付けていない。この確認は、機器の中の話なので、外からの到達とは別である。待ち受けがあっても、ファイアウォールが外からを止めていることがある。
🅲 手順3 — 別の回線から、外の立場で問い合わせる
待ち受けがあった機器は、機器と同じネットワークの外から、自分で問い合わせてみる。スマートフォンのテザリングなど、別の回線から、dig @確かめたいIPアドレス example.com A、またはWindowsのnslookup example.com 確かめたいIPアドレスを打つ。結果の読み方は、筆者の案として3つに分ける。答えのIPアドレスが返れば、外からの再帰的な問い合わせに答えている疑いがある。拒否（REFUSED）が返れば、答えていない。タイムアウトなら、届いていない。同じネットワークの中から試すと、許可した範囲の中なので、答えが返るのは普通である。
🅲 手順4 — 試す道具が動くことを、先に確かめる
タイムアウトは、「答えていない」の証拠にも、「道具が動かなかった」の証拠にもなる。区別するために、同じ道具で、事業者が一般向けに公開しているDNSサービスに問い合わせて、答えが返ることを先に確かめる。答えが返れば、道具と回線は動いている。この確認は、自分のアドレスの確認とは別に、1回で足りる。
🅲 手順5 — 答えていたとき、設定を見直す
外から答えていた機器は、設定を見直す。JPNICのページは、DNSサーバーのソフトの設定例として、問い合わせを許可するIPアドレスを自組織や顧客のネットワークに限る書き方を示している。BINDのallow-recursionや、Unboundのaccess-controlが例である。権威サーバーだけの機器なら、再帰的な問い合わせに答えない設定にする。ルーターは、メーカーの製品アップデート情報と説明書を確かめる。設定を変えた後は、手順3をもう一度行い、結果を日付つきで書く。
🅲 手順6 — 結果を、機器ごとの1行に残す
確かめた結果は、機器の一覧に列を足して書く。足す列は5つで足りる。確かめた日、機器の中の待ち受け（あり・なし）、外からの結果（答えあり・拒否・応答なし）、確かめた人、次に確かめる日である。「ない」「問題なし」と書くだけにせず、何で確かめたかを一言添える。たとえば、「ss -lnuで:53の行が0」「別の回線からnslookupで応答なし」と書く。後から読んだ人が、同じ確認を繰り返せるからである。
ルーターや小さな機器は、画面の言葉で探す
ルーターのような小さな機器には、機器の中に入って待ち受けを調べる方法がないことが多い。その場合は、管理画面の中で「DNS」「DNSリレー」「DNSプロキシ」「外部からのアクセス」といった言葉を探し、設定の画面を写真で残す。外からの問い合わせ（手順3）の結果と、画面の設定が食い違うときは、メーカーの説明書とアップデート情報を確かめる。食い違いが解けないなら、メーカーに問い合わせる材料として、結果と日付を持っていく。
05 明日、担当サイトで確認できることチェックリスト
以下は、確認サイトに頼らず、自分が管理する機器が外からのDNSの問い合わせに答えていないかを確かめる13項目である。1〜3番目はお知らせの確認、4〜6番目は機器の書き出し、7〜10番目は機器の中と外からの確認、11〜13番目は結果の記録と続け方である。1項目は5分以内でできる。チェックの状態は、お使いのブラウザに保存され、サーバーには送られない。
- JPCERT/CCのお知らせを開き、休止の期間の2つの日付をメモ帳に書き写す
- お知らせの最終更新の日付を書き写し、次に開く日を2週間後に決める
- お知らせのページに再開の記載がないことを確かめ、確認した日を書く
- 自分が管理するサーバー、ルーター、ネットワーク機器を、1台ずつ1行で書き出す
- 書き出した機器のうち、DNSの問い合わせに答えうるものに印をつけ、印の数を書く
- 印のついた機器ごとに、外から見えるIPアドレスを1つずつ書く
- 印のついた機器のうち3台まで、機器の中でUDPとTCPの待ち受けの一覧を出し、「:53」の行があるかを書く
- 待ち受けがあった機器のうち1台で、別の回線から、自分のアドレスだけに問い合わせの道具を使い、結果を「答えあり・拒否・応答なし」のどれかで書く
- 同じ道具で、事業者が一般向けに公開しているDNSサービスに問い合わせ、答えが返ることを確かめて書く
- 外から答えていた機器があれば、機器の名前と設定を直す人の名前を書く
- メーカーの製品アップデート情報のページを、ルーターごとに1つ開き、最新の版と、自分の機器の版を書く
- 確かめた日、結果、確かめた人を1行にして、機器の一覧に書き足す
- 次に確かめる日を、確認サイトの再開の予定日（2027年1月31日）より前の、1か月後に決める
チェックが終わったら、機器の一覧に「最後に確認した日」を書く。再開したら、確認サイトでも1回確かめ、手元の結果と合うかを見る。
06 代替・他の選択肢 — 確認サイトが休んでいるあいだの、4つの方法
4つの方法を並べる
オープンリゾルバーかどうかを確かめる方法は、確認サイトだけではない。以下は、今回開いた資料と、筆者の案を分けて並べた表である。
| 方法 | できること | 限界 |
|---|---|---|
| 確認サイト（openresolver.jp） | アドレスを入れて、答えるかを調べる | 2027年1月31日まで休止の予定。11月2日は503 |
| JPNICのページが挙げる、ほかの確認サイト | 同様に確認できると、2014年7月更新のページは書く | 今も使えるかは未確認。11月2日は403と404 |
| 自分で外から問い合わせる | 結果を、答えあり・拒否・応答なしで読める | 別の回線と、自分のアドレスだけが条件 |
| 機器の中で待ち受けを調べる | DNSを受け付けているかが分かる | 外からの到達は、別に確かめる |
貸しサーバーで、DNSを立てていないとき
DNSの運用を、ドメインの管理会社やホスティング事業者に任せているサイトは、サーバー側で再帰的な問い合わせに答える設定をしていないのが普通である、というのが筆者の読みである。その場合、確かめるのは、手順2で「:53」の待ち受けが無いことと、手順3で外から答えが返らないことの2つで済む。ネームサーバーの設定を、事業者の画面で変えている場合は、変更の履歴を確認する。
確認サイトの再開を待つ人へ
予定は2027年1月31日だが、お知らせは、早く再開する場合があると書く。再開の知らせは、お知らせのページで出る。見に行く日を決めておかないと、休止が終わったことに気づけない。05章の2番目の項目は、そのための確認である。
事業者へ聞くときの言い方
運用を委託先に任せている場合は、「再帰的な問い合わせに答えない設定になっているか」「確かめた日はいつか」を、書面で聞く。聞くときに、確認サイトが休止中であることを添えると、手元の確認が必要な理由が伝わりやすい。
07 当サイトで確かめたこと — 当サイトのサーバーは、DNSの待ち受けが0で、外からの問い合わせにも答えなかった
機器の中で確かめたこと
2026年11月2日の10時台に、当サイトのサーバーの中で、UDPとTCPの待ち受けの一覧を出し、「:53」の行を数えた。UDPは0行、TCPは0行だった。当サイトのサーバーは、DNSの問い合わせを受け付ける待ち受けを、持っていなかった。
外から確かめたこと
同じ日の10時台に、手元のパソコンから、当サイトのサーバーのIPv4アドレスへ、example.comの問い合わせを送った。タイムアウトを5秒にして、再送1回を含む2回とも、応答は無かった。同じ道具で、事業者が一般向けに公開しているDNSサービスに問い合わせると、答えが返った。道具は動いており、当サイトのサーバーが答えなかった、と言える。IPv6のアドレスと、ほかの回線からの確認は、していない。
ドメインのDNSは、事業者の側にある
親のドメイン（usersupports.com）のネームサーバーを調べると、3つとも、サーバーの事業者のドメインの名前だった。つまり、ドメインのDNSの運用は、当サイトのサーバーの上ではなく、事業者の側にある。事業者のネームサーバーが、再帰的な問い合わせに答えるかは、確かめていない。確かめる対象が、当サイトの管理するアドレスではないためである。
実務のヒント
「立てていない」ことを確かめるには、機器の中の待ち受けと、外からの問い合わせの2つを、別々の結果として書く。片方だけだと、「ファイアウォールが止めている」のか「元から無い」のかが区別できない。
確認サイトの代わりになる、当サイトの無料ツール
当サイトには、外から見える設定を調べる会員向けの無料ツールがある。ドメインのDNSのレコード（A、AAAA、MX、NS、TXTなど）や、開いているポートを外から調べる、と案内されている。ただし、案内の文には、再帰的な問い合わせに答えるかを確かめる、とは書かれていない。このため、この記事は、同ツールの結果を、オープンリゾルバーの判定には使わない。使うのは、ネームサーバーの名前など、手順の前提を確かめるところまでにとどめる。
当サイトの今後の確認
当サイトは、確認サイトが再開した後に、当サイトのサーバーのアドレスを確認サイトでも1回確かめ、手元の結果と合うかを見る。合わなければ、日付つきでこの記事に追記する。再開の日付は、JPCERT/CCのお知らせで確かめる。
08 このテーマは、ここまで — 外から確かめて、台帳に書く流れ
これまでの記事
- 控えファイルを外から確かめた日 ── 当サイトで読めたのは25本。「403でも置かない」理由と、次から積もらない手順 — 外から叩いて、状態コードで確かめた記録
- Basic認証のパスワードのファイルが、公開の場所の中に9本あった ── 外からは全部403だったが、読めなかったのは1つの決まりのおかげだった。確かめ方と、公開の外へ移した記録 — 外からの結果が、中の状態の証拠にならない例
- 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった ── Apache 2.4.***を、記事を公開したその日に上げるまで — 書いたチェック項目を、自分に当てる
- 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった ── 当サイトが外から圧縮を受け取る場所を数え、その日のうちに塞いだ記録と、同じ日にサーバーが止まったあとの確かめ方 — 数え方と、止まったあとの確かめ方
- IPAは、外部に公開しているアプリ・利用中の外部サービス・保有データの3つを速やかに点検するよう呼びかけた ── 管理画面の利用者・ログの保持日数・不要なデータを台帳にして確かめる13項目（2026年10月時点） — 機器と外部サービスを台帳にする
今回の記事の位置
これまでの記事は、「自分の管理するものを一覧にし、外からの見え方を確かめる」という型を使ってきた。今回は、その型を使う材料として、確認サイトの休止が出た。変わったのは、確認の道具が約3か月使えなくなったことだけで、確かめる対象の機器の状態は変わっていない。手順は、機器の中と外の2方向から確かめて、結果を日付つきで残す、という前と同じ型である。
次に続報が出たときは、JPCERT/CC のお知らせの最終更新の日付を先に見る。日付が動いて再開が書かれていたら、確認サイトでも1回確かめて、手元の結果と比べる。日付が動いていなければ、手元の結果の「確認した日」だけを書き足す。
現在の貴方のIPアドレス
このサイトで書いている人
