序章


DNS(ドメインネームシステム)は、Webサイトやサーバーの構成方法を学ぶときに、正しく理解するのが難しいコンポーネントであることがよくあります。 ほとんどの人はおそらくホスティング会社またはドメインレジストラが提供するDNSサーバーを使用することを選択しますが、独自のDNSサーバーを作成することにはいくつかの利点があります。

このガイドでは、Ubuntu14.04マシンにBind9DNSサーバーを権限のある専用DNSサーバーとしてインストールおよび構成する方法について説明します。 これらの2つのバインドサーバーを、プライマリ-セカンダリ構成でドメインに設定します。

前提条件と目標

このガイドを完了するには、最初にいくつかの一般的なDNS用語に精通している必要があります。 このガイドで実装する概念については、このガイドをご覧ください。

また、少なくとも2台のサーバーが必要です。 1つはドメインのゾーンファイルが発信される「プライマリ」DNSサーバー用で、もう1つは転送を通じてゾーンデータを受信し、他のサーバーがダウンした場合に利用できる「セカンダリ」サーバー用です。 これにより、DNSサーバーに単一障害点が発生する危険性を回避できます。

DNSサーバーのキャッシュまたは転送または多目的DNSサーバーとは異なり、権限のみのサーバーは、権限のあるゾーンの反復クエリにのみ応答します。 これは、サーバーが回答を知らない場合、クライアント(通常はある種の解決DNSサーバー)に回答を知らないことを通知し、より多くのことを知っている可能性のあるサーバーへの参照を提供することを意味します。

権限のみのDNSサーバーは、クライアントからの再帰クエリを解決するオーバーヘッドがないため、多くの場合、高性能を実現するための適切な構成です。 彼らは彼らが奉仕するように設計されているゾーンだけを気にします。

このガイドでは、実際には3台のサーバーを参照します。 上記の2つのネームサーバーと、ゾーン内のホストとして構成する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つの権限のみのネームサーバーが構成されているはずです。 上の表の中央の列にある名前は、さまざまなホストに到達するために使用できます。 この構成を使用すると、再帰DNSサーバーはドメインに関するデータをクライアントに返すことができます。

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

ネームサーバーの構成に入る前に、プライマリDNSサーバーとセカンダリDNSサーバーの両方でホスト名が正しく構成されていることを確認する必要があります。

/etc/hostsファイルを調査することから始めます。 テキストエディタでsudo権限でファイルを開きます。

sudo nano /etc/hosts

各サーバーのホスト名とFQDNを正しく識別するようにこれを構成する必要があります。 プライマリネームサーバーの場合、ファイルは最初は次のようになります。

127.0.0.1       localhost
127.0.1.1       ns1 ns1
. . .

2行目を変更して、特定のホストとドメインの組み合わせを参照し、これをパブリックの静的IPアドレスにポイントする必要があります。 次に、修飾されていない名前をエイリアスとして最後に追加できます。 この例のプライマリサーバーの場合、2行目を次のように変更します。

127.0.0.1       localhost
192.0.2.1       ns1.example.com ns1
. . .

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

また、/etc/hostnameファイルを変更して、修飾されていないホスト名を含める必要があります。

sudo nano /etc/hostname
ns1

次のように入力することで、現在実行中のシステムにこの値を読み込むことができます。

sudo hostname -F /etc/hostname

セカンダリサーバーで同じ手順を実行します。

/etc/hostsファイルから始めます。

sudo nano /etc/hosts
127.0.0.1       localhost
192.0.2.2       ns2.example.com ns2

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

次に、/etc/hostnameファイルを変更します。 このファイルには、実際のホスト(この例ではns2のみ)のみを使用することを忘れないでください。

sudo nano /etc/hostname
ns2

もう一度、ファイルを読んで現在のシステムを変更します。

sudo hostname -F /etc/hostname

これで、サーバーのホスト定義が正しく設定されているはずです。

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

これで、各ネームサーバーに、使用するDNSサーバーであるBindをインストールできます。

BindソフトウェアはUbuntuのデフォルトのリポジトリ内で利用できるため、ローカルパッケージインデックスを更新し、aptを使用してソフトウェアをインストールする必要があります。 ドキュメントといくつかの一般的なユーティリティも含まれます。

