名前解決フローおよびメール送受信フロー

#はじめに
名前解決をする際のフローについては様々な参考書が紹介してくれておりますが、DNSサーバが社内にあったときはLAN-WAN間ではどのようなトラフィックが生成されるのか？社外にあったときは？などと、具体的なフローについては漠然としたままでしたので、一度腰を据えて考えてみました。
それは違うよ、といった内容がありましたらご教示ください。

#DNS
名前解決のフローについていかにイメージ図をまとめる。
##教科書に載っているフロー
PCが名前解決をする際には、端末上のDNSクライアントがフルサービスリゾルバにクエリを送信し、フルサービスリゾルバは権威DNSサーバに反復問い合わせを行って、解決結果をDNSクライアントに回答する。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2b281756-9107-be01-337b-4b45b929bca0.png)

##もうちょっと具体的に
###社内DNSサーバがフルサービスリゾルバとして、PC端末から参照されている場合
社内リソースはそのままAレコードを見て解決する。社内DNSサーバが保持していないゾーンについて解決しないといけない場合、ルートヒントを参照してルートサーバから反復問い合わせを行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/f3938eaa-bd7b-d432-a3a1-ef6d84451645.png)

社内DNSサーバがフォワーダを指定している場合、社内DNSサーバからフォワーダへは再帰問い合わせを行い、フォワード先のDNSサーバが反復問い合わせを行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/8f33bd62-1562-e223-22d0-32bcbc4ec1a4.png)

###社外DNSサーバがフルサービスリゾルバとして、PC端末から参照されている場合
社内DNSサーバの際と比較して、フルサービスリゾルバが社内にあるか社外にあるかだけ。ただしこの場合は社内リソースの名前解決はできない。ISPのDNSサーバを参照している場合などは、自社ドメインのゾーン情報をDNSサーバに登録することはできない。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2af07d00-af07-df44-1a78-787d2b899d6f.png)

###Proxy接続時の名前解決フロー(社外DNS)
Proxyサーバを経由する通信の場合、端末からはproxy通信のほうが先に行われる。DNSの名前解決はproxyサーバが行う。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/d766d3f8-8338-44e8-d7b4-8a91fa0f46fb.png)
こちらの[SEの道標](https://milestone-of-se.nesuke.com/nw-basic/grasp-nw/proxy/)さんが非常にわかりやすかった。私の資料なんかよりこちらを一読することを強く推奨。

####DNS用語
ゾーン…コンテンツサーバが管理するドメインの情報の範囲。各ゾーンを一つのデータベースが管理している。ドメインごとにデータベースを分けて管理しても、複数ドメインをまとめて一つのデータベースで管理してもよい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/1d9d0c80-1015-1db0-38ff-cee60966e4d0.png)
出典：ITmediaさんの[ゾーンとは](https://atmarkit.itmedia.co.jp/fnetwork/dnstips/008.html)

フォワーダ…クライアントから名前解決のクエリがあった場合に、そのクエリを再帰問い合わせとして別のDNSサーバに転送すること。
　排他モード…フォワーダがDNSクエリを解決できない場合、フルリゾルバは自分で名前解決を行わず、失敗を返す。
　非排他モード…フォワーダがDNSクエリを解決できない場合、フルリゾルバが自分で名前解決を行う。

ルートヒント…フルリゾルバに保存されているルートサーバのIPアドレス一覧情報。企業内ネットワークにおいて各DNSサーバがインターネット上のリソースの名前解決を行わない場合、ルートヒントには企業内ネットワークにおけるルートサーバのIPアドレスに変更する必要がある。



##レコードの種類
|レコード名|内容|
|:---:|:---|
|Aレコード|ホスト名とIPv4アドレスの結びつきを示す。|
|AAAAレコード|ホスト名とIPv6アドレスの結びつきを示す。|
|SOAレコード|自ゾーンや下位ドメインのDNSサーバのホスト名を記述する。|
|MXレコード|メールアドレスの@以下を解決する。実際にメールアドレスから宛先メールサーバのホスト名を調べるのはメールサーバであり、PC端末上のクライアントはメールをサーバに送信するだけ。|
|CNAMEレコード|ホスト名に別名をつける。1台のWebサーバにメールサーバやFTPサーバの機能を持たせたいときなど。コンテンツサーバはAレコード検索にて情報が見つからなければ、CNAMEレコードを検索し、その結果を回答する。別ホスト名にて同一ゾーンにAレコードがあればその検索結果も回答するが、ない場合はリゾルバ側で改めて問い合わせを行う。|
|SPFレコード(TXTレコード)|送信元アドレスのドメインを参照し、メールの認証を行う。|

###ゾーンファイル例
DNSサーバの保持するゾーンファイルの一例を以下に示す。リソースレコードの集合体を、ゾーンファイルという。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/e44c8e48-7eb8-67cf-cee9-899a6cbfc5dc.png)
出典：infraexpertさんの[TCP/IP - DNS 2](https://www.infraexpert.com/study/tcpip23.html)

###BIND
上記のゾーンファイルは、DNSサービスを提供するソフトウェアであるBINDにおける例である。
BINDは、DNSサーバとして機能するゾーン、プライマリ/セカンダリの指定およびコンテンツ/キャッシュなどの指定をするnamed.confファイルと各ゾーンの情報を保持するゾーンファイルから構成される。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/db79f913-a190-3da9-401b-a59dbad70eb3.png)
出典：Plat’Home[DNSサーバの設定](https://www.plathome.co.jp/support/labo/obs/dns.html)

##その他
###URLとFQDNとホスト名の違い
ホスト名＋ドメイン名=FQDN
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/55d9a404-b4bf-09ce-6cc1-e0f85ea1896b.png)
FQDNの頭に利用する通信方式(httpsやftp)およびディレクトリ・ファイル名を指定したものがURL。FQDNの部分はIPアドレスでもOK。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/64b7864e-3465-5d92-6aba-ea4bec12f255.png)

