夜中の3時、データセンターの監視モニターに真っ赤なアラートが点灯する。新規にローンチしたマイクロサービスのWeb APIが、突如として「502 Bad Gateway」や「名前解決できません」の嵐に見舞われた瞬間だ。
こういうとき、若手エンジニアは慌ててアプリケーションのログやロードバランサーのCPU使用率を見がちだが、百戦錬磨のNOCエンジニアが真っ先に疑うのは「DNS」だ。そして、こう呟く。「おい、まずは dig でレコードの引け具合を確認しろ。キャッシュの腐敗か、それとも権威DNSのゾーンファイルの書き忘れか、パケットを覗けば一発でわかる」と。
Web APIの設計やクラウドインフラの運用において、DNSはすべてのトラフィックの入口であり、最も見落とされがちな「隠れたシングルポイント・オブ・ファailure（単一障害点）」だ。今回は、トラブルシューティングの現場で私たちが日々叩き込んでいる、DNSクエリタイプ（A、AAAA、CNAME、MX、NS、SOA、TXT）の個別照会と、そのレスポンスの深層にあるパケットの挙動について徹底的に解説しよう。
—
1. なぜDNSトラブルは現場を絶望させるのか？
現代のWebアプリケーションは、単一のIPアドレスで動いていることは稀だ。CDN、API Gateway、マイクロサービス群、外部SaaSとの連携など、複雑な名前解決のチェーン（連鎖）の上になり立っている。
例えば、あるAPIエンドポイント api.example.com にリクエストを送った際、背後では次のような名前解決のドラマが繰り広げられている。
1. クライアント（ブラウザやバックエンドのHTTPクライアント）がOSのresolverに問い合わせる。
2. フルリゾルバ（ISPやGoogle Public DNS 8.8.8.8 など）が、ルートサーバーから .com サーバー、そして example.com の権威ネームサーバー（NS）へと再帰的問い合わせ（Recursive Query）を行う。
3. 返ってきた CNAME を辿り、最終的な A レコードや AAAA レコードに到達する。
このチェーンのどこか一箇所でも、例えば CNAME の向こう側の実体が消滅していたり、IPv6（AAAA）の不整合があったりすると、クライアントは容赦なく接続エラーを吐き出す。ここで感覚的なデバッグをしていては、原因にたどり着くまでに夜が明けてしまう。正確に、クエリタイプを指定してDNSの「今」を暴くスキルが不可欠なのだ。
—
2. 実務で必須のDNSクエリタイプと dig コマンドの極意
DNSの照会には nslookup も使われるが、出力が冗長であったり、パケットの詳細なフラグ（AA, RAなど）が見えなかったりするため、NOCの現場では dig （Domain Information Groper）がデファクトスタンダードとして愛用されている。
基本構文は以下の通りだ。
# 基本的な構文
dig @[ネームサーバーIP] [対象ドメイン] [クエリタイプ]ここでは、実務で頻繁に直面する主要な7つのクエリタイプについて、その意味と現場での確認方法を見ていこう。
① A レコード（IPv4アドレス）
もっとも基本的かつ最も重要なレコード。ドメイン名に対して、32ビットのIPv4アドレスを紐付ける。
# GoogleのAレコードをCloudflareのDNS(1.1.1.1)に問い合わせる
dig @1.1.1.1 google.com A +short- 読み方のポイント:
+shortオプションをつけるとIPアドレスだけが返ってくるため、シェルスクリプトやCI/CDパイプラインでの疎通確認に重宝する。もしここであらぬプライベートIPや旧サーバーのIPが返ってきたら、TTL（Time to Live）のキャッシュが残っているか、レコードの更新漏れ（ステールレコード）を疑う。
② AAAA レコード（IPv6アドレス）
128ビットのIPv6アドレスを紐付けるレコード。近年、IPv6ファーストの環境やモバイルキャリア網からのアクセスにおいて、このレコードの不備が原因で「一部のユーザーだけ繋がらない」という難解なトラブルを引き起こす。
# AAAAレコードの指定と、詳細な応答セクションの表示
dig api.example.com AAAA- 現場のTips: IPv4の
Aレコードは正常に引けるのに、AAAAレコードが古いIPv6アドレスを指しているためにタイムアウトエラー（Connection timed out）を引き起こす障害は非常に多い。デュアルスタック環境のインフラ構築時は、必ずセットでdigを叩く癖をつけよう。
③ CNAME レコード（正規名 / カノニカルネーム）
あるドメイン名を別のドメイン名にエイリアス（転送）させるためのレコード。AWSのALB（Application Load Balancer）やCloudFront、各種SaaSのエンドポイント（例: xxx.cloudfront.net）に向ける際によく使われる。
# CNAMEレコードの確認
dig my-api.example.com CNAME- 注意点:
CNAMEレコードが存在する場合、RFCの仕様上、同じ名前（Apexドメイン）にMXレコードやAレコードを同居させることは原則できない（ルートドメインexample.com自体にCNAMEを設定してはいけないという有名な制約がある）。これに違反しているDNS設定を見つけたら、即座に修正を促そう。
④ MX レコード（メール交換サーバー）
ドメイン宛ての電子メールをどのメールサーバーに配送すべきかを指定するレコード。優先度（Preference）を表す数値がセットで記録される。
# メールの配送先サーバーと優先度を確認
dig example.com MX- 応答の見方:
ANSWER SECTIONに10 mail.example.com.のように表示される。この数値が小さいほど優先度が高い。メールが届かないというインシデントでは、ここが外向きの正しいSMTPサーバーを向いているか、また後述するTXTレコード（SPF/DKIM）と整合性が取れているかを真っ先に確認する。
⑤ NS レコード（ネームサーバー）
そのドメインのゾーン情報を管理している「権威ネームサーバー」を指定するレコード。ドメインの委任（Delegation）が正しく行われているかを検証する際に使用する。
# 権威ネームサーバーのリストを取得
dig example.com NS- 現場のTips: レジストラ側のネームサーバー設定と、ゾーンファイル内の
NSレコードが一致していないと、DNSのキャッシュ汚染や名前解決のループ（Lame Delegation）が発生する。ドメイン移管直後のトラブルでは、必ず親ゾーン（ルートやTLD）から順にdigでNSを追う「トレーシング調査」が必要になる。
⑥ SOA レコード（権威の開始 / Start of Authority）
ゾーンファイルの管理責任者、プライマリネームサーバー、シリアル番号（リビジョン）、およびキャッシュの有効期限（TTLやリトライ間隔）などのメタデータを保持する、いわば「ゾーンの戸籍謄本」だ。
# SOAレコードの取得
dig example.com SOA- 応答の見方:
ns1.example.com. hostmaster.example.com. 2023102401 7200 3600 1209600 300 この中の 2023102401 といった数値が「シリアル番号」だ。プライマリとセカンダリ（スレーブ）の間でゾーン転送（AXFR/IXFR）が正常に行われているかを確認する際、セカンダリ側のシリアル番号がプライマリより古くないかをチェックするために必ずこの SOA を見比べる。
⑦ TXT レコード（テキスト情報）
任意の文字列を格納できるレコード。現代のインフラ運用においては、メールのなりすましを防ぐ SPF / DKIM / DMARC の設定や、Let’s EncryptなどのSSL/TLS証明書を発行する際のDNS認証（_acme-challenge）に不可欠な存在となっている。
# SPFやドメイン認証用のTXTレコードを確認
dig example.com TXT- 現場のTips: 1つのドメインに複数の
TXTレコード（SPFと証明書検証など）が登録されている場合、文字列が結合されて返ってくることがある。文字数制限やエスケープシーケンスのミスでAPI連携やメール配信が弾かれるトラブルは後を絶たない。
—
3. 実コードからのDNS照会：PythonとWeb API開発者のための実装例
インフラエンジニアだけでなく、Web APIを設計・開発するエンジニアにとっても、コードレベルで名前解決の挙動を理解しておくことは強力な武器になる。特に、カスタムDNSリゾルバを使用するマイクロサービスや、外部APIへの接続タイムアウトをハンドリングする際には、標準ライブラリの挙動を把握する必要がある。
以下に、Pythonのサードパーティライブラリ dnspython を用いて、プログラムから明示的に各種クエリタイプを指定してDNSサーバーを叩く実用的なスクリプトを示す。
#!/usr/bin/env python3
import dns.resolver
def diagnose_dns(domain: str):
"""
指定されたドメインに対して主要なDNSレコードを個別に照会し、
インフラの状態を診断するスクリプト
"""
# 問い合わせに使用するDNSサーバー（例: Cloudflare Public DNS）
resolver = dns.resolver.Resolver()
resolver.nameservers = ['1.1.1.1', '8.8.8.8']
# 検査するレコードタイプのリスト
record_types = ['A', 'AAAA', 'CNAME', 'MX', 'NS', 'SOA', 'TXT']
print(f"=== DNS Diagnostics for: {domain} ===")
for r_type in record_types:
try:
# 各レコードタイプを指定して問い合わせを実行
answers = resolver.resolve(domain, r_type)
print(greeen_log(f"[{r_type} Record Found]"))
for rdata in answers:
print(f" -> {rdata}")
except dns.resolver.NoAnswer:
print(f"[{r_type} Record] -> 該当するレコードなし (NoAnswer)")
except dns.resolver.NXDOMAIN:
print(f"[Error] ドメイン自体が存在しません (NXDOMAIN)")
break
except dns.exception.Timeout:
print(f"[Error] DNSサーバーへの問い合わせがタイムアウトしました")
except Exception as e:
print(f"[{r_type} Record] -> その他エラー: {e}")
print("========================================")
def greeen_log(text: str) -> str:
# ログの見栄えを良くするためのヘルパー（本番スクリプトではお好みで）
return f"\033[32m{text}\033[0m"
if __name__ == "__main__":
# テスト対象のドメイン
target_domain = "example.com"
diagnose_dns(target_domain)このコードをCI環境や死活監視スクリプトに組み込んでおけば、「AレコードはあるのにTXTのSPF設定が消えている」といった微妙なコンフィグレーションミスをデプロイ直後に検知できる。
—
4. トラブルシューティングの現場から：パケットキャプチャと最終奥義
もし dig でも原因が特定できない、あるいは「DNSサーバーが応答しない」という深刻なパケットロスに直面したときは、ネットワークの原点に立ち返り、tcpdump でUDP/TCP 53番ポートのパケットを直接キャプチャしよう。
# 53番ポート（DNS）の通信をリアルタイムでキャプチャして中身を覗く
sudo tcpdump -nn -vvv -i any port 53現場でよくある「落とし穴」をいくつか挙げておく。
1. EDNS0（Extended DNS）のサイズオーバー: 近年のDNS応答（DNSSECや多数のIPリストを含むレスポンス）は、従来のUDPパケットの制限である512バイトを超えることが多い。ルーターやファイアウォール（FW）がUDPの大きなパケット（Jumbo Frameやフラグメント）をドロップしている場合、TCP 53番へのフォールバックが失敗して名前解決が不発になる。
2. TTLのキャッシュ汚染: アプリケーション層（JavaのJVMやNode.jsの内部DNSキャッシュなど）が、OSの挙動を無視して古いDNSキャッシュを抱え込み続けるケース。この場合はアプリケーションプロセスの再起動が必要になる。
—
5. まとめ
DNSトラブルシューティングの本質は、「どこでパケットが迷子になり、どのキャッシュが現実と乖離しているか」を論理的に切り分けることにある。
ただ漫然と ping を打つのではなく、今回紹介した dig による個別レコード（A, AAAA, CNAME, MX, NS, SOA, TXT）の照会手法を手の内に入れておけば、どんなに複雑なクラウド上のルーティング迷子に遭遇しようとも、必ず真犯人（原因）にたどり着くことができる。
さあ、アラート対応に戻ろう。パケットは嘘をつかない。コンソールを開き、自分の手でDNSの真実を暴き出せ。
コメント