WEBVTT 00:00.290 --> 00:01.920 Jason: このレッスンでは､ 00:01.920 --> 00:04.920 ドメインネームシステム（DNS）についてお話しします｡ 00:04.920 --> 00:08.070 DNSプロトコルは､ 数値のIPアドレスの代わりに人間が読めるホスト名を使用して､ 00:08.070 --> 00:12.720 ネットワーククライアントがウェブサイトを見つけるのを助けるために使用されます｡ 00:12.720 --> 00:15.360 例えば､ 私のウェブサイトを訪問するように言ったとしたら､ 「やあ､ 00:15.360 --> 00:23.310 diontrainingに行ってごらん｡ com "の方が､ 66と覚えるよりずっと簡単だ｡ 00:23.310 --> 00:23.310 123. 45. 237､ 00:26.280 --> 00:29.670 あるいは私のウェブ・サーバーのIPアドレスがどうであれ｡ 00:29.670 --> 00:32.010 結局のところ､ テレビコマーシャルの一部としてこれらの数字をすべて言うことは､ 消費者にdiontrainingを訪問するよう伝えるほどキャッチーでもないし､ 00:32.010 --> 00:39.420 記憶に残るものでもない｡ 00:39.420 --> 00:39.420 com､ あるいはコカ・コーラ｡ com､ 00:39.420 --> 00:41.760 またはマイクロソフト｡ comだろ？ 00:41.760 --> 00:47.220 では､ コンピューターはこれらの異なるドメイン名からウェブサーバーのIPアドレスを見つける方法をどうやって知るのだろうか？ 00:47.220 --> 00:51.720 それがDNS（ドメインネームシステム）の目的だ｡ 00:51.720 --> 00:57.660 DNSの仕組みは､ ユーザーのコンピューターがdiontrainingのような場所に行くように指示されるというものだ｡ 00:57.660 --> 00:57.660 comのDNSサーバーにアクセスして､ 00:57.660 --> 01:02.139 「diontrainingって誰？ 01:02.139 --> 01:02.139 com? そしてDNSサーバーは､ 01:02.139 --> 01:04.687 「ああ､ ディオントレーニングを知っているよ｡ comに移籍した｡ 01:04.687 --> 01:07.140 IPアドレスは66ドット・サムシング､ 01:07.140 --> 01:14.490 ドット・サムシング､ ドット・サムシング｡ DNSは私たちのネットワークやシステムに組み込まれているため､ 01:14.490 --> 01:26.730 このようなことは､ 誰も実際に要求することなく､ ユーザーやコンピュータのバックグラウンドで行われます｡ 01:26.730 --> 01:28.800 さて､ ホームユーザーである私たちのほとんどは､ 01:28.800 --> 01:33.360 自分でDNSサーバーを運用することはないだろう｡ 01:33.360 --> 01:35.550 しかし､ 独自のウェブサイトや大規模な企業ネットワークを運営している場合､ 01:35.550 --> 01:40.770 ネットワーク内に独自のDNSサーバーがあり､ どのサーバーがどのIPアドレスにあり､ 01:40.770 --> 01:49.050 どのような目的で使用されるかを指示する独自のDNSレコードを設定する責任があるかもしれません｡ 01:49.050 --> 01:55.620 これにより､ 独自のドメイン名とホスト解決を実行し､ ドメイン名をIPアドレスに変換することができます｡ 01:55.620 --> 02:00.120 例えるなら､ 携帯電話の連絡先リストに似ている｡ 02:00.120 --> 02:01.380 今､ あなたはいくつの電話番号を記憶しているだろうか？ 02:01.380 --> 02:04.440 おそらく､ そんなに多くはないだろう？ 02:04.440 --> 02:09.120 普通はスマートフォンを取り出し､ 相手の名前までスクロールし､ 02:09.120 --> 02:11.490 指で相手の名前を打つ｡ 02:11.490 --> 02:13.800 例えば､ 妻に電話をかけたい場合､ 彼女の名前までスクロールし､ 02:13.800 --> 02:19.500 彼女の顔写真を携帯電話にプッシュすると､ すぐに彼女の番号にダイヤルする｡ 02:19.500 --> 02:24.600 彼女の電話番号の10桁すべてを暗記する必要はない｡ 02:24.600 --> 02:34.200 そのため､ 連絡先リストを使って顔や名前から番号への変換を行うのだ｡ 02:34.200 --> 02:42.808 コンピューターにとっては同じことだが､ コンピューターは名前よりも数字の方が好きなので､ 02:42.808 --> 02:49.410 私たちにとって使いやすいドメイン名を､ コンピューターがルーティングしやすいIPアドレスに変換したい｡ 02:49.410 --> 02:52.260 名前を数字に､ 数字を名前に変換する｡ 02:52.260 --> 02:59.280 さて､ DNSの概念のひとつに､ 完全修飾ドメイン名（FQDN）というものがある｡ 02:59.280 --> 03:00.810 これは､ ドメイン名がトップレベルプロバイダーの下にある場合である｡ 03:00.810 --> 03:08.040 例えば､ 最も一般的なトップレベルプロバイダーは.NETです｡ comのようなものもある｡ 03:08.040 --> 03:08.040 ミル､ . edu, . org, . ネット 03:08.040 --> 03:11.670 ディオン・トレーニングの例を使ってみよう｡ 03:11.670 --> 03:16.200 ディオン・トレーニングでは､ さまざまなサーバーを用意しています｡ 03:16.200 --> 03:18.360 私たちのサーバーのひとつがウェブサーバーで､ 03:18.360 --> 03:21.210 www. ディオントレーニング comに移籍した｡ 03:21.210 --> 03:23.220 さて､ ここでのトップレベルドメインは.NETである｡ comに移籍した｡ 03:23.220 --> 03:27.750 私が使っているドメイン名はDion Trainingです｡ 03:27.750 --> 03:30.660 完全に修飾するためには､ その前にWWWを付けなければならない｡ 03:30.660 --> 03:33.420 これでwww ディオントレーニング comに移籍した｡ 03:33.420 --> 03:43.770 さて､ 私のウェブサーバーに行きたい場合は､ ブラウザにwww.と入力することになる｡ 03:43.770 --> 03:43.770 ディオントレーニング comにリダイレクトされ､ 03:43.770 --> 03:53.160 私のウェブサーバーに転送される｡ 03:53.160 --> 03:55.350 さて､ 代わりに私のファイルサーバーに行きたい場合は､ 03:55.350 --> 04:00.300 ftpと入力しなければならない｡ ディオントレーニング comで運用しているサーバーだからだ｡ 04:00.300 --> 04:03.660 私のメール・サーバーに行きたいなら､ 04:03.660 --> 04:05.820 mailとタイプすればいい｡ ディオントレーニング comに移籍した｡ 04:05.820 --> 04:10.140 これら3つはすべて､ 完全修飾ドメイン名（FQDN）の例である｡ 04:10.140 --> 04:11.610 基本的に､ サービス､ 04:11.610 --> 04:14.910 ドット､ ドメイン名､ ドット､ トップレベルドメインがあり､ 04:14.910 --> 04:21.240 これはインターネット上のどのドメインを見ても同じように機能する｡ 04:21.240 --> 04:22.830 さて､ DNSは階層構造として設定される｡ 04:22.830 --> 04:25.680 これは5つの異なるレベルで発生する｡ 04:25.680 --> 04:28.830 ルートレベル､ トップレベルドメイン､ セカンドレベルドメイン､ 04:28.830 --> 04:31.050 サブドメイン､ ホストがある｡ 04:31.050 --> 04:33.750 ルートレベルはDNS階層ツリーの最上位レベルで､ 04:33.750 --> 04:40.800 ルートネームサーバーはルートゾーンのリクエストに応答します｡ 04:40.800 --> 04:44.550 これらのサーバーには､ すべてのトップレベルドメインのグローバルリストが含まれている｡ 04:44.550 --> 04:44.550 com､ ｡ net, . org, . 工場など｡ 04:44.550 --> 04:46.320 2つ下のレベルはトップレベルドメインになる｡ 04:46.320 --> 04:53.190 これらは2つのカテゴリーに分けられる｡ 04:53.190 --> 04:53.190 com, . net, . .orgなどの地理的階層がある｡ 04:59.100 --> 04:59.100 ukはイギリス､ . frはフランス｡ イタリアや他の国もそうだ｡ 04:59.100 --> 05:03.300 3つ下のレベルはセカンド・レベル・ドメインと呼ばれる｡ 05:03.300 --> 05:06.000 これらのドメインはトップレベルドメインの直下に位置する｡ 05:06.000 --> 05:10.447 例えば､ 私のドメイン「Dion Training」は､ 05:10.447 --> 05:13.620 .NETドメイン下のセカンドレベルドメインです｡ comのトップレベルドメインです｡ 05:13.620 --> 05:16.710 その. comはルートドメインの下にある｡ 05:16.710 --> 05:23.130 これは､ これらのものがヒエラルキーの一部として一緒にレベルアップしていく方法である｡ 05:23.130 --> 05:33.270 4つ下の階層はサブドメインと呼ばれ､ 2つ目の階層であるdiontrainingドメインの下に新しいサーバーを作るとします｡ 05:33.270 --> 05:33.270 comでは､ 05:33.270 --> 05:34.950 サブドメインを使うことができます｡ 05:34.950 --> 05:39.720 私の場合､ 目的別にたくさんのサブドメインを持っている｡ 05:39.720 --> 05:43.170 私のメインのウェブサイトはwwwのサブドメインでホストしているので､ 05:43.170 --> 05:45.330 wwwと入力する｡ ディオントレーニング com』から私のウェブ・サーバーに飛びますが､ 05:45.330 --> 05:48.870 サポートというものもあります｡ 05:48.870 --> 05:56.070 現在､ サポート・サブドメインはsupportにある｡ 05:56.070 --> 05:56.070 ディオントレーニング comに移籍した｡ 05:56.070 --> 05:57.840 もうひとつ､ メール､ メール｡ ディオントレーニング comに移籍した｡ 05:57.840 --> 05:59.910 これらはすべて異なるサブドメインである｡ 05:59.910 --> 06:01.740 さて､ 最後から5番目のレベルはホストレベルである｡ 06:01.740 --> 06:07.620 これは､ DNS階層構造の最下位で最も詳細なレベルであり､ 06:07.620 --> 06:09.660 ネットワーク上の特定のマシンまたはサーバーを指す｡ 06:19.887 --> 06:19.887 ディオントレーニング comは､ 06:19.887 --> 06:23.640 サブドメイン､ セカンドレベルドメイン､ トップレベルドメインを含む｡ 06:23.640 --> 06:31.170 もう一歩踏み込んで､ URLの観点から見てみよう｡ URLはユニフォーム・リソース・ロケータとして知られている｡ 06:31.170 --> 06:34.920 ここでも､ 私のウェブサーバーを例にとってみよう｡ 06:34.920 --> 06:34.920 ディオントレーニング comに移籍した｡ 06:34.920 --> 06:37.170 これは私の完全修飾ドメイン名だが､ 06:37.170 --> 06:40.110 アクセス方法は書かれていない｡ 06:40.110 --> 06:41.700 セキュアにやりたいのか､ インセキュアにやりたいのか｡ 06:41.700 --> 06:45.540 まあ､ それはURLを見てもらうしかない｡ 06:45.540 --> 06:47.700 ユーザー名とパスワードを教えたいなら､ 06:47.700 --> 06:50.460 安全にやってね｡ 06:50.460 --> 06:56.610 したがって､ www.の前にHTTPS://を追加することになる｡ 06:56.610 --> 06:56.610 ディオントレーニング comにアクセスすれば､ 06:56.610 --> 07:00.720 それがURL（ユニフォーム・リソース・ロケーター）になり､ diontrainingへのアクセス方法がわかるからです｡ 07:00.720 --> 07:00.720 comのウェブサーバー｡ 07:00.720 --> 07:05.190 そのため､ 冒頭にHTTPSを付けている｡ 07:05.190 --> 07:12.450 ハイパー・テキスト・トランスファー・プロトコルのセキュアなアクセス方法だ｡ 07:12.450 --> 07:16.200 さて､ もしあなたが私のウェブサイトに安全でない方法でアクセスしたいのなら､ 07:16.200 --> 07:22.020 ウェブアドレスの先頭にHTTP://を追加すればいい｡ 07:22.020 --> 07:25.650 FTPを使って接続する場合は､ FTP://FTPを使う｡ 07:25.650 --> 07:25.650 ディオントレーニング comをURLとして使用します｡ 07:25.650 --> 07:39.320 このように､ システムに指示する方法はさまざまで､ URLと完全修飾ドメイン名を作成します｡ 07:40.230 --> 07:43.860 次に､ DNSサーバー内に存在するさまざまなタイプのDNSレコードについて説明する必要がある｡ 07:43.860 --> 07:49.470 DNSサーバーの内部では､ ユースケースに応じてさまざまな種類の情報を保持するレコードを作成することになる｡ 07:49.470 --> 07:53.100 これらはAレコード､ AAAAレコード､ CNAMEレコード､ MXレコード､ TXTレコード､ 07:53.100 --> 07:55.200 NSレコードとして知られている｡ 07:55.200 --> 07:59.760 これらの異なるレコード・タイプをそれぞれ簡単に見てみよう｡ 07:59.760 --> 08:08.520 まず､ アドレス・レコードを意味するAレコードがある｡ 08:08.520 --> 08:11.610 Aレコードは､ ホスト名をIPv4アドレスにリンクするために使用される｡ 08:11.610 --> 08:15.210 例えば､ www. ディオントレーニング comのIPアドレスにリンクしている｡ 08:15.210 --> 08:15.210 79. 184. 180. 08:15.210 --> 08:17.370 これに加えて､ @ホストにAレコードを設定することもでき､ 08:17.370 --> 08:24.000 これはルートドメインのレコードを示します｡ 08:24.000 --> 08:31.650 ディオン・トレーニングの例では､ @レコードはdiontrainingを意味します｡ 08:31.650 --> 08:31.650 comは､ 08:31.650 --> 08:36.930 私たちのドメインのルートであり､ あるIPにリストされることになる｡ 08:36.930 --> 08:38.400 こうすることで､ ユーザーはwww.のサブドメインにアクセスして､ 08:38.400 --> 08:43.980 当社のウェブサイトを見つけることができる｡ ディオントレーニング com､ またはdiontrainingにアクセスしてください｡ 08:43.980 --> 08:43.980 comのA 08:43.980 --> 08:45.510 @レコードを使用する｡ 08:45.510 --> 08:51.180 現在､ AレコードはIPv4アドレスに対してのみ機能するが､ 最近のウェブサイトの多くはIPv6もサポートしている｡ 08:51.180 --> 08:54.060 ドメイン名をIPv6アドレスにマッピングするには､ 08:54.060 --> 08:56.820 AAAAレコードを使用する｡ 08:56.820 --> 09:00.210 ディオン・トレーニングのサイトを例にとると､ ウェブサーバーのIPv6アドレスが2400:cb00:2049:1::a29f:1804であれば､ 09:00.210 --> 09:06.804 AAAAレコードを2400:cb00:2049:1::a29f:1804に設定できます｡ 09:06.804 --> 09:12.930 おわかりのように､ IPv6アドレスはIPv4よりもずっと複雑で､ 09:12.930 --> 09:30.563 私たち人間が記憶するのは本当に難しい｡ 09:30.563 --> 09:36.300 次に使えるレコードのタイプは､ CNAMEレコード（正規名レコード）と呼ばれるものです｡ 09:36.300 --> 09:43.650 AAAAレコードのAレコードの代わりにCNAMEレコードが使われるのは､ ドメインを別のドメイン名やサブドメイン名に向けたい場合である｡ 09:43.650 --> 09:49.200 例えば､ 私はdiontraining以外にもたくさんのドメイン名を所有しています｡ 09:49.200 --> 09:49.200 comに移籍した｡ 09:49.200 --> 09:52.230 これらの中には､ 私が以前経営していた会社やプロジェクトのものもあれば､ 将来いつか使おうと思っているものもありますが､ 09:52.230 --> 10:02.220 とりあえずdiontrainingに解決するCNAMEレコードを設定しています｡ 10:02.220 --> 10:02.220 comに移籍した｡ 10:02.220 --> 10:05.220 例えば､ 私は以前itil4examというウェブサイトを運営していた｡ comのドメイン名を使用していましたが､ そのドメイン名を使用するのをやめて､ 10:05.220 --> 10:12.300 これらのコースをすべて自分のdiontrainingに統合しました｡ 10:12.300 --> 10:12.300 comのウェブサイト｡ 10:12.300 --> 10:15.960 だから､ その古いウェブサーバーを閉鎖したとき､ 10:15.960 --> 10:20.430 私はまだ人々がitil4examと入力できるようにしたかった｡ comにアクセスし､ エラー・ページではなく何かに到達する｡ 10:20.430 --> 10:25.380 そこで､ CNAMEレコードを使って直接diontrainingを指すようにした｡ 10:25.380 --> 10:25.380 comに移籍した｡ 10:25.380 --> 10:28.770 さて､ なぜそんなことをしたいのだろう？ 10:28.770 --> 10:31.650 まあ､ ディオントレーニングと並行して数年間､ 10:31.650 --> 10:40.200 別のサイトにいたからね｡ comに掲載されたリンクの多くは､ そのitil4examで開催された私たちのコースへの推薦でインターネット上に溢れています｡ 10:40.200 --> 10:40.200 comのウェブサイト｡ 10:40.200 --> 10:42.390 そのサイトから最も人気のあるコースの1つがITIL 10:42.390 --> 10:47.400 4 Foundationコースで､ itil4examにありました｡ 10:47.400 --> 10:47.400 com/itil-4-foundation｡ 10:47.400 --> 10:50.100 ウェブブラウザーにそれを入力すると､ 10:50.100 --> 10:54.000 itil4examが表示されます｡ comの一部をdiontrainingに提供した｡ comから直接diontrainingにアクセスしてください｡ 10:54.000 --> 10:54.000 com/itil-4-foundation｡ 10:54.000 --> 11:06.000 つまり､ Redditで見つけた数年前のコースを勧めるリンクを使用しても､ 11:06.000 --> 11:13.500 元のitil4exam. 11:13.500 --> 11:13.500 comサーバーはもはやサービスされておらず､ 11:13.500 --> 11:15.510 オフラインになっている｡ 11:15.510 --> 11:17.790 CNAMEレコードを使用するもう一つのユースケースは､ サービスとしてのソフトウェアを使用していて､ 11:17.790 --> 11:23.370 そのサーバーにサブドメインを提供している場合です｡ 11:23.370 --> 11:28.380 例えば､ 私はFreshdeskというサービスデスクのチケット追跡ソフトを使っている｡ 11:28.380 --> 11:28.380 comのような､ 11:28.380 --> 11:36.360 ちょっと覚えにくいサブドメインをくれた｡ 11:36.360 --> 11:36.360 フレッシュデスク comに移籍した｡ 11:36.360 --> 11:39.780 そこで､ スタッフがサポートデスクを見つけやすくするために､ 11:39.780 --> 11:42.960 SupportというCNAMEレコードを作成し､ この覚えにくいサブドメインを指定しました｡ 11:42.960 --> 11:47.160 だから､ 私のスタッフがサポートに入れば ディオントレーニング comにアクセスすると､ 11:49.050 --> 11:57.780 Freshdeskが発行したサブドメインが提供するクラウドインスタンスにリダイレクトされます｡ 11:57.780 --> 12:03.330 CNAMEレコードはIPアドレスを指すために使用できないことを覚えておいてください｡ 12:03.330 --> 12:09.480 別のドメイン名またはサブドメイン名を指すためにのみ使用できます｡ 12:09.480 --> 12:15.030 次に､ MXレコードがある｡ これはメール交換レコードの略で､ あなたが考えているとおりの働きをする｡ 12:15.030 --> 12:17.940 メールサーバーがどこにあるのかを把握するのに役立つ｡ 12:17.940 --> 12:19.890 MXレコードは､ あなたのメールサーバーに電子メールを誘導するために使用されます｡ 12:19.890 --> 12:21.930 MXレコードは､ CNAMEレコードと同様に､ IPアドレスではなく､ 12:21.930 --> 12:23.670 別のドメインを指すためにのみ使用することができます｡ 12:23.670 --> 12:33.750 MXレコードを作成する際､ それぞれのレコードの優先順位も指定できるようになります｡ 12:33.750 --> 12:38.340 これにより､ メールが最初に使用するサーバーを指定することができます｡ 12:38.340 --> 12:43.770 優先順位の設定に関しては､ 入力した数字が小さいほど優先順位が高くなる｡ 12:43.770 --> 12:47.220 基本的にはゴルフのルールだ｡ 12:47.220 --> 12:48.900 つまり､ mail1. ディオントレーニンフ comを10に設定し､ 12:48.900 --> 12:50.490 mail2. ディオントレーニング comの優先順位を20に設定すると､ 12:50.490 --> 12:52.140 メールはまずメール1を使おうとする｡ 12:52.140 --> 12:57.720 メール1に到達できなかった場合は､ メール2に到達しようとする｡ 12:57.720 --> 13:01.140 複数のサーバーにメールをロードバランスさせたい場合は､ 13:01.140 --> 13:05.700 それぞれの優先順位を同じ値に設定すればよい｡ 13:05.700 --> 13:07.860 つまり､ メール1とメール2のレコードを作成し､ 13:07.860 --> 13:14.760 両方とも優先順位を10にした場合､ すべての受信メールはこれらのサーバー間で交互に負荷分散されることになる｡ 13:14.760 --> 13:17.730 1本目は1本､ 2本目は2本､ 3本目は1本､ 13:17.730 --> 13:21.990 4本目は2本......といった具合だ｡ 13:21.990 --> 13:24.240 次に､ TXTレコード､ つまりテキスト・レコードがある｡ 13:24.240 --> 13:28.050 現在､ テキストレコードは､ ドメイン管理者がドメインネームシステム､ またはDNSにテキストを追加するために使用されています｡ 13:28.050 --> 13:36.120 元々テキストレコードは､ 人間が読めるメモをDNSレコードに追加するための方法として設計されましたが､ 13:36.120 --> 13:42.420 時が経つにつれて､ このテキストレコードに追加されるものが増えていき､ 13:42.420 --> 13:48.000 最終的には､ 機械が読めるデータもテキストレコードに追加されるようになりました｡ 13:48.000 --> 13:53.970 あなたのドメインは､ さまざまなテキストレコードを持つことができます｡ 13:53.970 --> 13:55.770 どちらか1つに限定されるわけではない｡ 13:55.770 --> 13:59.160 ほとんどの場合､ テキストレコードは､ 検証のために機械可読コードを追加することでドメインの所有権を証明したり､ 13:59.160 --> 14:05.100 TXTレコードに特定の機械可読コードを追加することで電子メールのスパム防止を提供したりするために使用されます｡ 14:05.100 --> 14:09.420 例えば､ ディオントレーニング｡ comの場合､ fdkeyという名前のテキストレコードがある｡ 14:09.420 --> 14:09.420 をサポートし､ 14:09.420 --> 14:15.990 DNSレコード内に32桁の16進数でテクスチャを作成する｡ 14:15.990 --> 14:18.330 これにより､ 当社のサポートシステムFreshdeskは､ 14:18.330 --> 14:30.000 当社がドメイン名diontrainingを所有していることを確認できます｡ 14:30.000 --> 14:32.670 これは､ ドメイン所有権の検証の一形態であり､ 14:32.670 --> 14:34.712 そのシステムは私たちのDNSレコードを照会し､ 私たちがDNS 14:34.712 --> 14:39.870 TXTレコードにこのユニークな32桁の16進数列を入力したことを確認することができるからである｡ 14:39.870 --> 14:45.240 本質的には､ 「おい､ このドメインは俺のものだ」と言うためのパスワードのようなものだ｡ 14:45.240 --> 14:45.240 TXTレコードには､ 14:45.240 --> 14:47.130 SPF､ DKIM､ DMARCメッセージなどの情報を記載することで､ お客様のメールサービスを検証し､ 14:47.130 --> 14:57.932 お客様のドメインやメールアドレスを使用している他の人々へのなりすましやスパムとして知られる不要なメッセージの送信をブロックすることができます｡ 14:57.932 --> 15:06.535 SPF（送信者ポリシーフレームワーク）は､ ドメインのメール送信を許可されたホストを識別するDNSレコードで､ 15:06.535 --> 15:10.068 各ドメインに対して1つだけ許可されます｡ 15:10.068 --> 15:13.170 さて､ これらを見ると､ このようなものがあるはずです｡ 15:13.170 --> 15:18.300 これはテキストレコードと呼ばれるDNSレコードです｡ 15:18.300 --> 15:21.780 記号があり､ V=SPF1と書かれていることに気づくだろう｡ 15:21.780 --> 15:22.800 一番最初だよ｡ 15:22.800 --> 15:24.480 次にMX（メールサーバーレコード）があり､ 15:24.480 --> 15:31.350 include:_SPFとある｡ グーグル com､ email:を含む｡ 15:31.350 --> 15:31.350 フレッシュデスク com-all｡ 15:31.350 --> 15:33.600 さて､ これは何を物語っているのだろうか？ 15:33.600 --> 15:34.980 これは私のメールサーバーのSPFレコードです｡ 15:34.980 --> 15:37.830 さて､ なぜグーグルがあるのか｡ そこにいるのか？ 15:37.830 --> 15:41.520 というのも､ 私たちはグーグルのG Suiteを使っていて､ 15:41.520 --> 15:46.200 グーグルは私たちの電子メール・サービス・プロバイダーだからだ｡ 15:46.200 --> 15:47.700 私たちは独自のメールサーバーを運営していません｡ 15:47.700 --> 15:53.640 その代わりに､ 私たちは彼らにそれをさせ､ そのSPFステートメントを含めることで､ 15:53.640 --> 15:57.600 彼らが私たちに代わってメールを送信することを許可しているのです｡ 15:57.600 --> 15:58.920 さて､ その2つ目だが､ 15:58.920 --> 16:00.330 「何のためにあるんだ？ 16:00.330 --> 16:02.100 1つしか持てないと思っていた｡ さて､ SPF文は1つしか持てないが､ DNSで書くとこの全体が1行であり､ 16:02.100 --> 16:07.343 テキストからすべてまでこの全体が1行であり､ それが1つのSPF文である｡ 16:07.343 --> 16:12.960 Freshdeskとは､ 私たちのトラブルチケットシステムです｡ 16:12.960 --> 16:19.230 Dion Trainingのサポートにメールを送ると､ Freshdeskに送信されますが､ 16:19.230 --> 16:22.050 Dion Trainingの私の個人的なメールにメールを送ると､ 16:22.050 --> 16:34.770 Googleに送信されます｡ 16:34.770 --> 16:37.980 さて､ 次にお話ししなければならないのは､ DKIM（dkim）についてです｡ 16:37.980 --> 16:39.300 さて､ これはドメインキーで識別されたメールである｡ 16:39.300 --> 16:44.940 これは､ DNSレコードとして公開される公開鍵を使用したメールの暗号認証メカニズムを提供する｡ 16:44.940 --> 16:46.592 さて､ SPFやDKIMを調べると､ 16:46.592 --> 16:48.660 このように表示される｡ 16:48.660 --> 16:52.500 アドビへのメールの例です｡ comに移籍した｡ 16:52.500 --> 16:55.020 一番上にDMARCが見えますが､ 16:55.020 --> 16:57.660 これについては後で説明します｡ 先ほど説明したSPF､ 16:57.660 --> 17:05.339 そしてDKIMが見えます｡ 17:05.339 --> 17:08.910 これは基本的に非常に長い暗号認証キーで､ 17:08.910 --> 17:10.290 画面上で見ることができる｡ 17:10.290 --> 17:11.520 現在､ DKIMはSPFを置き換えることも､ SPFとともに使用することもできる｡ 17:11.520 --> 17:16.200 次にお話しするのはDMARCで､ DMARCとはドメインベースのメッセージ認証報告と適合性のことです｡ 17:16.200 --> 17:33.870 これは基本的にフレームワークであり､ このフレームワークはDNSレコードとして公開されるポリシーを利用してSPFとDKIMの適切な適用を保証するために使用されます｡ 17:33.870 --> 17:39.240 戻って見たければ､ この時点で見ることができる｡ 17:39.240 --> 17:41.370 DMARCを扱う場合､ SPFと併用することも､ 17:41.370 --> 17:47.190 DKIMと併用することも､ あるいは両方使うこともできる｡ 17:47.190 --> 17:48.690 DMARCは､ どちらか一方を使うこともできるし､ 17:48.690 --> 17:50.340 両方を使うこともできる｡ 17:50.340 --> 17:51.720 さて､ MARCを扱う場合､ 17:51.720 --> 17:55.890 このようになる｡ 17:55.890 --> 17:56.723 では､ これらすべてがどのように連動しているのだろうか？ 17:56.723 --> 18:01.020 まず､ SPF､ DKIM､ DMARCがすべてDNSサーバー上にあることを確認しなければならない｡ 18:01.020 --> 18:05.670 すべての記録が揃えば､ そこからすべてのプロセスが始まる｡ 18:05.670 --> 18:07.050 さて､ 一度これをやってしまえば､ 18:07.050 --> 18:08.842 あとはメッセージを送ろうとするたびに､ 18:08.842 --> 18:12.180 すべてがフォローアップされることになる｡ 18:12.180 --> 18:17.160 この例では､ 2つのメッセージが送信され､ 1つはSMTPサーバーからで､ これは認証済みで緑色で表示され､ 18:17.160 --> 18:20.321 もう1つはドメインを詐称しようとする敵からで､ 18:20.321 --> 18:22.320 これは赤色で表示される｡ 18:22.320 --> 18:24.540 まずは公認のものから｡ 18:24.540 --> 18:27.270 ここでは2Aと記載されている｡ 18:27.270 --> 18:28.740 送信者はそのメッセージをMTAに送る｡ 18:28.740 --> 18:30.960 このメッセージはMTA（メッセージ転送エージェント）に送られ､ 18:30.960 --> 18:35.280 MTAはSPFまたはDKIMヘッダーの付いたメッセージを受け取ることになる｡ 18:35.280 --> 18:37.350 さて､ このメッセージに少しこだわって､ 18:37.350 --> 18:39.030 敵の話に戻ろう｡ 18:39.030 --> 18:42.510 MTAはそのメッセージを受け取ると､ 18:42.510 --> 18:47.340 そのメッセージを見て､ そのメッセージを処理する｡ 18:47.340 --> 18:49.700 その際､ DNS経由で送信者のDMARCポリシーとSPFレコード､ 18:49.700 --> 18:55.455 DKIMレコードを検索することになる｡ 18:55.455 --> 18:57.840 さて､ MTAがそうすれば､ それが正当なものであれば､ 18:57.840 --> 18:59.400 そのメッセージはIMAPサーバー上の受信者のメールボックスに入れられ､ 18:59.400 --> 19:05.430 その人がメールユーザーエージェントを使ってメッセージを読めるようになるのを待つことができる｡ 19:05.430 --> 19:09.330 なぜなら､ 設定されたポリシーに基づいて､ 19:09.330 --> 19:15.360 SPF､ DKIM､ DMARCとそれらの値を比較したからだ｡ 19:15.360 --> 19:21.143 敵がメッセージを送信する際､ エンドユーザーに届くにはMTAに送らなければならないからだ｡ 19:21.143 --> 19:22.740 いったんDMARCに届くと､ 19:22.740 --> 19:29.370 MTAはSPFやDKIMレコードを見ながらDMARCポリシーと照合する｡ 19:29.370 --> 19:31.020 もし一致しなければ､ 5Bにあるように､ 19:31.020 --> 19:33.205 そのメッセージは拒否され､ 削除されるか､ 19:33.205 --> 19:37.350 隔離されて捨てられる｡ 19:37.350 --> 19:44.268 DKIM､ DMARC､ SPFを併用することで､ 組織にセキュリティを加えることができる｡ 19:44.268 --> 19:48.210 最後に､ ネームサーバーレコードを意味するNSレコードがある｡ 19:48.210 --> 19:50.010 さて､ ネームサーバーレコードは､ 19:50.010 --> 19:55.740 世界中のどのDNSネームサーバーがそのドメインの権威となるかを示すために使用されます｡ 19:55.740 --> 19:58.910 DNSは先ほど説明した階層モデルを使用しており､ すべてのサーバーは誰がそのレコードの所有者で､ 19:58.910 --> 20:05.730 そのレコードに変更を加える権限があるのかを知る必要があるからだ｡ 20:05.730 --> 20:08.550 さて､ ネームサーバーとは､ Aレコード､ AAAAレコード､ 20:08.550 --> 20:11.220 カノニカルネームレコード､ MXメール交換レコード､ TXTテキストレコードなど､ 20:11.220 --> 20:18.900 すでに説明したすべてのタイプを含む､ 指定されたドメインのすべてのDNSレコードを格納するDNSサーバーの一種です｡ 20:18.900 --> 20:20.550 1つのドメインに対して複数のネームサーバーが存在することもよくあるので､ 20:20.550 --> 20:22.855 プライマリとバックアップのネームサーバーを持つこともできます｡ 20:22.855 --> 20:28.800 さらに､ ネームサーバーは常に自分でホストする必要はありません｡ 20:28.800 --> 20:36.780 diontraintrainingの場合｡ comでは､ 独自のネームサーバーをホストしていません｡ 20:36.780 --> 20:42.960 その代わりに､ 私たちはクラウドサービス・プロバイダーであるCloudflareを利用している｡ 20:42.960 --> 20:47.670 そこで､ diontraining.comのDNSレコードを調べると､ 次のようになります｡ comの2つのネームサーバーである｡ 20:47.670 --> 20:54.510 さて､ ここまでは､ 世界中の誰もがアクセスできる一般公開されたDNSサーバーをホスティングするという観点からDNSについて話してきたが､ 20:54.510 --> 20:59.880 DNSは実際には内部でも外部でも使用することができる｡ 20:59.880 --> 21:01.593 これまで話してきたことはすべて対外的な話だが､ 21:02.490 --> 21:06.330 対内的な話を少ししよう｡ 21:06.330 --> 21:10.230 最近のクラウドコンピューティングでは､ 同じネットワークやプライベートクラウド内のクラウドインスタンスに､ 21:10.230 --> 21:14.100 IPアドレスを使用する代わりに内部DNS名を使用して相互にアクセスできるように､ 21:14.100 --> 21:18.900 内部DNSサービスもセットアップすることが非常に一般的になっている｡ 21:18.900 --> 21:20.460 そのために､ 内部Aレコードが作成され､ 21:20.460 --> 21:25.590 内部ポインターレコードもリバースゾーンに作成される｡ 21:25.590 --> 21:28.350 幸いなことに､ ほとんどのクラウドプロバイダーは､ プライベートクラウドでさまざまな仮想マシンやその他のインスタンスを作成したり削除したりする際に､ 21:28.350 --> 21:36.960 これらの内部DNSレコードを自動的に作成､ 更新､ 削除してくれる｡ 21:36.960 --> 21:40.740 しかし､ 外部DNSは私たちの多くがより慣れ親しんでいるものだ｡ 21:40.740 --> 21:43.980 これは､ 私たちが中央機関から購入し､ 21:43.980 --> 21:51.930 公共のインターネット上で使用するドメイン名の周りに作成されるレコードです｡ 21:51.930 --> 21:55.710 さて､ 各DNSレコードには､ TTL（生存時間）と呼ばれるものも関連付けられています｡ 21:55.710 --> 21:58.830 time to liveは､ DNSリゾルバに､ 新しいクエリを要求する前にクエリをキャッシュできる時間を指示する設定である｡ 21:58.830 --> 22:04.890 つまり､ 私のDNSレコードが86,400秒（通常デフォルト）に設定されている場合､ 22:04.890 --> 22:12.060 私のコンピューターはそのDNSレコードを解決し､ DNSサーバーに再度情報を要求するまでの24時間､ 22:12.060 --> 22:15.540 そのレコードを記憶していることになる｡ 22:15.540 --> 22:18.390 このDNSリゾルバは､ DNSキャッシュとしても知られ､ 22:18.390 --> 22:22.380 個々のホストに配置されています｡ 22:22.380 --> 22:27.720 そのため､ 例えばWindows 10を使用している場合､ インターネット上のウェブサイトに接続するたびに､ 22:27.720 --> 22:32.160 コンピューターはDNSエントリーのローカルコピーを作成していることになる｡ 22:32.160 --> 22:37.410 この一時データベースは､ DNSサーバーから受け取った回答を記憶している｡ 22:37.410 --> 22:43.409 だから､ diontrainingに行けば｡ comの場合､ 今日初めてそれを実行すると､ コンピューターはDNSサーバーにそのIPアドレスを問い合わせなければならないが､ 今ではそのIPアドレスがどこにあるか知っており､ 22:43.409 --> 22:49.410 今後24時間そのIPを記憶している｡ 22:49.410 --> 22:52.980 今日､ 私のウェブサイトに5回アクセスしたとしても､ そのIPアドレスを調べる必要があったのは1回だけだ｡ 22:52.980 --> 22:54.630 これは､ 私たちにとってプロセス全体のスピードアップに役立つ｡ 22:54.630 --> 22:59.550 さて､ 明日もう一度やってみると､ コンピューターはまずDNSキャッシュをチェックし､ 22:59.550 --> 23:02.370 そこにレコードがあることを確認する｡ 23:02.370 --> 23:04.620 しかし､ もしその持ち時間がすでに過ぎていれば､ そのレコードは無効となり､ 23:04.620 --> 23:09.660 別のルックアップが実行されることになる｡ 23:09.660 --> 23:13.590 最後に､ 再帰検索の概念について説明しよう｡ 23:13.590 --> 23:15.270 あなたのコンピュータがdiontrainingのようなウェブサイトを見つけようとするとき､ 23:15.270 --> 23:19.050 あなたは知っています｡ comの場合､ まずDNSサーバーにその場所を尋ねる必要がある｡ 23:19.050 --> 23:20.910 例えば､ 自宅でベライゾン・フィオスの接続を使っている場合､ 23:20.910 --> 23:26.400 DNSサーバーに "Who's diontraining. 23:26.400 --> 23:26.400 com? さて､ 23:26.400 --> 23:28.560 ベライゾンのDNSは､ diontrainingのIPアドレスを知っているかもしれないし､ 知らないかもしれない｡ comに移籍した｡ 23:28.560 --> 23:33.210 何しろ､ 世の中には何百万､ 何千万というウェブサイトがあるのだから､ 24時間ごとに記録を再同期させなければならないとしたら､ 23:33.210 --> 23:35.790 長い時間がかかることになる｡ 23:35.790 --> 23:39.510 そのため､ DNSはこの再帰的戦略を使って検索を行う｡ 23:39.510 --> 23:44.220 ベライゾンに聞いて､ 答えがわからなければ､ レベルを上げて次のDNSサーバーに聞くというわけだ｡ 23:44.220 --> 23:46.200 もしそのサーバーが答えを知らなければ､ もう一つ上のレベルに行き､ 23:46.200 --> 23:55.350 diontrainingのIPアドレスを知っている人を見つけるまでこのプロセスを続ける｡ 23:55.350 --> 23:55.350 comに移籍した｡ 23:55.350 --> 23:59.850 さて､ この再帰の間に. 23:59.850 --> 23:59.850 com､ またはdiontrainingのルートドメインです｡ comに問い合わせることができる｡ 23:59.850 --> 24:04.230 comのルートサーバーは､ どのDNSサーバーがdiontrainの権威であるか｡ 24:04.230 --> 24:04.230 comから直接､ 24:04.230 --> 24:05.520 権威ある回答を得ることができる｡ 24:05.520 --> 24:07.654 基本的に､ 再帰検索では､ DNSリゾルバは､ 24:07.654 --> 24:11.370 「このドメインのIPが何であるか知らないが､ 24:11.370 --> 24:22.530 DNSサーバーに尋ねるつもりだ｡ 24:22.530 --> 24:22.530 さて､ 24:22.530 --> 24:25.320 反復ルックアップと呼ばれる別の方法もある｡ 24:25.320 --> 24:27.090 反復検索では､ DNSサーバーがあなたのために情報を検索し続け､ 24:27.090 --> 24:28.777 その結果をあなたに送らないことを除けば､ 24:28.777 --> 24:30.870 再帰検索に似ている｡ 24:30.870 --> 24:35.310 その代わり､ 反復検索では､ DNSリゾルバがDNSサーバーにドメインのIPを尋ね､ DNSサーバーが知らなければ､ 24:35.310 --> 24:37.140 次のDNSサーバーに尋ねるようにリゾルバに伝え､ 24:37.140 --> 24:43.530 そのサーバーがIPを提供します｡ 24:43.530 --> 24:45.929 再帰検索では､ DNSサーバーがそれを探し出し､ 24:45.929 --> 24:53.550 リゾルバに報告しますが､ 反復検索では､ DNSリゾルバは､ 24:53.550 --> 25:02.820 そのドメインのIPを持つものを見つけるまで､ このクエリを再帰的に実行し続けます｡ 25:02.820 --> 25:04.800 さて､ このレッスンで多くの情報を扱いましたが､ 25:04.800 --> 25:09.390 簡単なまとめとして､ 試験のために知っておくべきことは何でしょうか？ 25:09.390 --> 25:12.540 ドメイン名をIPアドレスに､ IPアドレスをドメイン名に変換するために､ 25:12.540 --> 25:17.310 DNSがどのように機能するかを理解する必要があります｡ 25:17.310 --> 25:23.670 AレコードはIPv4アドレスのドメイン名に使用され､ AAAAレコードはIPV6アドレスのドメイン名に使用されることを覚えておく必要がある｡ 25:23.670 --> 25:28.260 CNAMEレコードは､ ドメイン名を他のドメイン名にマッピングするために使用されます｡ 25:28.260 --> 25:30.463 MXレコードは電子メールに使われ､ 25:30.463 --> 25:33.690 NSレコードはネームサーバーに使われる｡ 25:33.690 --> 25:39.213 TXTレコードは､ 人間が読めるデータまたは機械が読めるデータとしてテキストを保存する｡ 25:39.213 --> 25:48.030 この要約を覚えておけば､ 試験で出題されるDNSの問題のほとんどに答えられるはずだ｡