Ubuntu 14.04で権限のあるDNSサーバーであるNSDを使用する方法

前書き

ドメイン名を担当するように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サーバー

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というユーザーとして実行されることを想定していますが、パッケージは実際にはこのユーザーアカウントを作成しません。

インストール時のエラーを回避するために、ソフトウェアをインストールするこのユーザー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

内部には、コメント化されたいくつかの構成行がセクションに編成されています。 主なセクションは、serverremote-controlkeypattern、および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"

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

serverremote-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.comns2.example.comを返します。 これらをIPアドレスに解決するためのAレコードを含めない場合、クライアントはこのポイントを超えることはできません。 これらは通常ネームサーバー自体で定義されるため、必要なネームサーバーのIPアドレスを見つける方法はありません。

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

Namecheap nameserver registration

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

Namecheap map name servers

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

Namecheap set nameservers

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

Namecheap input nameservers

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

結論

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

Related