用語集:DNSサーバーとは?

Network server racks

「DNSサーバーとは何か」という問いに対する答えは、デバイスからのDNSクエリに応答し、それを解決するものである。

DNSサーバーはネットワーク運用において極めて重要である。DNSサーバーがなければ、コンピュータやスマートフォンなどのデバイスは、ネットワークを介して通信したり、インターネットにアクセスしたりすることができなくなる。

ドメインネームシステム(DNS)は、ネットワーク上のデバイス間の通信を可能にする階層的な命名システムです。 具体的には、人間が読みやすいドメイン名(bluecatnetworks.comなど)を、コンピュータが理解しやすいインターネットプロトコル(IP)アドレス(IPv4では104.239.197.100など)に変換します。

DNS のおかげで、IP アドレスの数字の列を覚える必要なく、ウェブサイトに接続することができます。DNS があれば、ウェブブラウザを開く際に必要なのはウェブサイトの名前だけです。スマートフォンなどのデバイスは、ウェブサイトのドメイン名に対応する IP アドレスを特定するために、DNS サーバーに情報を要求します。

この用語解説では、まずDNSサーバーとは何かという基本について触れます。次に、DNSサーバーがDNSクエリを完了するために通常行う8つのステップを詳しく解説します。最後に、DNSサーバーが応答しない場合の意味について探っていきます。

DNSサーバーとは?

DNSネームスペースとは、インターネット上に登録されているドメイン名の総体を指します。これは、ツリーのような構造で階層的に整理されています。ツリーの最上部にはルートドメインがあり、その下にトップレベルドメイン(TLD)が配置されています。 (TLDとは、.comや.orgなど、ドメイン名の末尾の部分のことです。)その次に、example.comの「example」のようなセカンドレベルドメインが続きます。

DNSサーバー(ネームサーバーとも呼ばれます)は、DNSレコードを保存したり、他のサーバーと通信したりします。クライアントデバイスからクエリが送信されると、リゾルバーとネームサーバーが介入します。これらは、クエリが関連するレコードから応答を受け取れるようにします。

コンピュータやスマートフォン(クライアントデバイスとも呼ばれる)に、Webサイトにアクセスするよう指示します。その際、デバイスはDNSクエリまたはリクエストを送信します。スタブリゾルバーとは、クライアントデバイス内でこれらのリクエストを処理する部分のことです。

その後、2種類のDNSサーバーが関与します。 それらは、再帰的リゾルバー(または再帰的DNSサーバー)と、権威ネームサーバー(権威DNSサーバーとも呼ばれる)です。

後者には、ルートサーバーやTLDサーバーが含まれます。通常、これらはルックアップチェーン内で権威ネームサーバーと連携して、クライアントデバイスにIPアドレスを配信します。

特に注目すべきは、DNSサーバーにはさまざまな形態があるという点です。物理サーバーや仮想サーバーである場合もあれば、AWSのサーバーレス関数(Route 53と呼ばれる)やKubernetes上のコンテナとして実装される場合もあります。

DNSサーバーへのクエリは絶えず行われています

DNSクエリ(DNSルックアップとも呼ばれる)は、常に発生しています。

その一部はネットワーク内部で行われており、内部DNSクエリはパブリックインターネットには決して到達しません。 オンプレミスのローカルエリアネットワーク(LAN)を構成するDNSサーバーは、ネットワーク運用に不可欠です。これらがなければ、ネットワーク上のユーザーやそのデバイスは、ローカルサーバーやプリンターに接続できなくなります。企業環境では通常、ネットワーク内の内部DNSクエリを解決するための専用の内部DNSサーバーが設置されています。

一方、外部のWebサイトへのクエリはネットワークの外に送信され、解決には外部サーバーに依存します。

さらに、今日のハイブリッドクラウド環境における企業環境では、DNSサーバーが極めて重要な役割を果たしています。かつては、Microsoft Wordを使用するために必要なのは、コンピュータとインストールされたソフトウェアだけでした。 現在では、企業ユーザーは主にSaaS(Software-as-a-Service)アプリケーション(Office 365など)を利用しています。また、多くの企業向けアプリケーションは、データセンターのサーバー上ではなく、IaaS(Infrastructure-as-a-Service)クラウド上に配置されています。

いずれの構成においても、DNSサーバーはユーザーをアプリケーションの宛先へと誘導する必要があります。

DNSサーバーがルックアップを完了するための8つのステップ

多くのシナリオでルックアップが必要となります。ここでは、Webブラウザを使用する非常に一般的なケースにおける8つの基本的な手順を紹介します:

