1.DNS

DNSの基礎

はじめに

LinuxのDNSについての勉強をしていこうと思う。DNSの設定は基本的にはどのOSでもあまり変わらないと思うが、linuxでの設定は結構難しい。少しずつ理解を深めようと思う。

基本的にはドメイン名からIPアドレスに変換するための機能であるが、昔と比べるとかなり進化しているため、かなり複雑になってきている。

DNS（Domain Name System）は、ドメイン名からIPアドレスに変換したり（正引き）、IPアドレスからドメイン名に変換したり（逆引き）を管理するシステムのことであり、多様化するインターネットの世界で非常に重要な役割を演じている。

初期のころ（Arpanetの時代）は、一台のコンピュータがIPアドレスと対応名を一元管理していた。

 リスト1．ホスト名とIPアドレスの対応表
111.xxx.110.110 anie
122.xxx.244.115 kenn
136.xxx.211.206 suzie
注）IPアドレスが実在のIPにならないよう、xxxは0から255までの架空の数である。

上のリストのように、コンピュータ名（ホスト名）とIPアドレスの対応表を作り、作成されたファイルを公開することで対応していた。この単純な方式は今でも残っていて、/etc/hostsファイルの運用に生かされている。

当初は、直接IPアドレスを指定したり、上記のような登録されているホスト名を自動的にIPアドレスに変換するソフトを利用して、様々なコンピュータと通信をしていた。しかし、登録コンピュータが膨大になるにつれて単純なホスト名が使用済みになってしまい、複雑なホスト名を付けるなどの利便性が悪くなり、ホスト名の命名ルールを決めようということになった。

そこで登場したのが、ドメイン名の考え方であり、

ホスト名.ドメイン名.co.jp

などのように、異なるドメイン名なら同じホスト名が使えるようにしようということになった。現在では、「ドメイン名.co.jp」全体をドメイン名と呼ぶことが主流となり、

ホスト名.ドメイン名

と記述することが多い。(ホスト名.ドメイン名全体をドメイン名とする場合もあり、文脈により適切に解釈するのがよい。)

これにより、各組織ごとに簡単なホスト名（コンピュータ名）を付けられるようになり、ドメイン名からどこの国のどのような組織に所属するコンピュータなのかわかり易くなり、系統的かつ合理的かつ簡単にドメイン名を管理運用できる下地が出来上がってきた。

しかしそれだけでは、余りにも膨大になったコンピュータ群を一元管理することは非常に困難であった。そこで、多くのコンピュータにより分散管理する方式を採用することになった。


図1．DNSの階層構造

上図のように、ドメイン名の階層構造を構築し、上位ドメインから下位ドメインへと階層毎にDNSサーバを設置することになった。

DNSサーバはドメイン名とIPアドレスとの対応関係を含むデータベースを運用・管理するDomain Name System(DNS)を実行しているコンピュータのことであり、分散データベース管理システムのひとつである。世界中で膨大な量のDNSサーバが稼働している。

DNSサーバはネームサーバとも呼ばれるが、ここではDNSサーバに統一表記する。

jpドメインはJPNIC(Japan Network Information Center)が管理することになり、ドメイン名の最後に.jpとなる日本国内のコンピュータの最上位DSNサーバが設置された。現在はJPRS(日本レジストリサービス)に管理が移管され、複数のDNSサーバにより分散管理されている。

もちろん、すべての.jpのドメイン名をJPRSが一元管理するわけではなく、膨大になるドメイン名はより下層のDNSサーバで管理される。

DNSサーバの階層構造はさらに末端のDNSサーバへと繋がり、階層の深さは127レベルまでとなっている。（現実的にはドメイン名の長さ253文字までの制約があるため、階層の深さがそれによりさらに制限されることになる。実用上、5～6レベルまでの運用がほとんどなので、気にする必要はない。）それゆえ、だれでも自由にDNSサーバを立ち上げ、上位DNSサーバに繋がれば、運用できるようになる。しかし、運用するためには、DNSについての専門的知識が必要となり、管理運用は基礎知識のない人には非常に困難になっている。

リスト１のようなホスト名とIPアドレスの対応情報は、ゾーンと呼ばれる単位で分散管理され、ゾーンは階層型に構成される。

図1のようにドメイン名の階層構造があることから、それぞれのドメイン名が表すDNSサーバが管理するゾーンに階層構造があることが容易に理解できる。そして、それぞれが独立した領域（ゾーン）を形成し、階層構造を通して全体を構築していると認識できる。

