前書き

” ” ‘

DNS、またはドメインネームシステムは、多くの場合、Webサイトとサーバーの構成方法を学習するときに適切なコンポーネントを取得するのが困難です。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。

このガイドでは、Ubuntu 14.04マシンでBind9 DNSサーバーを権限のある専用DNSサーバーとしてインストールおよび構成する方法について説明します。 これらの2つのバインドサーバーを、プライマリとセカンダリの構成でドメインにセットアップします。

前提条件と目標

このガイドを完了するには、まずいくつかの一般的なDNS用語に精通する必要があります。 このガイドで実装する概念については、https://www.digitalocean.com/community/tutorials/an-introduction-to-dns-terminology-components-and-concepts [このガイド]をご覧ください。

また、少なくとも2つのサーバーが必要です。 1つはドメインのゾーンファイルが作成される「プライマリ」DNSサーバー用で、もう1つは転送を通じてゾーンデータを受信し、他のサーバーがダウンした場合に利用できる「セカンダリ」サーバーです。 これにより、DNSサーバーに単一障害点が生じる危険を回避できます。

link:[キャッシュDNSサーバーまたは転送DNSサーバー]や多目的DNSサーバーとは異なり、権限のみのサーバーは、権限のあるゾーンに対する反復クエリにのみ応答します。 これは、サーバーが答えを知らない場合、クライアント(通常、何らかの種類のDNSサーバー)に答えを知らないことを伝え、より多くを知っているサーバーへの参照を与えることを意味します。

権限のみのDNSサーバーは、クライアントからの再帰クエリを解決するオーバーヘッドがないため、多くの場合、高いパフォーマンスを得るための適切な構成です。 彼らは彼らがサービスを提供するように設計されているゾーンのみを気にします。

このガイドでは、実際には* 3 *サーバーを参照します。 上記の2つのネームサーバーと、ゾーン内でホストとして構成するWebサーバー。

このガイドでは、ダミードメイン「++」を使用します。 構成中のドメインに置き換える必要があります。 設定するマシンの詳細は次のとおりです。

Purpose DNS FQDN IP Address

Primary name server

ns1.example.com.

192.0.2.1

Secondary name server

ns2.example.com.

192.0.2.2

Web Server

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

. . .

完了したら、ファイルを保存して閉じます。

また、修飾されていないホスト名を含むように `+ / etc / hostname +`ファイルを変更する必要があります。

sudo nano /etc/hostname

次のように入力することにより、この値を現在実行中のシステムに読み込むことができます。

sudo hostname -F /etc/hostname

セカンダリサーバーで同じ手順を実行します。

`+ / etc / hosts +`ファイルから始めます:

sudo nano /etc/hosts
127.0.0.1       localhost

完了したら、ファイルを保存して閉じます。

次に、 `+ / etc / hostname `ファイルを変更します。 このファイルには実際のホスト(この例では ` ns2 +`のみ)のみを使用することを忘れないでください:

sudo nano /etc/hostname

もう一度、ファイルを読んで現在のシステムを変更します。

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";



       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 "" {
};

このブロック内に、このゾーンに関する管理情報を追加します。 このDNSサーバーとゾーンの関係を指定します。 これは、このマシンをすべてのゾーンのプライマリネームサーバーとして構成しているため、後続のサンプルゾーンでは「+ type master; +」です。 また、ゾーンを定義する実際のリソースレコードを保持するファイルをBindにポイントします。

プライマリゾーンファイルは、バインド構成ディレクトリ内の「+ zones 」というサブディレクトリに保存します。 ファイル「 db.example.com +」を呼び出して、バインドディレクトリ内の他のゾーンファイルから規約を借用します。 ブロックは次のようになります。

zone "example.com" {
   type master;
   file "/etc/bind/zones/db.";
};

このゾーンをセカンダリサーバーに転送できるようにするには、次のような行を追加する必要があります。

zone "example.com" {
   type master;
   file "/etc/bind/zones/db.example.com";

};

次に、ドメインの逆ゾーンを定義します。

逆ゾーンについて少し

IPアドレスを提供した組織がネットワーク範囲を提供せず、その範囲に対する責任をあなたに委任しなかった場合、リバースゾーンファイルは参照されず、組織自体によって処理されます。

ホスティングプロバイダーでは、通常、リバースマッピングは会社自体が処理します。 たとえば、DigitalOceanでは、コントロールパネルでサーバー名としてマシンのFQDNを使用すると、サーバーの逆マッピングが自動的に作成されます。 たとえば、このチュートリアルの逆マッピングは、次のようにサーバーに名前を付けることで作成できます。

image:https://assets.digitalocean.com/articles/bind_auth/auto_reverse.png [DigitalOcean自動リバースDNSマッピング]

このようなインスタンスでは、管理するアドレスのチャンクが割り当てられていないため、この戦略を使用する必要があります。 以下に概説する戦略は、完全性と、連続するアドレスのより大きなグループの制御を委任された場合に適用できるようにカバーされています。

逆ゾーンは、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.

これを行っている間、逆ゾーンのテンプレートもコピーできます。 `+ db.127 +`ファイルを使用します。これは、必要なものとほぼ一致するためです。

