いまさら聞けないDNS

最近本業でドメイン周りを触る機会があったんですが、その際にDNS関連の知識が無さすぎてさすがにやばいなとなったのでDNSについてまとめていきます。

座学なのでn番煎じのような記事にしかなりませんが、できる限りこの記事単体で包括的に把握できるようにまとめていきます。

ご査収くださいませ。

※ちなみに、「いまさら聞けない」というキーワードは、特に商標登録とかされていないみたいです。安心して使用させていただきます。

## DNSとは

おなじみのドメインネームシステムです。

ネットワーク上に存在するサーバーは、IPv4アドレスによって一意に特定されますが、 `127.0.0.1` のようなIPアドレスを人間が認知・記憶するのは難しいので、 `example.com` のような人間が識別しやすいドメインと、サーバーの実在を示すIPアドレスを対応付けて保存し、サイトへのアクセサビリティを高める役割を果たしています。

### 名前解決の手順

以下リンク先の図が非常に分かりやすいです。

https://aws.amazon.com/jp/route53/what-is-dns/#:~:text=DNS%20%E3%81%A7%E3%83%88%E3%83%A9%E3%83%95%E3%82%A3%E3%83%83%E3%82%AF%E3%81%8C%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%AE%E3%82%A6%E3%82%A7%E3%83%96%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E3%83%AB%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%95%E3%82%8C%E3%82%8B%E6%96%B9%E6%B3%95

クライアント（ブラウザ等）からドメインが入力されると、DNSリゾルバに問い合わせが届きます。
DNSリゾルバはルートサーバーから順に問い合わせを行い、IPアドレスが返却されるまで複数のネームサーバーに問い合わせを続けます。

IPアドレスを特定できると、そのIPアドレスに基づいてwebサーバーにリクエストを送信し、レスポンスを受け取るという流れです。

### DNSリゾルバについて

「DNSリゾルバ」という呼び方をするとなんだかブラックボックス感がありますねー。
リゾルバには

- フルサービスリゾルバ
- スタブリゾルバ

の2種類が存在しますが、一般的にはスタブリゾルバを指す場合が多いとのこと。
で、そのスタブリゾルバ自体はOSの機能として提供されるという事なので、私が使用しているMac OSにおいても、ブラウザからドメイン名にアクセスを試みると、Mac内のスタブリゾルバが稼働して名前解決を行なってくれるという動作だと解釈しました。

https://atmarkit.itmedia.co.jp/fnetwork/dnstips/010.html

https://www.infrastudy.com/?p=1299

じゃあフルサービスリゾルバってなんなの？っていう質問についても。


https://jp.quora.com/DNS-kiyasshu-sa-ba-furu-sa-bisu-rizoruba-tte-doko-ni-aru-nde-suka-jibun-ie-no-ru-ta-desu-ka

### キャッシュについて

https://kinsta.com/jp/knowledgebase/flush-dns/

### URLの構造について

URLについても、最低限の教養として各文字列がどのような意味合いを持っているかは把握しておいた方が良さそうですね。
以下の記事が分かりやすくて非常によき。

https://www.asobou.co.jp/blog/web/url-optimisation#:~:text=%E3%81%95%E3%81%84%E3%81%94%E3%81%AB-,URL%E3%81%AE%E6%A7%8B%E9%80%A0%E3%82%92%E7%90%86%E8%A7%A3%E3%81%97%E3%82%88%E3%81%86,-URL%E3%81%AE%E6%9C%80%E9%81%A9%E5%8C%96

```
# 以下のURLの場合。

https://www.example.com/hoge/index.html

https: # 通信プロトコルを明示
www　# ホスト名
example.com　# ドメイン

# ちなみに、ホスト名とドメイン名を合わせた www.example.com の部分をFQDNと呼ぶ。

hoge/index.html　# 該当プログラムへのpath
```

## さまざまな種類のDNSレコード

基本的に以下のページを見れば分かるっちゃ分かるのですが、できるだけ平易な言葉で分かりやすく説明する事を試みてみます。

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/route-53-concepts.html#:~:text=%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82-,%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%8D%E3%83%BC%E3%83%A0%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%20(DNS)%20%E3%81%AE%E6%A6%82%E5%BF%B5,-%E3%81%93%E3%81%93%E3%81%A7%E3%81%AF%E3%80%81%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/ResourceRecordTypes.html

尚、僕が業務上で一度も関わる機会がなかったものたちは説明を割愛いたします。

### A レコード（アドレスレコード）

以下の記事がわかりやすい。

https://e-words.jp/w/A%E3%83%AC%E3%82%B3%E3%83%BC%E3%83%89.html

IPv4アドレスとドメインを対応づけるレコードです。
すごくシンプルにhostsファイルに記述するとしたら、以下のようなイメージ。

```hosts
127.0.0.1 example.com
```

AWSでAレコードをALBに向ける場合は、以下のような設定になるイメージですね。

```
- Record name
    - example.com
- Type
    - A
- alias
    - yes
- value
    - xxxx-000000000.ap-northeast-1.amazonaws.com. 
```

これで、www.example.com にアクセスするとALBのDNS名にリクエストが転送され、ALBの背後に存在するAWSリソースに通信が届くようになります。

