📘

DNSとは

に公開
DNS
Domain
tech

はじめに

ドメインとはなんだろう？という疑問から、DNSについて少しですが学んだため記事に残します。
DNSとは何か、そして名前解決の仕組みまで、まで見て行きたいと思います。あくまで初心者目線ですが、ドメインとDNSはこのような仕組みだったのかと感じてもらえるきっかけになれば嬉しいです。

ドメイン名が生まれた背景

ドメイン名がない時代は、「HOSTS.TXT」というHOSTSファイルに、ホストのIPアドレスとホスト名の対応を記載し、SRI-NICという組織が一元的に管理をしていました。
当初は、SRI-NICに対して申請をし、申請内容を確認して アドレスを割り当てHOSTSファイルに登録をしていました。SRI-NICがHOSTSファイルをインターネット上で公開することにより、ユーザーはそれを元にIPアドレスを判断していました。しかし、申請数の増加によりHOSTSファイルの反映に時間がかかるなど、管理をするのが大変になっていきました。そこで、効率よく管理するために「階層化」「委任」という、分散管理の仕組みが誕生しました。

階層化と委任

ここでいう階層化とは、ドメイン名を右から左へ読む事で上位から下位へと構造化する考えです。最上位には、「ルート」と呼ばれるそうがあり、通常ドット(.)で表されます。しかし、日常的には省略されており意識することは少ないです。
例えば、「www.hoge.com」というドメインには、実際には最後にルート(root)を示す「.」が暗黙的に存在し、「www.hoge.com.」となります。
また、右から順番に、root → TLD(Top Level Domain) → 2LD(2nd Level Domain) → 3LD(3rd Level Domain)と呼びます。
名前解決の際は、このルートを出発点として順に下位のドメインをたどっていきます。

  1. ルートDNSサーバがお問い合わせを受け付けて、該当するTLD(com)を管理するDNSサーバーの情報を返す。
  2. 次に、comのDNSサーバがhoge.comの情報を持つDNSサーバの情報を返す。
  3. 最後に、hoge.comのDNSサーバがwww.hoge.comのIPアドレスを返す。

このような流れになります。これが階層化の仕組みです。
加えて、それぞれの階層を特定の組織や団体に委任することで、中央集権的な運用を避け、分散的かつスケーラブルな管理が可能になっています。各TLDは、レジストリ(管理者)が存在しています。
そして、TLDは大きく分けて以下の2種類に分類されます。

  • ccTLD（country code Top Level Domain）
    国や地域ごとに割り当てられたトップレベルドメインです。
    .jp（日本）、us（アメリカ）、uk（イギリス）
    のように、ISO 3166-1に基づく2文字の国コードが使われます。各国・地域ごとに異なるポリシーで運用されています。
  • gTLD（generic Top Level Domain）
    gTLDは、特定の国に属さず、世界中の誰でも登録できる汎用のTLDです。
    .com（商業）、.org（非営利団体）などがあります。

DNSとは

DNS（Domain Name System）は、ドメイン名とIPアドレスを対応づけるための仕組みです。人間にとって覚えやすい「www.hoge.com」のような文字列を、コンピュータが通信に使用する「192.0.2.1」のようなIPアドレスへ変換する役割を担っています。いわば、インターネット上の「住所録」や「電話帳」のような存在です。
この仕組みがあることで、私たちはIPアドレスを直接入力することなく、ドメイン名を使ってWebサイトにアクセスできるようになります。
DNSは、前述した階層構造と委任の考え方に基づいて設計されています。名前解決は、ルートから始まり、TLD、セカンドレベルドメインと順に下位のDNSサーバへ問い合わせが転送され、最終的に目的のホスト名のIPアドレスが返されます。

レジストリ、レジストラとは

ドメイン名の登録や管理の仕組みには、レジストリ（Registry）とレジストラ（Registrar）という2つの役割があります。

レジストリ（Registry）

レジストリとは、各TLDを管理している上位機関です。レジストリは、TLDごとのドメインデータベースを保持し、DNSのゾーン情報を管理・公開します。

レジストラ（Registrar）

