BIND DNSサーバー（理論）

DNSの主な目的は、ドメイン名をIPアドレスにマッピングすること、およびその逆-IPからDNSにマッピングすることです。 この記事では、BIND DNSサーバー （以前はBerkeleyインターネットネームドメイン、Berkeleyインターネットネームデーモン）の動作を最も一般的な（単語を恐れずに）考えました。 BINDはすべてのUNIXディストリビューションに含まれています。 BINDの基礎は名前付きデーモンです。このデーモンは、作業と一部のTCP / 53要求にUDP / 53ポートを使用します。

ドメインネームシステムの概念

歴史的に、ドメインネームシステムの出現前は、IPのシンボル名を解決するツールの役割は/ etc / hostsファイルによって実行されていました。 しかし、グローバルネットワーク内のホスト数の増加に伴い、すべてのホスト上の名前のデータベースの追跡と保守は非現実的に難しくなっています。 その結果、ドメインゾーンの階層型分散システムであるDNSを思い付きました。 図のドメインネームシステムの構造を見てみましょう。





DNSドメイン構造は、ノード、ゾーン、ドメイン、サブドメイン、および以下で説明する他の要素で構成されるツリー階層です。 ドメイン構造の「上部」はルートゾーンです。 ルートゾーン設定は、世界中にあるさまざまなサーバー/ミラー上にあり、ルートゾーンのすべてのサーバーに関する情報と、第1レベルドメイン （ru、net、orgなど）の情報が含まれています。 ルートゾーンサーバーに関する情報は、このルートサーバーサイトにあります。 ルートゾーンの設定は常にここで利用できます 。 ルートゾーンサーバーは、要求を処理して応答し、第1レベルドメインに関する情報のみを提供します（つまり、すべての要求に非再帰的に応答します）。 そのため、ワードゾーンは何度も繰り返されています。 この用語について説明します。



ゾーンは、 DNSサーバー上のユニットとしてホストされるドメインネームシステムツリーの一部です。 ゾーンは、理解を深めるために、 「責任のゾーン」と呼ぶことができます。 ツリーの一部を別のゾーンに分離する目的は 、このブランチの責任（ 委任 ）を別の個人または組織に移すことです。 図では、ゾーンの例が青のグラデーションで強調表示されています（ゾーン名 。、ゾーンk-max.name 。すべての従属リソースの場合、すべての従属サブドメインとリソースのwww.openoffice.org ）。 図ではすべてのゾーンが強調表示されているわけではありませんが、一般的な理解とプレゼンテーションのためにいくつかのゾーンのみが強調表示されています。 各ゾーンには、責任のあるゾーンに関するすべての情報を格納する少なくとも1つの権限のあるDNSサーバーがあります 。



ドメインは、DNS名前ツリー内の名前付きブランチまたはサブツリーです。つまり、すべての従属ノードを含む特定のノードです。 Linux Network Administrators Guideからの次の引用は、ゾーンとドメインの違いの全体像を示しています。

したがって、名前空間はゾーン（ゾーン）に分割され、各ゾーンは独自のドメインによって管理されます。 ゾーンとドメインの違いに注意してください：groucho.eduドメインはGroucho Marx Universityのすべてのマシンに影響を与えますが、groucho.eduゾーンには数学センターなどのコンピューターセンターで直接動作するホストのみが含まれます。 。 物理学部門のホストは別のゾーン、すなわちphysics.groucho.eduに属します。

DNS階層の各ノードは、その親からドットで区切られています。 Linuxファイルシステムを例にとると、ドメインシステムの構造は似ていますが、ファイルシステムの区切り文字はスラッシュであり、DNSではピリオドです。 また、Linuxファイルシステムのパスとは異なり、 DNSアドレスは右から左（ルートドメインからホスト名）に読み取られます。 ドメイン名はドット （ ルートドメイン ）で始まり 、最初、2番目、および必要に応じて3番目などのドメインを通過します。 レベルとホスト名で終了します。 T.O. ドメイン名 はDNS階層構造を完全に反映します 。 多くの場合（私は言う-いつも日常生活で）、ドメイン名の最後のドット（ルートドメインの指定）は省略されます（つまり、ブラウザーではk-max.nam eではなく、k-max.nam eと入力します）。 そのため、ドメイン名の構造を調べた後、 FQDNの概念に静かにアプローチしました。



