前書き

ドメイン名を担当するようにDNSサーバーを設定することは、ベテランの管理者にとっても複雑な作業です。 DNSゾーン管理は重要な任務ですが、特に開始しようとするときは戸惑う可能性があります。

  • Bind * DNSサーバーなどのソフトウェアは非常に柔軟であり、DNS階層全体の多くのコンポーネントを操作するように構成できます。 ただし、その柔軟性は、バインドが1つのタスクに対して最適化されていないことも意味します。 これにはいくつかの副作用があります。

ほとんどの場合、構成に必要のない機能の巨大なチャンクがあります。 この追加の複雑さにより、管理がより困難になります。 また、ソフトウェア自体が1つのタスクに対して応答性が低下することも意味します。

この問題を解決するために、DNS解決の単一の領域に特化した代替DNSサーバーが作成されました。 * NSD *として知られるソフトウェアは、権限のあるDNSゾーンを正式に管理するのに理想的な、権限のみのDNSサーバーです。 再帰やキャッシュについて心配する必要なく、このサーバーは高いパフォーマンスと低いフットプリントで動作します。

このガイドでは、Ubuntu 14.04サーバーでDNSゾーンを安全に管理するためにNSDをインストールおよび構成する方法を示します。

前提条件と目標

このガイドを始める前に、https://www.digitalocean.com/community/tutorials/an-introduction-to-dns-terminology-components-and-concepts [基本的なDNSの概念と用語]に精通している必要があります。 権限のみのDNSサーバーの用途を理解するのに支援が必要な場合は、https://www.digitalocean.com/community/tutorials/a-comparison-of-dns-server-types-how-toのガイドをご覧ください。 -choose-the-right-dns-configuration [DNSサーバータイプの違い]。

権限を持つDNSサーバーとして、NSDはキャッシュ、転送、または再帰的な機能を提供しません。 制御するゾーンに対する反復要求にのみ応答します。 また、委任されたゾーンのリゾルバーを他のネームサーバーに参照することもできます。

このガイドでは、ゾーンのプライマリサーバーとセカンダリサーバーとして機能するように、NSDソフトウェアを備えた2台のサーバーを構成します。 また、クライアントが3番目のホスト上の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台のサーバーをNSDで構成して、ゾーンの権限のみのサーバーとして機能させる必要があります。 構成したホスト名を使用して、インターネットからサーバーにアクセスし、IPアドレスを照会してホスト名を見つけることができます。 サーバーにアクセスできる解決クライアントは、サーバーからドメインデータを取得できます。

ネームサーバーでのホスト名の設定

私たちがとる必要がある最初のステップは準備です。 DNS構成を心配する前に、ネームサーバーが必要な方法で自分のホスト名を正しく解決できることを確認する必要があります。

最初のDNSサーバーで、 `+ / etc / hosts +`ファイルを編集して、このコンピューターのFQDNをセットアップします。

sudo nano /etc/hosts

この場合、 + 192.0.2.1 + IPアドレスを最初のネームサーバーのフルネームである `+ ns1.example.com +`にマッピングする必要があります。 これを行うには、ホスト名を指定する行をパブリックIPアドレス、FQDN、およびホストの短縮エイリアスで置き換えます。

127.0.0.1       localhost

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

次に、 `+ / etc / hostname +`ファイルを再確認する必要があります。

sudo nano /etc/hostname

これには、_unqualified_ホスト名の値が含まれている必要があります。 必要に応じて変更します。

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

上記の `+ / etc / hostname +`ファイルを変更した場合、ファイルを再読み込みするようシステムに指示します。

sudo hostname -F /etc/hostname

とりあえず、最初のDNSサーバーの使用は完了です。 2番目のサーバーで手順を繰り返します。

`+ / etc / hosts +`ファイルを変更して、2番目のDNSサーバーのホストを指定します。

sudo nano /etc/hosts
127.0.0.1       localhost

`+ / etc / hostname +`ファイルも確認してください。 これには、短い非修飾名のみを使用する必要があります。

sudo nano /etc/hostname

繰り返しますが、何かを変更する必要がある場合は、システムにファイルを再読み込みさせます。

sudo hostname -F /etc/hostname

サーバーは、DNSを使用せずに独自の名前を解決できるようになりました。 これで、サーバーでNSDをセットアップする準備ができました。

両方のネームサーバーにNSDをインストールする

