drill は「自分で決めた1台の DNS サーバーに、決めた方法で問い合わせて生の答えを見る」コマンドで、dnschecker は「世界各地の公開キャッシュサーバーが今どう答えているかを一覧で見る」Web サービスです。前者は設定の正しさ、後者は変更の広がり具合を確かめるのに向いています。この記事では、2つの道具の違いを整理したうえで、DNS 事業者の移転と DNSSEC の導入という具体的な作業の流れの中で、どの段階でどちらを使うかを説明します。
2つの道具の違い
まず、仕組みの違いを押さえておくと、結果が食い違ったときの読み方が分かります。
| 観点 | drill | dnschecker |
|---|---|---|
| 実行する場所 | 自分のパソコンやサーバー | ブラウザ（サービス側の各地の拠点から問い合わせる） |
| 問い合わせ先 | 自分で指定（権威サーバーも可） | サービスが選んだ各地の公開キャッシュサーバー |
| 見えるもの | 1台の答えの全体（フラグ・TTL・各セクション） | 多数の拠点の答えの値と、そろっているかどうか |
| DNSSEC | 署名の連鎖をたどって確かめられる | 主に値の表示（検証の過程は見えない） |
| 自動化 | スクリプトや監視に組み込める | 手作業での確認が中心 |
drill は NLnet Labs の ldns に付属するコマンドで、Debian・Ubuntu では ldnsutils、Fedora などでは ldns 系のパッケージ、macOS では Homebrew の ldns で入ります。FreeBSD では標準で入っています。使い方は dig に近く、drill 名前 種別 で問い合わせ、@ で問い合わせ先を指定します。dig と違い、drill の -t は種別ではなく「TCP で問い合わせる」指定なので、種別は名前の後ろに書きます。
dnschecker（dnschecker.org）は、ドメイン名と種別を入れると、各地の公開キャッシュサーバーの答えを地図と一覧で表示するサービスです。DNS の確認以外の道具も多く提供されています。拠点の数や画面の構成は変わることがあるため（2026年10月現在）、使う際は画面の表示に従ってください。
大事なのは、dnschecker が見ているのは「キャッシュサーバーが今持っている答え」だという点です。権威サーバーの設定が正しくても、キャッシュの残り時間が切れるまでは古い値が表示されます。また、dnschecker は現在の委任（レジストラに登録された NS）に従って答えを集めるため、まだ切り替えていない新しい DNS 事業者の設定内容は確かめられません。
移転作業の段階ごとの使い分け
WordPress サイトのドメインを、ある DNS 事業者から別の事業者へ移す場合を例に、段階ごとに使う道具を整理します。
1. 移転前：現在の設定を控え、TTL を下げたことを確かめる
最初に、現在の権威サーバーから主なレコードを引いて控えておきます。これは移転後に比較するための元データです。
drill example.com NS
drill @ns1.old-dns.example.net example.com A
drill @ns1.old-dns.example.net example.com MX
drill @ns1.old-dns.example.net example.com TXT
drill @ns1.old-dns.example.net www.example.com A移転に備えて TTL を短くした場合は、権威サーバーに聞いた答えの TTL が新しい値になっているかを確かめます。権威サーバーの答えであることは、ヘッダーの flags: に aa が付いているかで判断します。この段階は dnschecker では確かめられません。キャッシュサーバーには古い長い TTL の答えが残っているためです。
2. 切り替え前：新しい事業者の設定を直接確かめる
新しい事業者にゾーンを作ったら、NS を切り替える前に、新しい権威サーバーに直接問い合わせて中身を比べます。
drill @ns1.new-dns.example.net example.com A
drill @ns1.new-dns.example.net example.com MX
drill @ns1.new-dns.example.net example.com TXT手順1で控えた値と同じになっているかを、レコードごとに確かめます。メール関連の MX や SPF の TXT は移し忘れが起きやすく、切り替え後に気づくとメールが届かなくなります。この段階も drill の役割です。
3. NS の切り替え直後：委任が変わったかを確かめる
レジストラで NS を変更したら、親ゾーン（.com や .jp など）の委任が新しい NS になったかを -T で確かめます。-T はルートから順に委任をたどって表示する指定です。
drill -T example.com途中の行で、親ゾーンが返す NS が新しい事業者のものになっていれば、委任の変更は反映されています。
4. 待ち時間：世界各地への広がりを見る
ここからが dnschecker の出番です。種別に A や NS を選んで調べると、各地のキャッシュサーバーが新旧どちらの値を返しているかが一覧できます。切り替え後しばらくは新旧が混ざるのが普通で、古い値の拠点は TTL が切れた順に新しい値へ入れ替わっていきます。
特定のキャッシュサーバーの残り時間を知りたいときは、drill でそのサーバーに聞き、答えの TTL を見ます。
drill @1.1.1.1 example.com A
drill @8.8.8.8 example.com A5. DNSSEC：署名の連鎖を確かめる
DNSSEC を導入する、または署名したまま事業者を移す場合は、DS の登録と鍵の対応が崩れると、検証をするキャッシュサーバーで名前解決が失敗します。署名の連鎖を確かめるのは drill の役割です。
drill -D example.com A # DNSSEC の情報（RRSIG）も受け取る
drill -S example.com A # ルートから署名の連鎖をたどって検証する-S は署名を1段ずつたどり、各段が検証できたかを記号付きで表示します（記号の意味は出力の末尾に凡例として出ることが多く、表示は版によって異なります）。トラストアンカーのファイルを -k で指定できる版もあります。dnschecker では、検証の過程ではなく、各地で答えが返っているかどうかを見る使い方になります。DNSSEC を有効にしたドメインで「一部の拠点だけ答えが返らない」場合は、その拠点のキャッシュサーバーが検証をしていて失敗している可能性があり、drill の -S で原因を確かめます。
結果が食い違ったときの判断
2つの道具の結果が違うときは、次の順に考えると判断を誤りにくくなります。
- drill で権威サーバーに聞いた答えが正しいか：ここが間違っていれば、dnschecker の結果にかかわらず設定の修正が必要です。
- 権威サーバーは正しく、dnschecker の一部が古い：キャッシュの残り時間の問題です。TTL が切れるのを待ちます。移転前に TTL を下げていなかった場合は、元の TTL の長さだけ待つ必要があります。
- dnschecker の多くの拠点で失敗し、drill では答えが返る：DNSSEC の検証の失敗、権威サーバーの一部が応答していない、特定の地域から権威サーバーに届いていない、などを疑います。drill で NS に並ぶすべての権威サーバーに1台ずつ聞いて確かめます。
dnschecker の結果は「その拠点のその瞬間の見え方」です。利用者が使っているプロバイダーのキャッシュサーバーが含まれているとは限らないため、問い合わせを受けた利用者の環境で確かめたい場合は、その利用者の問い合わせ先に drill で聞く方が近い結果になります。
使うときの注意
- 社内用の名前を入れない：dnschecker に入力した名前は外部のサービスに送られ、各地の公開サーバーに問い合わせられます。社内だけで使う名前や公開前のサブドメインは、手元の drill で確かめます。
- 問い合わせを繰り返しすぎない：結果を待つ間に何度も再読み込みしても、キャッシュの残り時間は短くなりません。数分おきに見る程度で足ります。
- 変更前に控えを取る：レコードを作り直す前に、現在の値を drill の出力として保存しておくと、元に戻すときに迷いません。
まとめ
- drill は1台のサーバーの生の答えを見るコマンド、dnschecker は各地のキャッシュサーバーの見え方を一覧するサービスです。
- 移転前の控え、切り替え前の新しい事業者の確認、委任の変更の確認、DNSSEC の連鎖の確認は drill で行います。
- 切り替え後に変更がどこまで広がったかは dnschecker で見ます。
- 食い違ったら、まず drill で権威サーバーの答えを確かめ、正しければキャッシュの問題と考えます。