ルートサーバ直下のjp、com、org、net…などのドメインをトップレベルドメインTop Level Domain(TLD)と呼び、その下のドメインはセカンドレベルドメインSecond Level Domain(2LD)と呼ばれて、分類されている。

ccTLDとgTLD

ccTLDはCountry Code TLDの略であり、国レベルで割り当てられる。.jp、.cnや.ukなどがある。

gTLDはGeneric TLDの略であり、国以外の分類で割り当てられる。.com、.net、.orgなどがある。genericは「属の、一般的な、包括的な、汎用の、ノーブランドの」などに訳されるが、ある共通の属性を持つ包括的な分類上のものを指す場合に用いられることが多いように思われる。ピッタリした日本語が見つからない難しい単語である。generic programmingは汎用性を重視した再利用可能のプログラム手法を意味し、個別の異なるプログラムをgeneric programから派生させることでプログラム作成の効率化をおこなう。generic technologyは基盤技術と訳され、将来的に活用できる基礎研究技術を意味する。両者とも共通する属性の何かを抽出し、そこに焦点を当てながら、広範囲に活用できる意味合いがある。

gTLDは、現在、様々な分野の1200以上のものが登録されている。その中には、.pharmacyや.bankなどのコミュニティベースTLDや.tokyoや.osakaなどの地理的名称TLDも含まれている。

問い合わせの仕組み

一般のパソコンにはDNSサーバは組み込まれておらず、インターネットプロバイダーから提供されているDNSサーバ（DNSキャッシュサーバとも言う）に問い合わせる形で運用されている。それゆえ、ただ単にインターネットを利用するだけならばDNSの知識は不要である。

しかし、組織内に多数のコンピュータを置き、サブドメインを設定して運用管理する場合、DNSサーバの設置は必要になる。DNSの知識が不足している組織の場合、もしくは、効率的運用のため、外部ネットワーク会社のDNSサーバを借りる方法もあるが、専門家の助力を得て独自にDNSサーバを構築することもできる。または、組織内に専門家を置き、構築することもあるだろう。

下図は、DNSの基本的動作原理を説明するものであり、概念化されたものなので実際とはかなり趣が異なる。しかし、基本的考え方であるので、しっかりと把握しておくことは重要であろう。


図2．DNS 問い合わせの基本的原理（正引き）

上図は、ドメイン名からIPアドレスを問い合わせる「正引き」と呼ばれる仕組みを解説したものである。

最上位のルートゾーンから開始し、ルートゾーン→comゾーン→googleゾーンへと、下方に向かって順に問い合わせる。最終的にgoogleゾーンのDNSサーバにたどり着き、そこにあるwwwのIP情報を入手することができる。このように繰り返し問い合わせて名前解決する行為をiterative resolutionという。また、繰り返し問い合わせをiterative queryという。

階層の上位に当たるDNSサーバには膨大な量の問い合わせがあり、分散して対応する方式が採用されている。最上位のルートサーバはAからMまでの13個のDNSサーバが世界中に分散して設置され、さらに同じデータを共有するDNSサーバが複数設置されている。Mは日本、韓国、パリなどに設置されている。

DNSではゾーンの情報を管理するサーバを別のゾーンに置くこともでき、ルートゾーンを管理するサーバは「root-servers.net」内に置かれている。つまり、TLD（トップレベルドメイン）であるnetゾーン内のroot-serversというゾーンにルートゾーンを管理するサーバがあるという少し不思議な状況になっている。さらに、comゾーンを管理するDNSサーバは「gtld-servers.net」内に置かれている。

それゆえ、より具体的なwww.google.comの正引き問い合わせは下図のようになる。


図3．DNS 問い合わせのより具体的仕組み（正引き）

上図において、hogeゾーンは、利用者PCが所属している組織のドメイン名がhoge.co.jpであることを想定している。また、DNSサーバは一定時間データを保持するので、保持されているデータの中に目的のものがあれば、問い合わせを行わないで利用者PCに返答することもある。

① 利用者PCは、PC内に登録されているDNSサーバ（linuxの場合/etc/resolv.confに記述）に「www.google.com」のIPアドレスを問い合わせる(再帰問い合わせrecursive query)。

② hogeゾーンのDNSサーバは、最初から所有しているルートゾーン情報（ルートDNSサーバのドメイン名と対応IPアドレス）から、通常はランダムに13個のルートサーバのどれか一つを選択し、選択したルートサーバにwww.google.comを問い合わせる(非再帰問い合わせnon-recursive query)。例えば、選択したサーバをc.root-servers.netとしよう。

