序章
ドメイン名を担当するDNSサーバーを設定することは、経験豊富な管理者にとっても複雑な作業になる可能性があります。 DNSゾーンの管理は重要な義務ですが、特に始めようとすると、当惑する可能性があります。
Bind DNSサーバーのようなソフトウェアは非常に柔軟性があり、DNS階層全体で多くのコンポーネントを操作するように構成できます。 ただし、その柔軟性は、バインドが1つのタスクに対して最適化されていないことも意味します。 これにはいくつかの副作用があります。
ほとんどの場合、構成に必要のない機能の巨大なチャンクがあります。 この追加の複雑さにより、管理がより困難になります。 また、ソフトウェア自体が1つのタスクに対して応答性が低くなることも意味します。
この問題を解決するために、DNS解決の単一の領域に特化した代替DNSサーバーが作成されました。 NSD と呼ばれるソフトウェアは、DNSゾーンを正式に管理するのに理想的な、権限のみのDNSサーバーです。 再帰やキャッシュについて心配する必要がないため、このサーバーは高性能でフットプリントが小さくなります。
このガイドでは、Ubuntu14.04サーバーでDNSゾーンを安全に管理するためにNSDをインストールおよび構成する方法を示します。
前提条件と目標
このガイドを開始する前に、いくつかの基本的なDNSの概念と用語に精通している必要があります。 権限のある専用DNSサーバーが何に使用されているかを理解するためのヘルプが必要な場合は、DNSサーバータイプの違いに関するガイドを確認してください。
権限のみの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サーバー | www.example.com。 | 192.0.2.3 |
このガイドを終了したら、最初の2台のサーバーをNSDで構成して、ゾーンの権限のみのサーバーとして機能させる必要があります。 インターネットからサーバーにアクセスするために構成されたホスト名を使用したり、IPアドレスを照会してホスト名を確認したりできます。 サーバーに到達できる解決クライアントは、サーバーからドメインデータを取得できます。
ネームサーバーでのホスト名の設定
私たちが取るべき最初のステップは準備段階です。 DNS構成について心配する前に、ネームサーバーが必要な方法で独自のホスト名を正しく解決できることを確認する必要があります。
最初のDNSサーバーで、/etc/hostsファイルを編集して、このコンピューターのFQDNを設定します。
sudo nano /etc/hosts
この場合、192.0.2.1IPアドレスをファーストネームサーバーのフルネーム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というユーザーとして実行されることを想定していますが、パッケージは実際にはこのユーザーアカウントを作成しません。
インストール時のエラーを回避するために、ソフトウェアをインストールする前にこのユーザーを作成します。 各マシンで、次のように入力してnsdシステムユーザーを作成します。
sudo useradd -r nsd
これにより、インストールを正常に完了するために必要な正しいアカウントが作成されます。
これで、NSDソフトウェアをインストールする必要があります。 幸い、NSDはUbuntu 14.04リポジトリに含まれているため、aptを使用してプルダウンできます。 ローカルパッケージインデックスを更新してから、適切なパッケージをダウンロードします。
sudo apt-get update
sudo apt-get install nsd
これにより、ソフトウェアがインストールされ、初期構成が行われます。 また、まだ何も提供するように構成していなくても、サービスを開始します。
プライマリNSDサーバーを構成する
まず、ns1サーバーをセットアップします。このサーバーは、ゾーンのプライマリDNSサーバーとして構成されます。
最初に行うべきことは、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は必要な逆マッピングを自動的に作成します。
リバースマッピングの詳細については、Bindauthority-onlyガイドの「ABitAboutReverseZones」セクションを参照してください。 情報提供と柔軟性の向上のためにNSDのリバースゾーンを設定する方法を示します。ただし、これは、IPブロックのリバースマッピングの制御が委任されている場合にのみ関係します。
逆引きゾーンの場合、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.は、ゾーン管理者に連絡できる電子メールアドレスを指定するために使用されます。
この場合のメールアドレスはadmin@example.comです。 DNSゾーンファイルでは、「@」記号をドットに変更する必要があります。 FQDNを指定する場合は常に終了ドットであるため、終了ドットも重要です。
括弧内の値は、ゾーンの値の一部を定義します。 ここで言及するのはシリアル番号だけです。 この値は、ゾーンファイルに変更を加えるたびに増分する必要があります。 ここでは、この記事の執筆日（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アドレスおよびを指定する必要があります。
終了すると、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を使用してこれを行う方法を示します。
ドメインの親にgluerecords を設定できるように、ネームサーバーを調整する必要があります。 これは、ネームサーバーがドメイン自体の内にある場合は常に必要です。
サブドメイン（comドメインからexample.comなど）を委任する場合は、ドメインに対して権限のあるネームサーバーを指定する必要があります。 ネームサーバーがドメイン内にある場合は、またにグルーレコードを含める必要があります。これは、委任されたゾーンに対して権限を持つ各ネームサーバーの単なるAレコードです。
グルーレコードが含まれていない場合、DNSルックアップがループに巻き込まれるため、これが必要です。 クライアントは、ドメインexample.comの権限を持つレジストラに問い合わせると、レジストラは（これを設定した後）ns1.example.comとns2.example.comを返します。 これらをIPアドレスに解決するためのAレコードを含めないと、クライアントはこのポイントを超えて移動できなくなります。 必要なネームサーバーのIPアドレスは通常、ネームサーバー自体で定義されているため、これらのIPアドレスを見つける方法はありません。
ネームサーバーおよびに関連付けられたIPアドレスを構成できるレジストラのインターフェイス内の場所は、プロバイダーによって異なります。 Namecheapには、「Nameserver Registration」と呼ばれるセクションがあり、ネームサーバーのIPアドレスを設定してグルーレコードを作成できます。
ここで、ネームサーバーを設定し、それらを特定のIPアドレスにマップできます。
これが完了したら、ドメインで使用されているアクティブなネームサーバーを設定する必要があります。 Namecheapには、次のことを実現する「ドメインネームサーバーのセットアップ」と呼ばれるオプションがあります。
そのオプションを選択したときに表示されるインターフェイスで、登録したネームサーバーのホスト名を入力できます。
レジストラで行った変更は、反映されるまでに時間がかかる場合があります。 また、データが世界の他のDNSサーバーに拡散するまでにさらに時間がかかります。 通常、このプロセスは24〜48時間以内に完了する必要があります。
結論
このガイドを使用すると、ドメインに関するDNS情報を提供するために使用できるプライマリおよびセカンダリの権限のみのDNSサーバーが作成されます。 バインドとは異なり、NSDは高性能の信頼できる動作用に最適化されているため、ニーズに合わせて特別に調整されたパフォーマンスを向上させることができます。