次のステップは、実際にネームサーバーにソフトウェアをインストールすることです。

開始する前に、実際にもう1つの準備手順を実行する必要があります。 リポジトリ内のNSDパッケージはソフトウェアをインストールし、いくつかのコンポーネントを構成し、サービスを開始しようとします。 サービスは「+ nsd +」と呼ばれるユーザーとして実行されることを想定していますが、パッケージは実際にはこのユーザーアカウントを作成しません。

インストール時のエラーを回避するために、ソフトウェアをインストールする前に、このユーザーを作成します。 各マシンで、次のように入力して `+ nsd +`システムユーザーを作成します。

sudo useradd -r nsd

これにより、インストールを正常に完了するために必要な正しいアカウントが作成されます。

ここで、NSDソフトウェアをインストールするだけです。 幸いなことに、NSDはUbuntu 14.04リポジトリに含まれているため、 `+ apt +`を使用してプルダウンできます。 ローカルパッケージインデックスを更新してから、適切なパッケージをダウンロードします。

sudo apt-get update
sudo apt-get install nsd

これにより、ソフトウェアがインストールされ、初期設定が行われます。 まだ何も提供するように設定していない場合でも、サービスを開始します。

プライマリNSDサーバーを構成する

まず、ゾーンのプライマリDNSサーバーとして設定される「+ ns1 +」サーバーを設定します。

最初にすべきことは、アプリケーションのデーモン部分とコントローラーの間で安全に通信するためにNSDが使用するすべてのSSLキーと証明書が生成されることを確認することです。

これを行うには、次を入力します。

sudo nsd-control-setup

`+ / etc / nsd +`ディレクトリにはおそらく既にキーと証明書が存在しますが、このコマンドは欠落しているものをすべて生成します。

nsd.confファイルを構成する

NSDのメインの設定ファイルは、 `+ / etc / nsd `ディレクトリにある ` nsd.conf +`というファイルです。

このディレクトリには既に数個のコメントのみを含むファイルがありますが、より完全にコメントされたサンプルファイルをテンプレートとして使用します。 これをコピーして、現在のファイルを上書きします。

sudo cp /usr/share/doc/nsd/examples/nsd.conf /etc/nsd/nsd.conf

次に、sudo権限を使用して、テキストエディターで新しいファイルを開きます。

sudo nano /etc/nsd/nsd.conf

内部には、コメント化されたいくつかの構成行がセクションに編成されています。 主なセクションは、「+ server 」、「 remote-control」、「+ key」、「+ pattern a」、および「+ zone」です。 これらのほとんどを構成に使用します。

まず、 `+ server `セクションでDNSサーバーの基本的なプロパティを設定する必要があります。 デフォルトのDNSポート53で基本的なIPv4トラフィックを処理します。 前に設定した ` nsd +`ユーザーを使用します。 これらのほとんどはデフォルト値になりますが、関連する行のコメントを外して、値を明示します。

また、ゾーンデータを含むディレクトリ、およびログファイルとpidファイルの場所を明示的に設定する必要があります。 このセクションには、他にも多くの設定オプションを設定できますが、比較的単純なものにしておきます。 追加の変更を行ってください。

サーバーセクションは次のようになります。

server:
   do-ip4: yes
   port: 53
   username: nsd
   zonesdir: "/etc/nsd"
   logfile: "/var/log/nsd.log"
   pidfile: "/run/nsd/nsd.pid"

次に、「+ remote-control」セクションを見てみましょう。 このセクションは、デーモンのリモート制御にのみ使用されるわけではないため、少し間違っています。 これを設定して、デーモンをローカルで制御します。

まず、リソースを有効にし、そのインターフェイスとポート番号を設定する必要があります。 これはすべて、適切な行のコメントを外し、 `+ control-enable +`ディレクティブを“ yes”に変更することで実行できます。

次に、キーと証明書ファイルを指定する行のコメントを外します。 これらは、 `+ nsd-control-setup +`コマンドを実行したときに生成されたファイル名と一致するため、コメントを解除したら変更する必要はありません。

このセクションの値は次のようになります。

remote-control:
   control-enable: yes
   control-interface: 127.0.0.1
   control-port: 8952
   server-key-file: "/etc/nsd/nsd_server.key"
   server-cert-file: "/etc/nsd/nsd_server.pem"
   control-key-file: "/etc/nsd/nsd_control.key"
   control-cert-file: "/etc/nsd/nsd_control.pem"

