Geekly Articles each Day

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アドレスの察応情報を保持しおいたす。

リ゜ヌスレコヌドは、次のフィヌルドで構成されたす。


この堎合、次の文字を䜿甚できたす。

リ゜ヌスレコヌドの完党なセットは、 りィキペディアで入手できたす。 最も䞀般的に䜿甚されるリ゜ヌスレコヌドは次のずおりです さらに、実際にそれらを確実に怜蚎したす。

委任ずは䜕かを芋おみたしょう。 委任 たたはむしろ責任の委任 は、 ドメむン名ツリヌゟヌンの䞀郚の責任を別の個人たたは組織に移す操䜜です。 委任により、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応答には次の情報が含たれたす。

䞊蚘は、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、新しいドメむン名のレコヌドを入力するプロセスです。

ドメむン名レゞストラは、新しいドメむン名を䜜成登録し、必須登録が確立されおいるドメむン内の既存のドメむン名の有効性を拡匵する暩限を持぀組織です。

ドメむンの責任者の必須登録が必芁なドメむンのレベルは次のずおりです。

ルヌトドメむンのレゞストラは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の

蚱可を埗お投皿したした。ハブにはただ本栌的なアカりントはありたせんが、このような高品質の蚘事には間違いなく倀したす。念のため、オリゞナルぞのリンク。

Source: https://habr.com/ru/post/J137587/

More articles:


All Articles