リゾルバ
名前解決を要求するクライアントのこと．
特に，PC等のエンドポイントのことをスタブリゾルバと呼ぶ
フルサービスリゾルバ
再帰検索によって名前解決を実施してくれるDNSサーバのこと
コンテンツサーバ
オリジナルのDNSレコードが保存されているDNSサーバのこと
別名は権威サーバ
キャッシュサーバ
フルサービスリゾルバにおいて，一定期間の問い合わせ結果を保持（キャッシュ）し，有効期限内はキャッシュ内から結果を応答するDNSサーバ．
自ドメインからの要求に対してのみ，再帰解決を行う設定とすべき．外部ドメインからの要求に対して名前解決を実施できる場合，DSNリフレクションに利用される．
オープンリゾルバ
外部ドメインからの要求に対して，名前解決を実施するDNSサーバ．
DNSリフレクションに利用されるため，この設定は無効化されるべき．
プライマリサーバ，セカンダリサーバ
コンテンツサーバを冗長化する際に，オリジナルのレコードを保存しているコンテンツサーバをプライマリサーバと呼ぶ．プライマリサーバから同一情報をセカンダリサーバに転送し，冗長化されたシステムとする．
なお，DNSレコードの集合のことをゾーンと呼び，セカンダリサーバにこの情報を転送することをゾーン転送と呼ぶ
外部DNSサーバ
外部DNSサーバ＝コンテンツサーバ
外部から自ドメインの問い合わせがあった場合に応答するサーバーのこと．例えば自ドメイン内にあるWebサーバ等の名前解決を実際に提供するサーバ．
内部DNSサーバ
内部DNSサーバ＝内部で独自のドメインを構築している場合にはコンテンツサーバ，あるいは，自ドメインからの要求で外部の名前解決を実施するキャッシュサーバ，あるいはその両方
実際の構成
プライマリサーバ，セカンダリサーバをDMZに，内部DNSサーバ（キャッシュサーバ）を内部ネットワークに配置する．
小規模ネットワークでは，DMZに唯一のDNSサーバーを設置し，外部DNSサーバーと内部DNSサーバーの役割を兼ねることがある
DNSリフレクション
オープンリゾルバに対して，自身のIPを攻撃対象のIPに偽装して名前解決を要求することで，その応答を攻撃対象に送り付けることができる攻撃方法．
DNSは基本的にUDPを採用していることから，IP偽装が容易であることから非常によく利用される攻撃．また，攻撃者のリクエストに対して，DNSサーバからのレスポンスは非常に大きいため，攻撃者はDNSを仲介することで効率的に攻撃対象に負荷をかけることが可能．
対策は外部からの名前解決要求には応答しないように，全てのDNSサーバ(コンテンツサーバ・キャッシュサーバともに)に設定すること
増幅される理由は以下が非常に分かりやすかったです．Aレコード数を調整することでフォーマット上許可される最大バイト数まで増幅して攻撃します．
https://jprs.jp/tech/material/iw2013-lunch-L3-01.pdfRFC1035
これがDNS関連の規格．パケットの規格も書かれています
DNSのUDP/TCPポート
53
DNS水責め攻撃
こちらもオープンリゾルバを利用した攻撃ですが，攻撃対象はDNSサーバです．DDos攻撃の一種です．
example.comのDNSサーバーに攻撃をするとします．この時，複数のオープンリゾルバに対して，dafafda.example.comのような架空アドレスの名前解決をリクエストします．その結果，大量のリクエストが対象のDNSサーバーに到達し，DNSサーバーが機能不全になります．
なお，架空アドレスはリクエストごとに変更します．これは同一アドレスを問い合わせた場合，オープンリゾルバがキャッシュした結果が応答されるため，攻撃対象にリクエストが届かないためです．
MXレコード
メールサーバーの位置を示す．
xxxxx@example.com
というメールを送信する場合には，example.comのdnsサーバに問い合わせが行われ，そのMXレコードからメールサーバを名前解決しそれを応答する．
//MXレコード例 10は優先度．複数ある場合に利用され，小さいほど優先度が高い． IN MX 10 mailserver.example.com.
ちなみに一番最後にドットを付けるのは必須です．注意してください．ドットがついている場合FQDNとして認識され，ドットがない場合にはゾーンのドメインが自動的で付与されます．たとえば，間違ってmailserver.example.comとするとmailserver.example.com.example.comとして認識されます．DNSレコード全てに適用されます．
SPF(Sender Policy Framework)
IPアドレスを使用した送信ドメイン認証で，認証にDNSサーバーを使用します．
①送信側：DNSのSPFレコードに送信可能性のあるメールサーバのIPを指定する
②メールを送信
③受信側：MAIL FROMに指定されたドメインのDNSのSPFレコードを参照し，SMTP通信を行ったIP（メールを送信したメールサーバ）が登録されたIPかどうか検証する
というプロセスで認証が行われます．SMTPにおいては，From:ヘッダーを容易に変更することができるため，そのなりすましの検出を目的としています．
SPFレコードに対応していないDNSも存在しているため，SPFとTXTの両方のレコードを登録することが推奨されている
TXTレコード
example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
SPFレコード
example.com. IN SPF "v=spf1 ip4:192.0.2.1 -all"
SMTPにおいてEnvelope-From (MAIL FROM)を偽装できるのはなぜ？
MAIL FROMの偽装を行えるのは効率を優先したプロトコルであるためです．郵便物もポストに投函するときに送信元住所のチェックがされないように，電子メールにおいてもMAIL FROMに記載されたドメインとIP接続しているメールサーバが同一かどうかは検証しません．これはメール転送時のオーバーヘッドを極力小さくするための仕様です．”Simple” Mail Transfer Protocolという名前からも想像できますね．
Envelope-Fromは宛先不在時にError通知メッセージの時に初めて利用されます．
SMTPにおいてHeader-Fromが偽装できるのはなぜ？
これは利便性が目的です．Envelope-FromとHeader-Fromを別に設定したい場合があります．例えば，外部のメールサーバを利用して送信したい場合等です．メールマガジンの配信を外部サービスを用いて行うことはよくあることですので，この場合，
Envelop-From : 外部のメールサーバ
Header-From：自分のメールサーバ
と設定したいことはよくあることです．したがって，Header-FromとEnvelope-Fromの齟齬は利便性から意図して組み込まれています．攻撃者にとってはとても都合がいいことになっているわけですが・・．
MTA (Mail Transfer Agent)
MUA(Mail User Agent)から送信されてきたメールをEnvelope情報に基づいてMTA(Mail Distributor Agent)に仕分けるSMTP内のプログラムのこと．
メールのHeader部を確認したい
Gmailの場合は以下から確認可能です．
Receivedフィールドを確認することでどのメールサーバを経由してきたか確認することが可能です．下にあるものほど古い情報になります（すなわち，下から上に伝播していっています）以下の形式で書かれているのでとても分かりやすいです．送信元MTAから送られたきたメールを送信先MTAで受信したというそのままの意味で理解できます．
Received: from 送信元MTA by 送信先MTA
Return-Path:送信元アドレス
Delivered-To:宛先アドレス（自分）
などがあります．Gmailの場合，SPF, DKIMは設定されていることがわかりますね．
DKIM（Domain Keys Identified Mail）
①送信側メールサーバがメールヘッダにデジタル署名を添付
②受信側メールサーバはDNSのTXTレコードから公開鍵を取得し，認証する
TXTレコード
sls.dkim._domainkey.smtest.com. 300 IN TXT "v=DKIM1; k=rsa; t=y; p={公開鍵}"
nslookup
DNSの名前解決を実施するコマンド．DNSサーバーが実施するリクエスト・レスポンスを様々な条件・形式で実施できるため，トラブルシュートに役立つ．
以下はgoogle.comのアドレスを問い合わせた例．他にも様々な機能があるので，実際に利用する際に調べること