次に、 `+ key +`セクションを設定します。 このセクションには、NSDがプライマリサーバーとセカンダリサーバー間のゾーン転送を安全に実行するために使用する秘密キーが含まれます。

使用する名前とアルゴリズムを設定する必要があります。 この例では、名前「+」を使用します。 また、選択したデフォルトのアルゴリズム( ` hmac-sha256 +`)も使用します。

シークレット自体については、コメント内のアドバイスを安全に生成する方法について説明します。 テキストエディタを終了します。 ターミナルで、次のコマンドを実行します。

dd if=/dev/random of=/dev/stdout count=1 bs=32 | base64

コマンドの出力でランダムに生成されたキーを受け取ります:

0+1 records in
0+1 records out
19 bytes (19 B) copied, 0.000571766 s, 33.2 kB/s

上記の赤色の出力をコピーして、構成ファイルを再度開きます。 コピーした出力を「+ secret +」パラメーターの値として使用します。 このセクションは次のようになります。

key:
   name: "demokey"
   algorithm: hmac-sha256
   secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="

次に、セカンダリサーバーに関連する反復的な情報があるため、単純なパターンを設定します。 毎回同じセカンダリにゾーンを通知して転送するため、パターンを作成することは理にかなっています。

パターンの用途を説明するために、パターンを「+ tosecondary +」と呼びます。 各ゾーンの名前とファイルを個別に設定するので、パターンでそれを心配する必要はありません。

パターンに「+ notify 」パラメーターを設定して、セカンダリサーバーのIPアドレスを参照するようにします。 また、指定したキーを使用して、TSIGでゾーンを安全に転送します。 ` provide-xfr +`パラメータをまったく同じ方法で設定します。

最後に、 `+ pattern +`セクションは次のようになります。

pattern:
   name: "tosecondary"
   notify:  demokey
   provide-xfr:  demokey

最後に、 `+ zone +`セクションに行きます。 ここでは、NSDが特定のゾーンとその関連ファイルを処理する方法を構成します。

最初に、順ゾーンを構成します。 「+」ゾーンのゾーンを設定する必要があります。 これは、 ` name +`パラメーターでドメイン自体を指定し、ゾーンファイルに使用する名前を指定し、これをセカンダリサーバーに転送するために上記で作成したパターンを含めるのと同じくらい簡単です。

デモの完成したフォワードゾーンは次のようになります。

zone:
   name: "example.com"
   zonefile: "example.com.zone"
   include-pattern: "tosecondary"

次に、逆ゾーンを処理できます。 逆ゾーンは基本的に、DNSソフトウェアがクライアントのホスト名にIPアドレスをマップできるゾーンファイルです。 一般に、DigitalOceanのようなホスティングでは、これはホスティングプロバイダーによって処理されます。

たとえば、DigitalOceanを使用すると、逆マッピングを設定するためのIPアドレスの範囲に対する責任が委任されません。 代わりに、コントロールパネルでサーバーのホスト名をマップし直したいFQDNに設定すると、DigitalOceanは必要な逆マッピングを自動的に作成します。

逆マッピングの詳細については、https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-an-authoritative-only-の「逆ゾーンに関するビット」セクションを参照してください。 dns-server-on-ubuntu-14-04 [権威者限定ガイドのバインド]。 IPのブロックのリバースマッピングの制御を委任された場合にのみ関連しますが、情報目的および柔軟性を高めるためにNSDのリバースゾーンを設定する方法を示します。

逆引きゾーンの場合、IPアドレスの最初の3オクテットを取得し、それらを逆引きし、特別なドメイン「+ in-addr.arpa 」にサブドメインの委任として追加します。 これは、DNSシステムが通常のドメインと同じ検索方法を使用してIPアドレスを検索する方法です。 このケースでは、 ` 2.0.192.in-addr.arpa +`マッピングを定義する逆ゾーンを作成します。 これは、順ゾーンの仕様と非常によく似ています。

zone:
   name: "2.0.192.in-addr.arpa"
   zonefile: "192.0.2.zone"
   include-pattern: "tosecondary"

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

順ゾーンファイルを作成する

次に、順ゾーンファイルを作成する必要があります。 この構成では、ゾーンファイルに「example.com.zone」という名前を付けました。 `+ / etc / nsd +`ディレクトリにこの名前のファイルを作成する必要があります。

sudo権限でテキストエディターでそのファイルを開きます。

