doggo は v1.4.0 で --trace オプションが加わり、ルートサーバーから権威サーバーまでの委任の経路を自動でたどれるようになりました。この記事では、トレースの実行方法、出力の各行の読み方、そして「どの段で止まったか」から原因を絞り込む手順を、キャッシュサーバーへの通常の問い合わせとの比べ方も含めて説明します。
トレースで何が分かるのか
ふだん doggo example.com のように問い合わせると、答えを返すのはパソコンに設定されたキャッシュサーバー（フルリゾルバー）です。キャッシュサーバーは裏でルート、TLD（.com や .jp）、ドメインの権威サーバーへと順に問い合わせていますが、その途中経過は見えません。返ってくるのは最終的な答えと、キャッシュの残り時間だけです。
--trace を付けると、doggo 自身がこの道のりを再現します。ソースコードと変更履歴を見る限り、動きは次のとおりです（2026年10月現在の v1.4 系）。
- 組み込みのルートヒント（IANA が公開するルートサーバーの一覧）から開始し、OS に設定されたキャッシュサーバーは使わない
- 各段の権威サーバーに再帰要求（RD ビット）を立てずに問い合わせ、返ってきた委任（referral）に従って次の段へ進む
- 委任先のネームサーバーにグルー（住所のヒント）が無ければ、その名前の A／AAAA を別途たどって調べる
- UDP の応答が切り詰められていれば TCP で問い直す
- CNAME が返った場合は、別名の先を同じトレースの中で追いかける
一方で、DNSSEC の署名検証は行いません。DO ビットを立てて問い合わせることはできても、署名が正しいかの判定はトレースの対象外です。DNSSEC が絡む不具合は drill の -S や DNSViz で別に確かめます。
導入とバージョンの確認
--trace は 2026年9月公開の v1.4.0 で追加された機能です。古い版にはないため、まず手元の doggo が対応しているかを確かめます。
# ヘルプに --trace が出てくるかを確認する
doggo --help | grep -- --trace何も表示されなければ古い版なので、更新します。公式 README に載っている主な導入方法は次のとおりです。パッケージマネージャー経由だと配布が新しい版に追いつくまで時間がかかることがあるので、更新後にもう一度ヘルプを確認してください。
# Homebrew（macOS / Linux）
brew upgrade doggo || brew install doggo
# Windows（Scoop）
scoop update doggo
# Go で入れる場合
go install github.com/mr-karan/doggo/cmd/doggo@latest基本のトレースを実行する
名前と種別を指定して --trace を付けるだけです。種別を省略すると A だけをたどります。通常の問い合わせでは A と AAAA の両方を引くので、IPv6 の経路を見たいときは AAAA を明示します。
doggo www.example.com --trace
doggo www.example.com AAAA --trace
doggo example.com MX --trace表示はおおよそ次の形になります。下の例は説明用に作ったもので、名前や数値は架空です。色分けや細かな書式は版によって変わることがあります。
TRACE www.example.com A IN
1 . root [referral]
-> a.root-servers.net (198.41.0.4) udp 14ms NOERROR
delegates com. to a.gtld-servers.net (192.5.6.30), b.gtld-servers.net (192.33.14.30), ... + 9 more
2 com. delegation [referral]
-> a.gtld-servers.net (192.5.6.30) udp 31ms NOERROR
delegates example.com. to ns1.example.net (192.0.2.53), ns2.example.net (198.51.100.53)
3 example.com. authoritative [ok]
-> ns1.example.net (192.0.2.53) udp 22ms NOERROR
ANSWER
www.example.com. A 300s 203.0.113.10
-- 3 hops · 67ms total · answer from ns1.example.net --出力の各行の読み方
段（hop）の見出し
左端の数字が段の番号、続いてその段で問い合わせたゾーン、最後に役割と結果の印が並びます。役割は、ルートゾーンなら root、次の段へ委任しただけの段なら delegation、最終的な答えを返した段なら authoritative です。角かっこの中は結果で、[referral] は「ここではなく下の段に聞け」という委任、[ok] は答えが得られたこと、[nxdomain] は名前が存在しないこと、[nodata] は名前はあるがその種別のレコードが無いこと、[error] は問い合わせに失敗したことを表します。
矢印で始まる行（問い合わせの試行）
-> の行は、実際に問い合わせたサーバー名と IP アドレス、通信方式（udp / tcp）、応答時間、応答コードです。1台目が応答しなかった場合は FAILED の行が残り、その下に2台目への試行が続きます。失敗の行が残っていても最終的に答えが得られていれば、利用者からは見えにくい不調が起きている、という読み方をします。truncated; retrying over TCP と出るのは、応答が大きすぎて UDP に収まらず TCP で取り直したことを示します。
delegates の行（委任先）
その段のサーバーが「この名前は次のサーバーに任せている」と答えた内容です。かっこ内の IP アドレスは、委任と一緒に渡されたアドレスのヒントです。ここに表示されるネームサーバー名が、レジストラ（ドメインの登録業者）に登録した値と一致しているかが、トレースで一番大事な確認点です。
最後のまとめ行
段の数、合計時間、そしてどのサーバーから答えを得たかが表示されます。answer from の後ろのサーバー名が、いま使っているつもりの DNS 事業者のものかを確認してください。
止まった場所から原因を絞り込む
トレースが期待どおりにいかないときは、どの段でどう止まったかで原因の見当がつきます。よくある順に並べます。
- **最後の段が
[nxdomain]や[nodata]になる**。権威サーバーが「そのレコードは無い」と答えています。レコードを作っていない、別の名前（www の有無など）で作った、あるいは DNS 事業者を乗り換えたのに旧事業者の管理画面で作業した、のどれかが多い原因です。答えたサーバー名と、レコードを編集した管理画面の事業者が同じかを照らし合わせます。 - 委任先が旧事業者のネームサーバーのまま。TLD の段の delegates 行に古いネームサーバー名が出ているなら、レジストラ側の NS 変更が済んでいないか、まだ反映待ちです。レジストラの管理画面で登録内容を確認します。
- 委任先のサーバーがすべて FAILED になる。登録された NS がそのドメインを預かっていない、サーバーが停止している、ファイアウォールで 53 番ポートが閉じている、などが考えられます。DNS 事業者の側でゾーンが作成され、有効になっているかを確認します。
- 一部のサーバーだけ FAILED になる。答えは返るものの冗長性が失われている状態です。失敗したサーバー名を控え、時間をおいて再実行しても同じなら事業者に問い合わせます。
- CNAME の先で止まる。別名の先のゾーンでレコードが消えている、外部サービス（CDN やメール配信サービス）側の設定が外れている、といった場合です。結果の印が別名を示しているときは、最後に出てくる名前を手がかりに、そのサービスの管理画面を確認します。
トレースが最後まで成功して正しい値が返るのに、ブラウザでは古いサイトが表示される、という場合は権威サーバー側に問題はありません。次の節のとおり、キャッシュサーバーの側を確認します。
キャッシュサーバーの答えと比べる
トレースで得た「正しい答え」と、世の中のキャッシュサーバーが持っている答えを比べると、反映待ちなのか設定ミスなのかを切り分けられます。doggo は複数のサーバーに同時に問い合わせられるので、この比較が得意です。
# 主要な公開キャッシュサーバーと手元の設定を並べて比べる
doggo www.example.com A @1.1.1.1 @8.8.8.8 @9.9.9.9 --time
doggo www.example.com ATTL の列は、そのキャッシュが期限切れになるまでの残り秒数です。トレースで得た値と違う答えを返しているサーバーがあっても、TTL の残りが減っていくなら、その時間が過ぎれば入れ替わります。
海外の拠点から見た答えを確かめたい場合は、Globalping という外部の計測網を経由する --gp-from も使えます。ただし --trace とは同時に使えません。トレースは手元から各サーバーへ直接問い合わせる必要があるためです。
スクリプトや監視で使う
結果を機械的に扱いたいときは出力形式を変えます。--short では段ごとに1行（ゾーン、結果、サーバー名、IP、通信方式、応答時間、応答コード）がタブ区切りで出ます。--json ではトレース全体が JSON になり、状態や各段の情報を jq などで取り出せます。
ソースコード上は終了コードも区別されていて、0 が正常終了（存在しないという権威ある答えを含む）、1 が指定の誤り、2 が途中まで進んでから失敗、9 が1段も進めなかった場合とされています（2026年10月現在）。監視に組み込む場合は、手元の版で実際の値を確認してから使ってください。
使うときの注意点
--traceは権威サーバーに直接問い合わせます。短い間隔で繰り返し実行すると相手の負荷になり、応答を制限される原因にもなります。監視に使うなら間隔を十分に空けます。- 社内ネットワーク専用の名前（内部と外部で答えを変える構成の内部側）は、ルートから公開の経路をたどるため確認できません。
--any、--gp-from、-4と-6の同時指定などは、トレースと組み合わせるとエラーになります。IPv6 の経路が不安定な環境では-4を付けると安定することがあります。@サーバーを指定しても、そのサーバーはルートの情報を得る最初の問い合わせに使われるだけで、トレース全体の問い合わせ先にはなりません。
まとめ
- doggo の
--trace（v1.4.0 以降）は、ルートヒントから権威サーバーまでを再帰要求なしでたどり、段ごとの問い合わせ先・応答コード・委任先を表示します。 - 読むべき点は、委任先のネームサーバー名がレジストラの登録と一致しているか、最後に答えたサーバーが使っている DNS 事業者のものか、の2つです。
- 止まった段と結果の印（nxdomain / nodata / FAILED / 別名）から、レコードの未作成、NS 変更の未反映、サーバー停止などを順に疑います。
- トレースが正しいのに表示が古いなら、複数のキャッシュサーバーへ同時に問い合わせて TTL の残りを確認します。
- DNSSEC の検証は行わないので、署名の問題は drill や DNSViz で別に確かめます。