③ c.root-servers.netは、答えとなる情報を所持していないことと、参考情報として、comゾーンを管理しているDNSサーバの情報（a～m.gtld-servers.netのIPアドレスなどの情報）を返信する。

④ hogeゾーンのDNSサーバは任意のgtld-serversのどれか一つを選択し、ここではg.gtld-servers.netとしよう、www.google.comを問い合わせる。

⑤ g.gtld-sersers.netは、答えとなる情報を所持していないことと、参考情報として、googleゾーンを管理しているDNSサーバの情報を返信する。

⑥ hogeゾーンのDNSサーバはgoogleゾーンのDNSサーバにwww.google.comを問い合わせる。

⑦ googleゾーンのDNSサーバは管理下にあるwww.google.comのIPアドレスを答えとして返信する。

⑧ hogeゾーンのDNSサーバはwww.google.comのIPアドレスを利用者PCへ返信する。

基本的に、DNSサーバが複数ある場合、ランダムに選択して問い合わせを試みるのが一般的と思われる。実際には最も高速に応答するサーバを選択することが好ましい。

linuxコマンドで「dig -t ns」の実行を繰り返すと、DNS起動初期のころは、ランダムな順番でルートサーバの情報が出力される。このことから、複数のDNSサーバがある場合はランダムに選択が一般的とかなり高い確率で推測される。ルートサーバの負荷バランスを考えると、ランダム選択が合理的であろう。しかし実際は、最も応答の速いDNSサーバが選択されるような工夫がなされている。

[RTTによるDNSサーバの選択]

BIND系のDNSサーバは、ラウンドトリップ時間(RTT)という値を基準にして、あるゾーンに対して権威を持つDNSサーバの中から1つを選んでいる。初めて問い合わせるサーバに対して、実世界のRTTよりも小さいランダムな値を割り当てておく。ストップウォッチを用意し、問い合わせから応答が返ってくるまでの時間を計測し、その時間をRTTとして記録する。最もRTT値が小さいものを選択して問い合わせをしていくことにより、最終的には、最も小さいラウンドトリップ時間(問い合わせから応答が返ってくるまでの時間)を持つDNSサーバが選択されるようになる。この単純だが簡潔かつ的確なアルゴリズムにより、BIND系のDNSサーバは最も近いDNSサーバに素早く照準を合わせることができる[4]。

図3の利用者PCは必ずしもhogeゾーン内のPCでなくてもよい。一般家庭のPCの場合、プロバイダー指定のDNSを設定するようになっていると思われるが、公開DNSサーバならばどのDNSサーバでも問題はないのではないかと思われる。しかしながら、セキュリティの観点から、配下の契約利用者にのみ開放するDNSサーバが一般的である。

一般利用者が利用する問い合わせ用のDNSサーバはDNSキャッシュサーバとも呼ばれ、最近問い合わせたデータはキャッシュされている、つまり、消去されずに残っている場合がある。問い合わせ内容がキャッシュされている場合は、上位DNSサーバに問い合わせることなく応答するため、上位DNSサーバの負荷を緩和するようになっている。

DNSキャッシュサーバの欠点として、最近更新されたDNS情報はすぐに反映されず、古いデータが返答される場合があることである。数日後には更新されるものの、反映に時間がかかる場合がある。

DNSキャッシュサーバは利用形態からそう呼ばれるものであり、DNSサーバのひとつの機能である。しかし、ゾーン管理を行うDNSサーバと切り離して、問い合わせのみを行うDNSキャッシュサーバとして利用されることも多い。また、インターネットから切り離して設置されるDNSキャッシュサーバというものもあるので、混乱しやすい。

