drill は ldns ライブラリに付属する DNS の問い合わせツールで、dig とよく似た出力に加えて、ルートからのトレース（-T）や DNSSEC 署名の追跡（-S）を備えています。この記事では「名前が引けない」「一部の環境だけ失敗する」といった症状を、drill の応答コードとフラグを読みながら原因に近づけていく手順を、よくある原因の順に説明します。
導入と基本の形
drill は多くの Linux ディストリビューションや Homebrew でパッケージとして配布されています。パッケージ名はディストリビューションによって異なります（2026年10月現在）。
# Debian / Ubuntu
sudo apt install ldnsutils
# Fedora など（パッケージ名は ldns-utils）
sudo dnf install ldns-utils
# Alpine Linux
sudo apk add drill
# macOS（Homebrew。ldns に drill が含まれる）
brew install ldns基本の形は「drill 名前 種別 @問い合わせ先」です。問い合わせ先を省くと /etc/resolv.conf に書かれたキャッシュサーバーを使います。
drill www.example.com A
drill www.example.com A @1.1.1.1
drill example.com MX @ns1.example.net出力のどこを見るか
drill の出力は dig とほぼ同じ構成です。以下は説明用の例で、名前と値は架空です。
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40213
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 18 msec
;; SERVER: 1.1.1.1
;; WHEN: ...
;; MSG SIZE rcvd: 49デバッグで最初に見るのは2行目までです。
- rcode：応答コード。
NOERROR（正常）、NXDOMAIN（名前が存在しない）、SERVFAIL（サーバー側で答えを作れなかった）、REFUSED（問い合わせを拒否した）が代表的です。dig ではstatus:と表示される部分です。 - flags：
qrは応答であること、rdは再帰を求めたこと、raは相手が再帰に対応していること、aaは権威ある答えであること、adは DNSSEC の検証に成功したとキャッシュサーバーが示していること、tcは応答が切り詰められたことを表します。 - 各セクションの件数：ANSWER が0件で AUTHORITY に SOA が1件だけ、という形は「名前はあるがその種別のレコードが無い」（NODATA）か、NXDOMAIN のときに見られます。
以下、症状ごとに原因の多い順に確認していきます。
原因1：権威サーバーの設定と、キャッシュの古い答えが食い違っている
一番多いのは、レコードを変更したのに古い値が返る、新しく作った名前が引けない、というケースです。まず権威サーバーとキャッシュサーバーの答えを並べます。
# 権威サーバーの名前を調べる
drill example.com NS
# 権威サーバーに直接聞く（再帰を求めない）
drill -o rd www.example.com A @ns1.example.net
# キャッシュサーバーに聞く
drill www.example.com A @1.1.1.1-o はヘッダーのビットを操作するオプションで、大文字で立て、小文字で下ろします。-o rd は再帰要求を外す指定です。権威サーバーの応答の flags に aa があり、値が意図どおりなら、権威サーバーは正しく設定されています。キャッシュサーバーだけが古い値を返すなら、ANSWER の TTL（残り秒数）が切れるのを待ちます。新しく作った名前で NXDOMAIN が続く場合は、作成前に問い合わせた「存在しない」という答えがキャッシュされている可能性があります。その保持時間は、AUTHORITY に出る SOA の最後の数値と SOA 自体の TTL の小さいほうが目安です。
権威サーバー自身が古い値や NXDOMAIN を返すなら、待っても直りません。DNS 事業者の管理画面で、レコードの名前（www の有無、サブドメインの綴り）と、編集しているゾーンが今の委任先の事業者のものかを見直します。
原因2：委任の途中が壊れている
権威サーバーのどれかが応答しない、委任先の登録が古い、といった問題は、ルートからたどると見つけやすくなります。
drill -T www.example.com A-T はルートサーバーから順に問い合わせ、各段の委任と最後の答えを表示します。このとき @サーバー の指定は使われません。途中の段で古い DNS 事業者のネームサーバーが出てくるなら、レジストラ側の NS 変更が済んでいないか反映待ちです。特定のネームサーバーへの問い合わせだけが時間切れになるなら、そのサーバーに drill -o rd ... @そのサーバー で個別に問い合わせ、REFUSED や aa の無い答えが返らないかを確かめます。委任されているのにそのドメインを預かっていないサーバー（lame delegation）は、こうした応答になります。
原因3：DNSSEC の検証に失敗している（SERVFAIL）
キャッシュサーバーが SERVFAIL を返し、権威サーバーに直接聞くと値が返る、という組み合わせは DNSSEC を疑う典型です。検証を行うキャッシュサーバーは、署名の検証に失敗すると答えを返さず SERVFAIL にします。
切り分けには CD（Checking Disabled）ビットを使います。CD を立てると、キャッシュサーバーは検証をせずに答えを返します。
# 通常の問い合わせ
drill www.example.com A @1.1.1.1
# 検証を無効にして問い合わせる
drill -o CD www.example.com A @1.1.1.1CD 付きでは答えが返り、CD 無しでは SERVFAIL になるなら、原因は DNSSEC の検証失敗とほぼ判断できます。続いて署名の連鎖を追います。
drill -S www.example.com A-S は、その名前の署名を親ゾーンへ向かってたどり、信頼の起点となる鍵まで検証を試みます。起点の鍵（トラストアンカー）は -k ファイル で指定でき、指定しない場合は既定の場所（Debian 系のマニュアルでは /usr/share/dns/root.key）のファイルが使われます。既定の場所はビルドや配布元によって異なることがあるので、エラーになる場合は手元の man drill で確認してください。
よくある原因は、DNS 事業者を移転した後に親ゾーンの DS レコードを更新していない、鍵の更新途中で古い DS が残っている、署名の有効期限が切れている、のいずれかです。どこで連鎖が切れているかを図で確かめるには DNSViz が分かりやすく、drill の結果と合わせて見ると判断がぶれません。DS の変更はレジストラ側の作業になることが多く、誤ると名前解決が止まるため、変更前に現在の値を控えておきます。
原因4：応答が大きく、UDP で受け取れていない
TXT レコードが多いドメインや DNSSEC の署名付き応答は、サイズが大きくなりがちです。途中の機器が大きな UDP パケットや断片化したパケットを落とす環境では、時間切れや不安定な失敗になります。
# TCP で問い合わせる
drill -t example.com TXT @ns1.example.net
# 切り詰められたら EDNS0 のバッファを広げ、だめなら TCP に切り替える
drill -a example.com TXT @ns1.example.net
# DNSSEC の署名も含めて要求する（DO ビット）
drill -D example.com DNSKEY @ns1.example.netUDP では失敗して TCP では成功するなら、経路上の機器か、権威サーバー側の TCP 対応・応答サイズの設定に問題があります。権威サーバーが TCP の 53 番ポートを受け付けていない場合も、大きな応答は受け取れません。サーバーを自分で運用しているなら、ファイアウォールで TCP の 53 番も許可されているかを確認します。
原因5：手元のリゾルバー設定が想定と違う
@ を付けたときは正常で、付けないときだけ失敗するなら、手元の設定が原因です。drill は既定で /etc/resolv.conf を読みますが、systemd-resolved を使う環境ではそこに 127.0.0.53 のようなローカルのスタブだけが書かれていることがあります。
# 使われているキャッシュサーバーを確かめる
cat /etc/resolv.conf
# 別の設定ファイルを読ませて比べる
drill -c /run/systemd/resolve/resolv.conf www.example.com A後者のファイルの場所は systemd-resolved を使う環境での一例です。内部と外部で答えを変える構成（社内 DNS）では、社内のキャッシュサーバーと公開のキャッシュサーバーで答えが違うのが正常な場合もあります。
調べるときの注意
- 問い合わせは読み取りだけの操作ですが、権威サーバーに短い間隔で大量に送ると応答を制限されることがあります。繰り返し確認するときは間隔を空けます。
- 他人のドメインやサーバーへの調査は、自分の管理範囲か、許可を得た範囲にとどめます。
- 設定を直すときは、DNS 事業者の管理画面で変更前のレコードを控え、TTL を短くしてから作業すると、誤りに気付いたときの戻しが早くなります。
まとめ
- drill の出力では、まず rcode（NOERROR / NXDOMAIN / SERVFAIL / REFUSED）と flags（aa / ad / tc など）を読みます。
- 権威サーバーへの問い合わせ（
-o rd）とキャッシュサーバーへの問い合わせを並べ、設定の誤りかキャッシュの残りかを分けます。 - 委任の問題は
-Tでルートからたどり、古いネームサーバーや応答しないサーバーを探します。 - SERVFAIL は
-o CDの有無で比べ、DNSSEC が原因なら-Sと DNSViz で連鎖の切れ目を確かめます。 - UDP だけ失敗するなら
-tや-aで TCP と比べ、手元だけ失敗するなら resolv.conf を見直します。