ネットワーク (4) 名前解決

前回の話で、インターネット技術を使った実際の通信は、IP アドレス のパケットで行われている事が解りました。

今回は、Webブラウザーからの Webサイトへの通信の裏側を追いながら、そこで行われている事を理解していきましょう。

この図で見ていきます。せっかく、構成が頭に入りましたからね。

intra01 にアクセスする

すぐ右隣のホストですね。アイコンからするに、Web Server が動いている様です。というか、動いています。MyComputer-01 が自分が使っているホストですね。

Web ブラウザー起動後に URL に「https://intra01」と入力します。

「intra01」のままだと、通信が出来ないです。IP Address を探すわけですね。

FQDN を IP Address に変換する処理を名前解決といいます。英語でいうと Name Resolution。ここから、Resolver - リゾルバ つまり名前解決をする処理の言葉が出てきます。DNS Server はその中核ですよね。

名前解決をするために、どうするかといえば、DNS Server に問い合わせるわけですね。

DNS Server の中には、予め intra01 のデータが登録されています。192 . 168 . 0 . 100 ですね。
DNS Server はこの情報を、リクエスト元に送信します。

IP Address を見ると、自分と同じネットワークにいる事が解ります。どのネットワークなのかは、IP Address を Subnet Mask でマスキングしたネットワークアドレスからわかりますね。これも、以前 扱いました。

今回の場合は、直接 intra01 とやりとりが出来ます。HTTPS の通信ですので、443 のポートで通信を開始します。
HTTPの通信内容は別の回で😊

同じネットワークにいるのかどうかは、すごく重要ですね!

www.contso.com にアクセスする

今度は、よくあるWebサイトのURLにアクセスする際の動きをみていきましょう。

やはり、DNS Server に問い合わせに行きます。名前解決ですね。
ところが、このドメインのデータを、この DNS Server は管理していません!

その際には、DNS Forwarder の機能を使います。何かと言えば、それを知っている別の DNS Server に依頼するわけです。もっと言えば丸投げです。

DNS Forwarder は、10. 0 . 0 . 1 だと設定されていますね。
ここで、ルーター経由で 10 . 0 . 0 . 1 のDNS Server に問い合わせます。このDNS Server には、たまたま www.contso.com の データが登録されています。その IP Address を 問い合わせ元である、DNS Server に送ります。そして、DNS Server から、ブラウザーに IP Address を返すわけです。
もし、Fowarder 自身がそのデータを持っていなければ、Fowarder自身が登録している別の DNS Server に問い合わせます。

ここで、ようやくIP Address が解りましたので、IP Address 200 . 0 . 0 . 1 のWeb サーバーの ポート 443 に通信を始めます。  

nslookup コマンド

これ、使えるようになってください。名前解決を確認できる必携ツールです。使えないとエンジニアと言わない😎 (冗談です)

このツールでは名前解決の動きを確認できます。

こちらが実行例です。

nslooup の後に通信したい先のFQDNを指定します。

nslookup だけ入力すると、このコマンドの中でいろいろできます。そのままFQDN入れると、名前解決を試みてくれますし。type= にて名前解決の方法をカスタマイズも出来ます。

どちらでも、お好みの方法で。

それ以外にも、ネットワークの通信の状況を確認するために、いろんなツールが標準で入っています。
こちらは Windows の例ですね。

DNS Resolver Cashe (DNS リゾルバ キャッシュ)

この通信を見ていくと、DNS Server 大変ですよね。自分をDNS Server としている全てのホストが、通信を行う度に、「このサーバーのIP Address 教えて」とリクエストが来ます。その都度、自分のデータを検索して、その結果を返すわけです。

そしてホスト側も、都度実際の通信をするのとは別で、その通信先のホストの場所を通信して問い合わせないといけない。

IP Address は、そう頻繁に変更するものではないですよね。ホスト名も同じ。毎日コンピューター名変えている人は極めて少ないと思います。IP Address が変わるかは。そのネットワークの設計次第ですが… これも同様です。

となれば、DNS の Record はめったに変わらないわけですよ。

であれば。DNS Server への問い合わせ結果を「キャッシュ」として各ホストで保持した方が、メリットが大きいですよね。キャッシュをもとに通信に失敗した際だけ DNS Server に問い合わせればいいだけですから。

この名前解決つまりリゾルバの結果をキャッシュしているデータをリゾルバキャッシュと言います。

リゾルバキャッシュは、Windows の場合は ipconfig コマンドのオプションで確認できるんです! 