FQDN （ Eng。Fully Qualifed Domain Name ）は、ドメイン名を一意に識別するドメイン名であり、ルートを含む DNS階層のすべての親ドメインの名前を含みます。 ファイルシステム内の絶対パスに特有の類似物。 例としてドメイン名mail.k-max.nameを使用して上記を見てみましょう。

  mail.k-max.name。
  |  |  |  |  |
  |  |  |  |  +-ルートドメイン
  |  |  |  + ---第1レベルドメイン
  |  |  + ------ FQDNドメイン/パーツを分離するポイント
  |  + ---------第2レベルドメイン
  + ---------------サブドメイン/第3レベルドメイン、おそらく-ホスト名 

FQDNと通常のドメイン（ 非FQDN ）名の違いは、第2、第3（など）レベルのドメインに名前を付けるときに表示されます。 FQDNを取得するには、ドメイン名に上位ドメインを指定する必要があります（たとえば、mailはドメイン名ですが、FQDN名はmail.k-max.nameのようになります）。 最大FQDNは255バイトで、ドメイン名ごとに63バイトの制限があります。



要するに、 サブドメインはサブドメインです。 概して、インターネット上のすべてのドメインは、ルートを除いて従属しています。 たとえば、k-maxドメインは名前ドメインのサブドメインであり、名前はルートドメインのサブドメインです。



したがって、上の図では、 ルートドメインを調べました。階層の次は、最初の/トップレベルのドメインであり、 TLDであり 、 トップレベルドメインでもあります。 これらのドメインには、 国別ドメイン （ ru。 、 Ua。 、など）および共通ドメイン （ com。 、 Net。 、など）が含まれます。 DNSで公開されていないが、プログラムで使用される特殊なドメインもあります （.onionドメインは、匿名のTorネットワークで使用され、このネットワーク上の隠されたサービスをインターセプトし、ルーティングします）。 まだいわゆる RFC 2606（ 予約済みトップレベルDNS名 ）で定義されている予約済みドメイン名は、テスト用だけでなく、例（ドキュメントなど）として使用されるべきドメイン名を定義しています。 このような名前には、たとえば、example.com、example.org、example.net、test、invalidなどが含まれます。階層の下には、ご覧のとおり、第3レベルのドメインなどがあります。 ドメイン階層は、対応するリソースレコードまたはホストレコードによって指定されるホスト名で終了します 。

リソースレコード

リソースレコードは、最終的にはDNSが存在するためのものです。 リソースレコードは、DNSに情報を保存および送信するための単位です。 このような各レコードは、DNSの名前とサービス 情報の対応 情報 、たとえば、ドメイン名とIPアドレスの対応情報を保持しています。

リソースレコードは、次のフィールドで構成されます。

• 名前（NAME） -このリソースレコードがアタッチされるか、「所属」するドメイン名、またはIPアドレス。 このフィールドがない場合、リソースレコードは前のレコードから継承されます。
• Time To Live（ TTL） -文字通りレコードの「ライフタイム」、レコードがDNSキャッシュに保存された時間（指定された時間後にレコードが削除されます）、このフィールドは個々のリソースレコードで示されない場合がありますが、ゾーンファイルの先頭で示され、すべてのレコードに継承されます。
• クラス（CLASS） -ネットワークのタイプを定義します（INはケースの99.99％で使用されます（インターネットを意味します）。このフィールドは、DNSがTCP / IPを除く他のタイプのネットワークで動作できることを前提に作成されました）
• type（TYPE） -レコードタイプの構文とレコードの目的
• データ（DATA） -さまざまな情報。形式と構文はタイプによって決まります。

この場合、次の文字を使用できます。

• ; -コメントを入力してください
• ＃-コメントも導入（BINDバージョン4.9のみ）
• @-現在のドメイン名
• （）-データが複数行にまたがることを許可する
• *-メタキャラクター（名前フィールドのみ）

リソースレコードの完全なセットは、 ウィキペディアで入手できます。 最も一般的に使用されるリソースレコードは次のとおりです （さらに、実際にそれらを確実に検討します）。

