Ubuntu14.04で権限のみのDNSサーバーとしてバインドを構成する方法
序章
DNS(ドメインネームシステム)は、Webサイトやサーバーの構成方法を学ぶときに、正しく理解するのが難しいコンポーネントであることがよくあります。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。
このガイドでは、Ubuntu14.04マシンにBind9DNSサーバーを権限のある専用DNSサーバーとしてインストールおよび構成する方法について説明します。 これらの2つのバインドサーバーを、プライマリ-セカンダリ構成でドメインに設定します。
前提条件と目標
このガイドを完了するには、最初にいくつかの一般的なDNS用語に精通している必要があります。 このガイドで実装する概念については、このガイドをご覧ください。
また、少なくとも2台のサーバーが必要です。 1つはドメインのゾーンファイルが発信される「プライマリ」DNSサーバー用で、もう1つは転送を通じてゾーンデータを受信し、他のサーバーがダウンした場合に利用できる「セカンダリ」サーバー用です。 これにより、DNSサーバーに単一障害点が発生する危険性を回避できます。
DNSサーバーのキャッシュまたは転送または多目的DNSサーバーとは異なり、権限のみのサーバーは、権限のあるゾーンの反復クエリにのみ応答します。 これは、サーバーが回答を知らない場合、クライアント(通常はある種の解決DNSサーバー)に回答を知らないことを通知し、より多くのことを知っている可能性のあるサーバーへの参照を提供することを意味します。
権限のみのDNSサーバーは、クライアントからの再帰クエリを解決するオーバーヘッドがないため、多くの場合、高性能を実現するための適切な構成です。 彼らは彼らが奉仕するように設計されているゾーンだけを気にします。
このガイドでは、実際には3台のサーバーを参照します。 上記の2つのネームサーバーと、ゾーン内のホストとして構成するWebサーバー。
ダミードメインを使用します example.com
このガイドのために。 構成しているドメインに置き換える必要があります。 構成するマシンの詳細は次のとおりです。
目的 | DNSFQDN | IPアドレス |
---|---|---|
プライマリネームサーバー | ns1.example.com。 | 192.0.2.1 |
セカンダリネームサーバー | ns2.example.com。 | 192.0.2.2 |
Webサーバー | www.example.com。 | 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/hostname
ns1
次のように入力することで、現在実行中のシステムにこの値を読み込むことができます。
sudo hostname -F /etc/hostname
セカンダリサーバーで同じ手順を実行します。
から始めます /etc/hosts
ファイル:
sudo nano /etc/hosts
127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2
終了したら、ファイルを保存して閉じます。
次に、 /etc/hostname
ファイル。 実際のホストのみを使用することを忘れないでください( ns2
この例では)このファイルの場合:
sudo nano /etc/hostname
ns2
もう一度、ファイルを読んで現在のシステムを変更します。
sudo hostname -F /etc/hostname
これで、サーバーのホスト定義が正しく設定されているはずです。
両方のネームサーバーにBindをインストールする
これで、各ネームサーバーに、使用するDNSサーバーであるBindをインストールできます。
BindソフトウェアはUbuntuのデフォルトのリポジトリ内で利用できるため、ローカルパッケージインデックスを更新し、を使用してソフトウェアをインストールする必要があります。 apt
. ドキュメントといくつかの一般的なユーティリティも含まれます。
sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc
プライマリおよびセカンダリDNSサーバーでこのインストールコマンドを実行して、適切なファイルを取得します。
プライマリバインドサーバーを構成する
ソフトウェアがインストールされたので、プライマリサーバーでDNSサーバーを構成することから始めます。
オプションファイルの構成
開始するために最初に構成するのは、 named.conf.options
ファイル。
BindDNSサーバーは別名 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
ドメインであり、ドメインのいかなる部分についても他のサーバーに責任を委任することはありません。 したがって、ゾーンはドメイン全体をカバーします。
ゾーンを構成するには、 /etc/bind/named.conf.local
sudo権限を持つファイル:
sudo nano /etc/bind/named.conf.local
このファイルは、コメント以外は最初は空になります。 私たちのサーバーが一般的な管理のために知っている他のゾーンがありますが、これらはで指定されています named.conf.default-zones
ファイル。
まず、フォワードゾーンを構成する必要があります example.com
ドメイン。 フォワードゾーンは、DNSについて議論するときに私たちのほとんどが考える従来の名前からIPへの解決策です。 構成するドメインゾーンを定義する構成ブロックを作成します。
zone "example.com" {
};
ノート: 多くのDNSツール、それらの構成ファイル、およびドキュメントでは、「マスター」および「スレーブ」という用語が使用されていますが、DigitalOceanは通常、代替記述子を好みます。 混乱を避けるために、サーバー間の関係を表すために「プライマリ」と「セカンダリ」という用語を使用し、構成ディレクティブで必要な場合にのみ「マスター」または「スレーブ」を使用することを選択しました。
このブロック内に、このゾーンに関する管理情報を追加します。 このDNSサーバーとゾーンの関係を指定します。 これは type master;
次のゾーンの例では、このマシンをすべてのゾーンのプライマリネームサーバーとして構成しているためです。 また、ゾーンを定義する実際のリソースレコードを保持するファイルにバインドを指定します。
プライマリゾーンファイルをというサブディレクトリに保持します 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アドレスの場合、最も具体的な部分は右側にあります。
- ドメイン仕様の最も具体的な部分は、サブドメインまたはホスト名のいずれかです。 これは、ドメインのゾーンファイルで定義されています。
- 各サブドメインは、さらに多くのサブドメインまたはホストを定義できます。
すべての逆引きゾーンマッピングは、特別なドメインの下で定義されます in-addr.arpa
、Internet Assigned Numbers Authority(IANA)によって管理されています。 このドメインの下には、サブドメインを使用してIPアドレスの各オクテットをマップするツリーが存在します。 IPアドレスの特異性が通常のドメインの特異性を反映していることを確認するために、IPアドレスのオクテットは実際には逆になっています。
つまり、IPアドレスが 192.0.2.1
、次のように読み取るために反転されます 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
ファイルは必要なものに近くなります。 そのファイルをにコピーします zones
で使用される名前のサブディレクトリ named.conf.local
ファイル。
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.
私たちの場合(末尾のドットに注意してください。 これは、エントリを正しく登録するために重要です!)。
また、次の部分を変更したいと思います。これは、実際には特別にフォーマットされた電子メールアドレスであり、 @
ドットに置き換えられました。 メールをドメインの管理者に送信する必要があるため、従来のメールは admin@example.com
. これを翻訳して、次のようにします admin.example.com.
:
@ IN SOA ns1.example.com. admin.example.com. (
次に編集する必要があるのはシリアル番号です。 シリアル番号の値は、Bindが更新された情報をセカンダリサーバーに送信する必要があるかどうかを通知する方法です。
注:シリアル番号の増分に失敗することは、ゾーンの更新に関する問題につながる最も一般的な間違いの1つです。 編集を行うたびに、シリアル番号を必ずバンプする必要があります。
一般的な方法の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
サーバーは、権限のあるゾーンにアクセスするためのものです。
次に、作成する必要があります A
これらのネームサーバー名をネームサーバーの実際のIPアドレスに関連付けるレコード:
; 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基本ガイドを参照して、追加のレコードを作成する際のオプションのいくつかを理解してください。
終了すると、ファイルは次のようになります。
$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アドレスの最後のオクテットを取得し、それを使用してそのホストのFQDNにマッピングし直します。 PTR
記録。 各IPアドレスには単一の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.conf.local
と named.conf.options
を使用してファイル named-checkconf
指図。 これらのファイルは両方ともスケルトンによってソースされているため 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サイトにアクセスする必要があります。 インターフェースとおそらく用語は、使用したドメイン名レジストラによって異なります。
ドメイン設定で、使用するネームサーバーを指定できるオプションを探します。 ネームサーバーはドメイン内であるため、これは特殊なケースです。
レジストラは、NSレコードを使用してゾーンの権限を単に委任するのではなく、glueレコードを作成する必要があります。 グルーレコードは、権限を委任するネームサーバーを指定した後、ネームサーバーのIPアドレスを指定するAレコードです。
通常、委任にはドメインの権限を処理するネームサーバーのみが一覧表示されますが、ネームサーバーがドメイン自体の中にある場合は、親ゾーンのネームサーバーにAレコードが必要です。 これが行われなかった場合、DNSリゾルバーは、委任パスをたどるドメインのネームサーバーのIPアドレスを見つけることができないため、ループに陥ります。
したがって、ドメインレジストラのコントロールパネルで、ネームサーバーとのIPアドレスを指定できるセクションを見つける必要があります。
デモンストレーションとして、レジストラNamecheapには2つの異なるネームサーバーセクションがあります。
ドメイン内のネームサーバーのIPアドレスを指定できる「ネームサーバー登録」というセクションがあります。
内部では、ドメイン内に存在するネームサーバーのIPアドレスを入力できます。
これにより、親ゾーンファイルに必要なグルーレコードとして機能するAレコードが作成されます。
これを実行すると、アクティブなネームサーバーをドメインのサーバーに変更できるようになります。 NameCheapでは、これは「ドメインネームサーバーのセットアップ」メニューオプションを使用して行われます。
ここでは、サイトの権限のあるサーバーとして追加したネームサーバーを使用するように指示できます。
変更が反映されるまでに時間がかかる場合がありますが、ほとんどのレジストラでは、24〜48時間以内にネームサーバーからのデータが使用されていることがわかります。
結論
これで、ドメインをサーバー化するために2つの権限のみのDNSサーバーが構成されているはずです。 これらを使用して、追加のドメインを取得するときに、追加のドメインのゾーン情報を保存できます。
独自のDNSサーバーを構成および管理すると、DNSレコードの処理方法を最大限に制御できます。 変更を加えて、関連するすべてのDNSデータがソースで最新であることを確認できます。 他のDNSソリューションを使用するとこのプロセスが簡単になる場合がありますが、オプションがあることを理解し、よりパッケージ化されたソリューションで何が起こっているかを理解することが重要です。