sudo apt-get update
sudo apt-get install bind9 bind9utils bind9-doc

プライマリおよびセカンダリDNSサーバーでこのインストールコマンドを実行して、適切なファイルを取得します。

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

ソフトウェアがインストールされたので、プライマリサーバーでDNSサーバーを構成することから始めます。

オプションファイルの設定

開始するために最初に構成するのは、named.conf.optionsファイルです。

BindDNSサーバーはnamedとも呼ばれます。 メインの設定ファイルは/etc/bind/named.confにあります。 このファイルは、実際に構成する他のファイルを呼び出します。

エディターでsudo権限を持つオプションファイルを開きます。

sudo nano /etc/bind/named.conf.options

以下では、コメント行のほとんどを簡潔にするために削除していますが、一般に、インストール後のファイルは次のようになります。

options {
        directory "/var/cache/bind";

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

このファイルで構成する必要がある主なものは再帰です。 権限のある専用サーバーをセットアップしようとしているため、このサーバーで再帰を有効にしたくありません。 optionsブロック内でこれをオフにすることができます。

また、デフォルトで転送を許可しないようにします。 後で個々のゾーン仕様でこれをオーバーライドします。

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

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

ローカルファイルの構成

次のステップは、このサーバーを制御するゾーンを指定することです。 ゾーンは、他のサーバーにサブ委任されていないネームサーバーに管理のために委任されたドメインの任意の部分です。

example.comドメインを構成しており、ドメインの一部の責任を他のサーバーにサブ委任することはありません。 したがって、ゾーンはドメイン全体をカバーします。

ゾーンを構成するには、sudo権限で/etc/bind/named.conf.localファイルを開く必要があります。

sudo nano /etc/bind/named.conf.local

このファイルは、コメント以外は最初は空になります。 サーバーが一般的な管理のために知っているゾーンは他にもありますが、これらはnamed.conf.default-zonesファイルで指定されています。

まず、example.comドメインの転送ゾーンを構成する必要があります。 フォワードゾーンは、DNSについて議論するときに私たちのほとんどが考える従来の名前からIPへの解決策です。 構成するドメインゾーンを定義する構成ブロックを作成します。

zone "example.com" {
};

ノート: 多くのDNSツール、それらの構成ファイル、およびドキュメントでは、「マスター」および「スレーブ」という用語が使用されていますが、DigitalOceanは通常、代替記述子を好みます。 混乱を避けるために、サーバー間の関係を表すために「プライマリ」と「セカンダリ」という用語を使用し、構成ディレクティブで必要な場合にのみ「マスター」または「スレーブ」を使用することを選択しました。

このブロック内に、このゾーンに関する管理情報を追加します。 このDNSサーバーとゾーンの関係を指定します。 これは、次のゾーンの例ではtype master;です。これは、このマシンをすべてのゾーンのプライマリネームサーバーとして構成しているためです。 また、ゾーンを定義する実際のリソースレコードを保持するファイルにバインドを指定します。

プライマリゾーンファイルを、Bind構成ディレクトリ内のzonesというサブディレクトリに保持します。 ファイルdb.example.comを呼び出して、Bindディレクトリ内の他のゾーンファイルから規則を借用します。 ブロックは次のようになります。

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
};

このゾーンをセカンダリサーバーに転送できるようにするために、次のような行を追加する必要があります。

zone "example.com" {
    type master;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 192.0.2.2; };
};

次に、ドメインの逆引きゾーンを定義します。

リバースゾーンについて少し

IPアドレスを提供した組織がネットワーク範囲を提供せず、その範囲の責任をあなたに委任した場合、リバースゾーンファイルは参照されず、組織自体によって処理されます。

ホスティングプロバイダーの場合、逆マッピングは通常、会社自体が処理します。 たとえば、DigitalOceanでは、コントロールパネルでサーバー名としてマシンのFQDNを使用すると、サーバーの逆マッピングが自動的に作成されます。 たとえば、このチュートリアルの逆マッピングは、サーバーに次のように名前を付けることで作成できます。

DigitalOcean auto reverse DNS mapping