• -（ アドレスレコード ）は、ホスト名（ドメイン名）をIPv4アドレスにマップします。 マシンのネットワークインターフェイスごとに1つのAレコードを作成する必要があります。 たとえば、次のエントリはドメイン名k-max.nameを表示します。 IPv4では、ホストアドレスは81.177.139.65です （ NAMEフィールドはk-max.nameです。TTLフィールドは86400 、 CLASSフィールドはIN 、 DATAフィールドは81.177.139.65です ）：
  
  

    k-max.name。  86400 IN A 81.177.139.65 

• AAAA （ IPv6アドレスレコード ）はAに似ていますが、IPv6用です。
• CNAME （ 正規名レコード/エイリアス） -（別の名前にリダイレクトするために）実名のエイリアスを表示します。たとえば、次のレコードはホストwww.k-max.nameの ftpエイリアスを設定します。
  
  

    ftp 86400 IN CNAME www.k-max.name。 

• MX （ メール交換 ）-ドメイン宛のメールを配信するホストを示します。 同時に、NAMEフィールドは宛先ドメインを示し、 TTL 、 CLASS フィールドは標準値、 TYPEフィールドはMX値を、DATAフィールドは優先順位を示し、スペースを使用して、 メールの受信を担当するホストのドメイン名を示します 。 たとえば、次のエントリは、k-max.nameドメインの場合、最初にmx.k-max.nameにメールを送信し、mx.k-max.nameに問題がある場合はmx2.k-max.nameにメールを送信することを示しています。 同時に、両方のMXホストに対応するAレコードが必要です。
  
  

    k-max.name。  17790 IN MX 10 mx.k-max.name。
   k-max.name。  17790 IN MX 20 mx2.k-max.name。 

• NS （ ネームサーバー/ネームサーバー ）は、このドメインにサービスを提供するDNSサーバーを指します。 むしろ、それは言われます-このドメインが委任されるサーバーを示します。 NSレコードが現在のゾーンのネームサーバーを参照している場合、ドメインネームシステムは実質的にそれらを使用しません。 ゾーンがどのように構成されているか、どのマシンがネームサービスを提供する上で重要な役割を果たすかを簡単に説明します。 たとえば、名前ゾーン。 次のNSを提供します。
  
  

   名前。  5772 IN NS l6.nstld.com。
  名前。  5772 IN NS m6.nstld.com
  名前。  NS c6.nstld.comの5772。
  名前。  NS j6.nstld.comの5772
   ...... 

  
  
  k-max.nameゾーンは以下によって提供されます：
  
  

    k-max.name。  1577 IN NSns2.jino.ru。
   k-max.name。  1577 IN NSns1.jino.ru。 

• PTR （ ポインター ）-IPアドレスをドメイン名にマップします（このタイプのレコードについては、以下の名前の逆変換に関するセクションで説明します）。
• SOA （ 権限の開始 ）-ゾーンの基本/初期設定について説明します 。つまり、 このサーバーの責任のゾーンを定義します 。 各ゾーンには、SOAレコードが1つだけ存在し、最初のレコードでなければなりません。 Nameフィールドには、ドメイン/ゾーン名 、 TTLフィールド、CLASS-標準値、 TYPEフィールドはSOA値、 DATAフィールドはスペースで区切られたいくつかの値で構成されます。 プライマリDNS（プライマリネームサーバー）の名前 、ゾーン管理者のアドレス、 ゾーンファイルのシリアル番号（シリアル番号） ゾーンファイルに変更を加えるたびに、この値を増やす必要があります。これは、ゾーンが変更され、ゾーンを更新する必要があることをセカンダリサーバーに示します。 次はタイマー値です （ 更新 -セカンダリサーバーがプライマリサーバーをポーリングしてゾーンのシリアル番号が増加したかどうかを確認する頻度を示します。 再試行 -ポーリング試行が失敗した後のタイムアウト、 期限切れ -セカンダリサーバーが情報を使用できる最大時間受信したゾーン、 最小TTL-データがセカンダリサーバーのキャッシュに残る最小時間）。 次の例は、2つの同一のSOAレコードを示しています（2番目のレコードは数行で記述されています）が、値は同じであり、2番目のフォーマットはその構造により理解しやすいです。
  
  

    k-max.name。  86400 IN SOAns1.jino.ru。  hostmaster.jino.ru。  2011032003 28800 7200 604800 86400
   k-max.name。  86400 IN SOAns1.jino.ru。  hostmaster.jino.ru。  （
                                                     2011032003; シリアル（シリアル番号）
                                                     28800; リフレッシュ
                                                     7200; 再試行（再試行）
                                                     604800; 期限切れ（有効期限）
                                                     86400）; 最小TTL 

