【入門編】 DNSプロトコルのメッセージフォーマットとUDP/TCPの使い分け – ネットワーク基礎とWebセキュリティ実践ガイド

こんにちは！インフラやネットワークの世界へようこそ。凄腕ネットワークスペシャリストの私と一緒に、日頃何気なく使っているインターネットの「裏側の立役者」について、ワクワクする冒険に出かけてみましょう。

私たちがブラウザに https://example.com と打ち込んだ瞬間、目にも留まらぬ速さでWebサイトが表示されますよね。「名前を教えたら、すぐに場所を教えてくれる」この便利な仕組みの裏側には、DNS（Domain Name System）という、インターネットの「巨大な電話帳」が隠されています。

今回は、このDNSがやり取りする「メッセージの構造」と、状況によってUDPとTCPを華麗に使い分けるプロフェッショナルの技について、身近な例えを交えながら一歩ずつ紐解いていきたいと思います！

—

1. 郵便配達で例えるDNSの基本とメッセージ構造

いきなり「DNSメッセージフォーマット」や「ヘッダー構造」なんて言葉を聞くと、エンジニア初学者の皆さんは「うっ、難しそう……」と身構えてしまうかもしれません。でも、安心してください！一歩ずつ理解していきましょう。

DNSのやり取りは、いわば「手紙のやり取り」です。

1. あなた（クライアント）が、「〇〇ビル（example.com）の住所を教えて！」と手紙（DNSクエリ）を書く。
2. 郵便局員（DNSサーバー）がその手紙を読み、住所を調べて返事の手紙（DNSレスポンス）をあなたの元へ届ける。

この手紙の封筒には、必ず「決まったルール（フォーマット）」があります。宛先や差出人だけでなく、「この手紙がどの質問に対する答えなのか」を識別するための重要な番号が書かれているのです。

DNSヘッダーの主要な立役者たち

DNSのメッセージ（手紙の封筒部分）には、いくつかの重要な管理情報が詰まっています。中でも絶対に覚えておいてほしい主役が「トランザクションID」です。

トランザクションID（16ビット / 約0〜65535の番号）
役割： これが今回の超重要ポイントです！カフェで注文したときに渡される「番号札」だと思ってください。
なぜ必要？： インターネットの世界では、あなたのパソコンは同時に何十もの宛先を調べようとします。もし番号札がなかったら、「さっき出した質問に対する答えは、どこのサーバーからの返事だっけ？」とパニックになってしまいますよね。サーバーは、あなたがくれた手紙に書いてあったトランザクションIDを、そのまま返事の封筒にも書いて送り返してくれます。これでパソコンは「あ、これさっきの質問の答えだ！」と完璧に紐付けられるわけです。

—

2. なぜ普段はUDPで、大容量のときはTCPに切り替わるのか？

さて、ここからがネットワークエンジニアの腕の見せ所です。DNSは、基本的にはUDP（User Datagram Protocol）というプロトコルを使っています。しかし、条件によってはTCPへ華麗に「フォールバック（切り替え）」します。

この使い分けの理由も、現実世界のコミュニケーションに例えるとスッキリ腑に落ちますよ。

通常時の主役：スピード重視のUDP

例え話： 近所の人に「いま何時ですか？」と声をかけるようなものです。
理由： UDPは、相手がちゃんと聞いたか確認（握手やコネクションの確立）をせずに、いきなりパッと投げ捨てるようにデータを送ります。DNSの質問なんて「〇〇のIPアドレス教えて」という一言だけの軽いもの。返事も一言で返ってきます。だから、事前の面倒な手続き（TCPの3ウェイハンドシェイクなど）を省いて、「秒速」でやり取りできるUDPが選ばれているのです。

ピンチの救世主：確実性重視のTCPフォールバック

では、どんなときにTCPに切り替わるのでしょうか？答えは「情報量が多すぎて、ハガキ（UDP）のサイズに入りきらないとき」です。

UDPで送受信できるパケットのサイズ（厳密にはDNSメッセージのサイズ）には、基本ルールとして512バイトという制限があります（EDNS0という拡張を使えばもっと大きくできますが、基本のキとしてここは512バイトと覚えておきましょう）。

インターネットのドメイン情報が増え、1つのドメインに対して大量のIPアドレスが登録されていたり、ドメインの所有権を丸ごとコピーする「ゾーン転送（Zone Transfer）」という重たい処理を行ったりすると、512バイトの枠をペロッと超えてしまいます。

例え話： ハガキ（UDP）には書ききれないほどの大量の書類を、書留（TCP）で確実にやり取りするようなものです。
UDPでの失敗（切り替えのトリガー）： サーバーにUDPで質問を投げたとき、返ってくる答えが大きすぎてハガキからはみ出てしまうと、DNSサーバーは返事のヘッダーに「Truncated（切り詰め・途中で切れちゃったよ）フラグ」という印をつけて返します。
TCPへのフォールバック： クライアントはこの「途中で切れちゃった」という印を受け取ると、「おっと、これはUDPのサイズじゃ無理だな。よし、今度はしっかり回線をつないで（TCPのコネクションを確立して）もう一度頼もう！」と、自動的にTCPを使った通信に切り替えて再挑戦します。

—

3. 実務で役立つ！パケットの流れと設定の確認

ここまで理論を学んだところで、実務やインフラ構築の現場でどう役立つのかを見てみましょう。Linux環境において、DNSが実際にどのように名前解決を行っているか、またパケットの挙動を調べるためのツールの使い方をご紹介します。

実務で使える！DNSの挙動を覗き見するコマンド

開発やインフラのトラブルシューティングで「DNSの応答がおかしいな？」と感じたとき、私たちは dig というコマンドをよく使います。

以下のコマンドを実行すると、DNSサーバーとどのようなやり取りをしているかを詳細に覗くことができます。

# example.com のDNSレコードを詳細に調べる（トレース機能付き）
dig +trace example.com

# あえてUDPではなくTCP強制でDNSクエリを投げる場合
dig +tcp example.com A

> 【実務ワンポイントアドバイス】
> ファイアウォールやセキュリティグループ（AWSのSGなど）の設計をする際、「DNSだからUDP 53番ポートだけを開ければいいや」と油断していると痛い目を見ます。
> ゾーン転送を行うセカンダリDNSサーバーの構築時や、巨大なレスポンスが返ってくる環境ではTCP 53番ポートの通信も必ず許可しておく必要があります。これ、インフラ面接や現場の障害対応で本当によくある落とし穴なのでメモしておいてくださいね！

—

まとめ

いかがでしたでしょうか？今回はDNSのメッセージ構造と、UDP・TCPのドラマチックな使い分けについて解説しました。

トランザクションIDは、たくさんの質問の中から自分の答えを見つけ出すための大切な「番号札」。
普段の軽い問い合わせは、スピード重視のUDP。
512バイトを超える巨大なデータやゾーン転送のときは、確実性重視のTCPへ華麗にフォールバック。

一見難しそうに見えるネットワークの仕組みも、私たちが普段行っている郵便のやり取りや会話のルールに置き換えてみると、とても理にかなった美しいデザインで作られていることが分かりますよね。

日々のインフラ運用のなかで、パケットがネットワークの海をどのように泳いでいるのかを想像できるようになると、エンジニアとしての視座がグッと広がります。ぜひ今日の学びを、明日からの開発やトラブルシューティングに活かしてみてくださいね！