DNS問い合わせの流れとは？パケットレベルで理解する名前解決の仕組み
KoAN
目次
DNS問い合わせの流れをパケットレベルで理解する
DNS（Domain Name System）は、インターネット上で最も重要な仕組みの一つです。Webサイトへアクセスするとき、メールを送信するとき、クラウドサービスへ接続するときなど、多くの通信でDNSが利用されています。
DNSの基本的な役割は、ドメイン名をIPアドレスへ変換することです。しかし、実際のDNS通信は単純な名前変換ではありません。クライアント、キャッシュDNSサーバ、ルートDNSサーバ、TLD DNSサーバ、権威DNSサーバが連携しながら名前解決を行っています。
本記事では、DNS問い合わせがどのようなパケットで行われるのか、どのような順序でDNSサーバ同士が通信するのかを詳しく解説します。
Webアクセスの最初に行われる処理
例えばブラウザに次のURLを入力したとします。
https://www.example.com/多くの人は、この瞬間にWebサーバへ接続していると思いがちです。しかし実際には、まずDNSによる名前解決が行われます。
ブラウザは「www.example.com のIPアドレスは何か？」を調べる必要があります。
DNSによってIPアドレスが判明して初めてTCP接続やHTTPS通信が開始されます。
DNS問い合わせの全体像
DNS問い合わせの流れを簡略化すると次のようになります。
PC
↓
キャッシュDNSサーバ
↓
ルートDNSサーバ
↓
TLD DNSサーバ
↓
権威DNSサーバ
↓
IPアドレス取得実際には複数のパケットがやり取りされながら名前解決が行われます。
最初にhostsファイルを確認する
OSはDNS問い合わせを行う前にhostsファイルを確認します。
Linuxでは次のファイルです。
/etc/hosts
Windowsでは次の場所にあります。
C:\Windows\System32\drivers\etc\hosts
例えば次のような設定が存在する場合です。
192.168.1.10 www.example.com
この場合、DNS問い合わせは行われず、そのまま192.168.1.10へ接続します。DNSキャッシュを確認する
hostsファイルに情報が無い場合、OSはDNSキャッシュを確認します。
過去に問い合わせた結果がキャッシュに残っていれば、外部DNSサーバへの通信は発生しません。
キャッシュが存在する場合は即座に名前解決が完了します。
キャッシュが無い場合のみDNS問い合わせが発生します。
DNSクエリパケットの送信
キャッシュが存在しない場合、クライアントはDNSサーバへ問い合わせパケットを送信します。
通常はUDPの53番ポートを利用します。
送信元IP : 192.168.1.100
送信元ポート : 53000
宛先IP : 192.168.1.1
宛先ポート : 53
問い合わせ:
www.example.com
Aレコードここで重要なのは、DNSサーバへ「Aレコードを教えてほしい」と問い合わせている点です。
DNSパケットの中身
DNSパケットには複数の情報が含まれています。
- Transaction ID
- Flags
- Questions
- Answers
- Authority
- Additional
Wiresharkで確認すると、次のような内容が見えます。
Transaction ID: 0x1234
Standard query
A www.example.comTransaction IDは問い合わせと応答を対応付けるために利用されます。
キャッシュDNSサーバの動作
キャッシュDNSサーバは問い合わせを受けると、まず自分のキャッシュを確認します。
キャッシュが存在すれば即座に応答します。
www.example.com
↓
93.184.216.34キャッシュが存在しない場合は、他のDNSサーバへ問い合わせを開始します。
ルートDNSサーバへの問い合わせ
キャッシュDNSサーバは最初にルートDNSサーバへ問い合わせます。
ルートDNSサーバは世界中に配置されており、DNS階層の最上位に位置します。
しかし、ルートDNSサーバは example.com のIPアドレスを知りません。
代わりに次のような情報を返します。
.com を管理するDNSサーバはこちらです
つまり、次に問い合わせるべきDNSサーバを教えてくれるのです。
TLD DNSサーバへの問い合わせ
TLD（Top Level Domain）DNSサーバは、.com や .jp を管理しています。
キャッシュDNSサーバは次にTLD DNSサーバへ問い合わせます。
www.example.com の情報は？
TLD DNSサーバは次のように返します。
example.com の権威DNSは
ns1.example.com
ns2.example.com
ですこの段階でもIPアドレスは返されません。
権威DNSサーバへの問い合わせ
続いてキャッシュDNSサーバは権威DNSサーバへ問い合わせます。
www.example.com のAレコードは？
権威DNSサーバは正式な情報を保持しています。
そのため最終的な回答が返されます。
www.example.com
IN A
93.184.216.34
これが名前解決の完了です。
クライアントへの応答
キャッシュDNSサーバは取得した結果をキャッシュへ保存します。
その後クライアントへ応答を返します。
Query:
www.example.com
Response:
93.184.216.34
クライアントはこのIPアドレスを使ってWebサーバへ接続します。
UDPが利用される理由
DNSでは通常UDPが利用されます。
理由は高速だからです。
DNS問い合わせは基本的に小さなデータです。
TCPのように接続確立を行う必要がないため、応答速度を向上できます。
TCPが利用されるケース
DNSではTCPも利用されます。
代表的な例は次の通りです。
- ゾーン転送（AXFR）
- 大きな応答パケット
- DNSSEC利用時
この場合はTCPの53番ポートが利用されます。
TTLとキャッシュ
DNS応答にはTTLが含まれています。
www.example.com. 3600 IN A 93.184.216.34
この3600はTTLです。
キャッシュDNSサーバは1時間この情報を保持できます。
同じ問い合わせが来た場合は、外部DNSへ問い合わせずに応答できます。
WiresharkでDNSを見る
DNS通信はWiresharkで簡単に確認できます。
フィルタに次のように入力します。
dns
または53番ポートのみ表示する場合は次のようにします。
udp.port == 53
実際にWebサイトへアクセスすると、DNS QueryとDNS Responseが確認できます。
digコマンドで確認する
Linuxではdigコマンドを使ってDNS問い合わせを確認できます。
dig www.example.com
特定のDNSサーバへ問い合わせる場合です。
dig @8.8.8.8 www.example.com
権威DNSサーバへ直接問い合わせることも可能です。DNSトラブルの切り分け
DNS障害が発生した場合は、どの段階で失敗しているかを確認します。
- hostsファイル
- ローカルキャッシュ
- キャッシュDNSサーバ
- ルートDNS
- TLD DNS
- 権威DNS
どこで応答が止まっているかを調査することで原因を特定できます。
まとめ
DNS問い合わせは単純な通信ではなく、キャッシュDNSサーバ、ルートDNSサーバ、TLD DNSサーバ、権威DNSサーバが連携して行われています。
クライアントはまずDNSクエリを送信し、キャッシュDNSサーバが再帰問い合わせによって最終的なIPアドレスを取得します。
DNS通信の大部分はUDP53番ポートで行われますが、ゾーン転送やDNSSECなどではTCP53番ポートも利用されます。
DNS問い合わせの流れを理解することで、名前解決トラブルの切り分けやDNSサーバ構築、ネットワーク運用への理解が大きく深まります。
