Ubuntu14.04で権限のみのDNSサーバーであるNSDを使用する方法

投稿日: 2022-07-24 2022-10-18
タグ: dns, Networking, ubuntu

序章

ドメイン名を担当する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.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、ただし、パッケージは実際にはこのユーザーアカウントを作成しません。

インストール時のエラーを回避するために、ソフトウェアをインストールする前にこのユーザーを作成します。各マシンで、を作成します 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の主な構成ファイルは、 nsd.conf にあります /etc/nsd ディレクトリ。

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

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. これらのほとんどを構成に使用します。

まず、DNSサーバーの基本的なプロパティをで構成する必要があります server セクション。デフォルトの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 「はい」への指示。

次に、キーファイルと証明書ファイルを指定する行のコメントを解除できます。これらは、実行時に生成されたファイル名と一致します 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
                        )

これにより、ゾーン全体の値が定義されます。 The ns1.example.com. valueは、このゾーンの権限のあるサーバーの1つのドメインの場所を指定するために使用されます。 The admin.example.com. ゾーン管理者に連絡できる電子メールアドレスを指定するために使用されます。

この場合のメールアドレスは [email protected]. 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ファイルを構成します

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

これはほぼ正確に私たちが必要としているものです。

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

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

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

同様の方法で、を変更する必要があります provide-xfr パラメータから request-xfr. この形式は少し変更されます。 AXFR転送（NSDプライマリが可能な唯一の種類）が必要であることを指定する必要があり、プライマリのIPアドレスおよびを指定する必要があります。

The 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 を設定できるように、ネームサーバーを調整する必要があります。これは、ネームサーバーがドメイン自体の内にある場合は常に必要です。

サブドメインを委任するとき（ example.com から 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は高性能の信頼できる動作用に最適化されているため、ニーズに合わせて特別に調整されたパフォーマンスを向上させることができます。

getdocs

13036