DNSとは何ですか?ドメインネームシステム、DNSサーバー、およびIPアドレスの概念の説明

前書き

この記事の終わりまでに、次のことをよりよく理解する必要があります。

  1. DNSとは何ですか?
  2. DNSサーバーの機能
  3. DNSのコンテキストでインターネットプロトコル(IP)アドレスがどのように機能するか

重要な概念

DNS、DNSサーバー、およびIPアドレスについて学習するときに知っておくべきいくつかの重要なメンタルモデルがあります。DNSについて学び始める前に、これらの概念を今すぐ確認してください。

  • これらのモデルに適合する動作を説明するために使用されるすべての異なる用語を理解するのに役立ちます。
  • 記憶保持を助けます。

メンタルモデルは、物事が少し奇妙でなじみのないものになったときに参照のフレームを提供します。

それでは、基礎を築きましょう。

  • クエリと応答。これは、Thing1がThing2に何かを要求し、Thing2がその要求に応答するときです。このような:
  • このように見える親子ノードの関係とグラフ(より複雑なだけ)。
  • メッセージ。応答がないため、クエリと応答ではありません。DNSの世界では、メッセージのフォーマットと内容は使用法によって異なります。
  • クライアント/サーバー関係。簡単に言うと、サーバーは、「クライアント」と呼ばれる他のソフトウェアまたはハードウェアデバイスに機能を提供するソフトウェアまたはハードウェアデバイスです。

    サーバーについての多くの話の準備をしてください。結局のところ、私たちがDNSと呼んでいるものに入るサーバーはたくさんあり、私たち人間がインターネットに接続するときにそれをどのように使用するかがわかります。

DNSとは何ですか?

ドメインネームシステム(DNS)は、人間が読み取れるドメイン名(URLまたは電子メールアドレス)をIPアドレスにマップします。たとえば、DNSはドメインfreecodecamp.orgを変換してIPアドレス104.26.2.33にマッピングします。

この説明を完全に理解できるように、このセクションでは以下について詳しく説明します。

  • DNS開発の歴史的背景-DNSとIPアドレスはどのような問題を解決しましたか?
  • ドメイン名
  • IPアドレス

歴史的背景

1966年、米国政府機関であるAdvanced Research Projects Agency(ARPA)は、ARPAnetと呼ばれるコンピュータネットワークを設立しました。簡単に言えば、ARPAnetは、現在インターネットとして知られているものの最初の反復と考えてください。

ARPAnetの主な目標は次のとおりです

「(1)機器の一部やネットワークに障害が発生した場合でも信頼性の高い通信を提供します。(2)さまざまな種類のコンピューターやオペレーティングシステムに接続できます。(3)単一の制御ではなく、協力的な取り組みです。株式会社。機器の故障に直面しても信頼できる通信を提供するために、ARPANETは、1つのポイントまたはリンクが他のどのポイントよりも重要にならないように設計されました。これには、冗長ルートの構築と、ネットワークのいずれかの部分に障害が発生した場合のデータのオンザフライ再ルーティングの使用が伴いました。」

問題点

DNSとTCP / IPは、ARPAnetの2つの問題を解決する上で重要でした。

ARPAnetの場合、ネットワーク上のすべてのホストのすべての名前からアドレスへのマッピングを含む単一の場所(HOSTS.TXTと呼ばれるファイル)がありました。

「HOSTS.TXTはSRIのネットワークインフォメーションセンター(「NIC」と呼ばれる)によって維持され、単一のホストであるSRI-NICから配布されました。[*] ARPAnet管理者は通常、変更をNICに電子メールで送信し、定期的にSRIにFTPで転送しました。 NICを使用して、現在のHOSTS.TXTファイルを取得しました。それらの変更は、週に1〜2回新しいHOSTS.TXTファイルにコンパイルされました。」

この設定には3つの課題がありました。

  1. トラフィックと負荷-ファイルの配布は、責任のあるホストが処理するには多すぎました。
  2. 名前の衝突-各ホストには一意の名前を付ける必要があり、ネットワークユーザーが競合する(一意ではない)名前のホストを追加して「スキーム全体を壊す」ことを防ぐ一元化された権限はありませんでした。
  3. 一貫性-ファイルを更新し、すべてのホストが最新のバージョンを持っていることを確認する行為は不可能になるか、少なくとも非常に困難になりました。