#メール送信フロー
メール送受信のフローについて以下にまとめる。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/3ef9a84d-d6a0-279d-b874-6af48fc1a032.png)

##メール送受信に必要なAgent
メールサービスは複数のプログラムを用いることで成立している。
**MUA：Mail User Agent**　ユーザの作成したメールをMTAに送る。MRAと連携し、メールをユーザが読める形式にする。
	メールクライアント
**MTA：Mail Transfer Agent**　メールを転送する。DNSのMXレコードを参照してドメイン名から転送先のメールサーバを探す
	sendmailやqmail、Postfix
**MDA：Mail Delivert Agent**　自身の所管のドメイン宛てのメールを受信した際に、各ユーザのメールボックスに格納する機能
**MRA：Mail Retrieval Agent**　サーバのメールボックスからメールを取り出し、クライアントに提示する機能。POPやIMAP
※各機能は一つのエージェントに同居する
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/2b978905-bc0e-f13b-bddb-bd738d43bf40.png)

##社外メールサーバ
例として、Exchange Online。
メールクライアントからメールが送信されるのは社外のExchangeサーバ。メールサーバ間でメールが受け渡されると、受信側のPCは社外のメールサーバに向けてメールの問い合わせを行う。（POP3,IMAP）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/6d9e9295-8842-08e3-415a-2583dcae4667.png)

##Webメール
gmailなどはブラウザ上から操作する場合にはメールサーバにはwebサーバが命令をするが、アプリから操作する場合には
メールクライアントが命令するらしい。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/469705/c9935fba-1da7-12ba-f91c-17fc31690780.png)

####メール用語
**POP** サーバからクライアントにメールを転送し、クライアントが読み出す。クライアントはネットワークに接続されていない
場合でもメールを読むことができる。

**IMAP** ヘッダ情報のみをクライアントに転送し、クライアントの指示に従いサーバはメールを転送する。ネットワークに接続
されていない場合でもメールを読めるよう、転送しておくことができる。

**APOP** メール受信時にMD5を利用したチャレンジーレスポンス認証方式を用いる。POPサーバとクライアントの双方がAPOP
に対応している必要。メール本文は暗号化しない。

**SMTP Auth** メール送信時にユーザの認証を行う。クライアント-サーバ間。

**POPS / IMAPS** メール受信時にSSL/TLSで通信経路を暗号化する。サーバ-クライアント間。

**SMTPS** メール送信時にSSL/TLSでメールクライアント-サーバ間の通信経路を暗号化する。

**S/MIME / PGP** クライアント間でのすべての経路にてメールの暗号化を確実にする仕組み。S/MIMEはPKIの仕組み、
PGPは信頼の輪。暗号化がクライアント-サーバ間のみで、サーバ間は暗号化が行われていない可能性があるため。