前書き
DNS、またはドメインネームシステムは、多くの場合、Webサイトとサーバーの構成方法を学習するときに適切なコンポーネントを取得するのが困難です。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。
このガイドでは、Bind9 DNSサーバーをUbuntu 14.04マシンに権限のある専用DNSサーバーとしてインストールおよび構成する方法について説明します。 これらの2つのバインドサーバーを、プライマリとセカンダリの構成でドメインにセットアップします。
前提条件と目標
このガイドを完了するには、まずいくつかの一般的なDNS用語に精通する必要があります。 このガイドで実装する概念については、this guideを確認してください。
また、少なくとも2つのサーバーが必要です。 1つはドメインのゾーンファイルが作成される「プライマリ」DNSサーバー用で、もう1つは転送を通じてゾーンデータを受信し、他のサーバーがダウンした場合に利用できる「セカンダリ」サーバーです。 これにより、DNSサーバーに単一障害点が生じる危険を回避できます。
caching or forwarding DNS serversや多目的DNSサーバーとは異なり、権限のみのサーバーは、権限のあるゾーンの反復クエリにのみ応答します。 これは、サーバーが答えを知らない場合、クライアント（通常、何らかの種類のDNSサーバー）に答えを知らないことを伝え、より多くを知っているサーバーへの参照を与えることを意味します。
権限のみのDNSサーバーは、クライアントからの再帰クエリを解決するオーバーヘッドがないため、多くの場合、高いパフォーマンスを得るための適切な構成です。 彼らは彼らがサービスを提供するように設計されているゾーンのみを気にします。
このガイドでは、実際にはthreeサーバーを参照します。 上記の2つのネームサーバーと、ゾーン内でホストとして構成するWebサーバー。
このガイドでは、ダミードメインexample.comを使用します。 構成中のドメインに置き換える必要があります。 設定するマシンの詳細は次のとおりです。
| 目的 | DNSFQDN | IPアドレス |
|---|---|---|
プライマリネームサーバー |
ns1.example.com. |
192.0.2.1 |
セカンダリネームサーバー |
ns2.example.com. |
192.0.2.2 |
Webサーバー |
192.0.2.3 |
このガイドを完了したら、ドメインゾーン用に2つの権限のみのネームサーバーを構成する必要があります。 上記の表の中央の列の名前は、さまざまなホストに到達するために使用できます。 この構成を使用すると、再帰DNSサーバーはドメインに関するデータをクライアントに返すことができます。
ネームサーバーでのホスト名の設定
ネームサーバーの構成に入る前に、プライマリDNSサーバーとセカンダリDNSサーバーの両方でホスト名が適切に構成されていることを確認する必要があります。
/etc/hostsファイルを調査することから始めます。 テキストエディターでsudo権限でファイルを開きます。
sudo nano /etc/hosts各サーバーのホスト名とFQDNを正しく識別するようにこれを構成する必要があります。 プライマリネームサーバーの場合、ファイルは最初は次のようになります。
127.0.0.1 localhost
127.0.1.1 ns1 ns1
. . .2行目を修正して、特定のホストとドメインの組み合わせを参照し、これをパブリックの静的IPアドレスにポイントする必要があります。 次に、最後に非修飾名をエイリアスとして追加できます。 この例のプライマリサーバーでは、2行目を次のように変更します。
127.0.0.1 localhost
192.0.2.1 ns1.example.com ns1
. . .完了したら、ファイルを保存して閉じます。
また、/etc/hostnameファイルを変更して、修飾されていないホスト名を含める必要があります。
sudo nano /etc/hostnamens1次のように入力することにより、この値を現在実行中のシステムに読み込むことができます。
sudo hostname -F /etc/hostnameセカンダリサーバーで同じ手順を実行します。
/etc/hostsファイルから始めます。
sudo nano /etc/hosts127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2完了したら、ファイルを保存して閉じます。
次に、/etc/hostnameファイルを変更します。 このファイルには、実際のホスト（この例ではns2のみ）のみを使用することを忘れないでください。
sudo nano /etc/hostnamens2もう一度、ファイルを読んで現在のシステムを変更します。
sudo hostname -F /etc/hostnameサーバーのホスト定義が正しく設定されているはずです。
両方のネームサーバーにバインドをインストールする
各ネームサーバーに、使用するDNSサーバーであるBindをインストールできます。
BindソフトウェアはUbuntuのデフォルトのリポジトリ内で利用できるため、ローカルパッケージインデックスを更新し、aptを使用してソフトウェアをインストールする必要があります。 ドキュメントと一般的なユーティリティも含まれます。
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-docプライマリおよびセカンダリDNSサーバーでこのインストールコマンドを実行して、適切なファイルを取得します。
プライマリバインドサーバーの構成
ソフトウェアがインストールされたので、プライマリサーバーでDNSサーバーを構成することから始めます。
オプションファイルの構成
開始するために最初に構成するのは、named.conf.optionsファイルです。
バインドDNSサーバーはnamedとも呼ばれます。 メインの設定ファイルは/etc/bind/named.confにあります。 このファイルは、実際に構成する他のファイルを呼び出します。
エディターでsudo特権でオプションファイルを開きます。
sudo nano /etc/bind/named.conf.options以下では、コメント化された行の大部分は簡潔にするために削除されていますが、一般的に、インストール後のファイルは次のようになります。
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};このファイルで設定する必要がある主なものは、再帰です。 権限のみのサーバーを設定しようとしているため、このサーバーで再帰を有効にしたくありません。 optionsブロック内でこれをオフにすることができます。
また、デフォルトでは転送を許可しません。 後で個々のゾーン仕様でこれをオーバーライドします。
options {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};終了したら、ファイルを保存して閉じます。
ローカルファイルの構成
次のステップは、このサーバーを制御するゾーンを指定することです。 ゾーンとは、管理のために他のサーバーにサブ委任されていないネームサーバーに委任されているドメインの任意の部分です。
example.comドメインを構成しており、ドメインのどの部分の責任も他のサーバーにサブ委任することはありません。 したがって、ゾーンはドメイン全体をカバーします。
ゾーンを構成するには、sudo権限で/etc/bind/named.conf.localファイルを開く必要があります。
sudo nano /etc/bind/named.conf.localこのファイルは、コメント以外は最初は空です。 サーバーが一般的な管理のために知っているゾーンは他にもありますが、これらはnamed.conf.default-zonesファイルで指定されています。
まず、example.comドメインのフォワードゾーンを構成する必要があります。 フォワードゾーンは、DNSについて議論するときに私たちのほとんどが考える従来の名前からIPへの解決です。 構成するドメインゾーンを定義する構成ブロックを作成します。
zone "example.com" {
};[.note]＃Note:Many DNS tools, their configuration files, and documentation use the terms “master” and “slave” while DigitalOcean generally prefers alternative descriptors. To avoid confusion we’ve chosen to use the terms “primary” and “secondary” to denote relationships between servers, and only use “master” or “slave” where a configuration directive requires it.
＃
このブロック内に、このゾーンに関する管理情報を追加します。 このDNSサーバーとゾーンの関係を指定します。 このマシンをすべてのゾーンのプライマリネームサーバーとして構成しているため、これは次のサンプルゾーンのtype master;です。 また、ゾーンを定義する実際のリソースレコードを保持するファイルをBindにポイントします。
プライマリゾーンファイルを、Bind構成ディレクトリ内のzonesというサブディレクトリに保持します。 ファイルdb.example.comを呼び出して、Bindディレクトリ内の他のゾーンファイルから規則を借用します。 ブロックは次のようになります。
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
};このゾーンをセカンダリサーバーに転送できるようにするには、次のような行を追加する必要があります。
zone "example.com" {
type master;
file "/etc/bind/zones/db.example.com";
allow-transfer { 192.0.2.2; };
};次に、ドメインの逆ゾーンを定義します。
逆ゾーンについて少し
IPアドレスを提供した組織がネットワーク範囲を提供せず、その範囲に対する責任をあなたに委任しなかった場合、リバースゾーンファイルは参照されず、組織自体によって処理されます。
ホスティングプロバイダーでは、通常、リバースマッピングは会社自体が処理します。 たとえば、DigitalOceanでは、コントロールパネルでサーバー名としてマシンのFQDNを使用すると、サーバーの逆マッピングが自動的に作成されます。 たとえば、このチュートリアルの逆マッピングは、次のようにサーバーに名前を付けることで作成できます。
このようなインスタンスでは、管理するアドレスのチャンクが割り当てられていないため、この戦略を使用する必要があります。 以下に概説する戦略は、完全性と、連続するアドレスのより大きなグループの制御を委任された場合に適用できるようにカバーされています。
逆ゾーンは、IPアドレスをドメイン名に戻すために使用されます。 ただし、ドメインネームシステムは元々フォワードマッピング用に設計されたものであるため、リバースマッピングを可能にするためにこれを適応させるにはいくつかの検討が必要です。
逆マッピングを理解するために留意すべき情報は次のとおりです。
-
ドメインでは、アドレスの最も具体的な部分は左側にあります。 IPアドレスの場合、最も具体的な部分は右側にあります。
-
ドメイン仕様の最も具体的な部分は、サブドメインまたはホスト名です。 これは、ドメインのゾーンファイルで定義されます。
-
各サブドメインは、さらに多くのサブドメインまたはホストを定義できます。
すべての逆引きゾーンマッピングは、Internet Assigned Numbers Authority（IANA）によって制御される特別なドメインin-addr.arpaの下で定義されます。 このドメインの下には、サブドメインを使用してIPアドレスの各オクテットをマップするツリーが存在します。 IPアドレスの特異性が通常のドメインの特異性を反映することを確認するために、IPアドレスのオクテットは実際に逆にされます。
したがって、IPアドレスが192.0.2.1のプライマリDNSサーバーは、1.2.0.192として読み取られるように反転されます。 このホスト仕様をin-addr.arpaドメインの下に存在する階層として追加すると、特定のホストを1.2.0.192.in-addr.arpaとして参照できます。
DNSを使用する場合、ゾーンファイル自体の中に個々のホスト（ここでは先頭の「1」など）を定義するため、構成するゾーンは2.0.192.in-addr.arpaになります。 私たちのネットワークプロバイダーが私たちにアドレスの/ 24ブロック、たとえば192.0.2.0/24を与えた場合、彼らはこのin-addr.arpaの部分を私たちに委任したでしょう。
逆ゾーン名の指定方法がわかったので、実際の定義は順ゾーンとまったく同じです。 example.comゾーン定義の下で、指定されたネットワークの逆引きゾーンを作成します。 繰り返しますが、これはおそらく、アドレスのブロックの制御を委任された場合にのみ必要です。
zone "2.0.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.192.0.2";
};ファイルにdb.192.0.2という名前を付けることにしました。 これは、ゾーンの構成内容に固有のものであり、逆表記よりも読みやすくなっています。
完了したら、ファイルを保存して閉じます。
順ゾーンファイルを作成する
これで、順方向ゾーンと逆方向ゾーンについてBindに通知しましたが、これらのゾーンを定義するファイルはまだ作成していません。
思い出してください。ファイルの場所は、zonesというサブディレクトリ内にあると指定しました。 このディレクトリを作成する必要があります。
sudo mkdir /etc/bind/zonesこれで、Bindディレクトリにある既存のゾーンファイルの一部を、作成するゾーンファイルのテンプレートとして使用できます。 フォワードゾーンの場合、db.localファイルは必要なものに近くなります。 そのファイルを、named.conf.localファイルで使用されている名前でzonesサブディレクトリにコピーします。
sudo cp /etc/bind/db.local /etc/bind/zones/db.example.comこれを行っている間、逆ゾーンのテンプレートもコピーできます。 db.127ファイルを使用します。これは、必要なものとほぼ一致しているためです。
sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2次に、テキストエディタでsudo権限で順ゾーンファイルを開きます。
sudo nano /etc/bind/zones/db.example.comファイルは次のようになります。
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1最初に行う必要があるのは、最初の@記号で始まり、閉じ括弧まで続くSOA（権限の開始）レコードを変更することです。
localhost.をこのマシンのFQDNの名前に置き換える必要があります。 レコードのこの部分は、定義されているゾーンに対して正式に応答するネームサーバーを定義するために使用されます。 これは、現在構成しているマシンになります。この場合はns1.example.com.です（末尾のドットに注意してください）。 これは、エントリを正しく登録するために重要です！）。
また、次の部分を変更したいと思います。これは、実際には、@がドットに置き換えられた特別にフォーマットされた電子メールアドレスです。 メールをドメインの管理者に送信する必要があるため、従来のメールは[email protected]です。 これをadmin.example.com.のように変換します。
@ IN SOA ns1.example.com. admin.example.com. (次に編集する必要があるのは、シリアル番号です。 シリアル番号の値は、更新された情報をセカンダリサーバーに送信する必要があるかどうかをバインドがどのように判断するかです。
Note：シリアル番号のインクリメントに失敗することは、ゾーンの更新に関する問題につながる最も一般的な間違いの1つです。 編集を行うたびに、mustがシリアル番号をバンプします。
一般的な方法の1つは、番号を増やすための規則を使用することです。 アプローチの1つは、YYYYMMDD形式の日付と、最後に追加された日のリビジョン番号を使用することです。 したがって、2014年6月5日に行われた最初の改訂には2014060501のシリアル番号があり、その日以降に行われた更新には2014060502のシリアル番号があります。 値は10桁の数値にすることができます。
使いやすさのために規則を採用する価値がありますが、デモンストレーションのために物事を単純にするために、今のところは5に設定します。
@ IN SOA ns1.example.com. admin.example.com. (
5 ; Serial次に、ファイルの最後の3行（@で始まる下部の行）を削除して、独自の行を作成します。
SOAレコードの後に最初に確立したいのは、ゾーンのネームサーバーです。 ドメインを指定してから、ゾーンに対して権限を持つ2つのネームサーバーを名前で指定します。 これらのネームサーバーはドメイン自体内のホストになるため、少し自己参照的に見えます。
このガイドでは、次のようになります。 繰り返しますが、最後のドットに注意してください！：
; Name servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.ゾーンファイルの目的は主にホスト名とサービスを特定のアドレスにマッピングすることなので、まだ完了していません。 このゾーンファイルを読み取るソフトウェアは、権限のあるゾーンにアクセスするために、ns1サーバーとns2サーバーがどこにあるかを知りたいと思うでしょう。
したがって、次に、これらのネームサーバー名をネームサーバーの実際のIPアドレスに関連付けるAレコードを作成する必要があります。
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2ネームサーバーを正しいIPアドレスに正常に解決するためのAレコードができたので、追加のレコードを追加できます。 ホストの1つにWebサーバーがあり、これを使用してサイトの提供を行います。 一般ドメイン（この場合はexample.com）の要求と、wwwホストの要求をこのホストにポイントします。 これは次のようになります。
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3追加のAレコードを作成することにより、定義する必要のあるホストを追加できます。 DNS basics guideを参照して、追加のレコードを作成する際のオプションのいくつかに慣れてください。
終了すると、ファイルは次のようになります。
$TTL 604800
@ IN SOA ns1.example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
example.com. IN NS ns1.example.com.
example.com. IN NS ns2.example.com.
; A records for name servers
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
; Other A records
@ IN A 192.0.2.3
www IN A 192.0.2.3完了したら、ファイルを保存して閉じます。
逆ゾーンファイルを作成する
これで、順ゾーンが設定されましたが、設定ファイルで指定した逆ゾーンファイルを設定する必要があります。 最後のセクションの冒頭で既にファイルを作成しました。
sudo権限でテキストエディターでファイルを開きます。
sudo nano db.192.0.2ファイルは次のようになります。
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.フォワードゾーンで行ったのと同じ手順の多くを実行します。 最初に、最後のファイルにあったものと正確に一致するようにドメイン名、管理者の電子メール、およびシリアル番号を調整します（シリアル番号は異なる場合がありますが、増やす必要があります）。
@ IN SOA example.com. admin.example.com. (
5 ; Serialここでも、SOAレコードの閉じ括弧の下の行を消去します。 ネットワーク範囲内の各IPアドレスの最後のオクテットを取得し、PTRレコードを使用してそのホストのFQDNにマッピングし直します。 一部のソフトウェアでの問題を回避するために、各IPアドレスには単一のPTRレコードのみを含める必要があるため、リバースマップ先のホスト名を選択する必要があります。
たとえば、メールサーバーをセットアップしている場合、多くのシステムはアドレスの検証にリバースマッピングを使用するため、おそらくメール名へのリバースマッピングをセットアップする必要があります。
まず、ネームサーバーを再度設定する必要があります。
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.次に、参照しているIPアドレスの最後のオクテットを使用し、返される完全修飾ドメイン名を指すようにします。 この例では、これを使用します。
; PTR Records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.終了すると、ファイルは次のようになります。
$TTL 604800
@ IN SOA example.com. admin.example.com. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers
IN NS ns1.example.com.
IN NS ns2.example.com.
; PTR records
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.完了したら、ファイルを保存して閉じます。
ファイルのテストとサービスの再起動
プライマリサーバーの構成はこれで完了しましたが、変更を実装する必要があります。
サービスを再起動する前に、すべての構成ファイルをテストして、正しく構成されていることを確認する必要があります。 各ファイルの構文をチェックできるツールがいくつかあります。
まず、named-checkconfコマンドを使用して、named.conf.localファイルとnamed.conf.optionsファイルを確認できます。 これらのファイルは両方ともスケルトンnamed.confファイルのソースであるため、変更したファイルの構文をテストします。
sudo named-checkconfこれがメッセージなしで返される場合は、named.conf.localファイルとnamed.conf.optionsファイルが構文的に有効であることを意味します。
次に、ゾーンが処理するドメインとゾーンファイルの場所をnamed-checkzoneコマンドに渡すことにより、個々のゾーンファイルを確認できます。 したがって、このガイドでは、次のように入力して順ゾーンファイルを確認できます。
sudo named-checkzone example.com /etc/bind/zones/db.example.comファイルに問題がない場合は、正しいシリアル番号がロードされ、「OK」メッセージが表示されることを通知する必要があります。
zone example.com/IN: loaded serial 5
OK他のメッセージに遭遇した場合は、ゾーンファイルに問題があることを意味します。 通常、このメッセージは、どの部分が無効であるかを非常に説明しています。
in-addr.arpaアドレスとファイル名を渡すことで、逆引きゾーンを確認できます。 デモでは、次のように入力します。
sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2繰り返しますが、これにより正しいシリアル番号のロードに関する同様のメッセージが表示されます。
zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OKすべてのファイルがチェックアウトされている場合、バインドサービスを再起動できます。
sudo service bind9 restart次のように入力してログを確認する必要があります。
sudo tail -f /var/log/syslogこのログに注意して、エラーがないことを確認してください。
セカンダリバインドサーバーを構成する
プライマリサーバーが構成されたので、次に進み、セカンダリサーバーをセットアップします。 これは、プライマリサーバーよりも非常に簡単です。
オプションファイルの構成
ここでも、named.conf.optionsファイルから始めます。 テキストエディターでsudo権限で開きます。
sudo nano /etc/bind/named.conf.optionsこのファイルに対して、プライマリサーバーのファイルに対して行ったのとまったく同じ変更を行います。
options {
directory "/var/cache/bind";
recursion no;
allow-transfer { none; };
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};完了したら、ファイルを保存して閉じます。
ローカル構成ファイルの構成
次に、セカンダリサーバーでnamed.conf.localファイルを構成します。 テキストエディターでsudo権限で開きます。
sudo nano /etc/bind/named.conf.localここでは、プライマリサーバーで行ったように、各ゾーン仕様を作成します。 ただし、値と一部のパラメーターは異なります。
最初に、順ゾーンで作業します。 プライマリファイルで行ったのと同じ方法で開始します。
zone "example.com" {
};今回は、このサーバーがこのゾーンのセカンダリとして機能しているため、typeをslaveに設定します。 これは単に、ローカルシステム上のファイルではなく、転送によってゾーンファイルを受信することを意味します。 さらに、ゾーンファイルへの絶対パスではなく相対ファイル名を指定するだけです。
これは、セカンダリゾーンの場合、Bindがファイル/var/cache/bindを格納するためです。 バインドはすでにこのディレクトリの場所を検索するように設定されているため、パスを指定する必要はありません。
フォワードゾーンの場合、これらの詳細は次のようになります。
zone "example.com" {
type slave;
file "db.example.com";
};最後に、allow-transferディレクティブの代わりに、このサーバーがゾーン転送を受け入れるプライマリサーバーをIPアドレスで指定します。 これは、mastersというディレクティブで実行されます。
zone "example.com" {
type slave;
file "db.example.com";
masters { 192.0.2.1; };
};これで、順ゾーンの仕様が完成しました。 これとまったく同じ形式を使用して、逆ゾーンの指定を処理できます。
zone "2.0.192.in-addr.arpa" {
type slave;
file "db.192.0.2";
masters { 192.0.2.1; };
};終了したら、ファイルを保存して閉じることができます。
ファイルのテストとサービスの再起動
前述のように、このサーバーはプライマリサーバーからゾーンファイルを受信するため、セカンダリマシンで実際にゾーンファイルを作成する必要はありません。 これでテストする準備ができました。
繰り返しますが、構成ファイルの構文を確認する必要があります。 チェックするゾーンファイルがないため、named-checkconfツールを使用するだけで済みます。
sudo named-checkconfこれがエラーなしで戻る場合、変更したファイルに構文エラーがないことを意味します。
この場合、バインドサービスを再起動できます。
sudo service bind9 restart次を使用して、プライマリサーバーとセカンダリサーバーの両方でログを確認します。
sudo tail -f /var/log/syslogゾーンファイルが正しく転送されたことを示すエントリが表示されます。
ネームサーバーへの権限の委任
これで、権限のみのネームサーバーが完全に構成されました。 ただし、ドメインの権限をネームサーバーに委任する必要があります。
これを行うには、ドメイン名を購入したWebサイトにアクセスする必要があります。 インターフェイスとおそらく用語は、使用したドメイン名レジストラによって異なります。
ドメイン設定で、使用するネームサーバーを指定できるオプションを探します。 ネームサーバーはドメインのwithinであるため、これは特殊なケースです。
レジストラは、NSレコードを使用してゾーンの権限を単に委任するのではなく、glue recordを作成する必要があります。 グルーレコードは、権限を委任するネームサーバーを指定した後、ネームサーバーのIPアドレスを指定するAレコードです。
通常、委任にはドメインの権限を処理するネームサーバーのみがリストされますが、ネームサーバーがドメイン内にある場合、親ゾーンのネームサーバーにはAレコードが必要です。 これが行われない場合、ドメインのネームサーバーのIPアドレスを見つけて委任パスをたどることができないため、DNSリゾルバーはループでスタックします。
そのため、ドメインレジストラのコントロールパネルで、ネームサーバーのIPアドレスをandで指定できるセクションを見つける必要があります。
デモンストレーションとして、レジストラNamecheapには2つの異なるネームサーバーセクションがあります。
ドメイン内のネームサーバーのIPアドレスを指定できる「ネームサーバー登録」というセクションがあります。
内部では、ドメイン内に存在するネームサーバーのIPアドレスを入力できます。
これにより、親ゾーンファイルで必要なグルーレコードとして機能するAレコードが作成されます。
これを行うと、アクティブなネームサーバーをドメインのサーバーに変更できるようになります。 NameCheapでは、これは「Domain Name Server Setup」メニューオプションを使用して行われます。
ここで、サイトの権限のあるサーバーとして追加したネームサーバーを使用するように指示できます。
変更が反映されるまでに時間がかかる場合がありますが、ほとんどのレジストラで24〜48時間以内に使用されているネームサーバーのデータが表示されるはずです。
結論
これで、ドメインをサーバーするように2つの権限のみのDNSサーバーを構成する必要があります。 これらを使用して、追加のドメインのゾーン情報を保存できます。
独自のDNSサーバーを構成および管理することにより、DNSレコードの処理方法を最大限に制御できます。 変更を行い、関連するすべてのDNSデータがソースで最新であることを確認できます。 他のDNSソリューションはこのプロセスを簡単にするかもしれませんが、選択肢があることを知り、よりパッケージ化されたソリューションで何が起こっているかを理解することが重要です。