本質的に、HOSTS.TXは単一障害点であったため、ここでのプロセス全体は、特定の数のホストを超えて十分に拡張できませんでした。ARPAnetには、分散型でスケーラブルなソリューションが必要でした。DNSでした。ソース

同じネットワーク内のホスト間通信は、十分な信頼性がありませんでした。TCP / IPは、この問題の解決に役立ちました。

  1. 伝送制御プロトコル(TCP)は、(ホスト間で)メッセージをパケットに変換するプロセスの品質保証手段を提供します。TCPプロトコルはコネクション型です。つまり、送信元ホストと宛先ホストの間の接続を確立する必要があります。
  2. インターネットプロトコル(IP)は、送信元ホストと宛先ホストの間でメッセージ(パケット)がどのように伝送されるかを定義します。IPアドレスは、ネットワーク上のホストにつながる特定のパスの一意の識別子です。
  3. TCPとIPは密接に連携しているため、通常は「TCP / IP」のように参照されます。
  4. この記事では詳しく説明しませんが、DNSのデータトランスポート層ではTCPとユーザーデータグラムプロトコル(UDP)の両方が使用されています。UDPはより高速で信頼性がはるかに低く、接続を必要としません。TCPは低速で信頼性がはるかに高くなりますが、接続が必要です。これらは必要に応じてDNSで適切に使用されます。言うまでもなく、APRAnetにTCPを含めることは、データトランスポート層への貴重な追加でした。

1980年代初頭までに、DNSとTCP / IP(したがって、IPアドレス)はARPAnetの標準的な操作手順でした。

この歴史は非常に要約されています。これらのトピックについて詳しく知りたい場合は、この記事の最後にある「リソース」セクションを参照してください。

いくつかの歴史的背景ができたので、ドメイン名とIPアドレスについてさらに学びましょう。

ドメイン名

DNSのコンテキストでは、ドメイン名は非ローカルリソースを指すユーザーフレンドリーな方法を提供します。これは、Webサイト、メールシステム、プリントサーバー、またはインターネット上で利用可能なその他のサーバーである可能性があります。ドメイン名は単なるウェブサイト以上のものにすることができます!

「ドメイン名の目標は、名前がさまざまなホスト、ネットワーク、プロトコルファミリ、インターネット、および管理組織で使用できるようにリソースに名前を付けるためのメカニズムを提供することです。」

ドメイン名は、IPアドレスよりも、覚えて端末やインターネットブラウザに入力する方がはるかに簡単です。

ドメイン名はUniformResource Locator(URL)の一部ですが、これらの用語は同義ではありません。URLはリソースの完全なWebアドレスであり、ドメイン名はWebサイトの名前であり、すべてのURLのサブコンポーネントです。

URLとドメイン名には技術的な違いがありますが、通常、Webブラウザーはそれらを同じように処理するため、完全なWebアドレス、またはドメイン名だけを入力するとWebサイトにアクセスできます。

トップレベルドメインとセカンドレベルドメイン

特定のドメインには、トップレベルドメイン(TLD)とセカンドレベルドメイン(SLD)の2つの部分があります。ドメイン名の部分は、右(終わり)から左(始まり)に移動するときに、より具体的になります。

これは最初は混乱する可能性があります。たとえば、「freecodecamp.org」を見てみましょう。

  • URL://www.freecodecamp.org
  • ドメイン名:freecodecamp.com
  • TLD:組織
  • SLD:freecodecamp

ARPAnetの初期には、com、edu、gov、org、arpa、mil、および2文字の国コードドメインを含む、利用可能なTLDの数が限られていました。これらのTLDは当初、ARPAnetに参加している機関のために予約されていましたが、後に商業市場で利用できるようになりました。

今日、ネット、エアロ、ビズ、クープ、情報、博物館、名前など、利用可能なTLDは比較的豊富にあります。

セカンドレベルドメインは、ドメインレジストラ(Namecheapなど)を通じて個別に購入できるドメインです。

IPアドレス

IPアドレスはその機能においてDNSに関連していますが、インターネットプロトコル自体は技術的にDNSから分離されています。この区別についてはすでに歴史的な背景を説明したので、次にIPアドレスがどのように機能するかを説明します。

前述のように、IPアドレスは、ネットワーク上のホストにつながる特定のパスの一意の識別子です。電話番号と電話の例えを参照したいと思います。電話番号は電話自体を表すものではなく、電話を持っている人に連絡するための手段にすぎません。