このような場合、管理するアドレスのチャンクが割り当てられていないため、この戦略を使用する必要があります。 以下に概説する戦略は、完全を期すために、また、隣接するアドレスのより大きなグループに対する制御を委任された場合に適用できるようにするためにカバーされています。

リバースゾーンは、IPアドレスをドメイン名に接続するために使用されます。 ただし、ドメインネームシステムは元々フォワードマッピング用に設計されていたため、リバースマッピングを可能にするためにこれを適応させるためにいくつかの考慮が必要です。

リバースマッピングを理解するために覚えておく必要のある情報は次のとおりです。

  • ドメインでは、アドレスの最も具体的な部分は左側にあります。 IPアドレスの場合、最も具体的な部分は右側にあります。
  • ドメイン仕様の最も具体的な部分は、サブドメインまたはホスト名のいずれかです。 これは、ドメインのゾーンファイルで定義されています。
  • 各サブドメインは、さらに多くのサブドメインまたはホストを定義できます。

すべての逆引きゾーンマッピングは、Internet Assigned Numbers Authority(IANA)によって制御される特別なドメインin-addr.arpaの下で定義されます。 このドメインの下には、サブドメインを使用してIPアドレスの各オクテットをマップするツリーが存在します。 IPアドレスの特異性が通常のドメインの特異性を反映していることを確認するために、IPアドレスのオクテットは実際には逆になっています。

したがって、IPアドレスが192.0.2.1のプライマリDNSサーバーは、1.2.0.192として読み取られるように反転されます。 このホスト仕様をin-addr.arpaドメインの下に存在する階層として追加すると、特定のホストを1.2.0.192.in-addr.arpaとして参照できます。

DNSを使用する場合、ゾーンファイル自体に個々のホスト(ここでは先頭の「1」など)を定義するため、構成するゾーンは2.0.192.in-addr.arpaになります。 私たちのネットワークプロバイダーが私たちにアドレスの/24ブロック、たとえば192.0.2.0/24を与えた場合、彼らはこのin-addr.arpaの部分を私たちに委任したでしょう。

逆引きゾーン名を指定する方法がわかったので、実際の定義は順引きゾーンとまったく同じです。 example.comゾーン定義の下に、指定されたネットワークの逆引きゾーンを作成します。 繰り返しますが、これはおそらく、アドレスのブロックに対する制御を委任された場合にのみ必要です。

zone "2.0.192.in-addr.arpa" {
    type master;
    file "/etc/bind/zones/db.192.0.2";
};

ファイルにdb.192.0.2という名前を付けることにしました。 これは、ゾーンの構成に固有であり、逆表記よりも読みやすくなっています。

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

フォワードゾーンファイルを作成する

順方向ゾーンと逆方向ゾーンについてBindに説明しましたが、これらのゾーンを定義するファイルはまだ作成していません。

思い出してください。ファイルの場所は、zonesというサブディレクトリ内にあると指定しました。 次のディレクトリを作成する必要があります。

sudo mkdir /etc/bind/zones

これで、Bindディレクトリにある既存のゾーンファイルのいくつかを、作成するゾーンファイルのテンプレートとして使用できます。 フォワードゾーンの場合、db.localファイルは必要なものに近くなります。 そのファイルをzonesサブディレクトリにnamed.conf.localファイルで使用されている名前でコピーします。

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

これを行っている間、逆引きゾーンのテンプレートをコピーすることもできます。 db.127ファイルを使用します。これは、必要なものとほぼ一致しているためです。

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

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

sudo nano /etc/bind/zones/db.example.com

ファイルは次のようになります。

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1

最初に行う必要があるのは、最初の@記号で始まり、閉じ括弧まで続くSOA(権限の開始)レコードを変更することです。

localhost.をこのマシンのFQDNの名前に置き換える必要があります。 レコードのこの部分は、定義されているゾーンに対して正式に応答するネームサーバーを定義するために使用されます。 これは、現在構成しているマシンになります。この場合はns1.example.com.です(末尾のドットに注意してください)。 これは、エントリを正しく登録するために重要です!)。

