DNSの仕組みについてまとめてみた

# はじめに
DNSについて調べてみました

# 参考
[「DNSをはじめよう」](https://techbookfest.org/event/tbf04/circle/15420009)

# まとめ
* 名前解決の構成要素
  - 権威サーバー(DNSコンテンツサーバー)
  - DNSキャッシュサーバー(フルリゾルバ)
  - スタブリゾルバ(ブラウザとかの古リゾルバに問い合わせるソフトウェア)
* ドメイン名の管理者が管理する範囲
  - 自分のドメイン名のゾーンと、自分が委任したゾーンの委任情報(DNS情報)

* whois
  - Whois検索はレジストリが提供しているサービス
* ゾーン = ドメイン (ゾーンファイルは権威サーバーに存在)
  - 権威サーバーで管理するドメインの個数分、ゾーンファイルが存在(拡張子=.zone.trans)
  - 逆引きもある場合は逆引きファイルも存在
  - セカンダリの拡張子
    + 逆引き(拡張子=.rev.trans) ゼーン(拡張子=.zone.trans)
* キャッシュ(DNS浸透に時間がかかるとはこのこと)
  - DNSキャッシュサーバーが名前解決に成功した場合、**権威サーバーのゾーンファイルのTTL時間分**、キャッシュサーバーにAレコードの情報がキャッシュされる
* ネガティブキャッシュとは
  - DNSキャッシュサーバーが名前解決に失敗した場合(権威サーバーに対象のリソースレコードがない場合)に対象(ゾーン)ドメインの**SOAレコードのMiNIMUMのTTL時間**だけリソースレコード値が無いことがキャッシュされる
  - SOAレコード自身ののTTLとSOAレコードのMiNIMUMの小さいほうが選択される

```

@   IN   SOA   NS1.DO-REG.JP.    root.FSV.JP.(
                                 1001251650 ; Serial
                                 10800      ; Refresh 3 hour
                                 3600       ; Retry 1 hour
                                 3600000    ; Expire 1000 hours
                                 3600       ; Minium 1 hours
                                )
```

* DNS浸透とは
  - **DNSキャッシューサーバー**は一度検索すると権威サーバーのリソースレコードで指定されたTTL時間だけ内部にキャッシュを保存して**2度目からの検索はルートDNSに検索に行かずにキャッシュを参照すること**
  - よって権威サーバーDNSのAレコードを変更しても、以前の内容をDNSキャッシュサーバーが**以前のAレコードのTTL時間だけキャッシュする**のでAレコードを変更したとしても反映に時間がキャッシュ時間だけかかること。DNSキャッシュサーバーのキャッシュをクリアして新しくDNS検索するようにさせることもできる

# ドメインとは
* 名前空間の範囲
* `https://www.yahoo.jp` のwww.yahoo.jpのこと
* jp=TLD、yahoo=2LD、www=3LD

## サブドメインとは
* ある名前空間の範囲が別の名前空間の範囲に含まれている場合、名前空間1は名前空間2のサブドメイン
* ルートの名前空間を分割してできたドメインはすべてルートのサブドメイン
* 注目するドメインによってサブドメインの範囲が変わる

# DNS
* ドメイン名とIPアドレスの対応を管理し、利用者からの要求に応じてドメイン名に対応するIPアドレスを探し出す(**名前解決**)
* HOSTSファイルによる管理からDNSによる階層化、委任による管理の仕組みに変更
* ドメイン名の階層ごとに管理者(**レジストリ**)に問い合わせて、委任が行われていれば委任情報をもらい、最終的な管理者にたどり着いて、IPアドレスをもらう
* 委任によって管理を任された範囲を「**ゾーン**」と呼ぶ
* 委任している場合、委任先のDNSサーバを知っている

# レジストリ
* 委任されたゾーンを管理する
  * 委任されたサブドメインとIPアドレスの管理
* ゾーンを委任した場合、そのゾーンを委任した人が誰かを管理する
  * サブドメインの管理を委任する場合
* 登録情報の運用
   * ドメイン名を登録するために必要となる個人名、組織、各種連絡先など
* 自分で管理しているドメインの登録情報をWhoisサービスの提供
   * ドメインの登録情報、有効期限とかがわかる

## ゾーンの管理
委任されたゾーンは委任先で管理される。ゾーンのポリシーはそれぞれのゾーンの管理者が決められる。
jpのポリシー
登録者は日本時衆所を有する組織や個人であることなど。

# TLDの種類
* 国や地域ごとに割り当てられるccTLD
* 国や地域によらない、gTLD
* １つのTDLに対してレジストリは1つ

# レジストラ、レジストリモデル
* ドメイン名の一元管理、レジストリ
* ドメイン名登録者からの申請を取り次ぐ役割のレジストラ
  * さくら、Route53、お名前comなど

登録者はDNSサーバを用意せずに、レジストラが用意してくれているDNSサーバに設定をして、レジストリに登録したドメインを名前解決するときは、このDNSサーバを参照してね、ということを申請する。

これで、例えば、jp -> exampleを管理しているさくらのDNSサーバ　で名前解決できるようになる


# キャッシュ
* 名前解決の際に権威サーバ郡から受け取った応答の内容をしばらくの間蓄えておく仕組み
* **フルリゾルバーはキャッシュされた内容を次回移行の名前解決で使用する**

## ネガティブキャッシュ
目的のレコードが存在しなかったという結果もキャッシュすること

* 得られた応答をフルリゾルバーがキャッシュに保持してよい時間は各ゾーン管理者が決めることができる
* リソースレコード毎に制御できて、TTLと呼ぶ
* TTLはキャッシュに保持された後に、時間の経過とともに減少していく
* 300だと5分間キャッシュして良い時間となる。0になると、キャッシュが削除される



# ゾーン転送
* 可用性を高めるために、複数台で権威サーバを運用するときに、ゾーンデータをコピーすること
* これでどれも同じ情報を返すことができる
* だからこれは権威サーバを自分で運用するときの話


# 権威サーバ
* ゾーンデータをリソースレコードの形で保持
* フルリゾルバからの問い合わせは、ドメイン名と知りたい情報のクラスとタイプを指定して送られてくる。権威サーバは自身が管理するゾーンデータを確認して、問い合わせに対応するリソースレコードが見つかった場合、応答を返す


# クエリの種類
https://qiita.com/hypermkt/items/610b5042d290348a9dfa

DNSサーバーのクエリーには2種類あります。

* クライアントからキャッシュDNSサーバーへのクエリー(**再帰的クエリ**)
  - **送信相手に再帰的な動作を要求するため、再帰的クエリ**
  - クエリー中にRDビット = 1がセットされている
* キャッシュDNSサーバーから権威DNSサーバーへのクエリー(**非再帰的クエリ、反復クエリ**)
  - クエリー中にRDビットがセットされていない

# 登場人物
- レジストリ(登録管理組織)=卸元
  * レジストラに卸すだけ
  * TLDを管理
    - comとかjpとか

 販売 ↓ ↑ **ユーザーが登録したドメインをレジストラのNSで解決しますよ、という情報の登録お願い**

- レジストラ(登録事業者)=お名前comなど
  * ドメイン名をリセラに卸す
  * レジストラはレジストリが管理するデータベースに自由にアクセスできるよう、レジストリと契約を交わしているらしい
  * 一般消費者にドメインを販売(**サービス面や価格面で競争が働く仕組み**)
  * 登録者からドメイン名の登録申請を受け付け、その登録データをレジストリのデータベースに登録する機関です
  * ***登録したドメインは自分たちのNSで解決できますよーという情報をレジストリに登録してもらって、名前解決をたどれるようにする***　(委任情報の登録)

　　↓

- リセラ(再販事業者)　ムームードメインなど
  * 一般消費者にドメインを販売

- ICANN
  * ドメインの登録作業やIPアドレスを管理する役割を担う非営利団体。レジストラになるためには「ICANN」に認定を受けなければならず、「ICANN」の定める規則やポリシーを遵守することが求められる。

私たちユーザーがドメインを取得しようと思ったら、必ずレジストラを介してレジストリ(卸元)に申請
レジストラはレジストリが管理するデータベースに自由にアクセスできるよう、レジストリと契約を交わしてい

# ドメインを買うときのポイント
* ドメインの品質自体はどこで買おうが問題ない
* 各会社でオプションが異なる。更新のしやすさとか、更新料の安さなど



# レジストリとTLD(トップレベルドメイン)
google.comのcomやexample.jpのjpをTLDと呼ぶ

一意性を保つために一つのTLD**に一つのレジストリによって管理

レジストリのVeriSign Global Registry Servicesはcomだけでなく netやnameなど複数のTLDを任されています

レジストリが任されたTLDのドメインをネームサーバーで管理している。
* 信頼できない、新興のレジストリが管理しているドメインを使用する時は注意が必要
  - ioなどを使っていた監視サービスがioのNSが落ちたことで使えなくなったことがあった



# Whoisとは
* レジストリのサービス
* そのドメインを所有している組織や担当者の氏名や連絡先、ドメインの有効期限をwebで見れるようにしたもの
* レジストラが登録者の情報ではなくて代理でレジストラの情報をwhoisに登録もできる。


# DNSの種類
* ネームサーバー、コンテンツサーバー、権威サーバー
  - ドメイン名とIPアドレスを紐づけた情報を登録
* フルリゾルバ、DNSキャッシュサーバー、フルサービスリゾルバ
  - クライアントの代わりにドメイン名からIPアドレスを調べてくれる

# キャッシュに関して
## DNSキャッシューサーバー
*「DNSを変更したけど浸透には時間がかかる」
  - 調べた結果はリソースレコードに設定されている**TTLが切れるまでキャッシュに保存**してくれるのでキャッシュの情報が使われてしまうということ

```conf

  example.jp.     3600    IN NS   ns2.example.jp.
  example.jp.     3600    IN MX   10 mx1.example.jp.
  example.jp.     3600    IN A    61.120.151.84
```

* Aレコードを変更した場合はAレコードのTTL時間分かかる
* NSレコードを変更した場合はNSレコードのTTL時間分かかる

省略した場合は$TTL時間になる

**ただし一部のDNSキャッシュサーバーは一つ前の親のTTL時間でキャッシュしてしまうらしい**

https://qiita.com/soushi/items/7432710308a78a684299

この挙動はフルリゾルバの実装依存になります。体感的には子ネームサーバのTTLに従う実装が多いです。ただ親ネームサーバのTTLに従うフルリゾルバは存在します(例えばOCNが提供するフルリゾルバは親ネームサーバのTTLに従います)。


よって権威サーバーの古いリソースレコードのTTL時間、キャッシュサーバーがキャッシュで応答してしまうので
もしすぐに切り替えたければ、DNSキャッシュサーバーのキャッシュをクリアして新しくDNS検索するようにさせる


### ネガティブキャッシュとは
* 対象のリソースレコードがない場合に対象(ゾーン)ドメインのSOAレコードというのTTL時間だけリソースレコード値が無いことがキャッシュされる


## 権威サーバー
* リソースレコード
  - 「ドメイン名とIPアドレスの紐づけ」ひとつひとつのこ 
* 自分で権威サーバーを管理しようと思ったら
  - ドメインを取得した業者に権威サーバーの情報を登録する。その後？業者が上位に登録してくれる？？


## DNSゾーン
* インターネットのドメイン名の管理において、あるDNSサーバ（ネームサーバ）が**自ら管理するドメイン**のこと
  - IPアドレスを返すことに責任をもつ
* サブドメインなどもIPを返してもいいし、委任してもよい
* 権威サーバーはゾーン一つに対して、を保持


# 権威サーバー
bindの場合

## 設定ファイル
/etc/namd/named.conf

* ここに管理するゾーン情報のファイルの場所など書いてある
* ドメイン一つに一つのゾーン情報ファイルがある
* 逆引きがあれば逆引きのゾーン情報ファイルがある

## ゾーンファイル
ドメインに関する情報。SOAやそのドメインのNSやA、MXレコードなど

## SOA
ゾーンそのものに関する情報
委任されたゾーンを管理する際に必要な情報を設定

## リソースレコードの値

```

www.example.jp	3600	IN	A	61.120.151.84

左から
ラベル
TTL
クラス
タイプ
リソースデータ
```


## ゾーンファイル
https://do-reg.jp/college/dns_v02_p3.html
https://www.atmarkit.co.jp/fnetwork/dnstips/031.html
https://www.infraexpert.com/study/tcpip23.html



```conf

//デフォルトのTTL時間。下記レコードで省略するとこの時間がTTLになる
$TTL 5m

// @はドメイン名の省略記法
// $ORIGN ドメイン　で指定できる
// $ORIGNは修飾指定のないレコードに付加するドメイン名 (起点名) を設定する。
// 明示的にORIGINを指定しない場合、そのゾーンファイルのドメイン名自体が暗に指定される

// メールアドレス
// nsdomain1.jp　= このゾーンをもつプライムDNSサーバー
// root@ne.jp = 管理者のメールアドレス
@       IN      SOA     nsdomain1.jp. root.ne.jp. (
                2018102500      ; serial
                1h              ; refresh
                30m             ; retry
                4w              ; expire
                5m              ; ttl
)

// 左側の空白は@(ドメイン)が入る
// ラベルが同じ値の場合、省略すれば前段と同じ値になる
// ドメインを委譲する場合、移譲するNSレコードのAレコードも記載する必要がある
                IN      NS      nsdomain1.jp.
                IN      NS      nsdomain2.jp.
                IN      NS      nsdomain3.jp.
;
                IN      MX      10      mail
;
//.がついている場合FQDNとして解釈される
//左に.がついていないのでwww.ドメイン　mail.にドメインになる
                IN      A       x.x.x.x
www             IN      A       x.x.x.x
mail            IN      A       x.x.x.x
;
```

* ttl
  - 下記のようにTTL時間を指定することもできる
  - https://www.atmarkit.co.jp/fnetwork/dnstips/031.html

```
  example.jp.     3600    IN NS   ns1.example.jp.
  example.jp.     3600    IN NS   ns2.example.jp.
  example.jp.     3600    IN MX   10 mx1.example.jp.
  example.jp.     3600    IN A    61.120.151.84
  ;
  ns1.example.jp. 3600    IN A    61.120.151.82
  ns2.example.jp. 3600    IN A    202.11.16.212
  mx1.example.jp. 3600    IN A    61.120.151.83
  www.example.jp. 3600    IN A    61.120.151.84
```

## ORIGN
　※　 明示的にORIGINを指定しない場合、そのゾーンファイルのドメイン名が暗黙に指定される。
　※　 ORIGINと同じドメイン名は @ で記載される。 例 - infraeye.com. ⇒ @

http://park12.wakwak.com/~eslab/pcmemo/linux/bind/bind3.html

## 補足
* 末尾のドット
  - ドメイン名の最後に「.」を付けるとFQDNとして解釈され、「.」を付けずに書くとORIGINの内容が末尾に付くことになります。

* セミコロン
  - セミコロンはこの文字から行末まではコメント

* 省略
  - mx mailの末尾に.がないのでmail.ドメイン名になる
  - 左は省略されているので、ドメイン名 @ドメイン名のメールアドレスで名前解決きたとき
  - mail.ドメイン名のホストが使用されるということ。そのmail.ドメイン名のAは下に書かれている
* TTL 5m
  - 一度問い合わせを行ったDNSサーバーはキャッシュを保存し、再度問い合わせをする必要がなくなる。この時間**DNSキャッシュサーバーが保存する**

* @（アットマーク）
  - 自ドメインである を指しています。
  - このゾーンファイルのドメイン名しか記載がない場合@だけでそのドメイン名を明示できる

* root.メールアドレス.ne.jp.
  - 管理者のメールアドレス
  - 「.（ドット）」でユーザ名とドメインを区切ります。

* NSレコード
  - 本来これは一つ上のレイヤが知っていればよい情報だが、歴史的な経緯で必要みたい　
　- https://teratail.com/questions/155610


# ドメイン移管とは
https://www.kagoya.jp/howto/webhomepage/04/

* ユーザーとお金の管理などしているドメインの管理会社（レジストラ）について、他の事業者へ乗り換えること

# コマンド
## 構文チェック
コンフィグ

```
named-checkconf /etc/named.conf
```

ゾーンファイルの確認

ゾーン名とゾーンファイル名を指定する。

```
named-checkzone "{domain}" /path/to/{domain}.zone
```

# namedをコントロール


```
rndc reload
```

named.conf と ゾーン情報をリロードする。
シリアル番号が増えているゾーン情報のみリロードする。

http://www.maruko2.com/mw/rndc%E3%81%A7named%E3%82%92%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%AB%E3%81%99%E3%82%8B




# digコマンド
* BIND9.9以降のdigコマンドはデフォルトでEDNS0付きの問い合わせを送る
* 問い合わせの送り先がフルリゾルバか権威サーバーかで名前解決要求を有効、無効にするかを使い分ける必要がある
  - フルリゾルバには名前解決要求**有効**
  - 権威サーバーには名前解決要求**無効**


## 基本
dig ドメイン

## 権威サーバーを調べる
* dig NS ドメイン

# whois
* IPアドレスやドメイン名の登録者などに関する情報を、インターネットユーザーが誰でも参照できるサービスです
* **Whois検索はレジストリが提供しているサービス**


# DNSセキュリティ
* ゾーン転送の制限
  - スレーブDNSのみに限定
  - allow-transfer{ スレーブIP}

https://faq.interlink.or.jp/faq2/View/wcDisplayContent.aspx?id=567

## DNSSECとTSIG
zsk鍵とksk鍵
[「DNSをはじめよう」](https://techbookfest.org/event/tbf04/circle/15420009)

* トラストアンカーにはルートのksk公開鍵が最初からインストールされている
* 署名があるのは`zsk公開鍵`と`Aなどのリソースレコード`
* `DSレコードは下位権威サーバーのksk公開鍵のハッシュ値`
* **KSK公開鍵、ZSK公開鍵を信頼していく仕組み**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/273424/8a75eba1-8f5c-16ee-e552-ae71f2b48c5d.png)

### DNSSEC
キャッシュサーバーが権威サーバーで応答してきたDNS応答が正しい改ざん、正当な管理者によって行われたことを保証

https://internet.watch.impress.co.jp/docs/news/1072181.html

公開鍵は上位のゾーンに預けて検証して保証。信頼の連鎖。

マスター・サーバのIPを偽装した「なりすましサーバ」が出現した場合はまったくの無防備になります。

### TSIG
https://www.atmarkit.co.jp/ait/articles/0305/10/news001_3.html

　そこで、TSIG（Transaction Signature）を用います。TSIGはサーバとクライアントで共通の秘密鍵を保有し、DNSメッセージ全体に署名を行うことでメッセージの完全性の保証やリクエスト認証を可能にします