このアナロジーは、IPアドレスに関して(少なくとも表面レベルでは)かなり適切です。IPアドレスはエンドポイントを表しますが、エンドポイント自体ではありません。IP割り当ては、固定(永続的)または動的(柔軟で再割り当て可能)にすることができます。

ドメイン名と同様に、IPアドレスの編成は階層構造に従います。ドメイン名とは異なり、IPアドレスは左から右に向かってより具体的になります。これは以下のIPv4の例です。

この図は、129.144がネットワーク部分であり、50.56がIPv4アドレスのホスト部分であることを示しています。
  • ネットワーク:ネットワークに割り当てられた一意の番号
  • ホスト:ネットワーク上のホスト(マシン)を識別します

より高い特異性が必要な場合、ネットワーク管理者はアドレス空間をサブネット化し、追加の番号を委任できます。

IPアドレスはいくつありますか?

IPv4は、ARPAnetが本番環境で使用したIPの最初のイテレーションでした。80年代初頭に導入され、今でも最も普及しているIPバージョンです。これは32ビット方式であるため、40億をわずかに超えるアドレスをサポートできます。

しかし、待ってください、それで十分ですか?いいえ。

IPv6には128ビット方式があり、340兆のアドレスをサポートできます。また、IPv4のパフォーマンスも向上します。

IPv4アドレスの例:

  • 104.26.2.33(freeCodeCamp)

IPv6アドレスの例:

  • 2001:db8:a0b:12f0 :: 1(圧縮形式で、freeCodeCampを指していない)

ドメインネームシステムはどのように機能しますか?

だから、私たちはドメイン名について学びました!IPアドレスについて学びました!では、それらはドメインネームシステムとどのように関連していますか?

まず第一に、それらは名前空間に適合します。

ドメイン名前空間

言語の「トップ」レベルドメインと「セカンド」レベルドメインによって示されるように、名前空間は階層に基づいています

「...組織構造にほぼ対応する階層と、「。」を使用した名前 階層レベル間の境界を示す文字として。」ソース。

ルートが上部にあるこのツリーグラフは、構造を最もよく示しています。

上から始めて、これを分解してみましょう。

このグラフの上部。「。」で示されています。「ルート」と呼ばれます。

「一般に「ルートサーバー」として知られているDNSルートゾーンにサービスを提供する権威ネームサーバーは、世界中の多くの国にある数百のサーバーのネットワークです。これらは、DNSルートゾーンで13の名前付き機関として構成されています。」

ルートドメインには長さがゼロのラベルがあります。

これ以降、グラフの各ノード(ドット)には、最大63文字の一意のラベルが付けられます。

ルートから1つ下のレベルは、TLD(com、org、edu、およびgov)です。このグラフにはTLDの完全なリストが含まれていないことに注意してください。

TLDの下には、セカンドレベルドメインであるSLDがあります。各ノードの子は「サブドメイン」と呼ばれ、親ドメインの一部と見なされます。たとえば、freecodecamp.orgでは、freecodecamp(SLD)はorg(TLD)のサブドメインです。

Webサイトの階層に応じて、第3、第4、第5レベルのドメインが存在する場合があります。たとえば、hypothetical-subdomain.freecodecamp.orgでは、hypothetical-subdomainは第3レベルのドメインであり、freecodecampのサブドメインです。などなど、DNSで許可されている最大値である少なくとも127レベルまで。

名前空間を管理するのは誰ですか?

1人の人または組織にすべてを管理させようとするのはくだらないことではないでしょうか。はい、そうです。特に、DNSの主要な設計目標の1つは、システム全体の分散型の分散型管理を促進することであったためです。

担当者は「名前空間王」と呼ばれていると言えばいいのですが、残念ながら。

ドメイン名前空間内の各ドメイン(またはサブドメイン)は、「自律的に管理される名前空間の一部」であるゾーンであるか、その一部です。したがって、名前空間はゾーンに分割されます。

これらのゾーンの責任は、委任と管理を通じて管理されます。

サブドメインの責任を他のエンティティに割り当てるプロセスは、委任と呼ばれます。

たとえば、Public Interest Registryはドメイン名orgを管理しており、2003年から使用しています。PublicInterestRegistryは、組織のサブドメインを管理する責任を他の当事者に委任する場合があります。そして、freecodecampを管理する人は誰でも、freecodecampのサブドメイン(たとえば、hypothethical-subdomain.freecodecamp.com)の責任を別の当事者に割り当てることができます。