図3のように、利用者PCからの問い合わせを受けて、②から⑦のように繰り返し問い合わせをおこなう。このことをiterative queryと述べたが、テキストによっては、再帰的問い合わせ(recursive query)と述べているものもある。「利用者PCからDNSサーバへ再帰的問い合わせを行い、DNSサーバは非再帰的問い合わせ(non-recursive query)を繰り返して問い合わせを完了する。」という解説と微妙な齟齬が発生する。混乱を回避するため、DNSサーバからの問い合わせは繰り返し問い合わせ(iterative query)と統一することが望ましい。②から⑦までの一つ一つの問い合わせを非再帰的問い合わせ、全体を一纏めにして再帰問い合わせと考えてよいと思われるが、混乱回避の処方箋である。利用者PC（リゾルバ）から再帰的に名前解決してほしいとの依頼(recursive query)をDNSサーバに行う。DNSサーバはその依頼を受けて、非再帰的問い合わせ(non-recursive query)をルートサーバから順に下位のサーバへと繰り返すことにより、最終回答を得る。得られた答えを利用者PCへ返信する。通常、外部からの再帰問い合わせを無視または拒否する設定になっているDNSサーバがほとんどなので、このような区別をしっかり理解しておく必要がある。

エニーキャスト

エニーキャストは、同じIP（同じドメイン名）を持つサーバが複数存在し、any（どれでもいいが複数ある中のどれかという意味）のcast(投げるの意からIT用語としてデータ送信の意味、ユニキャスト、マルチキャスト、ブロードキャストなどがある)ということで、どれでもいいが複数ある中のどれかひとつに送信する方式の通信方法のことである。

エニーキャストは1対多の接続方式であるが、ある任意の時点で1対1に切り替わり、最も近いまたは最もよいDNSサーバに接続して送信するようになっており、地域分散型と言えるだろう。同じドメイン名かつ同じIPアドレスであるにも関わらず、異なるDNSサーバが対応し、分散処理を行う。

近年、エニーキャストで設置されるルートサーバが世界中に存在しているが、それぞれの管理組織（12組織）が異なるためか、aからmのそれぞれのルートサーバでエニーキャスト設置数に極端な違いがある。

さて、ルートサーバのaからmの13個のサーバとエニーキャスト(anycast)の関係は詳しい知識がないと混乱しそうである。a.root-servers.netからm.root-servers.netはそれぞれ異なるドメイン名とそれぞれに対応した異なるIPアドレスを持っている。所持するデータが同じであるようにそれぞれのサーバ間で通信し合っているが、エニーキャストで結ばれているのではない。

