TCP/IPアレルギー撲滅ドリル【総まとめ編5回目】DNSへの問い合わせをEtherealでのぞき込む
|
|
DNS問い合わせをのぞき込む |
前回「Etherealでarpパケットをのぞき込もう」では、arpがIPアドレスからMACアドレスを問い合わせ、その応答を受け取るまでを説明しました。今回は、その後に続くDNSの問い合わせと回答までを見ていきます。
普段、Webサーバへのアクセスにはwww.atmarkit.co.jpのようなドメイン名を使いますが、TCP/IPで通信するときには相手をIPアドレスで指定しなければなりません。そのためにドメイン名とIPアドレスに変換する仕組みがDNSで、その変換を依頼することをDNS問い合わせといいます。
・ドメイン名についてはそもそもドメインって何なんでしょうか?を参照してください ・DNSの名前解決については例えばWebに接続するとき、いつDNSを使うのですか?を参照してください ・DNSの動作についてはDNS全体の動作の様子を具体的に教えてくださいを参照してください |
前回のARPの説明で使ったEtherealの画面1にはDNSのやりとりも表示されています。
画面1 DNS問い合わせの流れ |
この画面に表示しているパケットのうち、No.3が192.168.1.5が192.168.1.1に対して行ったDNS問い合わせです(C)。またNo.4が192.168.1.1から192.168.1.5へのDNSの回答です(D)。このやりとりは観察対象となったPCとDNSサーバとのやりとりを表したものです。
DNSの問い合わせは図1の流れで行います。DNSの問い合わせコマンドにUDPヘッダが付き、さらにIPヘッダが付き、最後にイーサヘッダが付いてネットワークに流れます。
図1 DNS問い合わせの流れ |
このイーサヘッダには宛先のMACアドレスを書き込む必要があります。そのため、イーサヘッダを作り出す前にあらかじめARPを行って、送信先のMACアドレスを取得しておかなければなりません。画面1の(A)(B)で先にARPを行っているのは、このような理由があるためです。
・DNS問い合わせパケットを見せてください
画面2がDNSの問い合わせパケットの中身です。図1でネットワークに送出するパケット(C)-4を縦にすると、画面左端の「イーサヘッダ」〜「問い合わせコマンド」までに対応します。また、図の(C)-1から(C)-4までの各段階のパケットが、画面の(C)-1から(C)-4に対応すると考えてください。このように見ることで、パケットが作られていく段階と、その内容を対比して考えることができると思います。
画面2 DNS問い合わせパケットの内容 |
内容を少し見てみましょう。イーサヘッダを見ると、このフレームの送り先は00:80:87:96:59:e1になっています。このMACアドレスは、DNSサーバの役割をしている192.168.1.1のコンピュータのMACアドレスで、これに先立って行ったARPによって取得した情報です。
IPヘッダの部分では、送信元を表すSourceが192.168.1.5、あて先を表すDestinationが192.168.1.1になっています。これは、このパケットが192.168.1.5から送られ、192.168.1.1にあてたものであることを意味しています。またProtocolはUDPとなっていて、上位プロトコルはUDPであることが読み取れます。
UDPヘッダの部分からは、Destination portがdomainであることから、このパケットがDNS問い合わせ用のポートに送られていることが分かります。ポート番号でいうと53番です。
問い合わせコマンドの部分からは、これが問い合わせ(Response: Message is a query)であり、また問い合わせるものがホスト名(Type:
A(Host address))で、そのホスト名がwww.atmarkit.co.jp(Name: www.atmarkit.co.jp)であることが読み取れます。
なお、実際の問い合わせ処理では、まずプログラムがDNSの問い合わせを呼び出し、その問い合わせパケットがUDP処理プログラムに送られてUDPヘッダが付き、さらにIP処理プログラムに送られてIPヘッダが付き、最後にEthernetに送られてイーサヘッダが付く、という流れになります。
・IPパケットの構造についてはIPパケットはどんな構造なんですか?を参照してください |
画面3がDNSの回答パケットの中身です。
画面3 DNS問い合わせパケットの内容 |
図2でいうと、(D)-4のパケットを表しています。問い合わせの場合と同じく各段階が(D)-4〜(D)-1に対応しています。
図2 DNS回答の流れ |
イーサヘッダとIPヘッダのSourceとDestinationから、このパケットの送信元が192.168.1.1(DNSサーバ)で、またあて先が192.168.1.5(観察対象PC)であることが読み取れます。またIPヘッダのprotocolから、上位プロトコルがUDPであることが分かります。
UDPヘッダのSource portがdomainであることからは、これがDNSからのパケットであることが読み取れます。ところで先の問い合わせではDestination
portがdomainになっていました。これは、問い合わせをポート番号53番に送ったら、その答えが同じ53番から返ってきたことを意味しています。
DNS回答の部分からは、このメッセージが回答であること(Response: Message is a response)、エラーがなかったこと(Reply
code: No error)、IPアドレスが210.131.249.57であること(Addr: 210.131.249.57)が読み取れます。
ここまで、DNSのやりとりにおけるパケットの流れをご説明しました。次回は、Webページを読み出すプロトコルHTTPのやりとりを追います。
関連リンク | |
連載:TCP/IPアレルギー撲滅ドリル【超実践編】(上位レイヤ編) 連載:TCP/IPアレルギー撲滅ドリル【超実践編】(下位レイヤ編) 連載:インターネット・プロトコル詳説 連載:ルータの仕組みを学ぼう ホストのネット接続は正しく行われているか? 〜netstatによるネットワーク設定の確認〜 |
「Master of IP Network総合インデックス」 |
- 完全HTTPS化のメリットと極意を大規模Webサービス――ピクシブ、クックパッド、ヤフーの事例から探る (2017/7/13)
2017年6月21日、ピクシブのオフィスで、同社主催の「大規模HTTPS導入Night」が開催された。大規模Webサービスで完全HTTPS化を行うに当たっての技術的、および非技術的な悩みや成果をテーマに、ヤフー、クックパッド、ピクシブの3社が、それぞれの事例について語り合った - ソラコムは、あなたの気が付かないうちに、少しずつ「次」へ進んでいる (2017/7/6)
ソラコムは、「トランスポート技術への非依存」度を高めている。当初はIoT用格安SIMというイメージもあったが、徐々に脱皮しようとしている。パブリッククラウドと同様、付加サービスでユーザーをつかんでいるからだ - Cisco SystemsのIntent-based Networkingは、どうネットワークエンジニアの仕事を変えるか (2017/7/4)
Cisco Systemsは2017年6月、同社イベントCisco Live 2017で、「THE NETWORK. INTUITIVE.」あるいは「Intent-based Networking」といった言葉を使い、ネットワークの構築・運用、そしてネットワークエンジニアの仕事を変えていくと説明した。これはどういうことなのだろうか - ifconfig 〜(IP)ネットワーク環境の確認/設定を行う (2017/7/3)
ifconfigは、LinuxやmacOSなど、主にUNIX系OSで用いるネットワーク環境の状態確認、設定のためのコマンドだ。IPアドレスやサブネットマスク、ブロードキャストアドレスなどの基本的な設定ができる他、イーサネットフレームの最大転送サイズ(MTU)の変更や、VLAN疑似デバイスの作成も可能だ。
|
|