• SRV （ サーバー選択 ）-このドメイン内の特定のサービス（JabberやActive Directoryなど）の操作を提供するサーバーを示します。

委任とは何かを見てみましょう。 委任 （またはむしろ責任の委任 ）は、 ドメイン名ツリー（ゾーン）の一部の責任を別の個人または組織に移す操作です。 委任により、DNSでは、ゾーンの管理とストレージの配布が提供されます。 技術的には、委任では、ツリーの任意の部分を別のゾーンに割り当て、このゾーンを別の個人または組織に属するDNSサーバーに配置します。 同時に、「スティッキング」リソースレコード（NSおよびA）は、子ゾーンの信頼できるDNSサーバーへのポインターを含む親ゾーンに含まれ、子ゾーンに関連する他のすべての情報は既に子ゾーンのDNSサーバーに格納されています。 たとえば、図では、 ルートドメインはTLD、TLDを担当するサーバーに権限を委任し、次にゾーンを管理する権限を委任します-第2レベルのサーバー、場合によってはチェーンが終了しますが、委任は4レベルまたは5レベルにまで及ぶことがあります。



理解を深めるために、例を挙げます。 k-max.nameサブドメインの管理を別の人（私の場合はホスト）に委任すると、（親名に関係なく）ネームスペースの残りの部分から独立して管理される新しいゾーンが作成されます。 権限の委任後のゾーンk-max.nameは、名前に依存しなくなりました。 また、 * .k-max.nameで終わるドメイン名（または、任意の名前）を含めることができます。 一方、 名前ゾーン。 * .name。で終わるドメイン名のみが含まれますが、k-max.nameやa-lab.nameなど、このゾーンの委任されたドメイン名には含まれません。 k-max.nameは mail.k-max.name 、 ftp.k-max.nameなどの名前のサブドメインに分割でき 、これらのサブドメインの一部は個別のゾーンに割り当てることができ、これらのゾーンの責任も委任することができます。 ftp.k-max.nameが独立ゾーンになる場合、k-max.nameゾーンには* .ftp.k-max.nameで終わるドメインレコードが含まれません。



T.O. 責任の委任後 、委任ゾーンによって保存される情報には、委任されたサブドメインとそのホストリソースレコードに関する情報は含まれなくなりますが、委任されたサブドメインに対して権限のあるネームサーバーに関する情報は保存されます 。 これらは「貼り付け」メモであり、既に上で述べました。 この場合、委任されたサブドメインに属するアドレスに関する情報を使用して親ドメインのDNSサーバーが要求されると、関連情報を所有するDNSサーバーのリストが応答として提供されます。

DNSサーバー

上記では、リソースレコードの種類を検討する際に、 プライマリサーバーとセカンダリサーバーについて言及しました。 これらのタイプに加えて、別のタイプ- キャッシングがあります。



メインDNSサーバー （ プライマリ 、 マスター 、 プライマリ ）は、 権限のあるサーバー （ 権限のあるサーバーと呼ばれることもありますが、これをより正確に呼び出す方法はわかりません）で、システム管理者と共にゾーンデータファイルのメインコピーを保存します 。



セカンダリサーバーも権限がありますが、メインゾーンファイルをプライマリサーバーからコピーします 。 メインとセカンダリ の違いは、 メインの設定がゾーン設定ファイルから情報をダウンロードすることと、セカンダリの設定がメインサーバーからゾーン設定をダウンロード（受信）することだけです。 セカンダリDNSは、別のセカンダリサーバーからデータを受信できます。 権限のあるサーバーが担当するゾーン内のホストに対する要求は、最終的にこれらのサーバー（プライマリまたはセカンダリ）のいずれかに転送されます。 必要な数のセカンダリサーバーを設定できます。 設定に応じて、 メインサーバーはゾーンの変更に関するセカンダリシグナルを送信できますが、 セカンダリ サーバーはシグナルを受信するとコピーを作成します。 このアクションは、 ゾーン転送と呼ばれます。 ゾーンをコピーするメカニズムには、 フルコピー（AXFR）とゾーンの増分コピー（IXFR）の 2つがあります。