What is a DNS server? The eight steps for a DNS server to complete a lookup

  1. ユーザーがGoogle ChromeなどのWebブラウザに「example.com」と入力します。その後、クライアントデバイスはIPアドレス情報を要求し、デバイス上でローカルにその答えを見つけようとします。見つからない場合、次のステップは…
  2. 再帰的リゾルバーです。これは、クライアントと権威あるネームサーバーの間に位置するDNSサーバーの一種です。企業のIT部門は通常、1つ以上の再帰的リゾルバーを提供しています。家庭では、インターネットサービスプロバイダー(ISP)がいくつか提供しているでしょう。 ただし、代わりにパブリックDNSサーバーを使用することを選ぶ人もいるかもしれません(一般に利用可能なDNSサーバーのリストがあります)。クエリを受信すると、再帰型リゾルバーは、ほとんどの場合、キャッシュされた情報で応答します。しかし、答えが見つからない場合は、リクエストを…
  3. ルートネームサーバーへリクエストを転送します。これが、ドメイン名をIPアドレスに変換する最初のステップです。その主な役割は、より具体的なサーバーの場所を指し示すことです。ルートネームサーバーは、そのドメインに関する情報を格納しているTLDネームサーバーの名前を、リゾルバーに返答します。
  4. 再帰的リゾルバーは、TLDネームサーバーにリクエストを送信します。
  5. TLDネームサーバーは、要求されたドメインの権威ネームサーバーの名前と、考えられるIPアドレスを返します。
  6. 再帰的リゾルバーは、検索チェーンの末端にある権威ネームサーバーにリクエストを送信します。権威ネームサーバーはDNSレコード(正式にはリソースレコードと呼ばれる)を保持しており、その最終的な決定権を持っています。このプロセスの最後の段階として、このサーバーはWebブラウザが必要とするレコードを返すことができます。
  7. 権威ネームサーバーは、要求されたデータを再帰的リゾルバーに返します。
  8. 再帰的リゾルバーは、要求されたデータとともにWebブラウザに応答し、ユーザーは回答を受け取ります。

DNSキャッシュ

DNSレコード情報は、多くの場合、クライアントデバイス内やDNSサーバー階層のどこかにローカルにキャッシュされます。確かに、DNSキャッシュにより、クエリの解決がより効率的になります。

実際には、キャッシュが空の状態になることは比較的稀です。 効果的なキャッシュにより、多くの場合、手順を省略することが可能になります。しかし、前述のように、サーバー階層内の主要なノードすべてにクエリを送信しなければ、キャッシュを初期に構築することはできません。

前述のステップ2で述べたように、再帰的リゾルバーはキャッシュされた情報で応答することができ、それによってさらなる手順を省略してレコードを配信することができます。 さらに、前述のステップ3から5は、ネームサーバーに何もキャッシュされていないことを前提としています。しかし、キャッシュが存在する場合、ステップ3から5は次のような流れになります:

ステップ2の再帰的リゾルバーが答えを見つけられない場合、そのリクエストを…

  1. キャッシュから把握している最適なネームサーバーへリクエストを転送します。これは、すべての再帰的リゾルバーが認識していなければならない、ルートネームサーバー(インターネットのネームスペースツリーの最上位)である可能性があります。
  2. クエリを受けたネームサーバーは、自身が知る最善の回答を返します。これは多くの場合、ネームスペースツリーの下位にあるデータを知っている、別の権威ネームサーバー群への参照となります。
  3. 再帰的リゾルバは、ステップ3と4を繰り返しながら、名前空間ツリーを下へ進み、得た情報をすべてキャッシュします。

その後、前述の手順6に進み、権威ネームサーバーにリクエストを送信します。

有効期間(TTL)

さらに、ほとんどのスタブリゾルバーは、TTL(Time to Live)と呼ばれる一定期間、レコードをキャッシュするように設計されています。TTLが切れると、クライアントが次にそのアドレスを知る必要が生じた際、上記のステップ2から再び処理が開始されます。設定された再帰ネームサーバーへのクエリも、そこから再開されます。 管理者がDNSサーバーインフラストラクチャでTTLをどの値に設定するかは、多くの要因によって左右されます。

再帰ネームサーバーはTTLを遵守すべきです。しかし、一定期間再検索できない古いデータをそのまま提供し続ける方が、多くの場合、より現実的です。これにより、一時的なネットワーク障害が発生した場合でも、DNS検索の耐障害性が向上します。

2種類のDNSクエリ

また、DNSクエリには一般的に2つの種類があることに留意することが重要です。

再帰クエリ:ローカルのDNSリゾルバーは、クライアントデバイスに応答する際に完全な回答を提供する必要があります。リゾルバーはまずローカルキャッシュを検索します。そこで回答が見つからない場合、インフラストラクチャ内の他のDNSサーバーに問い合わせます。クライアントに返す完全な応答が得られるまで、リクエストを試行し続けます。

