DNS · 1 min read · Oct 03, 2025
従来のDNSハウツー
従来のDNSハウツー
バージョン 1.0
著者: Tom Adelstein
Falko Timme
最終編集日: 2006年3月11日
Linuxシステム管理者は従来のDNSを学ぶべきです。ドメインレコードを設定するためのフロントエンドやクイックテンプレートは、サイトの管理において役立ちます。すでに存在するDNS設定に直面したとき、基本を知り、使うことに代わるものはありません。
インターネット上のユーザーの大多数はDNSについて全く知識がありません。彼らはISP接続を設定したときにその用語を見たかもしれませんが、それが自分の生活とどのように関連しているかを理解していません。簡単に言えば、DNSサーバーは、ブラウザ、メール、またはその他のインターネットアプリケーションでIPアドレスを必要とするタスクを実行するために、フレンドリーな名前を使用できるようにします。
インターネットはTCP/IPプロトコルを使用して、インターネット上のすべてを送受信します。ブラウザにGoogle.comと入力して検索を行うとき、あなたはDNSを使用しています。そうでなければ、この数値を使用しなければなりません: 64.233.187.99。各リンクをクリックして、何が得られるか見てみてください。
Google.comは、ブラウザがGoogleウェブサイトのIPアドレスを見つけるために参照するデータベース内の名前です。しかし、これはユーザーには透明です。訪れたいウェブサイトを手動で調べるためにIPアドレスのノートを保持したいですか?まあ、ドメインネームシステムがそれを自動的に行ってくれます。
これを読んでいるあなたが「そうだ、私はそれについてすでに知っている」と思っているなら、ちょっと待ってください。DNSを扱うにはかなりの知識と規律が必要です。私が知っているシステム管理者は多くのタスクをこなすことができますが、DNSを扱える人は少ないです。ほとんど例外なく、彼らは基本を理解していないために迷子になります。
インターネットのドメインネームシステムは、地球上で最大の分散データベースを構成しており、非常に巧妙です。理論的には、欠陥はありません。実際には、人々は常にそれを混乱させます。人々は、自分のデータベースの一部に正しくフォーマットされていないDNSエントリを作成したり、エラーを引き起こす固有の欠陥を持つエントリを作成したりします。
DNSレコードのインターネット調査では、エラーの発生率が72%に達することが示されています。私たちは、そのエラーの大多数が無効な委任から来ていることを知っています。無効な委任には、実際にドメインをホストしていないDNSサーバーに割り当てられたドメインが含まれます。他の原因には、ゾーンファイルの提供の失敗、リソースレコードのエラー、期限切れのドメイン登録が含まれます。
DNS用語を学ぼうとすると、それが直感的でないことがわかります。最初は全く意味がありません。多くの点で、その用語は外国語を思い出させます。理解できるようになるまで、しばらくそれを使ってみる必要があります。
LinuxはDNS機能を実行するためにBINDを使用します。他のプログラムを使用しようとするのではなく、システム管理者はBINDから始めるべきです。なぜなら、世界中のほとんどすべてのDNSサーバーがそれを実行しているからです。BINDについての歴史的なレッスンを提供するつもりはありません。このテーマはどうせあなたを眠らせるでしょう。
ですので、BINDについてすべて学びたいのであれば、ぜひどうぞ。ただし、1つの例外を除いて、DNSにはあまり役立ちません。まだBINDバージョン4を使用している人もいます。BIND 4からBIND 8または9にアップグレードしたいです。運が悪いことに、DNS設定ファイルを作成しようとすると、意味がわからなくなるでしょう。それは、多くの人がまだBIND 4を実行しているからです。
設定ファイルについて教えてください
BINDには3つのコンポーネントがあります。最初のコンポーネントはnamedまたはネームディーと呼ばれます。これはDNSのサーバー側を実行するデーモンです。それは少し後で意味を持つでしょう。
BINDの2番目のコンポーネントはリゾルバライブラリと呼ばれます。人々はリゾルバをBINDのクライアント側と考えます。リゾルバコードは、フレンドリーな名前をIPアドレスに変換しようとするためにDNSサーバーにクエリを行います。このコンポーネントはresolv.confファイルを使用します。それはUNIXの略語のように聞こえますね。そうであるべきです。
BINDの3番目のコンポーネントは、DNSサーバーをテストするためのツールを提供します。私たちはそれらをツールと呼びますが、実際にはdigのようなコマンドラインユーティリティのセットです。コンソールに行き、dig yahoo.comと入力して、何が起こるか見てみてください。後でこれを見ていきます。
DNSシステムにおける私の責任は何ですか?
前述のように、DNSは分散データベースです。ドメインを登録するために料金を支払うとき、あなたが答える質問の1つは、あなたのネームサーバーに関するものです。2つをリストする必要があり、それらはDNSシステムに登録されている必要があります。
ドメインネームシステムデータベースには3つのレベルがあります。最初のサーバー群を「ルート」サーバーと呼びます。2番目はトップレベルドメイン(TLD)と呼びます。リゾルバがウェブサイトのアドレスを見つける必要があるとき、クエリを行います。
例えば、Google.comを見つけたいとしましょう。リゾルバはルートサーバーにGoogle.comのIPを特定するように尋ねます。ルートサーバーは「わからないが、答えを見つける場所を知っている」と返答します。COMのTLDサーバーから始めます。
それで、ルートはあなたのクエリをCOMサーバーに送ります。「わからないが、その情報を持っているネームサーバーを知っている」と言います。それは64.233.167.99のアドレスとns1.google.comという名前を持っています。だから、そのアドレスに行けば、google.comのウェブサイトアドレスを教えてくれます。
リゾルバはns1.google.comから情報を受け取り、IPアドレスを返します。もしGoogleのネームサーバーがリゾルバに正しい名前を与えたなら、ウェブページが得られます。
移動した経路は図1のようになります。