キャッシュサーバーは 認証されてい ません 。これらのサーバーはメモリ（キャッシュ）に保存され、以前のリクエストに応答します。このサーバーがリクエストを受信した場合、最初にキャッシュ内の情報を確認し、キャッシュに必要な応答がない場合、上流のDNSサーバーにリクエストを送信します。



DNSをstelsモード（いわゆる不可視）で構成することもできます。このサーバーに関する情報は直接クエリを使用して取得できません。 これは、安全な環境でプライマリサーバーを整理し、ゾーンに対する攻撃からゾーンを保護するのに役立ちます。

DNSクライアント（リゾルバー）

エンドマシンのプログラムは、DNSクエリを送信する場所と形式をどのように知っていますか？ 彼らはこれを知りません クライアントアプリケーションは、Resolverライブラリを使用して名前とIPアドレスを解決します。 これは特別なアプリケーションではなく、システムの機能（カーネル）です。 T.O. アプリケーションはシステムコール gethostbyname（2）およびgethostbyaddr（2）を送信し、カーネルは/etc/nsswitch.confファイルの設定に基づいて、次に進むべき方法を決定します。 このファイルは、どのサービス（ / etc / hostsまたはDNS ファイル ）および使用する順序を決定します。 以前のバージョンのLinuxライブラリlibcでは、 /etc/host.confファイルが使用されていました。 興味のあるファイルの断片を次に示します。

 ルート@ DNS：〜＃cat /etc/nsswitch.conf
 ......
ホスト：ファイルdns
ネットワーク：ファイル 

このフラグメントの2行は、最初にhostsファイルからDNSによってホスト名をIP（ hosts：files dns line ）に変換し、/ etc / networkファイルを使用してネットワーク名をIP（ networks：files line ）に変換するようカーネルに指示します。 NISまたはnispluパラメーターも使用 できます。 これらのパラメーターは、 ネットワーク情報システム（NIS）を使用してアドレスを検索するかどうかを決定します。 サービスがリストされる順序によって、ポーリングの順序が決まります。

/etc/nsswitch.confに従って、要求がDNSによって送信された場合、使用するDNSサーバーを決定する/etc/resolv.confファイルの設定が使用されます。 /etc/resolv.confファイルの典型的な例を次に示します。

 ルート@ DNS：〜＃cat /etc/resolv.conf
ネームサーバー192.168.1.1
ネームサーバー192.168.1.2
ドメインexamle.com 

nameserverディレクティブは、リゾルバの再帰クエリを実行するドメインネームサーバーのアドレスを定義します。 このファイルでは、最初に192.168.1.1 という名前を使用し 、最初の要求が192.168.1.2を処理できなかった場合に名前を使用することが示されています 。 3つ以上のネームサーバーパラメータを使用しないことをお勧めします 。 ネームサーバーオプションが指定されていない場合、リゾルバーはローカルホスト上のサーバーへの接続を試みます。 domainパラメーターは、DNSがホスト名を見つけられない場合に置換されるデフォルトのドメイン名を指定します。 ホスト名を検索および解決する追加のドメインを設定する検索オプションもあります 。 検索オプションとドメインオプションを一緒に使用することはできません。



DNSサーバー上のキャッシュに加えて、 インターネットブラウザーの キャッシュ 、 リゾルバーキャッシュがあります。 ウィキペディアはかなり透明な画像を提供しています。

DNSクエリ

DNSでは次のタイプのクエリを使用できます： 反復 （別名direct ）、 reverseおよびrecursive 。



反復 （ 直接 、 非再帰 ） 要求は、ドメイン名をDNSサーバーに送信し、このドメインのIPアドレスまたはこのドメインに対して権限のあるDNSサーバーの名前を返すように要求します。 ただし、DNSサーバーは応答のために他のサーバーをポーリングしません。 これがルートサーバーとTLDサーバーの機能です。



再帰クエリは、ドメイン名をDNSサーバーに送信し、要求されたドメインのIPアドレスを返すように要求します。 この場合、サーバーは他のDNSサーバーにアクセスできます。