また、次の部分を変更したいと思います。これは、実際には@がドットに置き換えられた特別にフォーマットされた電子メールアドレスです。 メールをドメインの管理者に送信する必要があるため、従来のメールはadmin@example.comです。 これをadmin.example.com.のように翻訳します。

@       IN      SOA     ns1.example.com. admin.example.com. (

次に編集する必要があるのはシリアル番号です。 シリアル番号の値は、Bindが更新された情報をセカンダリサーバーに送信する必要があるかどうかを通知する方法です。

:シリアル番号の増分に失敗することは、ゾーンの更新に関する問題につながる最も一般的な間違いの1つです。 編集するたびに、シリアル番号をバンプする必要があります。

一般的な方法の1つは、数を増やすための規則を使用することです。 1つのアプローチは、YYYYMMDD形式の日付と、末尾に追加された日のリビジョン番号を使用することです。 したがって、2014年6月5日に行われた最初のリビジョンのシリアル番号は2014060501であり、その日以降に行われた更新のシリアル番号は2014060502である可能性があります。 値は10桁の数値にすることができます。

使いやすさのために規則を採用する価値がありますが、デモンストレーションのために物事を単純にするために、今のところ5に設定します。

@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial

次に、ファイルの最後の3行(@で始まる下部の行)を削除して、独自の行を作成します。

SOAレコードの後で最初に確立したいのは、ゾーンのネームサーバーです。 ドメインを指定してから、ゾーンに対して権限のある2つのネームサーバーを名前で指定します。 これらのネームサーバーはドメイン自体のホストになるため、少し自己参照的に見えます。

ガイドの場合は、次のようになります。 繰り返しますが、末尾のドットに注意してください!:

; Name servers
example.com.    IN      NS      ns1.example.com.
example.com.    IN      NS      ns2.example.com.

ゾーンファイルの目的は主にホスト名とサービスを特定のアドレスにマップすることであるため、まだ完了していません。 このゾーンファイルを読み取るソフトウェアは、権限のあるゾーンにアクセスするために、ns1およびns2サーバーがどこにあるかを知りたいと考えています。

次に、これらのネームサーバー名をネームサーバーの実際のIPアドレスに関連付けるAレコードを作成する必要があります。

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

ネームサーバーを正しいIPアドレスに正常に解決するためのAレコードができたので、レコードを追加できます。 ホストの1つに、サイトのサービスに使用するWebサーバーがあることを忘れないでください。 一般ドメイン(この場合はexample.com)のリクエストと、wwwホストのリクエストをポイントします。 次のようになります。

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

追加のAレコードを作成することにより、定義する必要のあるホストを追加できます。 DNS基本ガイドを参照して、追加のレコードを作成する際のオプションのいくつかを理解してください。

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

$TTL    604800
@       IN      SOA     ns1.example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;

; Name servers
example.com.    IN      NS      ns1.example.com.
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

; Other A records
@               IN      A       192.0.2.3
www             IN      A       192.0.2.3

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

リバースゾーンファイルを作成する

これでフォワードゾーンが構成されましたが、構成ファイルで指定したリバースゾーンファイルを設定する必要があります。 前のセクションの冒頭ですでにファイルを作成しました。

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

sudo nano db.192.0.2

ファイルは次のようになります。

$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

フォワードゾーンで行ったのとほとんど同じ手順を実行します。 まず、ドメイン名、管理者の電子メール、およびシリアル番号を、最後のファイルにあったものと正確に一致するように調整します(シリアル番号は異なる場合がありますが、インクリメントする必要があります)。

@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial

ここでも、SOAレコードの閉じ括弧の下の行を消去します。 ネットワーク範囲内の各IPアドレスの最後のオクテットを取得し、PTRレコードを使用してそのホストのFQDNにマッピングし直します。 一部のソフトウェアでの問題を回避するために、各IPアドレスには単一のPTRレコードのみを含める必要があるため、リバースマップ先のホスト名を選択する必要があります。

たとえば、メールサーバーを設定している場合、多くのシステムがアドレスを検証するために逆マッピングを使用するため、メール名への逆マッピングを設定することをお勧めします。

まず、ネームサーバーを再度設定する必要があります。

; Name servers
        IN      NS      ns1.example.com.
        IN      NS      ns2.example.com.

次に、参照しているIPアドレスの最後のオクテットを使用し、それを返したい完全修飾ドメイン名を指し示します。 この例では、これを使用します。

; PTR Records
1       IN      PTR      ns1.example.com.
2       IN      PTR      ns2.example.com.
3       IN      PTR      www.example.com.

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

$TTL    604800
@       IN      SOA     example.com. admin.example.com. (
                              5         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache 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.

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

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

これでプライマリサーバーの構成は完了しましたが、変更を実装する必要があります。

サービスを再起動する前に、すべての構成ファイルをテストして、正しく構成されていることを確認する必要があります。 各ファイルの構文をチェックできるツールがいくつかあります。

まず、named-checkconfコマンドを使用して、named.conf.localおよびnamed.conf.optionsファイルを確認できます。 これらのファイルは両方ともスケルトンnamed.confファイルによってソースされているため、変更したファイルの構文をテストします。

sudo named-checkconf

これがメッセージなしで返される場合は、named.conf.localおよびnamed.conf.optionsファイルが構文的に有効であることを意味します。

次に、ゾーンが処理するドメインとゾーンファイルの場所をnamed-checkzoneコマンドに渡すことで、個々のゾーンファイルを確認できます。 したがって、ガイドでは、次のように入力してフォワードゾーンファイルを確認できます。

sudo named-checkzone example.com /etc/bind/zones/db.example.com

ファイルに問題がない場合は、正しいシリアル番号がロードされ、「OK」メッセージが表示されるはずです。

zone example.com/IN: loaded serial 5
OK

他のメッセージが表示された場合は、ゾーンファイルに問題があることを意味します。 通常、メッセージはどの部分が無効であるかについて非常に説明的です。

in-addr.arpaアドレスとファイル名を渡すことで、逆引きゾーンを確認できます。 デモンストレーションでは、次のように入力します。

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

繰り返しますが、これにより、正しいシリアル番号のロードについて同様のメッセージが表示されます。

zone 2.0.192.in-addr.arpa/IN: loaded serial 5
OK

すべてのファイルがチェックアウトしている場合は、バインドサービスを再起動できます。

sudo service bind9 restart

次のように入力してログを確認する必要があります。

sudo tail -f /var/log/syslog

このログを監視して、エラーがないことを確認してください。

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

プライマリサーバーが構成されたので、次にセカンダリサーバーをセットアップします。 これは、プライマリサーバーよりも大幅に簡単になります。

オプションファイルの設定

ここでも、named.conf.optionsファイルから始めます。 テキストエディタでsudo権限を使用して開きます。

sudo nano /etc/bind/named.conf.options

このファイルには、プライマリサーバーのファイルに加えたのとまったく同じ変更を加えます。

options {
        directory "/var/cache/bind";
        recursion no;
        allow-transfer { none; };

        dnssec-validation auto;

        auth-nxdomain no;    # conform to RFC1035
        listen-on-v6 { any; };
};

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

ローカル構成ファイルの構成

次に、セカンダリサーバーでnamed.conf.localファイルを構成します。 テキストエディタでsudo権限を使用して開きます。

sudo nano /etc/bind/named.conf.local

ここでは、プライマリサーバーで行ったように、各ゾーン仕様を作成します。 ただし、値と一部のパラメーターは異なります。

まず、フォワードゾーンに取り組みます。 プライマリファイルで行ったのと同じ方法で開始します。

zone "example.com" {
};

今回は、このサーバーがこのゾーンのセカンダリとして機能しているため、typeslaveに設定します。 これは単に、ローカルシステム上のファイルではなく、転送を通じてゾーンファイルを受信することを意味します。 さらに、ゾーンファイルへの絶対パスではなく、相対ファイル名を指定するだけです。

これは、セカンダリゾーンの場合、Bindがファイル/var/cache/bindを保存するためです。 バインドはこのディレクトリの場所を検索するようにすでに構成されているため、パスを指定する必要はありません。

フォワードゾーンの場合、これらの詳細は次のようになります。

zone "example.com" {
    type slave;
    file "db.example.com";
};

最後に、allow-transferディレクティブの代わりに、このサーバーがゾーン転送を受け入れるプライマリサーバーをIPアドレスで指定します。 これは、mastersと呼ばれるディレクティブで行われます。

zone "example.com" {
    type slave;
    file "db.example.com";
    masters { 192.0.2.1; };
};

これでフォワードゾーンの指定は完了です。 これとまったく同じ形式を使用して、逆引きゾーンの指定を処理できます。

zone "2.0.192.in-addr.arpa" {
    type slave;
    file "db.192.0.2";
    masters { 192.0.2.1; };
};

終了したら、ファイルを保存して閉じることができます。

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

前述のように、このサーバーはプライマリサーバーからゾーンファイルを受信するため、セカンダリマシンで実際にゾーンファイルを作成する必要はありません。 これで、テストする準備が整いました。

ここでも、構成ファイルの構文を確認する必要があります。 チェックするゾーンファイルがないため、named-checkconfツールを使用するだけで済みます。

sudo named-checkconf

これがエラーなしで返される場合は、変更したファイルに構文エラーがないことを意味します。

この場合、バインドサービスを再起動できます。

sudo service bind9 restart

以下を使用して、プライマリサーバーとセカンダリサーバーの両方のログを確認します。

sudo tail -f /var/log/syslog

ゾーンファイルが正しく転送されたことを示すいくつかのエントリが表示されます。

権限をネームサーバーに委任する

これで、権限のみのネームサーバーが完全に構成されているはずです。 ただし、ドメインの権限をネームサーバーに委任する必要があります。

これを行うには、ドメイン名を購入したWebサイトにアクセスする必要があります。 インターフェースとおそらく用語は、使用したドメイン名レジストラによって異なります。

ドメイン設定で、使用するネームサーバーを指定できるオプションを探します。 ネームサーバーはドメイン内であるため、これは特殊なケースです。

レジストラは、NSレコードを使用してゾーンの権限を単に委任するのではなく、glueレコードを作成する必要があります。 グルーレコードは、権限を委任するネームサーバーを指定した後、ネームサーバーのIPアドレスを指定するAレコードです。

通常、委任にはドメインの権限を処理するネームサーバーのみが一覧表示されますが、ネームサーバーがドメイン自体の中にある場合は、親ゾーンのネームサーバーにAレコードが必要です。 これが行われなかった場合、DNSリゾルバーは、委任パスをたどるドメインのネームサーバーのIPアドレスを見つけることができないため、ループに陥ります。

したがって、ドメインレジストラのコントロールパネルで、ネームサーバーのIPアドレスを指定できるセクションを見つける必要があります。

デモンストレーションとして、レジストラNamecheapには2つの異なるネームサーバーセクションがあります。

ドメイン内のネームサーバーのIPアドレスを指定できる「ネームサーバー登録」というセクションがあります。

NameCheap register name servers

内部では、ドメイン内に存在するネームサーバーのIPアドレスを入力できます。

NameCheap internal name server

これにより、親ゾーンファイルに必要なグルーレコードとして機能するAレコードが作成されます。

これを実行すると、アクティブなネームサーバーをドメインのサーバーに変更できるようになります。 NameCheapでは、これは「ドメインネームサーバーのセットアップ」メニューオプションを使用して行われます。

NameCheap domain name setup

ここでは、サイトの権限のあるサーバーとして追加したネームサーバーを使用するように指示できます。

NameCheap use name servers

変更が反映されるまでに時間がかかる場合がありますが、ほとんどのレジストラでは、24〜48時間以内にネームサーバーからのデータが使用されていることがわかります。

結論

これで、ドメインをサーバー化するために2つの権限のみのDNSサーバーが構成されているはずです。 これらを使用して、追加のドメインを取得するときに、追加のドメインのゾーン情報を保存できます。

独自のDNSサーバーを構成および管理すると、DNSレコードの処理方法を最大限に制御できます。 変更を加えて、関連するすべてのDNSデータがソースで最新であることを確認できます。 他のDNSソリューションを使用するとこのプロセスが簡単になる場合がありますが、オプションがあることを理解し、よりパッケージ化されたソリューションで何が起こっているかを理解することが重要です。