誰か(組織、チーム、または個人)がゾーンを管理している場合、彼らが行っているのは、ゾーンを担当するネームサーバーを管理することです。

これにより、ドメインネームシステムの最も基本的な概念の1つになります。

ドメインネームサーバー

「ドメイン名前空間に関する情報を格納するプログラムは、ネームサーバーと呼ばれます。」

この時点で、少なくとも最初は、クライアントとサーバーの関係について考えることが役立ちます。ドメインネームサーバーは、クライアントサーバー関係の「サーバー」側です。ネームサーバーは、1つ、数百、または数千のゾーンをロードする場合がありますが、名前空間全体をロードすることはありません。ネームサーバーがゾーン全体をロードすると、そのゾーンに対して権限があると言われます。

ネームサーバーがそのように機能する理由を理解するには、関係の「クライアント」部分を理解することが役立ちます。

リゾルバ

DNSでは、クライアント(情報の要求者)は「リゾルバー」と呼ばれ、最初は逆に見える場合があります。リクエストを解決しているサーバーは「リゾルバー」と呼ばれませんか?私もそう思いましたが、そうではありません。それを覚えて先に進むのが最善です。

通常、リゾルバーは事実上ほとんどのオペレーティングシステムに含まれているため、OSにインストールされているアプリケーションは、低レベルのDNSクエリを作成する方法を理解する必要はありません。

DNSクエリとその応答はDNSメッセージの一種であり、独自のデータ転送プロトコル(通常はUDP)があります。リゾルバーは、OSにインストールされたアプリケーションがDNS関連データの要求をDNSクエリに変換するのを支援する責任があります。

つまり、リゾルバーは、データの要求をパッケージ化して送信する責任があります。リゾルバーは、応答を受信すると(あるとしても)、それを要求元のアプリケーションに使用可能な形式で元の要求側アプリケーションに返します。

ネームサーバーに戻る

関係のクライアント側についてもう少し詳しく理解できたので、ドメインネームサーバーがリゾルバークエリにどのように応答するかを理解する必要があります。

ネームサーバーは、解決を通じてDNSクエリに応答します。解決は、ネームサーバーが名前空間でデータファイルを見つけるプロセスです。クエリの種類に応じて、ネームサーバーはさまざまなクエリに対して異なる応答をしますが、最終的な目標は解決です。

クエリタイプ

クエリの種類は?はい、DNSクエリには複数の種類があります。しかし、最初に、DNSクエリには通常何が含まれていますか?これは、特にドメイン名に関連付けられたIPアドレスに関する情報の要求です。

  • 再帰:再帰クエリを使用すると、クエリを複数のネームサーバーに参照して解決できます。最初にクエリされたネームサーバーに目的のデータがない場合、そのネームサーバーは、目的のデータファイルを持つネームサーバーが見つかり、リゾルバーに応答を送信するまで、最も適切な次のネームサーバーにクエリを送信します。
  • 反復反復クエリでは、クエリされたネームサーバーが目的のデータまたはエラーのいずれかで応答する必要があります。応答には、要求をnextに送信するのに最も適切なネームサーバーのIPアドレスが含まれる場合があります。次に、リゾルバは別の要求をそのより適切なネームサーバーに送信できます。

必要な場合は、IPアドレスしか持っていない場合は、ドメイン名を照会することもできます。これは逆DNSルックアップと呼ばれます。

クエリが目的のデータファイルを含むネームサーバーに到達すると、クエリを解決できます。ネームサーバーには多数のデータファイルが関連付けられており、そのすべてまたは一部を使用してクエリを解決できます。

リソースレコード(RR)

これらは、ドメイン名前空間内のデータファイルです。これらのデータファイルには、特定の形式と内容があります。

最も一般的なRR:

  • 記録:これ以外のRRについて聞いたことがない場合は、それは理にかなっています。これはおそらく最もよく知られているRRであり、特定のドメインのIPアドレスが含まれています。
  • CNAMEレコード:これとAレコード以外のRRについて聞いたことがない場合は、それも意味があります。「C」は「canonical」の略で、ドメインにエイリアスを割り当てるためにAレコードの代わりに使用されます。
  • SOAレコード:このレコードには、管理者の電子メールアドレスなど、レコードに関する管理情報が含まれています。ヒント:ゾーンを管理する場合は、ここに有効なメールアドレスがあることを確認してください。そうすれば、必要に応じて他の人から連絡を受けることができます。
  • その他の重要なリソースレコード(RR)タイプは、PR、NS、SRV、およびMXです。ここでそれらについて読んでください。