リターンリクエストはIPを送信し、ドメイン名を返すように要求します。



DNSサーバーは、 反復クエリに応答する必要があります 。 再帰クエリに応答するようにDNSを構成することは可能です 。 DNSが再帰クエリに応答するように設定されていない場合、DNSはそれらを反復として扱います。



通常 プロバイダーの問題 ローカルネットワークにDNSサーバーがあり、再帰クエリを処理します。また、ほとんどの場合、クエリキャッシュ用に構成されているため、トラフィックが節約され、ネットワーク負荷が軽減されます。 クライアントとDNSサーバーの相互作用スキームは、次の図で表すことができます。



手順に示されているものを見てみましょう。

1. クライアント （ブラウザー、メールプログラム、またはその他のアプリケーション） は リゾルバーに要求を送信し ます。リゾルバーは、これらの構成に基づいて構成済みネームサーバーのアドレスを決定します。
2. リゾルバ は、指定されたネームサーバーに 要求を送信し ます 。
3. ネームサーバーはこの再帰的リクエストを受け入れ、 ドメインや名前ゾーンに関する情報さえも持たず、ルートゾーンを担当 する サーバーに 再帰的（または設定によっては非再帰的）リクエストを 送信します 。
4. ルートゾーンサーバーは再帰的な要求を処理しません;その結果、この要求を繰り返し処理し、名前ゾーンに対して権限のあるサーバーの名前とアドレスを返します。
5. サーバーは、名前のゾーンのレベルの降順で後続のゾーンの権限のあるサーバーに問い合わせを続けます
6. 満足のいく答えを受け取るまで、これらの手順は、ドメイン名の長さに応じて、より多くなる場合があります
7. ドメイン名のネスト。
8. その結果、サーバーはネームサーバーから必要な応答を受信します。ネームサーバーは、ホストに関する必要なリソースレコードを保存します。
9. サーバー プロバイダー LANは、要求されたデータをクライアントリゾルバーに返します。

通常、ステップ数は最小限に削減されます。 リクエストを渡す途中で、キャッシュに必要な情報を保存するキャッシュサーバーがあります。 このスキームでは、問題が発生する可能性があります。リゾルバから再帰クエリを受信したローカルDNSサーバーは、信頼できるもののリストからDNSサーバーをどのように選択しますか？ インターネットには多くのルートDNSサーバーがありますが、DNSサーバーはどのルートサーバーにリクエストを送信しますか？



この問題を解決するために、 BIND DNSサーバーはラウンド トリップ 時間 （ RTT ）と呼ばれるメトリックを使用して、権限のあるDNSサーバーから1つのゾーンを選択します。 RTTは、リモートサーバーからの要求への応答が到着する遅延を決定します。 要求がリモートサーバーに送信されるたびに、 BIND DNSサーバーは内部タイマーを開始します 。 応答が受信されるとタイマーが停止し、ローカルサーバーによってメトリックがコミットされます。 複数の権限のあるサーバーのいずれかを選択する必要がある場合、選択はRTTが最も低いサーバーになります。



BINDが最初に任意のサーバーに要求を送信し、 それから応答を受信する前に、リモートサーバーには、測定に基づいて取得された他のすべてよりも小さいランダムなRTT値が割り当てられます。 したがって、 DNS BINDは 、メトリックに基づいて優先サーバーの選択を開始する前に、特定のゾーンのすべての権限のあるサーバーをランダムにポーリングすることが保証されています。

DNSサーバーの応答

DNS応答には次の種類があります。

• 信頼できる応答は、ゾーンを担当するサーバーから送信されます。
• 権限のない応答（権限のない応答）は、（キャッシュからの）ゾーンを担当していないサーバーから送信されます。

通常、DNS応答には次の情報が含まれます。

• ヘッダーレコード -リクエストに関するサービス情報。
• 要求レコード -送信された要求を繰り返します。
• 実際、 答えを記録することは答えそのものです。
• 権限サーバーレコード -現在の要求の情報を格納する権限のあるサーバーに関する情報。
• 追加情報 -NSサーバーのアドレスなどの追加レコード。

