おい、そこの君、ちょっと聞いてくれ。大規模データセンターの片隅で、今日もネットワークの魔物と格闘しているNOCのシニアエンジニアだ。俺たちの仕事は、目に見えないパケットの流れを読み解き、どこかでひっそりと息を潜めている障害の芽を摘み取ること。そのための強力な「メス」の一つが、今日話すdigコマンドだ。
「え、DNSの名前解決ならnslookupで十分じゃないですか？」なんて言ってるそこの若手、ちょっと待て。nslookupは確かに手軽だが、診断ツールとしてはおもちゃみたいなもんだ。本物の戦場で使うべきは、dig。こいつはDNS応答の深層までを覗き込み、ネットワークの闇を照らす強力なサーチライトなんだ。
Web APIの設計者も、インフラの運用エンジニアも、このdigコマンドの出力を隅々まで読み解く力は、今日日必須のスキルだ。なぜなら、Web APIのバックエンドはほとんどが名前解決に依存しているからな。名前解決の遅延や失敗は、サービス全体のパフォーマンス低下や停止に直結する。さあ、一緒にdigコマンドの真髄に迫っていこうじゃないか。
—
digコマンド、その基本のキ：なぜnslookupではなくdigを使うのか？
まず、なぜdigなのかという話から入ろう。昔はnslookupも使われていたが、現代のDNSトラブルシューティングでは、ほとんどのプロフェッショナルがdigを使っている。その理由は単純だ。digの方が圧倒的に多機能で、詳細な情報を提供し、RFCに準拠した挙動をするからだ。
nslookupは、歴史的な経緯もあり、一部のディストリビューションでは非推奨になっている。一方、digはDNSに関するあらゆる情報を引き出すための柔軟なオプションを備えている。DNSの挙動を深く理解し、正確な診断を下すためには、digが必須なんだ。
基本構文は至ってシンプル。調べたいドメイン名を引数に渡すだけだ。
# 基本的なdigコマンドの実行例
dig myapi.example.jpこのコマンドを実行すると、指定したドメイン名myapi.example.jpの名前解決に関する詳細な情報が返ってくる。では、この出力が一体何を意味するのか、その構造を一つずつ紐解いていこう。
—
DNS応答メッセージの構造を解剖する：セクションを読み解く力
DNSの応答メッセージは、RFC1035で定義されている通り、複数のセクションに分かれている。これは、単にIPアドレスを返すだけでなく、その情報がどこから来たのか、関連する他の情報は何か、といったメタデータを合わせて提供するためだ。このセクション構造を理解しているかどうかで、トラブルシューティングのスピードと精度が段違いになる。
ここでは、仮想的なAPIエンドポイントmyapi.example.jpを例に、そのdigコマンドの出力がどう構成されているかを見ていこう。
# myapi.example.jp の dig 出力例（架空のドメインとデータ）
dig myapi.example.jp
; <<>> DiG 9.16.1-Ubuntu <<>> myapi.example.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;myapi.example.jp. IN A
;; ANSWER SECTION:
myapi.example.jp. 300 IN CNAME api-lb.example.jp.
api-lb.example.jp. 60 IN A 192.0.2.10
api-lb.example.jp. 60 IN A 192.0.2.11
;; AUTHORITY SECTION:
example.jp. 3600 IN NS ns1.example.jp.
example.jp. 3600 IN NS ns2.example.jp.
;; ADDITIONAL SECTION:
ns1.example.jp. 3600 IN A 198.51.100.1
ns2.example.jp. 3600 IN A 198.51.100.2
;; Query time: 10 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Mar 20 10:30:00 JST 2024
;; MSG SIZE rcvd: 210この出力には、大きく分けて4つの重要なセクションがある。それぞれ詳しく見ていこう。
QUESTION SECTION: あなたは何を尋ねたのか
ここには、まさに「君が何をDNSサーバーに問い合わせたのか」が記載されている。
上の例で言えば、
;; QUESTION SECTION:
;myapi.example.jp. IN A;myapi.example.jp.: 問い合わせたドメイン名。末尾の.はルートドメインを表す。IN: クラス。通常はIN(Internet) を意味する。A: 問い合わせたレコードタイプ。ここではAレコード（IPv4アドレス）を求めている。
他にもAAAA (IPv6アドレス)、MX (メールエクスチェンジャー)、NS (ネームサーバー)、CNAME (正規名)、TXT (テキスト情報)、SRV (サービスレコード) など、様々なレコードタイプを問い合わせることができる。Web APIの文脈では、AやAAAAが最も頻繁だが、サービスディスカバリにSRVレコードを使うケースもあるので、頭に入れておこう。
ANSWER SECTION: それに対する答えだ
ここには、DNSサーバーが「あなたへの回答」として見つけたリソースレコード（RR）がリストされる。Web APIのエンドポイント解決において、ここが最も重要だ。
上の例では、myapi.example.jpに対する問い合わせで、2つのレコードが返ってきている。
;; ANSWER SECTION:
myapi.example.jp. 300 IN CNAME api-lb.example.jp.
api-lb.example.jp. 60 IN A 192.0.2.10
api-lb.example.jp. 60 IN A 192.0.2.11myapi.example.jp.: ドメイン名。300(または60): TTL (Time To Live)。このレコード情報がキャッシュサーバーに保持される時間（秒数）。この値は非常に重要だ。- 重要ポイント: TTLが短いと、レコードの変更が素早く伝播するが、キャッシュヒット率が下がり、DNSクエリが増える。逆にTTLが長いと、キャッシュヒット率が上がり、DNSクエリは減るが、レコード変更の伝播に時間がかかり、障害時の切り替えが遅れる可能性がある。Web APIのバックエンド切り替えなどで「DNS反映遅い！」と怒鳴り散らした経験はないか？それは大抵、このTTLのせいだ。
IN: クラス (Internet)。CNAME: レコードタイプ。myapi.example.jpはapi-lb.example.jpの別名（エイリアス）であることを示している。A: レコードタイプ。api-lb.example.jpは、192.0.2.10と192.0.2.11という2つのIPv4アドレスを持つことを示している。これは、ロードバランシングのためによく使われる構成だ。
この例では、myapi.example.jpという名前を解決するために、一度api-lb.example.jpという正規名に変換（CNAMEレコード）し、その上でapi-lb.example.jpのIPアドレスを解決している。このようなCNAMEチェーンはよくあるパターンで、Web APIのエンドポイントがCDNやロードバランサーのサービス名になっている場合によく見られる。
AUTHORITY SECTION: この権威を信じよ
このセクションは、「このドメインの情報を問い合わせるべき、権威あるネームサーバーはここだ」という情報が示されている。DNS委譲（デリゲーション）の仕組みを理解する上で非常に重要だ。
;; AUTHORITY SECTION:
example.jp. 3600 IN NS ns1.example.jp.
example.jp. 3600 IN NS ns2.example.jp.example.jp.: 対象のゾーン。3600: TTL。NS: レコードタイプ。このゾーンの権威ネームサーバーはns1.example.jpとns2.example.jpだ、と宣言している。
もしANSWER SECTIONに期待する情報がなく、ここに別のネームサーバーが示されていたら、それは「お前が問い合わせているDNSサーバーは、このゾーンの権威を持っておらず、あっちのDNSサーバーに聞きに行け」と教えてくれているサインだ。DNSの設定ミスでゾーン転送がうまくいっていない、あるいは委譲が正しく設定されていない場合など、トラブルシューティングの強力な手がかりになる。
ADDITIONAL SECTION: 更なる情報だ、受け取れ
このセクションには、ANSWERやAUTHORITYセクションに記載されたレコードを解決するために役立つ「追加情報」が含まれる。特に重要なのは「グルーレコード」だ。
;; ADDITIONAL SECTION:
ns1.example.jp. 3600 IN A 198.51.100.1
ns2.example.jp. 3600 IN A 198.51.100.2ns1.example.jp.,ns2.example.jp.: ドメイン名。A: レコードタイプ。198.51.100.1,198.51.100.2: IPv4アドレス。
上の例では、AUTHORITY SECTIONでexample.jpのネームサーバーがns1.example.jpとns2.example.jpだと示されている。しかし、これらのネームサーバー自身のIPアドレスがなければ、問い合わせ元のDNSサーバーはどこに問い合わせれば良いのか分からない。そこで、親ゾーンのDNSサーバーは、子ゾーンのネームサーバーのIPアドレスを「グルーレコード」としてADDITIONAL SECTIONに含めて回答するんだ。
これがなければ、無限ループに陥ってしまう。ns1.example.jpのIPを知るにはns1.example.jpに聞かなければならず、そのns1.example.jpのIPを知るには…という具合にな。このグルーレコードのミスは、DNSの委譲チェーンが途切れる致命的な障害を引き起こすことがある。
—
実務で役立つdigコマンドの応用テクニック
ここまででdig出力の基本構造は理解しただろう。ここからは、実践的なトラブルシューティングで役立つオプションをいくつか紹介しよう。
特定のDNSサーバーに問い合わせる
特定のDNSサーバーのキャッシュ状態を確認したり、DNSサーバーの切り替えテストをしたりする場合に使う。
# Google Public DNS (8.8.8.8) に直接問い合わせる
dig @8.8.8.8 myapi.example.jp
# 自社のDNSサーバー (例: 10.0.0.1) に問い合わせる
dig @10.0.0.1 myapi.example.jpこれは、特定のDNSサーバーが間違った情報を返している場合に、「どのサーバーがおかしいのか」を特定するために非常に有効だ。
特定のレコードタイプを指定する
デフォルトではAレコードを問い合わせるが、特定のレコードタイプだけを知りたい場合に指定する。
# myapi.example.jp の CNAME レコードを問い合わせる
dig myapi.example.jp CNAME
# example.jp の NS レコードを問い合わせる
dig example.jp NS
# example.jp の TXT レコード (SPF, DKIMなど) を問い合わせる
dig example.jp TXTWeb APIの背後でMXレコードやSRVレコードが使われていることは稀だが、例えばメール送信機能を持つAPIの場合、そのドメインのMXレコードが正しく設定されているかを確認することもある。
詳細表示を抑制する (+short)
とにかくIPアドレスだけ知りたい、といった場合に使う。スクリプトで名前解決結果を処理する際によく使うオプションだ。
# myapi.example.jp の IP アドレスだけをシンプルに表示
dig +short myapi.example.jp
# 出力例:
# api-lb.example.jp.
# 192.0.2.10
# 192.0.2.11CNAMEがあった場合は、その正規名と最終的なIPアドレスが表示されるのがポイントだ。
DNS委譲パスを追跡する (+trace)
これは非常に強力なオプションだ。ルートDNSサーバーから始まり、各権威DNSサーバーを順にたどりながら、最終的な回答を得るまでの「委譲の鎖」全体を表示してくれる。DNS委譲の設定ミスを見つけるのに最適だ。
# myapi.example.jp の DNS 解決パスをトレースする
dig +trace myapi.example.jpこの出力を見れば、どの権威サーバーが次にどのネームサーバーに問い合わせるべきかを指示したか、そしてそのネームサーバーのIPアドレス（グルーレコード）が正しく渡されているか、といった詳細な過程がわかる。途中で解決に失敗したり、間違った情報が渡されている箇所があれば、そこが問題の根源だと特定できる。
—
Web APIとDNS解決の現場での応用
さて、ここまでdigコマンドとその出力を詳しく見てきたが、これがWeb APIの設計や運用にどう役立つのか、具体的なシナリオを考えてみよう。
シナリオ1: Web APIエンドポイントが解決できない！
君が開発したWeb APIが、ある日突然Name resolution failedエラーを吐き始めたとする。
まず疑うべきはDNSだ。クライアントサイドからcurlやPythonのrequestsで叩いてみよう。
# curlでAPIエンドポイントにアクセス
curl -v https://myapi.example.jp/v1/dataもしCould not resolve host: myapi.example.jpのようなエラーが出たら、即座にdigの出番だ。
# まずは基本で、myapi.example.jp を dig
dig myapi.example.jpANSWER SECTIONに何も表示されない場合は、そのドメイン自体が存在しないか、DNSサーバーがレコードを知らない（設定ミス）可能性がある。status: NXDOMAINが表示されたら、ドメインが存在しないことを意味する。スペルミスを確認するか、そもそもDNSに登録されているかを確認する。status: SERVFAILが表示されたら、DNSサーバー自体が名前解決に失敗している。そのDNSサーバーの設定や upstream DNS への問い合わせに問題がある可能性がある。@オプションで別のDNSサーバーに問い合わせてみよう。
もしCNAMEチェーンが長すぎる場合、パフォーマンスに影響が出ることもある。dig +traceでチェーンの深さを確認し、設計の見直しを検討するヒントにもなる。
シナリオ2: APIへのリクエストが特定のIPアドレスにばかり行く！
Web APIのバックエンドで複数のサーバーをロードバランシングしているはずなのに、なぜか特定のサーバーばかりアクセスが集中している。これはDNSラウンドロビンの問題かもしれない。
# 複数回 dig を実行して、返ってくるIPアドレスの変化を見る
dig myapi.example.jp
dig myapi.example.jp
dig myapi.example.jpもし毎回同じIPアドレスが返ってくるなら、DNSラウンドロビンが正しく設定されていないか、問い合わせているDNSサーバーが結果をキャッシュしすぎている可能性がある。TTLを確認しよう。
api-lb.example.jp. 60 IN A 192.0.2.10
api-lb.example.jp. 60 IN A 192.0.2.11この例のTTLは60秒だ。これは比較的短く、キャッシュの影響は小さいはずだが、もしこれが3600秒（1時間）など長い値になっていたら、DNSキャッシュが更新されるまでに最大1時間かかってしまうことになる。もしトラブルシューティングで「すぐに反映させたい」と思ったら、TTLを一時的に短くするという運用テクニックもある。ただし、これはDNSクエリの増加を招くため、恒久的な解決策ではない。
シナリオ3: クライアントサイドでの名前解決の挙動
Webブラウザやアプリケーションは、通常、OSが設定しているDNSサーバーを使って名前解決を行う。PythonやJavaScript (Fetch API) など、各種言語での名前解決の挙動も理解しておこう。
Pythonでの名前解決
Pythonのsocketモジュールは、OSのDNSリゾルバを利用する。
import socket
def resolve_hostname(hostname):
"""
指定されたホスト名のIPアドレスを解決する
"""
try:
ip_addresses = socket.gethostbyname_ex(hostname)[2]
print(f"Hostname: {hostname}")
print(f"Resolved IP Addresses: {ip_addresses}")
return ip_addresses
except socket.gaierror as e:
print(f"Error resolving {hostname}: {e}")
return None
# Web APIのエンドポイントを解決
resolve_hostname("myapi.example.jp")
# Pythonでより詳細なDNSクエリを行いたい場合は、`dnspython`ライブラリが便利だ。
# pip install dnspython
import dns.resolver
def detailed_dns_query(hostname, record_type='A'):
"""
dnspythonを使って特定のレコードタイプを解決する
"""
try:
answers = dns.resolver.resolve(hostname, record_type)
print(f"\n--- Detailed DNS Query for {hostname} ({record_type}) ---")
for rdata in answers:
print(f" {rdata}")
except dns.resolver.NXDOMAIN:
print(f"Domain {hostname} does not exist.")
except dns.resolver.NoAnswer:
print(f"No {record_type} record found for {hostname}.")
except Exception as e:
print(f"An error occurred: {e}")
detailed_dns_query("myapi.example.jp", "A")
detailed_dns_query("myapi.example.jp", "CNAME")
detailed_dns_query("example.jp", "NS")JavaScript (Fetch API) での名前解決
ブラウザのfetch APIは、ブラウザがOSを通じて名前解決を行う。特別なDNSサーバーを指定することはできないが、エラーハンドリングは重要だ。
// JavaScript (ブラウザ環境) でのFetch API使用例
async function callApi(url) {
try {
const response = await fetch(url);
if (!response.ok) {
throw new Error(`HTTP error! status: ${response.status}`);
}
const data = await response.json();
console.log('API Response:', data);
} catch (error) {
// ネットワークエラーや名前解決失敗の場合、ここに到達する
console.error('API Call Error:', error);
if (error.message.includes('Failed to fetch')) {
console.error('Possible DNS or network connectivity issue.');
}
}
}
// myapi.example.jp にアクセスする
callApi('https://myapi.example.jp/data');これらのコード例からもわかるように、アプリケーションレベルではDNSの名前解決プロセスを直接コントロールすることは難しい。だからこそ、インフラエンジニアはdigを使って、その「見えない部分」を可視化し、問題の根源を特定するんだ。
—
まとめ：digは君の「目」だ
今日の話はどうだったかな？digコマンドは単なるIPアドレス表示ツールではない。その出力の各セクションは、DNSという複雑なシステムの内部構造を映し出す「窓」であり、トラブルシューティングの「設計図」なんだ。
QUESTION SECTIONで、君が何を尋ねたかを再確認し、意図しないクエリタイプになっていないか確認する。ANSWER SECTIONで、実際の解決結果とTTLを確認する。特にCNAMEチェーンはWeb APIで頻出だ。AUTHORITY SECTIONで、この情報がどこから来たのか、正しい権威が返答しているのかを確認する。ADDITIONAL SECTIONで、グルーレコードなどの補助情報が正しく提供されているかをチェックする。
これらの情報を組み合わせて分析することで、DNS設定のミス、キャッシュの問題、委譲の不具合など、様々な種類の障害を迅速に特定できるようになる。Web APIの設計者もインフラ運用者も、このdigコマンドを使いこなすことで、サービスの安定稼働に大きく貢献できるはずだ。
俺たちのNOCの現場では、障害発生時にまず叩くコマンドの一つがdigだ。ネットワークの闇に光を当て、見えない敵の正体を暴くための、最も信頼できる「目」なんだよ。さあ、君も今日からdigを片手に、ネットワークの深淵を覗いてみないか？きっと、新しい発見があるはずだ。頑張れよ！
コメント