非再帰的(または反復的)クエリ:DNSサーバーは、必ずしもクライアントデバイスに完全な回答を提供するわけではありません。回答を持っていない場合、返される回答は、その回答を持っている可能性のある他のDNSサーバーをクライアントに案内します。クライアントは、回答を持っているサーバーが見つかるまで、このプロセスを繰り返します(反復します)。

反復クエリは、多くの場合、再帰クエリよりも高速です。クエリを受けたサーバーは、応答を構築するために他のサーバーに問い合わせる必要がないからです。

もちろん、クエリが常に正常に解決されるとは限りません。解決されない場合、DNS応答コードから問題の原因に関する手がかりが得られることがあります。

DNSサーバーが応答しない場合はどうすればよいですか?

通常、「DNSサーバーが応答しません」というエラーが表示されるのは、次の2つの理由のいずれかによるものです。アクセスしようとしているドメインのDNSが利用できないか、あるいはウェブブラウザがインターネットへの接続を確立できないかのいずれかです。

このエラーメッセージの原因がサーバー自体にある場合もあります。停電、ハードウェアの故障、あるいは分散型サービス拒否(DDoS)攻撃などが原因として考えられます。(2016年にDNSプロバイダーのDynに対して行われた大規模なDDoS攻撃を覚えていますか?)

多くの場合、ユーザー側のミスが原因です

しかし、問題がユーザー側にあることも珍しくありません。ネットワーク接続の問題、設定の誤り、あるいはウェブブラウザのバージョンが古すぎるといったことが原因である可能性があります。

通常、ユーザーは簡単な手順で問題を解決できます。これには、ネットワーク設定のトラブルシューティング、別のデバイスやブラウザへの切り替え、ルーターの再起動などが含まれます。さらに、接続の無効化、DNSサーバーの変更、DNSキャッシュのクリアなども有効な対策となります。

一般的な予防策:高可用性、エニーキャスト、および自動化

ハードウェア障害によるエラーを回避するため、今日の DNS サーバーインフラの多くは冗長性を考慮して構築されています。(冗長性は、高可用性と呼ばれることもあります。)ほとんどの ISP はバックアップ用の再帰的リゾルバーを保有しており、ルートおよび TLD ネームサーバーには通常、複数のインスタンスが存在します。ウェブサイトも同様に、バックアップ用の権威ネームサーバーを保有しているのが一般的です。

さらに、稼働時間を確保するために、DNSサーバーでは通常、エニーキャストルーティングが採用されています。エニーキャストにより、ネットワーク上の複数のサーバーが同じIPアドレスを使用できるようになります。つまり、世界中のどこからでも、任意の数のDNSサーバーがクエリに応答できるということです。

通常、遅延を低減するために、クライアントに地理的に最も近いサーバーが応答を提供します。 しかし、そのサーバーがダウンした場合でも、稼働中でアクセス可能な他のサーバーが代わりに応答を提供できます。

自動化により、人為的ミスのリスクを低減できるだけでなく、効率も向上します。

DNS自動化ツールを使用すれば、ITスタッフやエンドユーザーが自ら新しいサーバーやサービスを立ち上げる、あるいは廃止することが可能になります。 DNSレコードは、数秒で自動的に作成または更新できます。

BlueCatは、企業がネットワークの自動化と耐障害性を高めるお手伝いをします。DNS、DHCP、IPアドレス管理といった中核サービスをBlueCatプラットフォームソリューションに統合することで、ネットワーク管理を一新することができます。

関連コンテンツ

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

組織のネットワーク向けに、ガバナンスが確立され、監査対応可能なIPAMワークフローおよび承認モデルを構築する

ガバナンスが確立され、監査対応が可能なIPAMワークフローを実現するIP管理ソリューションをご覧ください。企業ネットワークチーム全体で、範囲を限定した承認と完全な監査証跡を実現します…

Read more
コンテンツハブ

OSIモデルの理解:7層構造におけるDNSとIPアドレスの位置づけ

OSIモデルの7つの層と、DNSおよびIPアドレスがそれらにどのように位置づけられるかを理解しましょう。BlueCatでネットワークアーキテクチャの基礎を学びましょう。…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

IPv6 およびデュアルスタック企業ネットワーク向けの DNS および IPAM のスケーリング

デュアルスタック企業ネットワーク向けに DNS および IPAM を拡張します。Micetro が、統合された DNS、DHCP、および IPAM…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

Embedding DNS, DHCP, and IPAM into Ansible and Git-based infrastructure-as-code pipelines

Embedding DNS, DHCP, and IPAM into Ansible and Git-based IaC pipelines with Micetro turns address and record changes into versioned, reviewable steps

Read more