上記は、digユーティリティによって明確に確認されています。

 ルート@ DNS：〜＃ya.ruを掘る
 ;  << >> DiG 9.7.3 << >> ya.ru（ヘッダーセクション）
 ;; グローバルオプション：+ cmd
 ;; 答えを得ました：
 ;;  ->>ヘッダー<<-オペコード：クエリ、ステータス：NOERROR、id：53499
 ;; フラグ：qr rd ra; クエリ：1、回答：7、権限：2、追加：3

 ;; 質問セクション：（クエリセクション）
 ;ya.ru。 で

 ;; 回答セクション：（応答セクション）
やる  4813 IN A 87.250.250.203
やる  4813 IN A 87.250.251.3
やる  4813 IN A 93.158.134.3
やる  4813 IN A 93.158.134.203
やる  4813 IN A 213.180.204.3
やる  4813 IN A 77.88.21.3
やる  4813 IN A 87.250.250.3

 ;; 権限セクション：（権限のあるサーバー）
やる  4813 IN NS ns1.yandex.ru。
やる  4813 IN NS ns5.yandex.ru。

 ;; 追加セクション：（追加情報-権限のあるネームサーバーのアドレス）
 ns5.yandex.ru。  345565 IN A 213.180.204.1
 ns1.yandex.ru。  345565 IN A 213.180.193.1
 ns1.yandex.ru。  3565 IN AAAA 2a02：6b8 :: 1

 ;; クエリ時間：7ミリ秒
 ;; サーバー：192.168.1.1＃53（192.168.1.1）
 ;; いつ：7月2日（土）23:02:45 2011
 ;;  MSGサイズrcvd：238 

名前の逆変換

DNSは主にドメイン名をIPアドレスに変換するために使用されますが、 逆名変換または逆 マッピングと呼ばれる逆プロセスを実行することもできます。 なぜなら 直接DNSデータベースのレコードはドメイン名によって階層構造になっており、 DNSはそのようなデータベースのIPアドレスで効率的に検索できません。 DNSへの逆変換には、特別なin-addr.arpaドメインが使用されます。 [名前]フィールドのこのドメインのリソースレコードには、[タイプ]フィールド -PTRおよび[データ]フィールド -このIPに対応するFQDN名の IPアドレスが含まれています。



この図は、 arpaドメインの構造を示しています。 ここではすべてがはっきりしていると思います。 ドメインarpa。 2つのサブドメインin-addrおよびip6があり、それぞれIPv4およびIPv6アドレスを担当します 。 ドメインin-addr.arpa。 から* .0.in-addr.arpa。 before * .255.in-addr.arpa。 各サブドメインには256個のサブドメインもあります。



不要な通信（スパム）の量を減らすために、多くのメールサーバーは、送信元のホストのPTRレコードを確認できます。 この場合、IPアドレスのPTRレコードは、SMTPセッション中に表示される送信メールサーバーの名前と一致する必要があります。



示されている図は、コマンドによって表すことができます。

  [ルート@ DNS〜]＃www.ruを掘る
 ...
 ;; 質問セクション：
 ; www.ru IN A

 ;; 回答セクション：
 www.ru 52119 IN A 194.87.0.50
 ...
 [ルート@ DNS〜]＃dig -x 194.87.0.50
 ...
 ;; 質問セクション：
 ; 50.0.87.194.in-addr.arpa。  PTRで

 ;; 回答セクション：
 50.0.87.194.in-addr.arpa。  30385 IN PTR www.ru
 .... 

同時に、dig -x 194.87.0.50コマンドは、dig 50.0.87.194.in-addr.arpa。、つまり* .in-addr.arpaサブドメインのエントリとしてより正確に表現されます。 いわゆる逆表記（または逆形式）で表されます。つまり、IP 194.87.0.50を持つホストは、FQDN 50.0.87.194.in-addr.arpa。を持つPTRレコードを持ち、これはwww.ruドメインを指します。ほとんどの場合、インターネットプロバイダーが逆引きゾーンとその編集を担当していることに注意してください。



約束どおり、 www.ruマシンの上記のAレコードに対応するIN-ADDR.ARPAドメインのPTRリソースレコードについて説明しています。 次のようになります。

  50.0.87.194 IN PTR www.ru 