sudo nano /etc/nsd/example.com.zone

最初に行う必要があるのは、いくつかのパラメーターを上に設定することです。 FQDN形式で設定しているドメインを指す `+ $ ORIGIN +`パラメーターを設定します(終了ドットで完了)。 また、デフォルトの有効期間も設定します。 1800秒、つまり30分を使用します。

$ORIGIN .
$TTL 1800

次に、SOA、または権限レコードの開始が必要です。 これは次のようになります。

@       IN      SOA     ns1..      admin.. (
                               ; serial number
                       3600                    ; refresh
                       900                     ; retry
                       1209600                 ; expire
                       1800                    ; ttl
                       )

これは、いくつかのゾーン全体の値を定義します。 `+ ns1.example.com。`の値は、このゾーンの権限のあるサーバーのいずれかのドメインの場所を指定するために使用されます。 ` admin.example.com。+`は、ゾーン管理者に連絡できるメールアドレスを指定するために使用されます。

メールアドレスは、この場合は「[email protected]」です。 DNSゾーンファイルでは、「@」記号をドットに変更する必要があります。 終了ドットも重要です。これは、FQDNを指定するときに常に使用されるためです。

括弧内の値は、ゾーンの値の一部を定義します。 ここで言及するのは、シリアル番号だけです。 この値は、ゾーンファイルに変更を加えるたびにインクリメントする必要があります。 ここでは、この文書の日付(2014年7月2日)と改訂番号を使用してデモを行っています。

次に、NSレコードを使用して、このゾーンに対して権限のあるネームサーバーを定義する必要があります。 終了ドットを含むドメインのFQDNを使用することを忘れないでください:

                   IN      NS      ns1..
                   IN      NS      ns2..

次に、指定したネームサーバーに到達する方法をクライアントに実際に伝えるAレコードを設定する必要があります。 これは、ホスト名を実際のIPアドレスにマップするものです。

ns1                 IN      A
ns2                 IN      A

最後に、他のホストのAレコードを追加します。 この例では、ベースドメイン( + example.com +)と `+ www +`ホスト名を設定してWebサーバーにマッピングします。

@                   IN      A
www                 IN      A

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

$ORIGIN .
$TTL 1800
@       IN      SOA     ns1..      admin.. (
                               ; serial number
                       3600                    ; refresh
                       900                     ; retry
                       1209600                 ; expire
                       1800                    ; ttl
                       )
; Name servers
                   IN      NS      ns1..
                   IN      NS      ns2..

; A records for name servers
ns1                 IN      A
ns2                 IN      A

; Additional A records
@                   IN      A
www                 IN      A

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

逆ゾーンファイルを作成する

次に、逆ゾーン用に同様のファイルを作成します。 これは、アドレスブロックの逆マッピングの責任を委任されている場合にのみ必要であることに注意してください。

`+ nsd.conf +`ファイルで参照した逆ゾーンファイルを作成し、テキストエディターでsudo権限で開きます。

sudo nano /etc/nsd/192.0.2.zone

繰り返しますが、 `+ $ ORIGIN `および ` $ TTL `パラメーターを定義することから始めます。 今回は、オリジンをゾーンの ` in-addr.arpa +`サブドメインに設定することを忘れないでください。 この場合、これは次のようになります。

$ORIGIN .in-addr.arpa.
$TTL 1800

次に、以前と同様にSOAレコードを設定する必要があります。 同じメールと権限のあるネームサーバーが両方のゾーンを担当するため、このファイルにはまったく同じ値を使用できます。 さらに、この例でも数値が機能するはずです。 変更するたびにシリアル番号を変更することを忘れないでください:

@       IN      SOA     ns1..      admin.. (
                               ; serial number
                       3600                    ; refresh
                       900                     ; retry
                       1209600                 ; expire
                       1800                    ; ttl
                       )

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

この場合も、ゾーンに対して権限のあるネームサーバーを定義する必要があります。 これらは再び同じサーバーになります。

                       IN      NS      ns1..
                       IN      NS      ns2..

最後に、PTRレコードを使用して、各IPアドレスの最後のオクテットを関連付けられたホストのFQDNにルーティングすることにより、実際の逆ドメインマッピングを提供する必要があります。

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

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

$ORIGIN .in-addr.arpa.
$TTL 1800
@       IN      SOA     ns1..      admin.. (
                               ; serial number
                       3600                    ; refresh
                       900                     ; retry
                       1209600                 ; expire
                       1800                    ; ttl
                       )
