Network_03_

name: wholesight
class: title, smokescreen, shelf, no-footer
# DNS Part I 全体像と用語

<div class=footnote>
<small><small>
注: Part ごとに別の動画になっています。中間試験の範囲はPart Iだけです
</small></small>
</div>

<div class=digest-begin-01></div>
---
class: img-right,compact
# WWWの動作(DNS込み)

![](images/resolver.png)

<small>
- 前回はDNSを省略しています(図(3)(4))
- 右図がDNSを含めたHTTPの動作です。
  ブラウザにURIを指示すると
    - (1) ブラウザはURIに含まれるサーバ名portal.mc.chitose.ac.jpの
          IPアドレスをDNSサーバに問い合わせます
    - (2) DNSサーバはブラウザにIPアドレス=210.128.52.45を回答
    - (3) ブラウザは210.128.52.45と通信を始めます
          (このあとは[前回](https://lectures.fml.org/slides/network/tcpip/app_www/#4)のとおり)
- このIPアドレスを検索する仕組みを**DNS**と呼んでいます。
  今回はコレの解説
</small>

---
class: img-right,compact
# DNS = Domain Name System (Service)

<div class=footnote>
<small><small>
(脚注)
ディレクトリサービス(DS)の典型例が電話帳(e.g. タウンページ)です。
認証システムもユーザとパスワードの一覧という電話帳似のデータを持つので DS です。
例: Active Directory, OpenLDAP(-> 後継? 389-ds?)
</small></small>
</div>

![電話帳](images/yellowpage.jpg)

<small>
- Domain Name System (Service)の略
- **ディレクトリサービス**の一種
- 文字列からIPアドレスを検索する仕組みが代表例です:
  DNSの検索例
    - portal.mc.chitose.ac.jpドメインのIPアドレスを知りたい
    - IPアドレス210.128.52.45に対応するサーバ(のドメイン)名が知りたい
    - user@photon.chitose.ac.jp宛メールの送信先(メールサーバ名)を知りたい
    - photon.chitose.ac.jpについて管理しているDNSサーバを知りたい
</small>

---
class: img-right,compact
# あらゆるサービスが裏でDNSを使っています

<div class=footnote>
<small><small>
右図: portal.mc.chitose.ac.jp にアクセスしている様子。
<br>
ブラウザは、裏で
(1)(2)DNSを使ってIPアドレスを割り出し、
(3)(4)そのIP(210.128.52.45)へアクセスします
</small></small>
</div class=footnote>

![](images/resolver.png)

<small>
- ユーザ利便性はドメインの方がよいはず
- ユーザがIPアドレスでインターネットにアクセスするのは現実的ではありません
    - 何十個も数字を覚えられる?
    - 英語に近い表記を使いたい
        - 例: `https://portal.mc.chitose.ac.jp/`
        - 例: `username@photon.chitose.ac.jp`
- プログラムにとっては、すべて**数字**
    - **OSの内部**では、通信先の指定を**数字=IPアドレス**で行っています
      <br>
      (例: 210.128.52.45)
</small>

---
class: col-2,compact
# DNS関連の重要用語まとめ

<div class=footnote>
<small><small>
(脚注1)業界人はdotを発音しませんが、あうんの呼吸で理解してね
(脚注2)Googleのchubbyも地球規模ですな...
</small></small>
</div class=footnote>

<small>
- **DNS**
    - Domain Name System (Service)
    - インターネットの基盤技術
    - 地球規模の**分散システム**の成功例
    - **UDP**ベースの数少ない例
- **ドメイン名**
    - **.**(発音はdot)区切の文字列
        - chitose.ac.jp
    - **FQDN** (Fully Qualified Domain Name)
        - ホストの完全なドメイン名
        - 階層をすべて表記したもの
            - portal.mc.chitose.ac.jp
            - g201pc001.pc.chitose.ac.jp

<wbr>
- **木構造**をしたデータベース
    - 格納している情報を**レコード**と呼ぶ
    - 例:Aレコード(IPアドレス)
- **ネームサーバ** (歴史的にはコレ)
    - 最近はDNSサーバと言うことも多い
    - スライドは**DNSサーバ**に統一
- **名前解決**(name resolution)
    - ネームサーバから情報を取得することで、
      この動作をするソフトウエアが**リゾルバ**(resolver)
    - 例:ドメイン名からIPアドレスを取得
</small>

---
class: col-2,compact
# ドメイン名

- ドット`.` 区切りの文字列
    - 使える文字は、英数字とハイフン(**-**)です
      (大文字小文字は区別しません)
    - 階層構造を表現しています(後述)
- 例: メールアドレス
    - b999999@photon.chitose.ac.jp
       - photon.chitose.ac.jp がドメイン名
       - b999999 はユーザ名
         (大文字小文字を区別したほうが良いでしょう。
	  区別するかしないかは微妙な話題で、
	  メールサーバとOSの実装依存ですが、
	  厳しい方に合わせるのが安全です)

<wbr>
- 用法上の注意
    - ドメインとドメイン名の使い分けはRFCも曖昧で断言しづらい...;_;
        - ドメイン: 領土のような意味合いに力点がある場合?(抽象的?)
        - 同じ意味で使っているようにみえる場合もあり...
            - ドメイン名をドメインと呼ぶ例: TLD(後述), サブドメイン
    - たとえばportal.mc.chitose.ac.jpの場合、(一番左の)
      ホストの役割を説明するportal部分をホスト名と呼ぶ風習がありますが、
      **コンピュータを識別するための名前(ホスト名)にはFQDN**を使うべきです

---
class: col-2,compact
# ドメインの階層構造(全体とTLD)

- ドット`.` 区切りの文字列
- 階層構造
    - **ホスト名.組織.組織種別.国名**
    - 右側がより大きな単位
    - 例: chitose.ac.jp
        -    chitose (千歳、この場合は大学名)
        -    ac (高等教育機関,academic)
        -    jp (日本,TLD)
- TLD (top level domain)
    - 一番大きな単位(一番右側)
    - もともとは国ごと+アメリカ特例枠
    - 基本は二文字の国名
        - jp (日), uk (英), us (米国,USA)
    - 各TLDごとに登録を管理する組織(レジストラ,民間企業)があります
    - アメリカ特例枠
        - (初期から存在する)us をつけないアメリカのドメイン
        - com net org が有名
            - 1990年代後半に一般開放したため、
              ドメイン取得者がアメリカ人とは限りません
            - 慣習的に<br>「**ソフトウエア名(OSS).org**」
                - 例: fml.org (このサーバ:-)
        - edu gov mil ... アメリカ固有
    - 目的別? info tel
    - 地域? asia など
    - その他も(気づくと)新TLDが登場...

---
class: compact
# ドメインの例

| TLD | 2LD     | 属性                   | 例                                        |
|-----|---------|------------------------|-------------------------------------------|
| net |         | ネットワーク           | nuinui.net                                |
| com |         | 営利企業               | amazon.com zoom.com(zoom.usへ転送)        |
| org |         | 任意団体(ソフト名)     | netbsd.org debian.org postfix.org fml.org |
| edu |         | アメリカの高等学術機関 | mit.edu                                   |
| gov |         | アメリカ政府           | www.whitehouse.gov                        |
| mil |         | アメリカ軍             | af.ml  (US空軍)                           |
|     |         |                        |                                           |
| us  |         |                        | zoom.us                                   |
|     |         |                        |                                           |
| jp  | ac      | 日本国内の高等教育機関 | chitose.ac.jp                             |
|     | co      | 民間の営利企業         | toyota.co.jp amazon.co.jp                 |
|     | go      | 政府関係               | mext.go.jp                                |
|     | ed      | 教育機関               | sapporonishi.hokkaido-c.ed.jp             |
|     | lg      | 地方自治体             | pref.hokkaido.lg.jp                       |
|     | 名前    | なし                   | toyota.jp amazon.jp(co.jpへ転送)          |

---
class: img-right,compact
# ドメインの階層は木構造

<div class=footnote>
<small><small>
(脚注)
正しいドメイン名は一番右に.がつきますが、
面倒(?)なので、たいてい一番右の.を省略して書くことが多いです
(例: portal.mc.chitose.ac.jp.)
</small></small>
</div>

![](images/tree.png)

- 各TLDごとに管理
    - 各TLDごとにレジストラ(+ レジストラへの登録代行業者)
    - jpドメインは[JPRS](https://www.jprs.co.jp/)(2002/04/01-)
      (2002/03/31までは[JPNIC](https://www.nic.ad.jp/))
- DNSは図のように木構造と考えられます
    - 数学のグラフ理論由来で、接点はnode、端はleaf(葉)、線はedge(枝)です。
      一番上には**.**で表現される**root(根)ノード**があるという想定
    - DNSの検索(query)とは、一番上の**rootノードから枝を下っていくこと**

---
class: img-right,compact
# ドメインの木構造とゾーンとドメイン

![](images/tree_with_nameserver.png)

- DNSは無数のゾーンに分割され管理されています。**委任された管理単位がゾーン**
- JPRSは(ルートの管理組織から)jpゾーン全体の管理を委任されています
    - さらに小さな単位の ad.jp ac.jp co.jp なども管理しています
- **大学はJPRSからchitose.ac.jpゾーンの管理を委任されています(図の網掛け部分**)
    - ゾーンの名称には一番上のノード名chitose.ac.jpを使います
    - ゾーン内の、
      より小さな管理単位であるphoton.chitose.ac.jpやmc.chitose.ac.jpも管理しています。
      なお、photonやmcなどは**サブドメイン**と呼ばれます

---
class: img-right,compact
# ドメインの木構造とゾーンとドメインとDNSサーバ

<div class=footnote>
<small>
(脚注1)
各ノードにドメイン名が対応するのだから、
各ノードに各ドメイン担当のDNSサーバ群を配置するのが素直に感じられますが、
サーバの台数を増やすのも管理が面倒なので、
ゾーンごとに2〜3台が普通
<br>
(脚注2)
(a)JPRSのDNSサーバはjpとac.jp他
(b)大学のDNSサーバはchitose.ac.jpおよびmc.chitose.ac.jp
を担当
</small>
</div>

![](images/tree_with_nameserver.png)

- 各ゾーンにはDNSサーバ群があります
    - 障害に備え複数(最低2)台のサーバ
      <br>
      (マスタのサーバをprimary,予備機をsecondaryと呼ぶ**ならわし**)
    - 定期的にサーバ間でデータを同期しています。
      同期の際のデータ転送は**TCP**です

---
class: img-right,compact
# ドメインの階層とクエリ

<div class=footnote>
<small>
(脚注)
(中間試験の範囲ではないので)具体的な動作を説明しないため、モヤモヤするとおもいますが、
クエリの動作の実際は Part II で実演するので、気になる人は、そちらも見ててください。
</small>
</div class=footnote>

![](images/tree_with_nameserver.png)

- DNSの問い合わせ動作が**クエリ(query)**
    - **正引き**: ドメイン名->IPアドレス
    - **逆引き**: IPアドレス->ドメイン名
- この問い合わせ(のデータ転送)は**UDP**
    - パケットが何度も往復するので**動作が軽いことは重要**です
      (詳細は Part II)
    - 一方、前頁で述べたように、
      DNSサーバ(primaryとsecondary)間の設定の同期では**信頼性**が重要なので、
      データ転送に**TCP**を使っています
    - この**TCPとUDPの使い分けに注目**
- クエリの際は木構造を一番上のルートから下にたどっていきます
  (詳細は Part II)

---
class: img-right,compact
# 世界規模の分散システムとしてのDNS

<div class=footnote>
<small>
(脚注1) (インターネットのご先祖の時代の)初期にはマスターファイル方式でしたが、破綻は見えていたので1980年代前半にDNSへ移行しました
(脚注2)
非常に多くのDNSサーバの自律的な分散と協調を期待したシステムです。
DNS管理者たちのスキルと善意に依存とも言う;-)
自信がない人はDNSサービス(SaaS)を買うのが推奨です
(脚注3)
でも、プロを目指す人は、中間試験に出ない範囲も勉強してほしい
</small>
</div class=footnote>

![](images/tree.png)

- 木構造を階層的に多数のゾーンに分け、
  各ゾーンが自分(および自分以下の階層)を管理することで、
  インターネットの名前空間を一極集中ではなく**小さな管理単位**の集合体として再編成しています
- 世界中に分散した無数のDNSサーバ群からなる**分散システム**で、
  世界規模で実に約40年動きつづけています

---
name: resolver
class: title, smokescreen, shelf, no-footer
# DNS Part II リゾルバの実際

<div class=footnote>
<small>
中間試験には出ません(が、設計や秋学期には関係あり,興味のある人むけ)
</small>
</div>

---
name: how-browser-resolve
class: img-right,compact
# WWWの動作(DNS込み)

![](images/resolver.png)

- 前述の図をもう一度
- 右図の(1)(2)
    - (1) ブラウザはURIに含まれるサーバ名portal.mc.chitose.ac.jpの
          IPアドレスをDNSサーバに問い合わせます
    - (2) DNSサーバはブラウザにIPアドレス=210.128.52.45を回答
    - (3)(4)はブラウザがHTTPでコンテンツを取りにいく様子
      ([WWW](https://lectures.fml.org/slides/network/tcpip/app_www/#4)を参照)
- この(1)(2)の裏側を解説します
   - 正確にはOSの「DNSクエリをおこなうライブラリ関数」
     +
     (右図の)「DNSサーバとインターネット上のDNSサーバ群との間のやりとり」からなる

---
class: img-right,compact
# 前図(2)の裏側, このあとのデモの概略

<div class=footnote>
<small>
(脚注)
ルートサーバ群のどれに問い合わせるか?はDNSソフトウエアに依存するでしょう。
ただし、常識的に考えれば、次のどちらかのロジックではないかと思います
(a)サーバ群に均等に問い合わせる(roundrobin)
(b)とりあえず一番近いサーバ(日本ならm)を使うが、応答が遅い場合は他のサーバへ切り替え
(random? roundrobin?)
</small>
</div>

![](images/tree_with_nameserver.png)

- 各ゾーンは直下のゾーンを管理するDNSサーバの情報を持っています
- portal.mc.chitose.ac.jp検索時(デモ参照)
    - ルートサーバへの問い合わせ
    - ルートサーバはjpゾーンのDNSサーバに問い合わせよと回答
    - jpのDNSサーバはchitose.ac.jpゾーンのDNSサーバについて知っており、
      そちらに問い合わせよと回答
    - chitose.ac.jpはportalのIPアドレスを知っているので、アドレスを回答

---
class: img-right,compact
# DNSの問い合わせと木構造(再掲)

![](images/tree_with_nameserver.png)

- 前述のように、DNSの検索とは木構造を**.**(root)から下っていくことです
- 右図にはデモで登場する各ゾーンのDNSサーバ群が書き込まれています
   - 実際には、各ゾーンに複数のサーバがあり、
     全サーバが同じデータをもっているので、
     どのサーバに問い合わせても結果は同じです
   - (以下の説明およびデモでは名前順の先頭のサーバを使っています)

---
class: img-right,compact
# DNSの問い合わせ(1): 正引きの例

<div class=footnote>
<small>
(脚注1)
(いまどきDHCPばかりで、OS設定経験者のほうが少数でしょうが)
OSの「DNSサーバの設定」という項目で指定するべき情報が
full service resolverのIPアドレスです
(脚注2)
Googleの8.8.8.8などのPublic DNSもfull service resolverですが、
分散システムであることが重要なインターネットの理念に逆らっていると批判あり
</small>
</div class=footnote>

![resolver全体図](images/resolver-full.png)

- 図(1)の裏側(a)〜(f)を解説します
    - 例: ドメインportal.mc.chitose.ac.jpのAレコードを問い合わせる
- クライアントのソフトウエア(例:WWWブラウザ)はリゾルバ関数を呼び出します
  (歴史的にはライブラリlibresolv.a)。これは通常stub resolverという役割をしていて、
  一番身近な full service resolver へ(1)問い合わせを送り(2)返事を待ちます
- 実際に検索の仕事をするのは full service resolver です(右図中央下のサーバ)

---
class: img-right,compact
# DNSの問い合わせ(a)(b): 正引きの例

![resolver全体図](images/resolver-full.png)

- 出発点は木構造の一番上**.**(root)ゾーンへの問い合わせです
    - **.**(root)の情報をもつDNSサーバ群をルートサーバと呼んでいます。
      これは世界各国に分散して設置している13台のサーバです
    - この情報は、出荷設定でOSに埋め込まれています
      (この情報が無いとDNSの検索が始められない)
- ここではルートサーバとしてA.ROOT-SERVERS.NET.を使うとします
- (a)ルートサーバに問い合わせを送ります
- (b)ルートサーバから
     「自分は知らない。
       JPゾーンについてはJPRSのサーバ(a.dns.jp)に聞きなさい、IPアドレスは〜」
       と返事をもらいます

---
class: img-right,compact
# DNSの問い合わせ(c)(d): 正引きの例

![resolver全体図](images/resolver-full.png)

- (c)再度a.dns.jpに問い合わせを行います
- (d)a.dns.jpからは
     「自分は知らない。
       CHITOSE.AC.JPゾーンについてはmcgn01.chitose.ac.jpに聞きなさい、IPアドレスは〜」
       と返事をもらいます
    - a.dns.jpはJPドメインとAC.JPドメイン両方の情報を管理しているので、
      (ノードの階層順に2回問い合わせそうですが、1回分は省略されて)
      いっきにCHITOSE.AC.JPゾーンのDNSサーバ情報を教えてもらえます

---
class: img-right,compact
# DNSの問い合わせ(e)(f): 正引きの例

![resolver全体図](images/resolver-full.png)

- (e)再度mcgns01.chitose.ac.jpに問い合わせを行います
- (f)このサーバはmc.chitose.ac.jpゾーンも管理しているので、
     いっきに答えまでたどりつき
     「portal.mc.chitose.ac.jpのIPアドレスは210.128.52.45です」
     と返事をもらいます(前頁と同様の理屈)
- (2)full service resolverは、
     問い合わせてきたクライアントに210.128.52.45という返事を返します
- (3)(4)このあと、
  前回説明した[HTTPの処理](https://lectures.fml.org/slides/network/tcpip/app_www/#4)がはじまります

---
class: center,compact
# デモ: ルートサーバ

---
class: compact
# デモで使うコマンドの説明

- DNSサーバに問い合わせをするdigコマンド

```
dig @DNSサーバ ドメイン名 [RR]

例: RR省略時は正引き
dig @210.128.52.11 portal.mc.chitose.ac.jp

例: メールサーバの問い合わせ(RRがMX)
dig @210.128.52.11 photon.chitose.ac.jp mx

```

- 類似のDNSを引くコマンドに**nslookup**と**host**があります
- プロは**dig**を好んで使っている雰囲気がありますね
- いずれのコマンドもBINDという最初期からあるDNSサーバソフトウエアの一部です
- **nslookup**は多くのOSでサポートされていて、
  UnixでもWindowsでも、たいてい使えるはずです

---
class: center,compact
# デモ: 正引き

---
class: compact
# リソースレコード

- ドメインに関連付けられた情報を**リソースレコード(RR)**と呼びます
  <br>
  (略して**レコード**と呼ぶことも多いです)
- **正引き**とは**ドメイン名から該当するIPアドレスを取得する**ことで、
  これは該当する**Aレコード**の検索になります。
  サーバが答えを知らない場合たとえば「jpドメインはa.dns.jpに聞け」
  と回答をしますが、
  ここで答える情報が(jpドメインの)**NSレコード**
- **逆引き**とは**IPアドレスからドメイン名を探す**ことで**PTRレコード**の検索
  (正引きの逆)

| リソースレコード | 値                       | 備考                                 |
|------------------|--------------------------|--------------------------------------|
| A                | IPアドレス               | Aレコードの検索が正引き              |
| PTR              | ドメイン名               | PTRレコードの検索が逆引き            |
| MX               | メールサーバ             | メールの送信先サーバの検索	     |
| NS               | DNSサーバ                | ゾーンを管理しているDNSサーバの情報  |
| TXT              | テキスト(任意のテキスト) | 例: [SPF](#SPF)			     |
<small>
表:代表的なDNSレコード
</small>

---
class: img-right,compact
# 逆引きの木構造とクエリ

![](images/tree_with_apra_and_nameserver.png)

- **arpa**という仮想TLDを用意し木構造を作ります
  (図中一番右の縦1列)
- 正引きと同様に**.**(root)から下る検索
- メリットは、正引きと同じしくみがそのまま使えることです
    - 関数、木構造、設定ファイルなど
- デメリットは、DNS管理者が設定を書くときに頭を使うことだけです
    - 大学側で管理しているドメインは**52.128.210.in-addr.arpa.**です
    - 問い合わせるドメイン名は**45.52.128.210.in-addr.arpa.**になります
    - 一番右側の列を下から上に読むと、この文字列になりますよね?

---
class: center,compact
# デモ: 逆引き

---
class: img-right,compact
# MXレコードの検索

![](images/tree_with_nameserver.png)

- 手順は正引きと同じで、問い合わせるものがMXレコードになるだけです
    - 例: photon.chitose.ac.jpのMXレコードを知りたい
- 問い合わせ先のドメインにMXレコードという情報があれば、それを返します
- photon.chitose.ac.jpの場合
  photon-chitose-ac-jp.mail.eo.outlook.com.
  というサーバ名(Office365のサーバ名)が返されます
- メールを送信する側は、このサーバにメールをSMTPで送ります

---
class: center,compact
# デモ: MXレコード

---
class: col-2,compact
# UDP の意義, TCP の使いどころ

- 本節で説明したように、
  一回の問い合わせだけで、パケットが4往復(1)(2)(a)〜(f)します。
  場合によっては、もっとたくさんの往復がありえます
- HTTP(TCPアプリケーションの代表例)とは、だいぶ挙動が違います
    - HTTPはWWWサーバと対向で様々なサイズのデータを返しうるのに対し
    - DNSでは相手が複数、短い問い合わせ(小サイズ)を何度も行います
    - DNSは処理速度も要求されます
    - DNSは静的で冗長性が高いシステムです。
      同じ情報を持ったDNSサーバ群が運用されており、どのサーバに問い合わせても大丈夫です
- DNSの問い合わせはUDPという転送方式をデフォルトで使います。
  ただし不具合や大量の答えが返る際にはTCPへ移行することがあります
- 問い合わせに不具合がある際は、
  再び問い合わせるなり、
  タイムアウト後に別のDNSサーバへ問い合わせるなりは、
  resolverが制御します
- こういった
  (TCPアプリとは挙動が異なる)処理を、
  **プログラム作成者(user)がすべてコントロールするためUDPベースで作られている**と言えます
- (再掲)各ゾーンには複数のDNSサーバがあり、
  同じ**設定情報**を持ちますが、
  そのサーバ間の**コピーはTCP**ベースです

---
class: col-2,compact
# まとめ

- Domain Name System (Service)
    - アプリにドメイン名名前空間の情報を取得する仕組みを提供します
        - 名前解決, リゾルバ
        - 正引き,逆引き,メールの送信先
    - 特徴
        - インターネットの基盤技術
        - 分散システムの大成功例
        - UDPベースの数少ない例
- ドメイン
    - **.**区切の文字列
    - FQDN (Fully Qualified Domain Name)
        - portal.mc.chitose.ac.jp

<wbr>
- 木構造をしたデータベース
    - 各自の管理(を委任された)部分がゾーンで、
      各ゾーンは複数のドメイン名を持ちえます
    - 各ノード(=ドメイン名)には複数のレコードが対応しえます。例:
        - IPアドレス(Aレコード),
         ドメイン名(PTR),
         メール転送先(MX),
         ドメイン管理情報(NS)
- 検索は、木構造を**.**(root)ノードからリーフへ下っていくことにあたります
- 転送方式
    - クエリはUDP、場合によってはTCP
    - サーバ間のコピーはTCP

---
name: references
class: title, smokescreen, shelf, no-footer
# DNS Part III 参考: ロードバランス,SPF

<div class=footnote>
中間試験には出ません(が、設計や秋学期には関係あり,興味のある人むけ)
</div>

---
class: col-2,compact
# DNSサーバの冗長化構成

- DNSサーバの冗長化は元々DNSが想定しているので、
  たんに複数台のDNSサーバを用意し
    - 1台がマスター、それ以外のサーバは定期的にマスターから情報をコピー
        - DNSの情報更新は稀なので、一時間に一回確認するといったペースで行えば十分です
    - マスターを primary DNS server (name server)、
      二台目以降のコピーをもつサーバを secondary DNS server (name server)と呼びます
      (ちなみに何台あってもsecondaryです)

<wbr>
- 問い合わせはクライアント側のfull service resolverの実装依存ですが
    - たいていは均等になるようNSレコードの順に聞いてくるはずです
      (roundrobin)
    - 例えば、a.dns.jpに尋ねたら、次の問い合わせはb.dns.jpといった具合に...

---
class: col-2,compact
# DNSサーバのロードバランス

<div class=footnote>
<small>
(脚注1)
特定のクライアントAがアクセスするサーバは、どちらか一つです。
サービス提供側からみた時に
「多数のクライアントからのアクセスが分散して嬉しい」という意味です
(脚注2)
秋学期OSの[「高信頼化」](https://lectures.fml.org/slides/os/internal/highavail/)を参照
</small>
</div class=footnote>

- クライアントはDNSサーバに均等に問い合わせるはずという性質を利用します
- 各DNSサーバに違う内容のレコードを用意することで、サービスを冗長化することが出来ます
- たとえば**portalサーバが二台(.45 と .46)ある場合**、
  右表のようにDNSサーバを設定しておけば、
  多数のユーザの問い合わせが、なんとなくDNSサーバ1と2に分散され、
  portalサーバへのアクセスも分散されます
  (長い時間でみれば統計的に均等なアクセス、つまり**ロードバランス**が実現されます)

<wbr>

| DNSサーバ        | portalのAレコード(返事)         |
|------------------|---------------------------------|
| DNSサーバ1       | portalのアドレスは210.128.52.45 |
| DNSサーバ2       | portalのアドレスは210.128.52.46 |

- ロードバランスの原始的なテクニック
- 設定ファイルをDNSサーバごとに個別管理しないといけないのが面倒ですが、
- それ以外にも、明らかな欠陥がありますけどね...
  (さて、それは何でしょう?:-)

---
class: col-2,compact
name: SPF
# メールの認証: SPF (TXTレコードの応用)

<div class=footnote>
<small>
(脚注)
DKIMおよびDMARCは省略しますが、最低限SPFは設定したい。
DKIMは非対称鍵暗号ベースで送信者の正当性を確認する技術、
DMARCはSPFとDKIMをさらに補強する技術
</small>
</div>

- メール送信サーバの正当性を検証する
   - メールで利用するドメインのTXTリソースレコードにSPF情報を書きます
   - SPFは**正しい送信サーバのIPアドレス**の情報です。
     このサーバ以外から送られてきたらSPAMメールのはず
- 受信側メールサーバがSPFを調べ受け取りを判断します(図中(2)の受信部分)
   - SPAMの場合、
     メールのドメイン名から調べたSPFのサーバと送信元サーバ情報が異なるので、
     受信を拒否

```
[図右側のサーバがあるドメインに設定するSPFの例]

v=spf1 ip4:210.128.52.0/24 mx ptr ~all
```

![](../app_mail/images/smtp-overview.png)