DNSの仕組みを調べてみた~概要編~
はじめに
こんにちは、SHIFT の開発部門に所属しているmurasawaです。
今期より中途で入社、バックエンド関連の開発を担当しています。
現在、研修でデータベースやRestAPIについて基本的な事から学んでいます。
学んだことをアウトプットし理解を深めていくとともに技術の共有として役に立てば幸いです。
バックエンドエンジニアとして最低限知っておくべきこととして、 DNS(Domain Name System)について調べてみました。
間違いなどあればコメントしていただければ幸いです。
DNS(Domain Name System)とは
ホスト名とIP(Internet Protocol)を紐づけるシステムです。
webサイトなどwebサービスにアクセスする際、その通信のあて先はサービスの稼働しているサーバーのIPアドレス(192.168.0.10など)です。
実際は「http://192.168.0.10/logon 」などにアクセスしています。
しかし、人間にとって「http://192.168.0.10 」と言われても意味の分からない数字の羅列でしかありません。
そこでこの192.168.0.10とshiftincを紐づけることで「http://shiftinc/logon 」にアクセスしたときに、「http://192.168.0.10/logon 」に変換してくれます。
この変換の仕組みは「名前解決」といいます。
これで「http://192.168.0.10/logon 」という何にログオンするのかわからない状態から, 「http://shiftinc/logon 」という会社サービスにログインすると意味のある状態になりました。
DNSの歴史
hostsファイル
まず、DNSを理解するためには、hostsファイルから説明する必要があります。インターネットの前身であるARPANETで生まれ、 IPアドレスとホスト名を紐づける名前解決の最も原始的な仕組みが「hosts」ファイルです。
Linuxでは「/etc/hosts」、Windowsでは「C:Windows\system32\drivers\etc」などのなかにあります。
このファイルに
127.0.0.1 localhost
192.X.X.X shiftinc
192.X.Y.Z www
192.168.W.Z hosts
のように記述しておくと、名前解決を行ってくれます。
非常に単純で対応もわかりやすいため、個人のパソコンなど小規模なネットワークでは現在でも有効な仕組みです。
一方で登録されるホスト名が増えれば増えるほど、管理や照合が大変になり、数万のホストが登録されているネットワークでは非効率です。
hostsファイル運用の限界
インターネットの前身ARPANETでは、ネットワークに接続されたホストが数百を超えたあたりで運用の限界に到達しました。
解決のために考案されたのが1984年より運用が開始されたDNSです。
hostsファイルのようなIPアドレス host の対応表を管理する専用のサーバを作り、情報を集約します。
名前解決が必要なクライアントやアプリケーションから問い合わせをさせ、対応表をもとに名前解決をすることにしました。
この専用サーバがDNSサーバです。 そしてデータの管理はDNSサーバが行うことになりましたが、 ここでもいくつか問題がありました。
●たった一つのDNSサーバーだけで全世界で増えつつけるホスト情報を処理するのは負荷に耐えられないため、複数サーバを立てる必要がある。
●複数のサーバで完全に同じデータを持ち合うのは非効率
●数百万にも及ぶ情報の中でのホスト名のユニーク性の確保
これらの問題を解決するのが、DNSの根本ともいえる「ドメイン・ツリー」の概念です。
ドメインツリーと分散環境
普段使用されている「DNS名(ドメイン名)」などと呼ばれているホスト名は、「.(ピリオド)」で階層分けされています。
それぞれの階層ごとにそれ以下の下位ドメイン名やホスト名を管理する「分散型サービス」になっています。
ルートノードというトップレベルドメインを管理しているDNSサーバーから始まり、jp→co.jp→test.co.jpのように問い合わせていきます。
test.co.jpというドメインは.jpが.coを管理し、.co.jpが.testを管理しています。
この階層部分、「枝分かれ」部分「www.shiftinc.jp、shiftinc.jp、jp 」などがいわゆるドメインです。
「www.shiftinc.jp 」など、上位ドメインを付けたものと区別するために「www.shiftinc、shiftinc.jp、jp 」などを「ノード」と呼ぶこともあります。
各ノードでは階層によって変わる場合もありますが基本的に、
●自身の下位ドメイン(サブドメイン)
●サブドメインの情報を持っているDNSサーバ
●自身に所属するホストの情報(IPアドレスなど)
を管理しています。
基本的に各ノードに割り当てられたDNSサーバでは、自身の管理するドメイン内情報とサブドメインのDNSサーバーしか知りません。
DNSへ問い合わせる側(DNSクライアント、リゾルバなどども呼ばれる)は、この階層構造を上位から順にたどっていけば良いことになります。
例ではjp→ shiftinc.jp→ www.shiftinc.jp → 192.X.Y.Zのように最終的に知りたい情報までたどっています。
このようなデータ配置によって、各ノードで
●分散して情報を持てる
●ノード内のユニーク性を保証すれば、ホスト名は何であっても自動的にユニーク性が保証される(図でいうホスト名wwwが何であっても、test.co.jpがユニークであればよい)
となり、非常に効率的で柔軟なシステムです。
DNSとは全世界に及んで展開されている「分散協調型データベース・システム」です。
権限移譲
こうした運用をしていく上で、上位ドメイン(ノード)はサブドメイン(ノード)のDNSサーバ情報のみを保持しており、サブドメイン以降の情報については保持していません。
サブドメインを信頼してサブドメイン以降の定義(さらにどんなサブドメイン、ホストが含まれているか)はサブドメインに任せています。
それは、一度組織にドメインが割り当てられれば、そのドメインで自由にサブドメインを作ったり、ホスト名を登録したりすることができ、管理効率が向上するからです。
このように上位ドメインがサブドメイン以降に管理を任せることを権限委譲といいます。
もちろん、私たち個人や組織のドメインもどこかから、権限移譲されています。権限移譲されているから、好きにホストを登録したり、サブドメインを作ることができます。
dig、nslookupコマンド
digコマンドでドメインからipアドレスを確認することができます。
mac,linuxなどではデフォルトで使え、windowsではデフォルトでは使えませんがwindows subsystem for linuxなどを使えば使用できます。
今回、windows subsystem for linuxのターミナルで www.yahoo.co.jp のipアドレスを調べてみます。
murasawa@NPC::/mnt/c/WINDOWS/system32$ dig www.yahoo.co.jp
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> www.yahoo.co.jp
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28254
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.yahoo.co.jp. IN A
;; ANSWER SECTION:
www.yahoo.co.jp. 146 IN CNAME edge12.g.yimg.jp.
edge12.g.yimg.jp. 31 IN A 182.22.28.252
;; Query time: 21 msec
;; SERVER: DNSサーバーIPアドレス#53(DNSサーバーIPアドレス)
;; WHEN: Tue Oct 26 14:00:52 JST 2021
;; MSG SIZE rcvd: 88
「->>HEADER<<-」行に「NOERROR」とあるので、正常に応答がありました(ドメイン名が見つからない場合は「NXDOMAIN」、応答が異常な場合は「SERVFAIL」)
www.yahoo.co.jp のipアドレスは182.22.28.252であることがわかりました。
DNSサーバーを指定して、調べることも可能です。
dig @DNSサーバー ドメイン
例 dig @8.8.8.8 www.yahoo.co.jp
murasawa@NPC:/mnt/c/WINDOWS/system32$ dig @8.8.8.8 www.yahoo.co.jp
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> @8.8.8.8 www.yahoo.co.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40375
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.yahoo.co.jp. IN A
;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 26 14:32:08 JST 2021
;; MSG SIZE rcvd: 33
DNSサーバー「8.8.8.8」を指定して問い合わせましたが、status: NXDOMAINとなりました。見つからない場合はこうなるようです。
ここで見つからないのはおそらくgoogle社のセキュリティに引っかかってしまったのではないかと思います。
nslookupはwindowsで使うことができます。
C:\develop>nslookup www.yahoo.co.jp
サーバー: サーバー名
Address: サーバーIPアドレス
権限のない回答:
名前: edge12.g.yimg.jp
Address: 182.22.16.251
Aliases: www.yahoo.co.jp
#DNSサーバー指定
C:\develop>nslookup www.yahoo.co.jp 8.8.8.8
サーバー: UnKnown
Address: 8.8.8.8
*** UnKnown が www.yahoo.co.jp を見つけられません: Non-existent domain
終わりに
DNSの大まかな仕組みを調べてまとめて見ました。
間違い等あれば指摘いただければと思います。
ドメインやDNSサーバーについて名前は聞くもののよくわかっていなかったところ、やなぜ「.」区切りされているかなどの不明点やユニーク性や応答性を担保するためのドメインツリーという仕組みがあることがわかり、webシステムに対する解像度が上がったように感じます。
具体的な通信部分なども調べさらに理解を深めていきます。
________________________________
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/