; Name servers
                       IN      NS      ns1..
                       IN      NS      ns2..

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

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

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

プライマリサーバーを構成したら、構成ファイルをテストして変更を実装できます。

付属の `+ nsd-checkconf +`ツールを使用して、メイン設定ファイルの構文を確認できます。 メインの設定ファイルにツールを向けるだけです:

sudo nsd-checkconf /etc/nsd/nsd.conf

これが出力なしですぐに返される場合、メイン構成ファイルの構文が有効であることを意味します。 エラーが発生した場合は、構成ファイルの構文を確認して、間違いを修正してください。

チェックを正常に実行できたら、次のように入力してサービスを再起動できます。

sudo service nsd restart

これにより、NSDデーモンが停止および開始されます。

ログを確認して、メッセージを確認します。

sudo tail -f /var/log/nsd.log

次のようなエラーがいくつか表示されるはずです。

. . .
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: received notify response error NAME ERROR from 192.0.2.2
[1404333729] nsd[2142]: error: xfrd: zone 2.0.192.in-addr.arpa: max notify send count reached, 192.0.2.2 unreachable

これは、NSDがまだ構成されていないセカンダリサーバーにゾーンを転送しようとしているためです。

セカンダリNSDサーバーを構成する

プライマリサーバーがセットアップされたので、次に進み、セカンダリサーバーも準備します。

繰り返しますが、SSL証明書とキーがすべて生成され、利用可能であることを確認したいと思います。 これを行うには、次のコマンドを発行します。

sudo nsd-control-setup

これにより、デーモンの制御に必要なすべての資格情報ファイルが使用可能になります。

nsd.confファイルを構成する

セカンダリサーバーの `+ nsd.conf `ファイルは、プライマリサーバーとほとんど同じです。 変更する必要があるのはほんの少しです。 まず、プライマリサーバーの ` / etc / nsd / nsd.conf `ファイルをセカンダリサーバーの ` / etc / nsd / nsd.conf +`ファイルにコピーします。

このセカンダリサーバーのファイルは次のようになります。

server:
   do-ip4: yes
   port: 53
   username: nsd
   zonesdir: "/etc/nsd"
   logfile: "/var/log/nsd.log"
   pidfile: "/run/nsd/nsd.pid"

remote-control:
   control-enable: yes
   control-interface: 127.0.0.1
   control-port: 8952
   server-key-file: "/etc/nsd/nsd_server.key"
   server-cert-file: "/etc/nsd/nsd_server.pem"
   control-key-file: "/etc/nsd/nsd_control.key"
   control-cert-file: "/etc/nsd/nsd_control.pem"

key:
   name: "demokey"
   algorithm: hmac-sha256
   secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="

pattern:
   name: "tosecondary"
   notify: 192.0.2.2 demokey
   provide-xfr: 192.0.2.2 demokey

zone:
   name: "example.com"
   zonefile: "example.com.zone"
   include-pattern: "tosecondary"

zone:
   name: "2.0.192.in-addr.arpa"
   zonefile: "192.0.2.zone"
   include-pattern: "tosecondary"

これは、まさに私たちが必要とするものです。

+ server ++ remote-control、および` + key`セクションはすでに完全に設定されています。 `+ key +`セクションの「秘密」はプライマリサーバーの値と一致する必要があるため、ファイルの内容全体をコピーすると、この要件を簡単に満たすことができます。

最初に変更する必要があるのは、 `+ pattern +`セクションです。 コピーしたセクションはプライマリサーバーに固有であるため、セカンダリサーバーの観点から物事に対処するために変更します。

まず、名前をよりわかりやすい名前に変更します。 同じ規則を使用して、これを「+ fromprimary 」と呼びます。 また、これが設定するディレクティブを変更する必要があります。 セカンダリサーバーには、 ` notify `パラメーターの代わりに、通知を許可するサーバーを指定する ` allow-notify +`パラメーターが必要です。 引き続き同じキーを使用するため、名前と適切なIPアドレスを変更するだけです。

同様に、 `+ provide-xfr `パラメータを ` request-xfr +`に変更する必要があります。 この形式はわずかに変更されます。 AXFR転送(NSDプライマリができる唯一の種類)が必要であることを指定する必要があり、IPアドレス_および_のポート番号を指定する必要があります。