sudo cp /etc/bind/db.127 /etc/bind/zones/db.

次に、テキストエディタでsudo権限で順ゾーンファイルを開きます。

sudo nano /etc/bind/zones/db.

ファイルは次のようになります。

$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 @ 」です。 これを翻訳して、 ` admin .. +`のようにします。

@       IN      SOA     ns1.example.com. admin.example.com. (

次に編集する必要があるのは、シリアル番号です。 シリアル番号の値は、更新された情報をセカンダリサーバーに送信する必要があるかどうかをバインドが判断する方法です。

:シリアル番号をインクリメントしないと、ゾーンの更新で問題が発生する最も一般的な間違いの1つです。 編集を行うたびに、シリアル番号をバンプする必要があります。

一般的な方法の1つは、番号を増やすための規則を使用することです。 アプローチの1つは、YYYYMMDD形式の日付と、最後に追加された日のリビジョン番号を使用することです。 したがって、2014年6月5日に行われた最初の改訂には2014060501のシリアル番号があり、その日以降に行われた更新には2014060502のシリアル番号があります。 値は10桁の数値にすることができます。

使いやすさのために慣習を採用する価値がありますが、デモンストレーションのために物事を単純にするために、今のところは「5」に設定します。

@       IN      SOA     ns1.example.com. admin.example.com. (
                                      ; Serial

次に、ファイルの最後の3行(一番下の `+ @ +`で始まる行)を削除できます。

SOAレコードの後に​​最初に確立したいのは、ゾーンのネームサーバーです。 ドメインを指定してから、ゾーンに対して権限を持つ2つのネームサーバーを名前で指定します。 これらのネームサーバーはドメイン自体内のホストになるため、少し自己参照的に見えます。

このガイドでは、次のようになります。 繰り返しますが、最後のドットに注意してください!:

; Name servers
.    IN      NS      ns1..
.    IN      NS      ns2..

ゾーンファイルの目的は主にホスト名とサービスを特定のアドレスにマップすることなので、まだ完了していません。 このゾーンファイルを読み取るソフトウェアは、権限のあるゾーンにアクセスするために、「+ 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の基本ガイドを参照して、追加のレコードを作成するためのオプションのいくつかに慣れてください。

終了すると、ファイルは次のようになります。

$TTL    604800
@       IN      SOA     ns1.. admin.. (
                                      ; Serial
                        604800         ; Refresh
                         86400         ; Retry
                       2419200         ; Expire
                        604800 )       ; Negative Cache TTL
;

; Name servers
.    IN      NS      ns1..
.    IN      NS      ns2..

; 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.

ファイルは次のようになります。

$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     . admin.. (
                                      ; Serial

繰り返しますが、 `+ SOA `レコードの閉じ括弧の下の行を消去します。 ネットワーク範囲内の各IPアドレスの最後のオクテットを取得し、「 PTR 」レコードを使用してそのホストのFQDNにマッピングします。 一部のソフトウェアでの問題を回避するために、各IPアドレスには単一の「 PTR +」レコードのみを含める必要があるため、逆マップするホスト名を選択する必要があります。

たとえば、メールサーバーを設定している場合、多くのシステムはアドレスを検証するために逆マッピングを使用するため、おそらくメール名への逆マッピングを設定する必要があります。

まず、ネームサーバーを再度設定する必要があります。

; Name servers
       IN      NS      ns1..
       IN      NS      ns2..

次に、参照しているIPアドレスの最後のオクテットを使用し、返される完全修飾ドメイン名を指すようにします。 この例では、これを使用します。

; PTR Records
1       IN      PTR      ns1..
2       IN      PTR      ns2..
3       IN      PTR      www..

終了すると、ファイルは次のようになります。

$TTL    604800
@       IN      SOA     . admin.. (
                                      ; 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..
2       IN      PTR      ns2..
3       IN      PTR      www..

完了したら、ファイルを保存して閉じます。

ファイルのテストとサービスの再起動

プライマリサーバーの構成はこれで完了しましたが、変更を実装する必要があります。

サービスを再起動する前に、すべての構成ファイルをテストして、正しく構成されていることを確認する必要があります。 各ファイルの構文をチェックできるツールがいくつかあります。

最初に、 `+ named-checkconf `コマンドを使用して、 ` named.conf.local `および ` named.conf.options `ファイルを確認できます。 これらのファイルは両方ともスケルトンの ` named.conf +`ファイルのソースであるため、変更したファイルの構文をテストします。

sudo named-checkconf

これがメッセージなしで戻る場合、それは `+ named.conf.local `と ` named.conf.options +`ファイルが構文的に有効であることを意味します。

次に、ゾーンが処理するドメインとゾーンファイルの場所を `+ named-checkzone +`コマンドに渡すことで、個々のゾーンファイルを確認できます。 したがって、このガイドでは、次のように入力して順ゾーンファイルを確認できます。

sudo named-checkzone  /etc/bind/zones/db.

ファイルに問題がない場合は、正しいシリアル番号がロードされ、「OK」メッセージが表示されることを通知する必要があります。

zone example.com/IN: loaded serial 5
OK

他のメッセージに遭遇した場合は、ゾーンファイルに問題があることを意味します。 通常、メッセージはどの部分が無効であるかを非常に説明しています。

`+ in-addr.arpa +`アドレスとファイル名を渡すことで逆ゾーンを確認できます。 デモでは、次のように入力します。

sudo named-checkzone .in-addr.arpa /etc/bind/zones/db.

繰り返しますが、これにより正しいシリアル番号のロードに関する同様のメッセージが表示されます。

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";



       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 ;
   file "db.";
};

最後に、 `+ allow-transfer `ディレクティブの代わりに、このサーバーがゾーン転送を受け入れるプライマリサーバーをIPアドレスで指定します。 これは ` masters +`と呼ばれるディレクティブで行われます:

zone "example.com" {
   type ;
   file "db.";
   masters { ; };
};

これで、順ゾーンの仕様が完成しました。 これとまったく同じ形式を使用して、逆ゾーンの指定を処理できます。

zone "2.0.192.in-addr.arpa" {
   type ;
   file "db.";
   masters { ; };
};

終了したら、ファイルを保存して閉じることができます。

ファイルのテストとサービスの再起動

前述のように、このサーバーはプライマリサーバーからゾーンファイルを受信するため、セカンダリマシンで実際にゾーンファイルを作成する必要はありません。 これでテストする準備ができました。

繰り返しますが、構成ファイルの構文を確認する必要があります。 チェックするゾーンファイルがないため、使用する必要があるのは `+ named-checkconf +`ツールのみです。

sudo named-checkconf

これがエラーなしで戻る場合、変更したファイルに構文エラーがないことを意味します。

この場合、バインドサービスを再起動できます。

sudo service bind9 restart

次を使用して、プライマリサーバーとセカンダリサーバーの両方でログを確認します。

sudo tail -f /var/log/syslog

ゾーンファイルが正しく転送されたことを示すエントリが表示されます。

ネームサーバーへの権限の委任

これで、権限のみのネームサーバーが完全に構成されました。 ただし、ドメインの権限をネームサーバーに委任する必要があります。

これを行うには、ドメイン名を購入したWebサイトにアクセスする必要があります。 インターフェイスとおそらく用語は、使用したドメイン名レジストラによって異なります。

ドメイン設定で、使用するネームサーバーを指定できるオプションを探します。 ネームサーバーはドメイン内にあるため、これは特殊なケースです。

レジストラは、NSレコードを使用してゾーンの権限を単純に委任する代わりに、*グルーレコード*を作成する必要があります。 グルーレコードは、権限を委任するネームサーバーを指定した後、ネームサーバーのIPアドレスを指定するAレコードです。

通常、委任にはドメインの権限を処理するネームサーバーのみがリストされますが、ネームサーバーがドメイン内にある場合、親ゾーンのネームサーバーにはAレコードが必要です。 これが行われない場合、ドメインのネームサーバーのIPアドレスを見つけて委任パスをたどることができないため、DNSリゾルバーはループでスタックします。

そのため、ネームサーバーのIPアドレスを指定できるドメインレジストラのコントロールパネルのセクションを見つける必要があります。

デモンストレーションとして、レジストラhttps://www.namecheap.com [Namecheap]には2つの異なるネームサーバーセクションがあります。

ドメイン内のネームサーバーのIPアドレスを指定できる「ネームサーバー登録」というセクションがあります。

image:https://assets.digitalocean.com/articles/bind_auth/register.png [NameCheap登録ネームサーバー]

内部では、ドメイン内に存在するネームサーバーのIPアドレスを入力できます。

image:https://assets.digitalocean.com/articles/bind_auth/give_ips.png [NameCheap内部ネームサーバー]

これにより、親ゾーンファイルで必要なグルーレコードとして機能するAレコードが作成されます。

これを行うと、アクティブなネームサーバーをドメインのサーバーに変更できるようになります。 NameCheapでは、これは「Domain Name Server Setup」メニューオプションを使用して行われます。

image:https://assets.digitalocean.com/articles/bind_auth/server_setup.png [NameCheapドメイン名のセットアップ]

ここで、サイトの権限のあるサーバーとして追加したネームサーバーを使用するように指示できます。

image:https://assets.digitalocean.com/articles/bind_auth/use_servers.png [NameCheap use name servers]

変更が反映されるまでに時間がかかる場合がありますが、ほとんどのレジストラで24〜48時間以内に使用されているネームサーバーのデータが表示されるはずです。

結論

ドメインをサーバーするために、2つの権限のみのDNSサーバーが構成されているはずです。 これらを使用して、追加のドメインのゾーン情報を保存できます。

独自のDNSサーバーを構成および管理することにより、DNSレコードの処理方法を最大限に制御できます。 変更を行い、関連するすべてのDNSデータがソースで最新であることを確認できます。 他のDNSソリューションはこのプロセスを簡単にするかもしれませんが、選択肢があることを知り、よりパッケージ化されたソリューションで何が起こっているかを理解することが重要です。