名前50.0.87.194はピリオドで終わっていないため、相対的です。 質問：何に関して相対的？ 「 www.ru 」とはまったく関係ありません。 このエントリをFQDNにするには、デフォルトドメインの名前を「IN-ADDR.ARPA」にする必要があります。 これは、ゾーンのデフォルトドメイン名がIN-ADDR.ARPAである別のファイルにPTRレコードを配置することで実現できます。 （名前付きデーモンブートストラップファイルで指定）、または$ ORIGINディレクティブを使用してこのドメインを変更することにより。 デフォルトのドメインが0.87.194.IN-ADDR.ARPA。として定義されている場合、エントリは次のように表すことができます。

  80 IN PTR www.ru 

ドメイン名登録

一言で言えば、ドメイン名の登録の問題に触れたいと思います。



ドメイン登録は、クライアントがどのDNSサーバーをサブドメインに委任する必要があるかをレジストラに通知し、またレジストラに連絡先と請求情報を提供するアクションです。レジストラは、情報を適切なレジストリに転送します。ほとんどの場合、これは、レジストリに最初のレベルのゾーン（つまり、ru、comなどのゾーンのTLD）、新しいドメイン名のレコードを入力するプロセスです。



ドメイン名レジストラは、新しいドメイン名を作成（登録）し、必須登録が確立されているドメイン内の既存のドメイン名の有効性を拡張する権限を持つ組織です。



ドメインの責任者の必須登録が必要なドメインのレベルは次のとおりです。

• ルートドメイン
• すべての第1レベルドメイン（TLD）
• いくつかの第2レベルドメイン（たとえば、com.ruまたはco.uk）

ルートドメインのレジストラはICANNです。セカンドレベルゾーン（.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...）でドメインレジストラーになるには、ICANN認定を取得する必要があります。



国際（gTLD-com。、Orgなど）ドメインの登録規則は、ICANNによって確立されます。国内（ccTLD-ru、usなど）ドメインの登録規則は、それぞれのレジストラおよび/または当局によって確立されます。たとえば、.ru、.rfドメインのすべてのレジストラの統一規則は、国内インターネットドメインの調整センターによって設定されます。多くのドメイン（ruを含む）では、レジストラだけがレジストラではありません。レジストラが複数ある場合は、すべてのレジストラで単一の（集中型または分散型）データベースを使用して競合を排除し、ドメイン名の一意性を確保する必要があります。



ほとんどの場合、ドメイン登録サービスは支払われ、登録の価格と条件はレジストラによって決定されます。ドメインを登録するには、無料の名前を選択し、レジストラのいずれかに登録するためのアプリケーション（nic.ruなど）を送信する必要があります。サービスの提供に対して支払います。登録を確認した後、レジストラインターフェイスでDNSサーバーを定義（委任）する必要があります。ほとんどの場合、それはホストのDNSになります。



記事の最後に、第2レベルドメインが第1レベルドメイン名と呼ばれることもあり、ルートドメインの値を「省略」し、ルートドメインのTLDドメインを取得するようなマーケティング上のニュアンスについても言及します。



また、ドメインアドレスとIPアドレスは同一ではないことに注意してください。単一のIPアドレスには多くの名前を付けることができます。これにより、1台のコンピューターで多くのWebサイトをサポートできます（共有ホスティングと呼ばれます）逆もまた真です-複数のIPアドレスを単一の名前に関連付けることができます。これにより、負荷分散を作成できます。

まとめ

したがって、本日の記事では、ドメインネームシステムの動作をできるだけ明確に説明しようとしました。私はそれをしたと思います。DNSデータベースの階層構造を調べ、クライアントとDNSサーバー間のやり取りのプロセス、およびDNSサーバーの種類を調べました。次の記事では、LinuxにBIND DNSサーバーをインストールして構成する際の実際的な問題について説明します。私はあなたのコメントに喜んでいるでしょう。

他に読むもの：

man（5）リゾルバ：http

://www.opennet.ru/man.shtml ? topic = resolver &category = 5 &russian = 0 man（3）gethostbyname：http : //www.opennet.ru/cgi-bin/opennet/man .cgiのトピック=のgethostbyname＆カテゴリ= 3？

Linuxネットワーク管理者ガイドレビューv2のロシア語：ダウンロード。

RFC882、1035、1183 mcsim85の



許可を得て投稿しました。ハブにはまだ本格的なアカウントはありませんが、このような高品質の記事には間違いなく値します。念のため、オリジナルへのリンク。