前書き
ドメイン名を担当するようにDNSサーバーを設定することは、ベテランの管理者にとっても複雑な作業です。 DNSゾーン管理は重要な任務ですが、特に開始しようとするときは戸惑う可能性があります。
Bind DNSサーバーのようなソフトウェアは非常に柔軟性があり、DNS階層全体でできるだけ多くのコンポーネントを操作するように構成できます。 ただし、その柔軟性は、バインドが1つのタスクに対して最適化されていないことも意味します。 これにはいくつかの副作用があります。
ほとんどの場合、構成に必要のない機能の巨大なチャンクがあります。 この追加の複雑さにより、管理がより困難になります。 また、ソフトウェア自体が1つのタスクに対して応答性が低下することも意味します。
この問題を解決するために、DNS解決の単一の領域に特化した代替DNSサーバーが作成されました。 NSDと呼ばれるソフトウェアは、DNSゾーンを権限を持って管理するのに理想的な権限のみのDNSサーバーです。 再帰やキャッシュについて心配する必要なく、このサーバーは高いパフォーマンスと低いフットプリントで動作します。
このガイドでは、Ubuntu 14.04サーバーでDNSゾーンを安全に管理するためにNSDをインストールおよび構成する方法を示します。
前提条件と目標
このガイドを開始する前に、いくつかのbasic DNS concepts and terminologyについて理解しておく必要があります。 権限のみのDNSサーバーが何に使用されているかを理解するためのヘルプが必要な場合は、the differences between DNS server typesに関するガイドを確認してください。
権限を持つDNSサーバーとして、NSDはキャッシュ、転送、または再帰的な機能を提供しません。 制御するゾーンに対する反復要求にのみ応答します。 また、委任されたゾーンのリゾルバーを他のネームサーバーに参照することもできます。
このガイドでは、ゾーンのプライマリサーバーとセカンダリサーバーとして機能するように、NSDソフトウェアを備えた2台のサーバーを構成します。 また、クライアントが3番目のホスト上の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台のサーバーを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
192.0.2.1 ns1.example.com ns1
完了したら、ファイルを保存して閉じます。
次に、/etc/hostname
ファイルを再確認する必要があります。
sudo nano /etc/hostname
これには、unqualifiedのホスト名の値が含まれている必要があります。 必要に応じて変更します。
ns1
完了したら、ファイルを保存して閉じます。
上記の/etc/hostname
ファイルを変更した場合は、ファイルを再読み取りするようにシステムに指示してください。
sudo hostname -F /etc/hostname
とりあえず、最初のDNSサーバーを使用しました。 2番目のサーバーで手順を繰り返します。
/etc/hosts
ファイルを変更して、2番目のDNSサーバーのホストを指定します。
sudo nano /etc/hosts
127.0.0.1 localhost
192.0.2.2 ns2.example.com ns2
/etc/hostname
ファイルも確認してください。 これには、非修飾の短い名前のみを使用する必要があります。
sudo nano /etc/hostname
ns2
繰り返しますが、何かを変更する必要がある場合は、システムにファイルを再読み込みさせます。
sudo hostname -F /etc/hostname
サーバーは、DNSを使用せずに独自の名前を解決できるようになりました。 これで、サーバーでNSDをセットアップする準備ができました。
両方のネームサーバーにNSDをインストールする
次のステップは、実際にネームサーバーにソフトウェアをインストールすることです。
開始する前に、実際にもう1つの準備手順を実行する必要があります。 リポジトリ内のNSDパッケージはソフトウェアをインストールし、いくつかのコンポーネントを構成し、サービスを開始しようとします。 サービスはnsd
というユーザーとして実行されることを想定していますが、パッケージは実際にはこのユーザーアカウントを作成しません。
インストール時のエラーを回避するために、ソフトウェアをインストールするこのユーザーbeforeを作成します。 各マシンで、次のように入力して、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
、および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がプライマリサーバーとセカンダリサーバー間のゾーン転送を安全に実行するために使用する秘密キーが含まれます。
使用する名前とアルゴリズムを設定する必要があります。 この例では、demokey
という名前を使用します。 また、彼らが選択したデフォルトのアルゴリズム(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
+kO0Vu6gC+9bxzMy3TIZVLH+fg==
上記の赤色の出力をコピーして、構成ファイルを再度開きます。 コピーした出力をsecret
パラメータの値として使用します。 このセクションは次のようになります。
key:
name: "demokey"
algorithm: hmac-sha256
secret: "+kO0Vu6gC+9bxzMy3TIZVLH+fg=="
次に、セカンダリサーバーに関連する反復的な情報があるため、単純なパターンを設定します。 毎回同じセカンダリにゾーンを通知して転送するため、パターンを作成することは理にかなっています。
パターンをtosecondary
と呼び、パターンの用途を説明します。 各ゾーンの名前とファイルを個別に設定するので、パターンでそれを心配する必要はありません。
パターンにnotify
パラメータを設定して、セカンダリサーバーのIPアドレスを参照します。 また、指定したキーを使用して、TSIGでゾーンを安全に転送します。 provide-xfr
パラメータをまったく同じ方法で設定します。
最終的に、pattern
セクションは次のようになります。
pattern:
name: "tosecondary"
notify: 192.0.2.2 demokey
provide-xfr: 192.0.2.2 demokey
最後に、zone
セクションに移動します。 ここでは、NSDが特定のゾーンとその関連ファイルを処理する方法を構成します。
最初に、順ゾーンを構成します。 example.com
ゾーンのゾーンを設定する必要があります。 これは、name
パラメータでドメイン自体を指定し、ゾーンファイルに使用する名前を指定し、これをセカンダリサーバーに転送するために上記で作成したパターンを含めるだけです。
デモの完成したフォワードゾーンは次のようになります。
zone:
name: "example.com"
zonefile: "example.com.zone"
include-pattern: "tosecondary"
次に、逆ゾーンを処理できます。 逆ゾーンは基本的に、DNSソフトウェアがクライアントのホスト名にIPアドレスをマップできるゾーンファイルです。 一般に、DigitalOceanのようなホスティングでは、これはホスティングプロバイダーによって処理されます。
たとえば、DigitalOceanを使用すると、逆マッピングを設定するためのIPアドレスの範囲に対する責任が委任されません。 代わりに、コントロールパネルでサーバーのホスト名をマップし直したいFQDNに設定すると、DigitalOceanは必要な逆マッピングを自動的に作成します。
Bind authoritative-only guideの「リバースゾーンについてのビット」セクションを読むと、リバースマッピングの詳細を学ぶことができます。 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
最初に行う必要があるのは、いくつかのパラメーターを上に設定することです。 構成しているドメインを指す$ORIGIN
パラメーターをFQDN形式(終了ドット付き)で設定します。 また、デフォルトの有効期間も設定します。 1800秒、つまり30分を使用します。
$ORIGIN example.com.
$TTL 1800
次に、SOA、または権限レコードの開始が必要です。 これは次のようになります。
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
これは、いくつかのゾーン全体の値を定義します。 ns1.example.com.
値は、このゾーンの権限のあるサーバーの1つのドメインの場所を指定するために使用されます。 admin.example.com.
は、ゾーン管理者に連絡できる電子メールアドレスを指定するために使用されます。
この場合の電子メールアドレスは[email protected]
です。 DNSゾーンファイルでは、「@」記号をドットに変更する必要があります。 終了ドットも重要です。これは、FQDNを指定するときに常に使用されるためです。
括弧内の値は、ゾーンの値の一部を定義します。 ここで言及するのは、シリアル番号だけです。 この値mustは、ゾーンファイルに変更を加えるたびに増分されます。 ここでは、この文書の日付(2014年7月2日)と改訂番号を使用してデモを行っています。
次に、NSレコードを使用して、このゾーンに対して権限のあるネームサーバーを定義する必要があります。 終了ドットを含むドメインのFQDNを使用することを忘れないでください:
IN NS ns1.example.com.
IN NS ns2.example.com.
次に、指定したネームサーバーに到達する方法をクライアントに実際に伝えるAレコードを設定する必要があります。 これは、ホスト名を実際のIPアドレスにマップするものです。
ns1 IN A 192.0.2.1
ns2 IN A 192.0.2.2
最後に、他のホストのAレコードを追加します。 この例では、ベースドメイン(example.com
)とwww
ホスト名を設定してWebサーバーにマップします。
@ IN A 192.0.2.3
www IN A 192.0.2.3
終了すると、完成したファイルは次のようになります。
$ORIGIN example.com.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
; Name servers
IN NS ns1.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
; Additional A records
@ IN A 192.0.2.3
www IN A 192.0.2.3
完了したら、ファイルを保存して閉じます。
逆ゾーンファイルを作成する
次に、逆ゾーン用に同様のファイルを作成します。 これは、アドレスブロックの逆マッピングの責任を委任されている場合にのみ必要であることに注意してください。
nsd.conf
ファイルで参照した逆引きゾーンファイルを作成し、テキストエディタでsudo権限で開きます。
sudo nano /etc/nsd/192.0.2.zone
ここでも、$ORIGIN
パラメーターと$TTL
パラメーターを定義することから始めます。 今回は、原点をゾーンのin-addr.arpa
サブドメインに設定することを忘れないでください。 この場合、これは次のようになります。
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
次に、以前と同様にSOAレコードを設定する必要があります。 同じメールと権限のあるネームサーバーが両方のゾーンを担当するため、このファイルにはまったく同じ値を使用できます。 さらに、この例でも数値が機能するはずです。 変更するたびにシリアル番号を変更することを忘れないでください:
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; ttl
)
終了すると、ファイルは次のようになります。
この場合も、ゾーンに対して権限のあるネームサーバーを定義する必要があります。 これらは再び同じサーバーになります。
IN NS ns1.example.com.
IN NS ns2.example.com.
最後に、PTRレコードを使用して、各IPアドレスの最後のオクテットを関連付けられたホストのFQDNにルーティングすることにより、実際の逆ドメインマッピングを提供する必要があります。
1 IN PTR ns1.example.com.
2 IN PTR ns2.example.com.
3 IN PTR www.example.com.
終了すると、ファイルは次のようになります。
$ORIGIN 2.0.192.in-addr.arpa.
$TTL 1800
@ IN SOA ns1.example.com. admin.example.com. (
2014070201 ; serial number
3600 ; refresh
900 ; retry
1209600 ; expire
1800 ; 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.
完了したら、ファイルを保存して閉じます。
ファイルのテストとサービスの再起動
プライマリサーバーを構成したら、構成ファイルをテストして変更を実装できます。
付属の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
セクションmustの「シークレット」はプライマリサーバーの値と一致するため、ファイルの内容全体をコピーすると、この要件を簡単に満たすことができます。
最初に変更する必要があるのは、pattern
セクションです。 コピーしたセクションはプライマリサーバーに固有であるため、セカンダリサーバーの観点から物事に対処するように変更します。
まず、名前をよりわかりやすい名前に変更します。 同じ規則を使用して、これをfromprimary
と呼びます。 また、これが設定するディレクティブを変更する必要があります。 セカンダリサーバーには、notify
パラメーターの代わりに、通知を許可するサーバーを指定するallow-notify
パラメーターが必要です。 引き続き同じキーを使用するため、名前と適切なIPアドレスを変更するだけです。
同様に、provide-xfr
パラメータをrequest-xfr
に変更する必要があります。 この形式はわずかに変更されます。 AXFR転送(NSDプライマリが可能な唯一の種類)が必要であることを指定する必要があり、プライマリのポート番号であるIPアドレスandを指定する必要があります。
終了すると、pattern
セクションは次のようになります。
pattern:
name: "fromprimary"
allow-notify: 192.0.2.1 demokey
request-xfr: AXFR 192.0.2.1@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情報を提供する準備ができました。 ただし、ネームサーバーを使用することを認識できるようにドメインを構成する必要があります。
これを行うには、ドメイン名を購入したレジストラでいくつかの設定を調整する必要があります。 用語の一部と確かにインターフェースはレジストラによって異なりますが、注意深く見れば設定を見つけることができるはずです。
かなり標準的なドメイン名レジストラであるNamecheapを使用してこれを行う方法を示します。
ドメインの親にglue recordsを設定できるように、ネームサーバーを調整する必要があります。 これは、ネームサーバーがドメイン自体のwithinである場合に必要です。
サブドメイン(com
ドメインからのexample.com
など)を委任する場合は、ドメインに対して権限のあるネームサーバーを指定する必要があります。 ネームサーバーがドメイン内にある場合は、alsoにグルーレコードを含める必要があります。これは、委任されたゾーンに対して権限を持つ各ネームサーバーの単なるAレコードです。
グルーレコードが含まれていないとDNSルックアップがループに巻き込まれるため、これが必要です。 クライアントは、ドメインexample.com
の権限を持つレジストラに問い合わせると、レジストラは(これを設定した後)ns1.example.com
とns2.example.com
を返します。 これらをIPアドレスに解決するためのAレコードを含めない場合、クライアントはこのポイントを超えることはできません。 これらは通常ネームサーバー自体で定義されるため、必要なネームサーバーのIPアドレスを見つける方法はありません。
ネームサーバーandに関連付けられたIPアドレスを構成できるレジストラのインターフェイス内の場所は、プロバイダーによって異なります。 Namecheapには、ネームサーバーのIPアドレスを設定してグルーレコードを作成できる「Nameserver Registration」というセクションがあります。
ここで、ネームサーバーをセットアップし、特定のIPアドレスにマップできます。
これが完了したら、ドメインで使用されているアクティブなネームサーバーを設定する必要があります。 Namecheapには、以下を実現する「ドメインネームサーバーセットアップ」というオプションがあります。
そのオプションを選択したときに表示されるインターフェイスで、登録したネームサーバーのホスト名を入力できます。
レジストラで行った変更が反映されるまでに時間がかかる場合があります。 データが他の世界中のDNSサーバーに拡散するのにも時間がかかります。 通常、このプロセスは次の24〜48時間で完了します。
結論
このガイドを使用して、ドメインに関するDNS情報を提供するために使用できるプライマリおよびセカンダリの権限のみのDNSサーバーが必要になります。 Bindとは異なり、NSDは高性能の信頼できる動作向けに最適化されているため、ニーズに合わせて調整された優れたパフォーマンスを得ることができます。