Zenn
Closed6

「DNSをはじめよう」メモ

DNS
ぱんだぱんだ
  • ドメインを購入できるところはたくさんあるけどどこで買っても一緒
  • ドメインを販売している会社はレジストラかリセラのどちらか
  • レジストラは登録事業者。ドメインの登録はレジストラがやっていてユーザーへの販売もやる
  • リセラはドメインの登録まではできないのでレジストラから仕入れて再販する再販事業者。
  • レジストラの上にはレジストリがいるよ。これは登録管理組織
  • TLD(Top Level Domain)ごとにレジストリがいるよ
  • TLDというのはcomやjpのような1番最後の部分
  • ドメインはレジストラもしくはリセラからならどこからでも買うことはできるが卸元は唯一のレジストリからのみ
  • これは独占とかではなくドメインの一意性を保つためにドメインの卸は一社のみにしている
  • ではレジストリを選んでるのはどこかというとそれはICANNという国際営利組織
  • ドメインとドメイン名は指す意味合いが違う
  • example.co.jpがあったとき.で区切られた各セクションをドメインと呼ぶことが多い
  • 一意に表現できるドメイン全体をドメイン名と呼ぶ。これはFQDNとも呼ばれたりする
  • .jpはwhoisで持ち主名が出てしまうらしい
  • whoisで情報を公開しているのはレジストリ
  • ちなみにドメインは大文字、小文字を区別しない
ぱんだぱんだ
  • DNSとはネームサーバーとフルリゾルバの両方を指していることが多い
  • ネームサーバーはドメインとIPを紐づけているサーバー
  • フルリゾルバはドメインに紐づいているIPをネームサーバーに問い合わせることで探してくれるやつ
  • フルリゾルバは解決したドメインとIPのマッピングをキャッシュしてくれるためDNSキャッシュサーバーとも呼ばれる
  • ブラウザから何かしらのドメインにアクセスするとまずはこのフルリゾルバにリクエストが飛ぶことになる
  • フルリゾルバは接続しているネットの回線事業者やや社内情シスが用意してるよ
  • 8.8.8.8 や1.1.1.1はGoogleやCloudflareが用意しているオープンリゾルバというのもある
  • DNSの名前解決の仕組みはフルリゾルバがルートネームサーバーに問い合わせをおこないFQDNに紐づくIPがわかるまでネームサーバーを辿る
  • ネームサーバーにはゾーンというものがあり、これは特定のドメイン名の全ての情報を管理する単位です
  • ゾーンは特定のドメインとそのサブドメインに関するリソースレコードを含んでいる
  • 名前解決はマシン上のhostsファイルも利用されている
  • hostsファイルになければフルリゾルバに問い合わせのような感じ
ぱんだぱんだ
  • AWSのRoute53のようなパブリッククラウドのDNSサービスについて
  • 独自のドメインを登録することでAWSのネームサーバーにゾーンを作成することができる
  • しかし、Route53でゾーンの作成をしただけでは名前解決に使われない
  • これはドメインの購入元でネームサーバーを変更する必要がある
  • ネームサーバーを変更することのメリットがあまりわからなかったけどAWSをメインで使っているなら他のマネージドサービスとの連携だったり、単純にネームサーバーの性能的なことでメリットがあるのかもしれない
  • 単純に管理がドメインだけ別なのもめんどくさいしね
  • ネームサーバーの情報は4つくらいある
  • プライマリーとかセカンダリー的な扱いっぽいが単純に高可用性や負荷分散てきな話
ぱんだぱんだ

ドメインを指定して紐づくIPやその他もろもろの情報を取得

% dig jy-panda.com  

; <<>> DiG 9.10.6 <<>> jy-panda.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30023
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;jy-panda.com.			IN	A

;; ANSWER SECTION:
jy-panda.com.		300	IN	A	172.67.136.92
jy-panda.com.		300	IN	A	104.21.80.253

;; Query time: 69 msec
;; SERVER: 240d:1a:de8:c300:f623:9cff:fed4:810#53(240d:1a:de8:c300:f623:9cff:fed4:810)
;; WHEN: Sun Apr 21 23:26:19 JST 2024
;; MSG SIZE  rcvd: 73

紐づくAレコードのみ

% dig jy-panda.com a +short
104.21.80.253
172.67.136.92

% dig jy-panda.com a +short
172.67.136.92
104.21.80.253

このドメインに紐づくAレコードは二つ登録されていることがわかり、digに実行で返ってくるIPの順番が違うことがわかる。これをDNSラウンドロビンといいロードバランサーがなくても負荷分散的なことをしてくれているのがわかる。

ぱんだぱんだ
  • nslookupやhostコマンドでもドメインに紐づくIPを調べられるけどdigでいいでしょう
  • digでわからないことはwhoisコマンドで調べよう
  • Aレコードはドメイン名とIPを紐づけているもの
  • このメールアドレスにメールを送ったらこのメールサーバーで受信しますという設定をしているのがMXレコード
  • 以下はGmailのメールサーバーを調べるコマンド
% dig gmail.com mx +short  
20 alt2.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
  • 先頭の数字はプリファレンス値といって複数サーバーがあるときの優先順位などを決める
  • MXレコードを作成しなかった場合で単なるwebサーバーとして動いている場合でも、メールが送れてしまう
  • メールサーバーとして利用する目的がないのであればプリファレンス値を0にしたNull MXレコードを作成してもよい
  • ただし、メールを送信する要件があるのであればバウンスメール受信のためにMXレコードは設定しておくべき
  • NSレコードはドメイン名のネームサーバーを指定している
dax.ns.cloudflare.com.
daphne.ns.cloudflare.com.
  • なりすましメールかを確認するのにSPF(TXT)レコードというのがある
  • digでtxtを指定すればSPFレコードが確認できる
  • SPFレコードなのにtxtを指定するのはいろいろあってSPFはTXTレコードで設定するとなったから
  • SPFレコードには送信元のIPアドレスの範囲などを設定することで、この範囲のIPから来たメールはなりすましじゃない本物だよみたいなことができるようになってる
  • IPからドメインを逆引きできるのがPTRレコード
  • ドメインの別名にCNAMEレコードを作成できる
  • CNAMEレコードを設定する場合他のリソースレコードを作成することはできない
  • 作成してもCNAMEで設定したドメインに問い合わせいってしまうので他のリソースレコードが使われるのかの保証がない
  • なのでRoute53などではCNAMEレコードを作成したら他のリソースレコードは設定できないようになってる
  • サブドメインを含まない1番短い状態のドメイン名をZONE APEXと言う
  • ZONE APEXにはNSレコードとSOAレコードが必ず含まれるのでCNAMEレコードは作ることはできない
  • なので別名にCDNのドメインを指定したくてもできない
  • しかし、Route53の独自拡張であるAliasレコードを使えばできる
  • CNAMEは名前解決を2回行うのに対して、Aliasレコードは一回の名前解決で済むという利点もある
このスクラップは2024/04/24にクローズされました