レジストラは、一般ユーザーに対してドメイン名の登録を提供する事業者です。ユーザーはレジストラが提供するWebサイトや管理画面を通じてドメイン名の検索・取得・更新・削除などの操作を行います。
このように、ドメインの管理には、レジストリとレジストラが役割分担する「レジストリ・レジストラモデル」が採用されています。

  • レジストリはTLD全体のドメイン名データベースやDNSインフラを一元管理する。
  • レジストラはエンドユーザーとの窓口となり、レジストリと通信して登録・更新処理を行う。
  • エンドユーザーは、複数あるレジストラの中から自由に選んでドメインを取得できる。

このモデルにより、レジストリがすべてのユーザーに直接対応する必要がなくなります。

名前解決の仕組み

名前解決とは、ドメイン名をIPアドレスに変換する一覧の仕組みやプロセスのことです。名前解決の過程は、主に以下の3種類の構成になります。

1. スタブリゾルバー（Stub Resolver）
DNSクライアント（Webブラウザやアプリケーションなど）の代理として、名前解決の問い合わせを開始します。OSに組み込まれている、あるいはアプリケーション自身が持つ機能です。常にフルリゾルバーに対して問い合わせを行い、その答えを待ちます。
2. フルリゾルバー（Full Resolver / Recursive Resolver）
スタブリゾルバーから受けた問い合わせに対して、最終的な答えを見つけるまで、権威DNSサーバーを再帰的に問い合わせをします。。そして、見つけた答えをスタブリゾルバーに返します。この過程で得た情報は一時的にキャッシュし、次回同じ問い合わせがあった際に高速に応答できるようにします。
3. 権威DNSサーバー（Authoritative DNS Server）
ある特定のドメイン情報を保持しているサーバーです。ドメインの所有者が、そのドメインのWebサイトのIPアドレス（Aレコード）、メールサーバーの情報（MXレコード）などを設定するのは、この権威DNSサーバーに対して行われます。自分が管理しているドメインゾーンに対する問い合わせに対しては、直接かつ最終的な答えを返します。それ以外のドメインについては「このドメインのことは知らないが、次の情報を持っているのはこのサーバーだよ」という委任情報を返します。

名前解決の流れ

以下に、www.hoge.comにアクセスする際の一般的な流れを説明します。

  • スタブリゾルバーからフルリゾルバーへお問い合わせ
    • ユーザーがブラウザで www.hoge.com にアクセスすると、PCやスマートフォンのスタブリゾルバーが、ローカルキャッシュにその情報があるか確認します。なければ、フルリゾルバーに問い合わせを送ります。
  • フルリゾルバーがルートDNSサーバーへ問い合わせ
    • フルリゾルバーはまず、ルートDNSサーバーに対して「www.hoge.com のIPアドレスが知りたい」と問い合わせます。返ってくるのは、.com を担当するTLDのDNSサーバーの情報（NSレコード）です。
      com. IN NS a.gtld-servers.net.
  • TLDサーバーに問い合わせ
    • 次に、.com のDNSサーバーに対して「hoge.com のDNSサーバーはどこですか？」と問い合わせます。ここでも、hoge.com を管理している権威DNSサーバーの情報（NSレコード）が返ってきます。
      hoge.com. IN NS ns1.hoge.com.
  • 権威DNSサーバーに問い合わせ
    • 次に、hoge.com の権威DNSサーバーに対して「www.hoge.com のIPアドレスを教えてください」と問い合わせます。
      　www.hoge.com. IN A 192.0.2.1

フルリゾルバーはこの答えをスタブリゾルバーに返し、同時に一定期間（TTL＝Time To Live）キャッシュに保存します。これにより、同じ名前への次の問い合わせでは高速な応答が可能になります。

最後に

DNSという仕組みは、自分にとって普段意識することは少ないですが、仕組みを知ることでインターネット全体の動きや構造への理解が少し深まったような気がします。

補足

ドメイン名ごとの情報はリソースレコード（RR）という形式でやり取りされます。
代表的なリソースレコードには以下があります：

Aレコード：IPv4アドレスを返す（例：www.hoge.com → 192.0.2.1）
AAAAレコード：IPv6アドレスを返す
NSレコード：ゾーンの管理DNSサーバーを示す
MXレコード：メールサーバー情報
CNAMEレコード：別のドメイン名のエイリアスを指定

参考資料

https://www.sbcr.jp/product/4797394481/

Discussion