終了すると、 `+ pattern +`セクションは次のようになります。

pattern:
   name: "fromprimary"
   allow-notify:  demokey
   request-xfr: AXFR @53 demokey

`+ zone `セクションでは、変更する必要があるのは、作成したばかりの新しいパターンに一致する ` include-pattern`だけです。

zone:
   name: "example.com"
   zonefile: "example.com.zone"
   include-pattern: "fromprimary"

zone:
   name: "2.0.192.in-addr.arpa"
   zonefile: "192.0.2.zone"
   include-pattern: "fromprimary"

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

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

セカンダリサーバーは、プライマリサーバーからの転送を通じてすべてのゾーンデータを受信するため、実際にこのホストでゾーンファイルを構成する必要はありません。

繰り返しますが、メインの構成ファイルの構文を確認するには、次のように入力します。

sudo nsd-checkconf /etc/nsd/nsd.conf

エラーが発生した場合は、構文の問題に対処するために、 `+ nsd.conf +`ファイルをもう一度確認する必要があります。 コマンドが出力なしで戻る場合、それは構文がファイルで有効であることを意味します。

構成ファイルがテストに合格したら、次のように入力してサービスを再起動できます。

sudo service nsd restart

ログをチェックして、問題がないことを確認します。

sudo tail -f /var/log/nsd.log

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

これで、権限のあるNSDサーバーが構成され、ドメインに関するDNS情報を提供する準備ができました。 ただし、ネームサーバーを使用することを認識できるように、ドメインを構成する必要があります。

これを行うには、ドメイン名を購入したレジストラでいくつかの設定を調整する必要があります。 用語の一部と確かにインターフェースはレジストラによって異なりますが、注意深く見れば設定を見つけることができるはずです。

これを行う方法を、かなり標準的なドメイン名登録機関であるhttps://www.namecheap.com/[Namecheap]で実演します。

ドメインの親に*グルーレコード*を設定できるように、ネームサーバーを調整する必要があります。 これは、ネームサーバーがドメイン内にある場合に必ず必要です。

サブドメイン(「+ com 」ドメインの「 example.com +」など)を委任する場合、ドメインに対して権限のあるネームサーバーを指定する必要があります。 ネームサーバーがドメイン内にある場合、_also_グルーレコードを含める必要があります。これは、委任ゾーンに対して権限を持つ各ネームサーバーのAレコードにすぎません。

グルーレコードが含まれていないとDNSルックアップがループに巻き込まれるため、これが必要です。 クライアントは、ドメイン `+ example.com `に対して権限のあるレジストラに問い合わせ、レジストラは(設定後) ` ns1.example.com `および ` ns2.example.com +`を返します。 これらをIPアドレスに解決するためのAレコードを含めない場合、クライアントはこのポイントを超えて移動することはできません。 これらは通常ネームサーバー自体で定義されるため、必要なネームサーバーのIPアドレスを見つける方法はありません。

レジストラのインターフェースでネームサーバーを構成できる場所とその関連IPアドレスは、プロバイダーによって異なります。 Namecheapには、ネームサーバーのIPアドレスを設定してグルーレコードを作成できる「Nameserver Registration」というセクションがあります。

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

ここで、ネームサーバーをセットアップし、特定のIPアドレスにマップできます。

image:https://assets.digitalocean.com/articles/bind_auth/give_ips.png [Namecheapマップネームサーバー]

これが完了したら、ドメインで使用されているアクティブなネームサーバーを設定する必要があります。 Namecheapには、以下を実現する「ドメインネームサーバーセットアップ」というオプションがあります。

image:https://assets.digitalocean.com/articles/bind_auth/server_setup.png [Namecheap set nameservers]

そのオプションを選択したときに表示されるインターフェイスで、登録したネームサーバーのホスト名を入力できます。

image:https://assets.digitalocean.com/articles/bind_auth/use_servers.png [Namecheap input nameservers]

レジストラで行った変更が反映されるまでに時間がかかる場合があります。 データが他の世界中のDNSサーバーに拡散するのにも時間がかかります。 通常、このプロセスは次の24〜48時間で完了します。

結論

このガイドを使用して、ドメインに関するDNS情報を提供するために使用できるプライマリおよびセカンダリの権限のみのDNSサーバーが必要になります。 Bindとは異なり、NSDは高性能の信頼できる動作向けに最適化されているため、ニーズに合わせて調整された優れたパフォーマンスを得ることができます。