図1 - ルートからあなたのドメインへ。
図1の左上には、ルートの注釈が付けられたサーバーのセットが描かれています。DNSの用語では、これらのサーバーはDNSパスの始まりを表します。これらはピリオドまたはドット(”.”)で表されます。設定ファイルでは、IPアドレスと名前のマッピングはピリオドで終わります。数分後にこれらのファイルのいくつかを見てみると、これがより明確になります。
ルートサーバーは分散DNSデータベースの最上部にあります。彼らはトップレベルドメイン(TLD)に関する情報を持っています。TLDにはcom, net, org, mil, gov, eduなどが含まれます。ドメイン名を使用する契約を結ぶとき、どのTLDを選択するかを決定します。私の場合、centralsoft.orgという名前空間にドメインがあります。
ネームサーバーを登録するとき、server1.centralsoft.orgとns0.centralsoft.orgの名前を登録エージェントに提供しました。orgのTLDサーバーには私のネームサーバーがあります。orgサーバーはcentralsoftに関する情報をどこで見つけるべきかを知っています。
登録時に、私はエージェントにIPアドレスとフレンドリーな名前のデータベースを維持し、それらを相互にマッピングする責任を負うことを伝えました。したがって、私たちは合意を結び、ドメインネームシステムは「OK、今あなたはcentralsoft.orgのデータに対する権限を持っています。誰かがインターネット上であなたが提供するサービスを見つけたいとき、私たちは彼らをあなたに指し示します。」と言いました。
したがって、今私はあなたのクエリに答え、「もちろん、私のウェブページを見たい場合や、私のユーザーの1人にメールを送信したい場合、ここで見つけることができます。名前を尋ねられたら、IPアドレスを教えます。なぜなら、あなたがTCP/IPを使用するプロトコルを持っていることを知っているからで、名前を指定してもアドレスが必要であることを理解しているからです。
新しい投稿を受信箱で受け取る
スパムはありません。いつでも購読を解除できます。