13個のルートサーバのそれぞれがエニーキャストで世界中に分散して存在するため、実際のルートサーバの数は2019年8月19日現在1011個存在する(https://root-servers.org/を参照)。

日本に存在するjpゾーンを管理するDNSサーバはa.dns.jpからg.dns.jpの7個あり、いくつかの組織で分散管理されている(https://www.nic.ad.jp/ja/basics/beginners/dns.htmlを参照)。ルートサーバと同じように、エニーキャストでさらに分散管理することで効率化が行われている（https://www.iij.ad.jp/dev/tech/activities/ddnsjp/を参照）。

レジストリとレジストラ

レジストリは、ゾーン情報を含むトップレベルドメイン(Top-Levet Domain(TLD) .jp, .com, .netなど）のデータベースのことを意味するが、それを管理する組織を指すこともある。(Wikipedia参照。日本においてはJPRSなどの管理組織または管理会社の意味で使われているが、データベースの意味に解釈しても問題ない場合が多いように思われる。Microsoft Windowsにおいては、管理用データベースを意味している。)

レジストラは、レジストリに登録する事業者であり、レジストリから登録権限を移管されている。トップレベルドメインの管理団体は、膨大に膨れ上がるドメイン名を維持管理するために、多くのレジストラと契約している。

リセラは、レジストラと登録者の間を仲介する業者のことを指し、レジストラを介して登録したドメイン名を別の登録者に再販する。リセラはレジストリと契約関係はない。

役割分担から見たDNSの構成要素

一括りにDNSサーバと呼んでいたが、役割分担でDNSの構成要素を分類する方法がある。

  1. スタブリゾルバ
  2. フルリゾルバ（フルサービスリゾルバ）
  3. 権威サーバ（権威DNSサーバ、権威ネームサーバ、コンテンツサーバとも言われる。）

スタブリゾルバはDNSサーバではないが、DNSサーバ(フルリゾルバ)に問い合わせを行うプログラム（アプリまたはソフト）のことであり、利用者PCまたはスマホで動作している。

Webブラウザ上のリンクをクリックすると、ブラウザはリンク情報をスタブリゾルバに問い合わせ、スタブリゾルバはフルリゾルバに問い合わせることで、リンク先IPアドレスを入手し、目的のWebを表示する仕組みを提供している。


図4．DNS 役割分担から見た正引き問い合わせの仕組み

上図は、図3の一部を書き換えたものであるが、青表示でスタブリゾルバ、フルリゾルバ、権威サーバの関係を示した。

スタブリゾルバはフルリゾルバに対し再帰問い合わせ(recursive query)を行う。フルリゾルバは上位権威サーバから順に繰り返し問い合わせ(iterative query)を行い、目的のIPを入手する。フルリゾルバは入手したIPをスタブリゾルバへ送信する。

フルリゾルバは「キャッシュ]と呼ばれる仕組みで入手した情報を一時的に記憶しておく。再度、同じ問い合わせがあった場合、キャッシュからデータを取り出し、権威サーバに問い合わせることなく回答する。また、上位ドメイン名が以前に問い合わせてキャッシュされていた場合、そのデータを活用して繰り返し問い合わせの回数を減らす工夫もされている。

DNSサーバについての混乱を避けるための一言

DNSサーバには、フルリゾルバのみ提供しているものから、フルリゾルバと権威サーバの両方を提供するもの、権威サーバのみ提供するものなど、いくつかの種類がある。そのため、一口にDNSサーバと言っても、どの種類のDNSサーバかを特定しないと、議論がかみ合わず、混乱を招くことが多い。また、DNSサーバ用として世界的に流布されているソフトも多種多様にあり、フルリゾルバのみ、権威サーバのみ、または両方をサポートするソフトがあり、そこで使われている用語もいくらか違いがあるため、混乱に拍車をかけている。

ゾーンデータを管理しているサーバを「権威サーバ」と言うが、その言葉からどういうサーバなのか推測するのは難しい。「ゾーン管理サーバ」としたほうがわかりやすいのではと、個人的には思うのであるが、そのような呼び方はどの教科書にも載っていない。一方で、「コンテンツサーバ」という呼び方もあるので、本文でもコンテンツサーバと記述しようかと思ったが、いくつかの教科書やネット上の解説でそのような記述はあったものの、権威サーバの方がより一般的に使用されているようである。jpドメインの管理権限を持つJPRSでは「権威サーバ」と明確に記述してあるので、本文でもそれを踏襲することにした。「いったい何が権威なんだ？」と奇妙な感覚に襲われるが、上位ドメインの管理サーバから管理権限の一部を下位ドメインの管理サーバへ委任、階層構造を作っていることと、上位サーバの管理ポリシーはより強い決定権があるため、管理下の下位サーバはそのポリシーに従わなければならない。それゆえ、管理ポリシーの決定権は常に上位サーバにあることを強調するために「権威サーバ」と言うのだろう。しかし、TLDなどの上位サーバを「権威サーバ」、下層のサーバを「コンテンツサーバ」と使い分けているようなテキストもあるようである。

DNSサーバのことを「ネームサーバ」と呼ぶことも多い。ほとんど同じ意味に使われているが、格式ある古いテキストではネームサーバと呼ぶことが多いように思われる。最近では両者混在し、両方ともよく使われている。

参考文献

[1] 「標準テキスト CentOS７ 構築・運用・管理パーフェクトガイド」、有限会社ナレッジデザイン著、SB Creative出版、2017年
p616- 13-1章 DNSサーバ に正引き、逆引きの詳しい解説がある。
「CentOS7で作るネットワークサーバ構築ガイド　1804対応　第2版」、サーバ構築研究会著、秀和システム出版、2018年
p204- 9章DNSコンテンツサーバ　にドメイン名空間、TLDについての解説がある。

[2] 「ドメイン名の仕組み」https://www.nic.ad.jp/ja/dom/system.html
「インターネット10分講座：DNS」https://www.nic.ad.jp/ja/newsletter/No22/080.html
にDNSについてのわかり易い簡単な解説がある。

[3] 「DNSが良くわかる教科書」株式会社日本レジストリサービス（JPRS)著、SB Creative出版、2018年
jpゾーンの管理会社JPRSの社員が、基礎からかなり専門的内容に踏み込んで解説している。しかし、初心者向けに抽象化して解説するために簡潔明瞭でない部分が多く、逆に読みづらい。しかし、最近のトピックを踏まえて丁寧に解説している必読書である。

[4]「DNS & BIND 第5版」Cricket Liu, Paul Albitz著、オライリー・ジャパン発行、2008年
DNSの簡単な歴史の概略から、ドメイン名空間とドメインおよびゾーンの概念についてのかなり詳しい解説がある。基礎からしっかりと理解し、さらなる理解を深めるための中級者から上級者必読の書である。


次は、dnsの基礎2である。

back    next