valueの所は、例えばAmplifyでホスティングしているサイトに向けたい場合はCloudfrontの値になると思いますし、条件によってさまざまです。


<b>wwwとは</b>

https://rs.sakura.ad.jp/column/rs/domain-www-iru/

### AAAA レコード

基本的な役割はAレコードと同じですが、IPv6アドレスとドメインを対応づける役割を果たすという事です。

IPv4すら怪しいので詳細は割愛。

### CAA レコード

詳細は割愛。

以下、さくらインターネットさんから引用。

>SSLサーバー証明書を第三者が勝手に発行することを防止する仕組みです。
認証局（CA）はSSLサーバー証明書を発行する際にDNSを確認し、
ドメイン所有者がその認証局にSSLサーバー証明書の発行を許可しているかどうかをチェックします。

https://help.sakura.ad.jp/ssl/2347/

SSL関連も難しくてよく分からないですよね。

### CNAME レコード

CNAMEは、FQDNに対するエイリアスを設定するレコードと解釈しています。

例えば、Aレコードで以下のように設定し、

`127.0.0.1 www.example.com`

CNAMEレコードで以下のように設定した場合、

```
www.example.com       IN CNAME www.example.com
hoge.example.com      IN CNAME www.example.com
hoge.fuga.example.com IN CNAME www.example.com
```

`www.example.com`など3つのFQDNから127.0.0.1のリソースを取得できるという感じですね。

ちなみに、技術的にはCNAMEを使わず全部Aレコードで登録する事も可能なようですが、管理するドメインが多くなってきた場合に、CNAMEを使う事でIPアドレスをいちいち書き換えなくてもAレコードの部分だけ書き換える事で対応できるというメリットがあります。

なお、CNAMEに登録されたドメインはMXレコードとNSレコードには登録できない。

### DS レコード

割愛。

### MX レコード

メール関連のレコードですね。

例えば、
・お名前.comでドメインを取得
・AWS route53でドメインを管理（ホスト）
・お名前のwebメール機能でメールをやり取りしたい

みたいな要件だった場合には、route53に以下のような感じでMXレコードを設定する必要があると思います。

```
- Record name
    - example.com
- Type
    - MX
- value
    - mail.onamae.com # この値はあくまでサンプル
```

なお、メール配信の技術についてもその内記事にしようと思っています。

### NAPTR レコード

割愛

### NS レコード

おなじみのNSレコード。
この記事内でよく出てくる、

`お名前で取得したドメインをroute53でホスト`

みたいなシナリオの際も、よくNSレコードの付け替え作業したりすると思います。
上記のシナリオの場合だと、AWSでホストゾーンを作成した際に以下のようなvalueがデフォルトで設定されるはずなので、この値をお名前側でNSに設定するという感じですね。

```
ns-xxxx.awsdns-xx.co.uk.
ns-xxxx.awsdns-xx.com.
ns-xxxx.awsdns-xx.net.
ns-xxxx.awsdns-xx.org.
```

このNSの付け替え作業を行う事によって、あるドメインにアクセスした際に、どのネームサーバーに問い合わせを行えば良いのか、DNSリゾルバが把握する事ができます。

以下の記事でも詳しく解説されている。

・NSリソースレコードとは

https://jprs.jp/glossary/index.php?ID=0146

・ゾーンとは

https://jprs.jp/glossary/index.php?ID=0142

### PTR レコード

割愛

### SOA レコード

これはDNS周りの設定をしていると必ず見る印象なのですが、ちょっと調べてみた感じ、僕の業務上ではそこまで深掘りする必要ないかなという印象でした。

https://powerdmarc.com/ja/what-is-a-dns-soa-record/

route53でホストゾーン作成すると最初から設定されてた気もするけど、どうだっけ...

### SPF レコード

割愛

### SRV レコード

割愛

### TXT レコード

DNSにメモ書きを残せるレコードみたいです。笑

https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-txt-record/

上記から引用

>現在、DNSのTXTレコードの最も重要な2つの用途は、電子メールのスパム防止とドメイン所有者の確認ですが、元々TXTレコードはこれらの用途のために設計されたものではありません。

なお、上記の記事はTXTレコードがいかにスパムメール防止やドメイン所有権の確認に役立つか、という点について書かれているので、一読をおすすめいたします。

## ある程度は把握しておきたいDNS

既存の業務の中ではあまりDNS周りに触れる機会がない人も多いと思います。
そのため、いざ新規でドメイン取得するとなった場合にいまいち手順がよく分からないみたいな事態もあるあるかなーと。

僕もついこの間業務で新しいドメインを取得する必要があったのですが、知識がなさすぎてちょっと危機感を覚えたので、最低限の知識は抑えておきたいなーと思った次第です。

DNS周りは結構クリティカルな設定なので、メンバーレベルでは設定の変更ができず、情シスや一定以上の役職者でなければ設定を変更できないといった状況は割とあるあるだと思います。

いざという時にピヨらないように多少の知識は身につけておきたいですね。

一般的なwebアプリケーションを動かす上で概ね重要になるのは、

- Aレコード
- CNAMEレコード
- NSレコード
- MXレコード

あたりだと思います。

雑に記事を書いてしまったので気が向いたらちゃんとした書体に整えたい。
それでは。