こちらが実行結果の例。

C:\Users\dahatake>ipconfig /displaydns

Windows IP 構成

    atb.im-apps.net
    ----------------------------------------
    レコード名 . . . . . . . : atb.im-apps.net
    レコードの種類 . . . . . : 1
    Time To Live  . . . . . .: 18
    データの長さ . . . . . . : 4
    セクション . . . . . . . : 回答
    A (ホスト) レコード. . . : 35 . 241 . 35 . 91


    レコード名 . . . . . . . : ns-764.awsdns-31.net
    レコードの種類 . . . . . : 1
    Time To Live  . . . . . .: 18
    データの長さ . . . . . . : 4
    セクション . . . . . . . : 追加
    A (ホスト) レコード. . . : 205 . 251 . 194 . 252


    partner.googleadservices.com
    ----------------------------------------
    レコード名 . . . . . . . : partner.googleadservices.com
    レコードの種類 . . . . . : 5
    Time To Live  . . . . . .: 59
    データの長さ . . . . . . : 8
    セクション . . . . . . . : 回答
    CNAME レコード . . . . . : partner46.googleadservices.com

(note.com の仕様上、IP Address の保存ができません。数字とドッとの間は実際には空いていません)

レコード名と A (ホスト) レコード としての IP Address が確認できますね。

実は、とても大事な情報があります。それは Time to Live (TTL) です。単位は秒です。そのレコードがキャッシュとして何秒だったらホスト側で保持していいかという期間になります。

最初の atb.im-apps.net なんて、この瞬間に18秒ですよ! メッチャ短い。今この行を書いている間には、もうキャッシュから消えているでしょう😊
もし、60秒くらいの設定だった場合。Web ブラウザーでの閲覧を考えると。サイトが表示されて、読み終わって同じドメインのページをリクエスト、くらいのスピード感が無いと、キャッシュの意味がないですね。

TTL は DNS Server 側で設定できます。
そしてこの数字はとても大事なので覚えちゃってください。DNS の TTL のデフォルト値は、86,400 です。60秒 x 60 分 x  24 時間の合計。つまり 1日です。各デバイスのキャッシュのクリアは出来ます。ipconfig コマンドに /flashdns というオプションがありますからね。でも、これを Server 側から実行できないんです。つまりキャッシュ消えるまで待つしかない。

ここから何が言えるか?

DNS 登録した後に IP Address の変更をする場合。最大24時間、クライアント側が古いサーバーを参照する可能性があるんです。

という事は?

3台ある Web サーバーに、1台サーバー追加をしました。そのためDNS にレコード追加しました。

www.contoso.com A 192 . 168 . 0 . 1
www.contoso.com A 192 . 168 . 0 . 2
www.contoso.com A 192 . 168 . 0 . 3

そして、以下追加。

www.contoso.com A 192 . 168 . 0 . 4

それが、iPhone から参照されるまで、最大24時間は待つ必要があるんです。
これは実はまだかわいい。

4台ある Web サーバーから、1台サーバーを削除します。そのために DNS レコードを削除しました。

www.contoso.com A 192 . 168 . 0 . 1
www.contoso.com A 192 . 168 . 0 . 2
www.contoso.com A 192 . 168 . 0 . 3
www.contoso.com A 192 . 168 . 0 . 4

が、

www.contoso.com A 192 . 168 . 0 . 1
www.contoso.com A 192 . 168 . 0 . 2
www.contoso.com A 192 . 168 . 0 . 3

に。

それが iPhoneに反映されるまで、最大24時間かかります。存在していないIP Address のサーバーを参照しにくる可能性が24時間ある、という事です。上記の例だと、192 . 168 . 0 . 4 
これは大問題!

そのため、DNS レコードを削除した場合、古いサーバーは追加の24時間は稼働させて、アクセスが完全に消えるのをモニタリングする必要があるんですね。

頻繁に増減するサーバーの場合は、DNS の TTL を短くした方がいいんですね。

名前解決に失敗するようであれば、リゾルバキャッシュが古い可能性があるわけです。

ipconfig /flashdns

にて、全部消しちゃってください。消したところで、大したオーバーヘッドではないです。

まとめ

殆どのアプリケーションは変更があっても大丈夫なようにFQDNで外部と通信をします。そのためには、ここで取り上げた名前解決を知らないと解決できません。

nslookup や ipconfig コマンドなどで、名前解決とお友達になってくださいね。