キャッシングと存続時間(TTL)

ローカルネームサーバーはクエリから応答を受信すると、そのデータをキャッシュ(メモリに保存)するため、次に同じクエリを受信したときに、元のより長い解決プロセスを経ることなく、クエリに直接応答できます。

ただし、この情報がキャッシュされると、静的かつ分離されているため、古くなるリスクがあります。したがって、リソースレコードにはすべて、データをキャッシュできる期間を決定する、いわゆる存続時間(TTL)値があります。その時間がなくなると(ゼロに達すると)、ネームサーバーはレコードを削除します。

重要な注意:TTLは、リソースレコードを含むゾーンに対して権限のあるネームサーバーには適用されません。これは、そのリソースレコードをキャッシュしたネームサーバーにのみ適用されます。

クエリの1日

この記事では多くのことを取り上げてきましたが、その概念に重点を置いています。これをすべて結び付けて現実のものにするために、クエリのライフサイクルの1日(比喩的な日)を次に示します。

では、なぜ私はこれらすべてを知る必要があるのでしょうか?

DNSとIPアドレスに関連する概念に精通する理由はたくさんあります。

  • まず、それはインターネットのバックボーンであり、私たちの多くが使用し、(愛/憎しみ/あなたの名前-それ)に対する感情を発達させ、毎日当たり前のことと思っています。今日のテクノロジーとインターネットで素晴らしいことを成し遂げることができる構造に精通することが重要です。
  • 信じられないほど賢い人々は、何十年もの人生をこのようなものの構築に費やしました!彼らの貢献に感謝し、感謝しましょう。
  • 厄介な問題が解決したので、会社やチーム、または自分のビジネスのインフラストラクチャに関連するすべての責任を負う場合に備えて、DNSの概念に精通することが重要です。重要な問題が発生したときに参照のフレームを用意することで、はるかに迅速に行動し、はるかに迅速に解決策を見つけることができます。

結論

この時点で、DNSとは何か、ネームサーバーとは何かを理解し、IPアドレスに関連する技術的な概念に精通している必要があります。

多くの本がDNSの魅力的な世界について書かれ、深く掘り下げられており、学ぶべきことがたくさんあります。この記事には含まれていませんが、DNSの一部であるか、非常に関連しているトピックは次のとおりです。

  • ネームサーバーの実装
  • フォワーディング
  • (詳細)ノードラベル
  • プライマリネームサーバーとセカンダリネームサーバーの関係
  • 再送信アルゴリズム
  • 負荷分散
  • さらに、インターネットの機能に関するその他のより一般的なトピックは次のとおりです。
  • ワールドワイドウェブ
  • HTTP
  • FTP
  • 通信プロトコル層:リンク層、IP層、トランスポート層、インターネット層など。

まだ読んでいるあなたのそれらのためにそしてDNSについてもっと知りたいので、私は何よりもまず、Cricket Liuによって書かれ、O'ReillyMediaによって発行された「DNSandBIND、5thEd。」をお勧めします。それはかけがえのないものです。

また、以下にリンクされている元のRequest for Comments(RFC)を確認することをお勧めします。一次資料を読むためのポイントがあるだけでなく、それらは非常によく整理されたわかりやすいドキュメントでもあるので、この記事でそれらを引用しました。

リソース

  1. RFC 1034:ドメイン名-概念と機能
  2. RFC 1035:ドメイン名-実装と仕様
  3. RFC 1122:インターネットホストの要件-通信レイヤー
  4. Connected:InternetEncyclopediaのDNS設計目標の詳細
  5. インターネットがARPAnetから解釈、会話からどのように生まれたか
  6. O'ReillyMediaのCricketLiuによるDNSビデオコースの学習

私について少し

オレゴン州ポートランドのアーティスト兼開発者であるクロエ・タッカーです。元教育者として、私は学習と教育、またはテクノロジーとアートの交差点を絶えず探しています。Twitter @_chloetuckerで私に連絡し、chloe.devで私のウェブサイトをチェックしてください。