ドメインとDNSについて理解する
ドメイン名について
ドメイン名はインターネット上で使われるユニークな名前で、原則として取得は「早い者勝ち」です。
IPアドレスは人間にとって覚えにくいため、DNSがあることによってインターネット上の住所を “https://example.com” などといった覚えやすい名前でアクセスすることができるようになります。
ピリオドで区切られたそれぞれの文字列は「ラベル」と呼ばれ、63文字以内でなければなりません。またドメイン名全体の長さも253文字以内と定められています。
ドメイン名の構造
ドメイン名はホスト名や組織名を識別するために階層構造がとられており、英字がピリオドによって繋がれています。
例として、”www.example.co.jp” のようなドメインがあった場合、これは以下の構造に分けられます
- jp → トップレベルドメイン (TLD)
- 国別、商用、地域などを表すドメイン
- us (アメリカ) com (商用) など
- co. → 第2レベルドメイン (SLD)
- 組織の種類を表すドメイン
- co (一般企業) ac (教育機関) go (政府機関) など
- example. → 第3レベルドメイン
- 具体的な企業名や組織名を表すドメイン
- yahoo google ntt など
- www. → 第4レベルドメイン
- 「ホスト名」に位置づけられるドメイン。一般的にWebサーバーであれば「www」として、ftpサーバーであれば「ftp」とすることが多い。
第4レベルドメインについては、昨今ではほとんどのURLがWeb上で公開されているため、省略されていることもあります（SEOの観点から、省略しているか否か、は統一するべきであるといわれている）。
以下はMDNより引用です。
はい、ひとつを選択して維持しなければなりません。基準となる場所に応じてどちらを選択するかはあなた次第ですが、どちらかを選択したら、それを維持してください。それにより、ユーザーや検索エンジンから見てウェブサイトが首尾一貫したものになります。 いいえ、二つ持つことができます。どちらが公式なドメインであるかについて、一貫性を持って矛盾しないことが重要です。この公式なドメインは正規名と呼ばれます。 すべての絶対パスリンクで正規名を使用するべきです。しかし、それでも他のドメインを機能させることができます。
ホスト名（第4レベルドメイン）を含まない箇所を一般的に「ドメイン名」と呼び、ホスト名まで含めたものをFQDN（完全修飾ドメイン名）と呼びます。
ドメイン名はルート「. 」を起点としたツリー構造となっており、以下のような形で一意性を保証しています。
参照: https://lpi.or.jp/lpic_all/linux/network/network07.shtml
ルート「.」はドメイン名の中では基本的に省略されていますが、実際には”www.example.co.jp”であれば”www.example.co.jp.” のように最後尾に記載されます。
ドメイン名の種類
gTLD (Generic Top Level Domain : 分野別トップレベルドメイン)
利用者の居住国などに関わらず、誰でも取得できるドメインです。代表的なものに「.com」「.net」「.info」などがあり、ICANN (Internet Corporation for Assigned Names and Numbers) によって管理されています。
当初は「.com」「.net」「.org」「.edu」「.gov」「.mil」「.int」の7つしか存在していませんでしたが、その後も申請にと審査によって少しずつ追加されていきました。
2012年にはICANNが「新gTLDプログラム」として、新しいgTLDの導入プロセスを大幅に緩和する形で申請受付が行われました。この受付プログラムの申請件数は1930件にのぼり、2013年以降は承認されたものから随時運用が開始されていきました。
以下より現在登録されているTLDの一覧を確認できます。
※ 「generic」で検索したところ、1249件が当てはまるようでした。
また、次回の新gTLDの申請受付はICANNより以下のように記されています。
The next application submission period for new gTLDs is expected to open in Q2 2026. A crucial driver of the timeline is the Policy Implementation work, culminating in completion of the Applicant Guidebook, which is estimated to conclude in May 2025. Once that work has been completed, ICANN estimates it will take approximately one year to operationalize the process and open the application submission period.
新gTLDの次回の申請受付は2026年第2四半期に開始される予定です。このスケジュールの重要な原動力は、申請者ガイドブックの完成を頂点とするポリシーの実施作業であり、この作業は2025年5月に完了すると見積もられています。この作業が完了した後、プロセスを運用し、申請受付を開始するまでに約1年かかるとICANNは予測しています。
ccTLD (Contry Code Top Level Domain : 国別コードトップレベルドメイン)
各国・地域に割り当てられたTLDです。ISO3166 で規定されている2文字の国コードを原則として使用しています。「.jp」「.au」「.us」などが挙げられます。
ちなみに、ccTLDは南極にもあるらしく、「.aq」が割り当てられています。これについてはICANNが選定しているというわけではなく、ISO3166で定義されているためのようです。
ccTLDとして使われるjpやusなどの文字列はIANAが決めるのではなく、国際標準化機構（ISO）が定めた「ISO3166-1 alpha-2」という国際規格に従って割り当てると決められています。ISO3166-1 alpha-2は国や地域の名称を2文字で示すための規格（定義）で、IANAはこれをそのままccTLDの文字列に採用しているのです。
基本的には国・地域に限定されているものがほとんどですが、中にはお金さえ払えばだれでも取得できるものも存在します。
「.tv」
南太平洋の島国ツバルに割り振られたccTLDで、2000年にアメリカのdotTV社に5000万ドルで売却されました。この売却益によってツバルは国連加盟を果たすことができたそうです。tvや映像関連のサービスなどで多く使用されています (abema.tvなど) 。
「.to」
トンガ王国のccTLDで、外貨獲得のため一般公開されており人気の高いドメインです。
Infrastructure TLD
インターネットインフラ用のトップレベルドメインのことで、「.arpa」があります。一般ユーザーが登録できるものではありません。
IPアドレスの逆引きを行う場合や、インターネット電話で電話番号とURIを対応づける際に用いられます。
DNSとは
DNSとはDomain Name Systemの略称で、ドメイン名（コンピュータを識別する名称）をIPアドレスに自動的に変換してくれるアプリケーション層のプロトコルです。
HOSTS.TXT時代
インターネットの全身であるARPNETでは、ホスト名とIPアドレスの対応表として、HOSTS.TXTというテキストファイルを使用していました。
このHOSTS.TXTはSRI-NIC (Stanford Research Institute’s Network Infomation Center) で保守・管理され、Anonymous FTPで公開されていました。
引用: https://www.nic.ad.jp/ja/newsletter/No22/080.html
管理のサイクルについては以下の流れです。
- 各組織はホストを登録するときにNICに申請する
- SRI-NICは各組織から申請があった内容をHOST.TXTに反映させる
- 各組織のホストはSRI-NICからHOSTS.TXTをFTPで入手して利用する
しかし、この管理方法は接続ホスト数の加速度的な増加や、ファイルサイズの肥大化などによって1980年代初頭には限界に達していました。そこで、この問題を解決するための新たな仕組みが開発され、1983年にRFC882およびRFC883として発表されました。
その後、RFC882とRFC883はRFC1034とRFC1035として改版され、現在のDNSとなりました。その後も多くの機能追加や改良が行われ、現在に至っています。
DNSの名前解決の流れ
DNSがどのような流れでドメイン名からIPアドレスを取得してきているのかについて記述していきます。まずは以下の図より全体像を把握しつつ、各機能とその働きについて理解を深めていきたいと思います。
引用: https://jprs.jp/glossary/index.php?ID=0145
権威サーバー
ドメインの項で、ドメイン名はツリー構造になっていると述べました。
このツリー構造ごとにドメインを管理しているのが「権威サーバー」です。
また、権威サーバーの中で一番初めにアクセスされるサーバーを「ルートサーバー」と呼びます。
例として “example.com” というドメインを名前解決したいとします。
- 問い合わせ側は、ルートサーバーにドメインのIPアドレスを確認しに行きます
- ルートサーバーはTLDの情報を知っているため、問い合わせ元に対象のTLDに対応したDNSサーバーの情報 (.com) を返します
- 問い合わせ側は、ルートサーバーに提示された情報をもとにTLD (.com) を管理する権威サーバーにもう一度IPアドレスを確認しにいきます
- TLDの権威サーバーは2LD (example.com) の権威サーバーの情報を返却します
- 再び問い合わせ側は2LDの権威サーバーにIPアドレスの問い合わせを行い、ここでようやく紐づけられたIPアドレス情報が返却されます。
最上位の階層となるルートサーバーは全世界に13組配置されており、以下のようにA～Mまでの種類があります。これらは13個のクラスタで、実際に稼働しているサーバーの数は1400以上にものぼるようです（参照: https://root-servers.org/）
| ルートサーバー | 運用組織 | 所在地 |
| A | VeriSign, Inc. | 米国バージニア州 |
| B | 南カリフォルニア大学情報科学研究所(ISI) | 米国カリフォルニア州 |
| C | Cogent Communications | 米国バージニア州 |
| D | メリーランド大学 | 米国メリーランド州 |
| E | 米航空宇宙局(NASA)エイムズ研究所 | 米国カリフォルニア州 |
| F | Internet Systems Consortium, Inc.(ISC) | 米国カリフォルニア州 |
| G | 米国防総省ネットワークインフォメーションセンター | 米国バージニア州 |
| H | 米陸軍研究所 | 米国メリーランド州 |
| I | Autonomica | ストックホルム |
| J | VeriSign, Inc. | 米国バージニア州 |
| K | Reseaux IP Europeens -Network Coordination Centre(RIPE NCC) | ロンドン |
| L | Internet Corporation for Assigned Names and Numbers(ICANN) | 米国カリフォルニア州 |
| M | WIDEプロジェクト | 東京 |
1台の権威サーバーが管理する範囲を「ゾーン」と呼び、そのゾーンのDNS (名前解決のための情報) を「ゾーン情報」と呼びます。ゾーン情報を構成する1件1件の情報を「リソースレコード (DNSレコード) 」と呼びます。
フルリゾルバー
「キャッシュDNSサーバー」や「フルサービスリゾルバー」などといった名称でもいわれています。
example.com にクライアントがアクセスする際、毎回ドメインツリーによる名前解決を行うのは非常に手間とコストがかかります。
そこで、IPアドレスとドメイン名の紐づけをキャッシュしてくれるサーバーがあります。それがフルリゾルバーです。
どのくらいキャッシュしてくれるのかという情報はTTL (Time To Live) として持っています。
初回アクセス時にフルリゾルバーはTTLと共にドメインツリーより名前解決した情報をキャッシュします。次回以降のアクセスがあった際は、TTL内の時間であればキャッシュされた情報を返し、そうでなければまたドメインツリーによる名前解決を行います。
引用: https://jprs.jp/glossary/index.php?ID=0158
リカーシブ (Recursive) は「再帰」を表す単語で、リカーシブモードについては画像引用元より以下の解説を参照します。
リゾルバーのうち、「リカーシブモード」と呼ばれる動作を行い、内部にキャッシュを持っているものを「フルサービスリゾルバー」と呼びます。リカーシブモードとは、DNSクエリを受信した際に、キャッシュの内容から答えるか、他の権威サーバー群に問い合わせを行うモードです。
もう一点、リカーシブモードについて
フルサービスリゾルバー（キャッシュDNSサーバー）が名前解決の際に、キャッシュの内容から答えるか、必要に応じて他の権威サーバー（権威DNSサーバー）に問い合わせを行う形式（モード）です。リカーシブモードで動作し、キャッシュを持つリゾルバーをフルサービスリゾルバーと呼びます。
フルリゾルバーは所属する企業やISP (Internet Service Provider) が運用するDNSサーバーにあり、後述する端末の「スタブリゾルバー」を経由してアクセスします。
また、フルリゾルバーは「ドメインに対してIPアドレスが存在しない」という情報もキャッシュします。目的の情報が存在しなかった場合のキャッシュをネガティブキャッシュと呼びます。
スタブリゾルバー
スタブ (stub) には「末端」という意味があり、主に利用者側の端末で動作し、フルリゾルバーに名前解決要求を行います。「DNSクライアント」とも呼ばれています。
引用: https://jprs.jp/glossary/index.php?ID=0197
スタブリゾルバーは、Webサービスやアプリケーションなどのプログラムに対して、名前解決を行う手段 (API) を提供します。基本的には、一般的なPCのOS等に標準搭載されています。
スタブリゾルバーからの全体的な問い合せの流れについて、ざっくりというと、「スタブリゾルバーは再帰問い合せをフルリゾルバーに送信」し、「フルリゾルバーは再帰問い合わせの結果を返すために権威サーバーに対して反復問い合わせ (非再帰問い合わせ) を行い、最終結果 (名前解決した結果) をスタブリゾルバーに送信」します。
Windowsを使用している場合は、以下の方法でスタブリゾルバがーがキャッシュしている情報を確認することが可能です。
Windows OSの場合は、クライアントOSとサーバOSの両方に、このスタブリゾルバが含まれており（「DNS Client」サービス）、手動でインストールする必要はない。スタブリゾルバがキャッシュしている内容は、コマンドプロンプトを開いて「ipconfig /displaydns」とすると確認できる。
リソースレコード (DNSレコード) について
ドメイン名に関連づけられた情報のことです。
リソースレコードは基本的には以下のような構造を取ります。
- ドメイン名
- TTL (Time to Live)
- class
- type
- RDATA
引用: https://jprs.jp/glossary/index.php?ID=0165
typeについては様々なものが存在し、class と typeによって後に続く RDATA の値が異なります。
よく使用されるtype
- A (エー) : そのドメインのIPv4アドレスを指定
- AAAA (クワッドエー) : そのドメインのIPv6アドレスを指定
- NS : そのドメインの権威サーバーのドメイン名を指定
- MX : そのドメイン宛の電子メールの配送先と優先度を指定
上記を含んだ、代表的なtypeの一覧
| リソースレコードのタイプ | 目 的 |
| SOA | ゾーンの管理情報を記述 |
| NS | ゾーンに対する権威（オーソリティ）を持つ権威サーバー（権威DNSサーバー）のドメイン名を指定 |
| MX | 配送における優先度を指定するプリファレンス（preference）と配送先ホストのドメイン名を指定 |
| A | ドメイン名に対するIPv4アドレスを指定 |
| AAAA | ドメイン名に対するIPv6アドレスを指定 |
| PTR | IPアドレスに対するドメイン名を指定（逆引きDNSで使用） |
| CNAME | ドメイン名に対する正式名を表すドメイン名を指定 |
| TXT | そのドメイン名で1文字以上の文字列を保持 |
| DS | 親ゾーンに登録され、委任先がDNSSEC署名されていることを示し、委任先の署名鍵の情報を記述 |
| DNSKEY | DNSSECで用いる署名鍵の公開鍵に関する情報を記述 |
| RRSIG | ドメイン名の各リソースレコードに対するDNSSEC署名を記述 |
引用: https://jprs.jp/glossary/index.php?ID=0165
ちょっとした疑問やら補足やら
フルサービスリゾルバの物理的な場所
調べた限りでは、プロバイダーが持っているDNSサーバー上、ということでした。
が、ルーターにあることもあるようで、物理的な場所については様々ありそうです。
ルータにあるリゾルバは、DNSフォワーダともいう？
この辺りの名前がどう当てはまるかについては、今後調べて固めていきたいとして、ツッコミ待ちです。
インターネット上の名前が氾濫している問題
DNSを学ぶとき、あまりにも言葉の定義が氾濫していて理解するまでに多大な時間を要したのですが、購入した書籍「DNSがよくわかる教科書」の中でその問題については懸念事項として解説がされていました。
| 構成要素 | 現在使われている別の名称 |
| スタブリゾルバー | DNSクライアントなど |
| フルリゾルバー | キャッシュDNSサーバー、参照サーバー、ネームサーバー、DNSサーバー、etc… |
| 権威サーバー | 権威DNSサーバー、ゾーンサーバー、ネームサーバー、DNSサーバー、etc… |
「ネームサーバー」「DNSサーバー」が丸かぶりしている時点でなんでやねーん！ って感じですが、そのせいで分かりにくさが加速しているなと…。
前述した書籍が網羅的に解説されているので、DNSについて理解しようとするならば周り道にならずに済むのでおすすめです。
Public DNS
インターネットに接続していれば、原則として誰でも、どこからでも利用できるフルリゾルバーのことです。Public DNSには覚えやすいIPアドレスが割り当てられていることが多く、代表的なものとして以下のようなものがあります。
- 運営 : Cloudflare/APNIC
- 優先IPアドレス : 1.1.1.1
- 代替IPアドレス : 1.0.0.1
- 運営 : Google
- 優先IPアドレス : 8.8.8.8
- 代替IPアドレス : 8.8.4.4
- 運営 : CleanerDNS (Quad9)
- 優先IPアドレス : 9.9.9.9
- 代替IPアドレス : 149.112.112.112
その他、使用できるものについては以下の記事で解説がされています。
一般的には、LAN内に設置されたDNSサーバーやISP (Internet Service Provider) が用意しているDNSサーバーなど、ネットワーク的 (物理的) に近いDNSサーバーを使った方が応答速度やトラフィック、セキュリティの面で有利とされています。具体的な使用例としては、ISPが提供するDNSサーバーに障害が発生した際や、DNSサーバーの性能や通信路の帯域幅が足りていない場合、大規模な利用者数を想定したPublic DNSの方が高速な応答を得られる場合があります。
引用 : https://xtech.nikkei.com/atcl/nxt/column/18/01882/121700014/
基本的に高速さなどをPubic DNSを利用する際の懸念点については、以下のようなことが挙げられています。
なおLAN内やISPのDNSでは、比較的経路が閉じられているため、 盗聴の危険はそれほど高くありません。 しかしパブリックDNSの場合、いわゆるインターネットを経由するため、 平文のやり取りは盗聴される危険があります。盗聴を回避するためには、 別の手段、例えばDNS over HTTPSなどで通信を暗号化する必要があります。
どのDNSサーバーを使えばよいのだろうという点については、以下の記事でまとめられており、様々な用途によって向き不向きがあるといえると思います。ここでは参照記事の貼り付けにとどめます。
※ オープンリゾルバーとはなんなのか
Public DNSについて調べていると出てくる「オープンリゾルバー」について。「Public (パブリック)」と「Open (オープン)」で似たようなニュアンスで受け取ってしまいがちですが、それぞれで意味が異なっているため以下に引用を記載します。
オープンリゾルバとは、DNSの名前解決を行うサーバやネットワーク機器などのうち、 不特定のクライアントからのDNS (Domain Name System)の問い合わせについて、 最終的な答えが得られるまで繰り返し問い合わせを行う再帰的な名前解決を行い、 結果を回答するDNSサーバなどのことです。
引用 : https://www.nic.ad.jp/ja/basics/terms/open-resolver.html
インターネット上のどのクライアントからの名前解決要求であっても実行してしまう状態のサーバーやネットワーク機器のことです。なお、ブロードバンドルーターやケーブルモデムといった機器に組み込まれているリゾルバーがオープンリゾルバーとなっているケースも存在します。
引用 : https://jprs.jp/glossary/index.php?ID=0184
引用より「誰からのアクセスであってもリクエストを受け入れてしまうため、悪用や攻撃の対象になってしまうことが問題」といえます。そのため、このオープンリゾルバーは根絶に向けて様々な企業や機関が注意喚起をおこなっています。
しかし、この定義で言えば「1.1.1.1」や「8.8.8.8」もオープンリゾルバーではないでしょうか？
どちらも「誰でも使える」という点に関しては共通していますが、具体的には以下のような違いがあるため、これらは混同しないように注意が必要です。
オープンリゾルバー
“管理者の意図に反して” 誰でも使えるようになってしまっているもの
Public DNS
“管理者が様々なセキュリティ上の対策を実施したうえ” で、意図的に誰にでも使用できるようにしているもの
まとめ
DNSについて、基本的な仕組みをまとめてみましたが例にも漏れず長くなってしまいました。
以下の点についても記事の中に盛り込みたかったのですが、今回は断念して別の記事として切り分けるか、追記することとします。
- DNS over TLS
- DNS over HTTPS
- DNSを経由した代表的な攻撃について
おかしな点がありましたら X のDMかお問い合わせフォームよりご連絡いただけるとありがたいです。
参考
書籍