4.6. BIND DNS サーバーでのゾーンの設定

PDF

DNS ゾーンは、ドメインスペース内の特定のサブツリーのリソースレコードを含むデータベースです。たとえば、example.com ドメインを担当している場合は、BIND でそのゾーンを設定できます。その結果、クライアントは www.example.com をこのゾーンで設定された IP アドレスに解決できます。

4.6.1. ゾーンファイルの SOA レコード

SOA (Start of Authority) レコードは、DNS ゾーンで必要なレコードです。このレコードは、たとえば、複数の DNS サーバーがゾーンだけでなく DNS リゾルバーに対しても権限を持っている場合に重要です。

BIND の SOA レコードの構文は次のとおりです。

name class type mname rname serial refresh retry expire minimum

読みやすくするために、管理者は通常、ゾーンファイル内のレコードを、セミコロン (;) で始まるコメントを使用して複数の行に分割します。SOA レコードを分割する場合は、括弧でレコードをまとめることに注意してください。

@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

重要

完全修飾ドメイン名 (FQDN) の末尾にあるドットに注意してください。FQDN は、ドットで区切られた複数のドメインラベルで設定されます。DNS ルートには空のラベルがあるため、FQDN はドットで終わります。したがって、BIND はゾーン名を末尾のドットなしで名前に追加します。末尾にドットがないホスト名 (例: ns1.example.com) は、ns1.example.com.example.com. に展開されます。これは、プライマリーネームサーバーの正しいアドレスではありません。

SOA レコードのフィールドは次のとおりです。

name: ゾーンの名前 (つまり origin)。このフィールドを @ に設定すると、BIND はそれを /etc/named.conf で定義されたゾーン名に展開します。
class: SOA レコードでは、このフィールドを常に Internet (IN) に設定する必要があります。
type: SOA レコードでは、このフィールドを常に SOA に設定する必要があります。
mname (マスター名): このゾーンのプライマリーネームサーバーのホスト名。
rname (責任者名): このゾーンの責任者の電子メールアドレス。形式が異なりますのでご注意ください。アットマーク (@) をドット (.) に置き換える必要があります。
serial: このゾーンファイルのバージョン番号。セカンダリーネームサーバーは、プライマリーサーバーのシリアル番号の方が大きい場合にのみ、ゾーンのコピーを更新します。
形式は任意の数値にすることができます。一般的に使用される形式は <year><month><day><two-digit-number> です。この形式を使用すると、理論的には、ゾーンファイルを 1 日に 100 回まで変更できます。
refresh: ゾーンが更新された場合は、プライマリーサーバーをチェックする前にセカンダリーサーバーが待機する時間。
retry: 試行が失敗した後、セカンダリーサーバーがプライマリーサーバーへのクエリーを再試行するまでの時間。
expire: 以前の試行がすべて失敗した場合に、セカンダリーサーバーがプライマリーサーバーへのクエリーを停止した後の時間。
minimum: RFC 2308 は、このフィールドの意味を負のキャッシュ時間に変更しました。準拠リゾルバーは、NXDOMAIN 名エラーをキャッシュする期間を決定するために使用します。

注記

refresh、retry、expire、および maximum フィールドの数値は、時間を秒単位で定義します。ただし、読みやすくするために、時間の接尾辞 (m は分、h は時間、d は日など) を使用してください。たとえば、3h は 3 時間を表します。

関連情報

RFC 1035: ドメイン名 - 実装および仕様
RFC 1034: ドメイン名 - 概念および機能
RFC 2308: DNS クエリーのネガティブキャッシュ (DNS キャッシュ)

4.6.2. BIND プライマリーサーバーでの正引きゾーンの設定

正引きゾーンは、名前を IP アドレスやその他の情報にマップします。たとえば、ドメイン example.com を担当している場合は、BIND で転送ゾーンを設定して、www.example.com などの名前を解決できます。

前提条件

BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
named または named-chroot サービスが実行しています。

手順

/etc/named.conf ファイルにゾーン定義を追加します。
```
zone "example.com" {
    type master;
    file "example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
これらの設定により、次が定義されます。
- このサーバーは、example.com ゾーンのプライマリーサーバー (type master) です。
- /var/named/example.com.zone ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options ステートメントの directory に設定したディレクトリーからの相対パスになります。
- どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。
- どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。
/etc/named.conf ファイルの構文を確認します。
```
# named-checkconf
```
コマンドが出力を表示しない場合は、構文に間違いがありません。
たとえば、次の内容で /var/named/example.com.zone ファイルを作成します。
```
$TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.
                  IN MX   10 mail.example.com.

www               IN A    192.0.2.30
www               IN AAAA 2001:db8:1::30
ns1               IN A    192.0.2.1
ns1               IN AAAA 2001:db8:1::1
mail              IN A    192.0.2.20
mail              IN AAAA 2001:db8:1::20
```
このゾーンファイル:
- リソースレコードのデフォルトの有効期限 (TTL) 値を 8 時間に設定します。時間の h などの時間接尾辞がない場合、BIND は値を秒として解釈します。
- ゾーンに関する詳細を含む、必要な SOA リソースレコードが含まれています。
- このゾーンの権威 DNS サーバーとして ns1.example.com を設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。
- example.com ドメインのメールエクスチェンジャー (MX) として mail.example.com を設定します。ホスト名の前の数値は、レコードの優先度です。値が小さいエントリーほど優先度が高くなります。
- www.example.com、mail.example.com、および ns1.example.com の IPv4 アドレスおよび IPv6 アドレスを設定します。
named グループだけがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。
```
# chown root:named /var/named/example.com.zone
# chmod 640 /var/named/example.com.zone
```

/var/named/example.com.zone ファイルの構文を確認します。

# named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022070601
OK

BIND をリロードします。
```
# systemctl reload named
```
change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

検証

example.com ゾーンからさまざまなレコードをクエリーし、出力がゾーンファイルで設定したレコードと一致することを確認します。
```
# dig +short @localhost AAAA www.example.com
2001:db8:1::30

# dig +short @localhost NS example.com
ns1.example.com.

# dig +short @localhost A ns1.example.com
192.0.2.1
```
この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

関連情報

4.6.3. BIND プライマリーサーバーでの逆引きゾーンの設定

逆ゾーンは、IP アドレスを名前にマップします。たとえば、IP 範囲 192.0.2.0/24 を担当している場合は、BIND で逆引きゾーンを設定して、この範囲の IP アドレスをホスト名に解決できます。

注記

クラスフルネットワーク全体の逆引きゾーンを作成する場合は、それに応じてゾーンに名前を付けます。たとえば、クラス C ネットワーク 192.0.2.0/24 の場合は、ゾーンの名前が 2.0.192.in-addr.arpa です。192.0.2.0/28 など、異なるネットワークサイズの逆引きゾーンを作成する場合は、ゾーンの名前が 28-2.0.192.in-addr.arpa です。

前提条件

BIND は、たとえばキャッシングネームサーバーとしてすでに設定されています。
named または named-chroot サービスが実行しています。

手順

/etc/named.conf ファイルにゾーン定義を追加します。
```
zone "2.0.192.in-addr.arpa" {
    type master;
    file "2.0.192.in-addr.arpa.zone";
    allow-query { any; };
    allow-transfer { none; };
};
```
これらの設定により、次が定義されます。
- 2.0.192.in-addr.arpa 逆引きゾーンのプライマリーサーバー (type master) としてのこのサーバー。
- /var/named/2.0.192.in-addr.arpa.zone ファイルはゾーンファイルです。この例のように相対パスを設定すると、このパスは、options ステートメントの directory に設定したディレクトリーからの相対パスになります。
- どのホストもこのゾーンにクエリーを実行できます。または、IP 範囲または BIND アクセス制御リスト (ACL) のニックネームを指定して、アクセスを制限します。
- どのホストもゾーンを転送できません。ゾーン転送を許可するのは、セカンダリーサーバーをセットアップする際に限られ、セカンダリーサーバーの IP アドレスに対してのみ許可します。
/etc/named.conf ファイルの構文を確認します。
```
# named-checkconf
```
コマンドが出力を表示しない場合は、構文に間違いがありません。
たとえば、次の内容で /var/named/2.0.192.in-addr.arpa.zone ファイルを作成します。
```
$TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.

1                 IN PTR  ns1.example.com.
30                IN PTR  www.example.com.
```
このゾーンファイル:
- リソースレコードのデフォルトの有効期限 (TTL) 値を 8 時間に設定します。時間の h などの時間接尾辞がない場合、BIND は値を秒として解釈します。
- ゾーンに関する詳細を含む、必要な SOA リソースレコードが含まれています。
- ns1.example.com をこの逆引きゾーンの権威 DNS サーバーとして設定します。ゾーンを機能させるには、少なくとも 1 つのネームサーバー (NS) レコードが必要です。ただし、RFC 1912 に準拠するには、少なくとも 2 つのネームサーバーが必要です。
- 192.0.2.1 および 192.0.2.30 アドレスのポインター (PTR) レコードを設定します。
named グループのみがそれを読み取ることができるように、ゾーンファイルに安全なアクセス許可を設定します。
```
# chown root:named /var/named/2.0.192.in-addr.arpa.zone
# chmod 640 /var/named/2.0.192.in-addr.arpa.zone
```

/var/named/2.0.192.in-addr.arpa.zone ファイルの構文を確認します。

# named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
zone 2.0.192.in-addr.arpa/IN: loaded serial 2022070601
OK

BIND をリロードします。
```
# systemctl reload named
```
change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

検証

逆引きゾーンからさまざまなレコードをクエリーし、出力がゾーンファイルで設定したレコードと一致することを確認します。
```
# dig +short @localhost -x 192.0.2.1
ns1.example.com.

# dig +short @localhost -x 192.0.2.30
www.example.com.
```
この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

関連情報

4.6.4. BIND ゾーンファイルの更新

サーバーの IP アドレスが変更された場合など、特定の状況では、ゾーンファイルを更新する必要があります。複数の DNS サーバーが 1 つのゾーンを担ってる場合は、この手順をプライマリーサーバーでのみ実行してください。ゾーンのコピーを保存する他の DNS サーバーは、ゾーン転送を通じて更新を受け取ります。

前提条件

ゾーンが設定されました。
named または named-chroot サービスが実行しています。

手順

オプション: /etc/named.conf ファイル内のゾーンファイルへのパスを特定します。
```
options {
    ...
    directory       "/var/named";
}

zone "example.com" {
    ...
    file "example.com.zone";
};
```
ゾーンの定義の file ステートメントで、ゾーンファイルへのパスを見つけます。相対パスは、options ステートメントの directory に設定されたディレクトリーからの相対パスです。
ゾーンファイルを編集します。
1. 必要な変更を行います。
2. SOA (Start of Authority) レコードのシリアル番号を増やします。
  重要
  シリアル番号が以前の値以下の場合、セカンダリーサーバーはゾーンのコピーを更新しません。

ゾーンファイルの構文を確認します。

# named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022062802
OK

BIND をリロードします。
```
# systemctl reload named
```
change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

検証

追加、変更、または削除したレコードを照会します。たとえば、次のようになります。
```
# dig +short @localhost A ns2.example.com
192.0.2.2
```
この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。

関連情報

4.6.5. 自動鍵生成およびゾーン保守機能を使用した DNSSEC ゾーン署名

DNSSEC (Domain Name System Security Extensions) でゾーンに署名して、認証およびデータの整合性を確保できます。このようなゾーンには、追加のリソースレコードが含まれます。クライアントはそれらを使用して、ゾーン情報の信頼性を検証できます。

ゾーンの DNSSEC ポリシー機能を有効にすると、BIND は次のアクションを自動的に実行します。

キーを作成します。
ゾーンに署名します
鍵の再署名や定期的な交換など、ゾーンを維持します。

重要

外部 DNS サーバーがゾーンの信頼性を検証できるようにするには、ゾーンの公開キーを親ゾーンに追加する必要があります。これを行う方法の詳細については、ドメインプロバイダーまたはレジストリーにお問い合わせください。

この手順では、BIND に組み込まれている default の DNSSEC ポリシーを使用します。このポリシーは、単一の ECDSAP256SHA 鍵署名を使用します。または、独自のポリシーを作成して、カスタムキー、アルゴリズム、およびタイミングを使用します。

前提条件

BIND 9.16 以降がインストールされている。この要件を満たすには、bind の代わりに bind9.16 パッケージをインストールします。
DNSSEC を有効にするゾーンが設定されている。
named または named-chroot サービスが実行しています。
サーバーは時刻をタイムサーバーと同期します。DNSSEC 検証では、正確なシステム時刻が重要です。

手順

/etc/named.conf ファイルを編集し、DNSSEC を有効にするゾーンにdnssec-policy default; を追加します。
```
zone "example.com" {
    ...
    dnssec-policy default;
};
```
BIND をリロードします。
```
# systemctl reload named
```
change-root 環境で BIND を実行する場合は、systemctl reload named-chroot コマンドを使用してサービスをリロードします。

BIND は公開鍵を /var/named/K<zone_name>.+<algorithm>+<key_ID>.key ファイルに保存します。このファイルを使用して、親ゾーンが必要とする形式でゾーンの公開鍵を表示します。

DS レコード形式:

# dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key
example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027

DNSKEY 形式:

# grep DNSKEY /var/named/Kexample.com.+013+61141.key
example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==

ゾーンの公開鍵を親ゾーンに追加するように要求します。これを行う方法の詳細については、ドメインプロバイダーまたはレジストリーにお問い合わせください。

検証

DNSSEC 署名を有効にしたゾーンのレコードについて、独自の DNS サーバーにクエリーを実行します。
```
# dig +dnssec +short @localhost A www.example.com
192.0.2.30
A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
```
この例では、BIND が同じホストで実行し、localhost インターフェイスでクエリーに応答することを前提としています。
公開鍵が親ゾーンに追加され、他のサーバーに伝播されたら、サーバーが署名付きゾーンへのクエリーで認証済みデータ (ad) フラグを設定することを確認します。
```
#  dig @localhost example.com +dnssec
...
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
```

関連情報

4.6. BIND DNS サーバーでのゾーンの設定

4.6.1. ゾーンファイルの SOA レコード

4.6.2. BIND プライマリーサーバーでの正引きゾーンの設定

4.6.3. BIND プライマリーサーバーでの逆引きゾーンの設定

4.6.4. BIND ゾーンファイルの更新

4.6.5. 自動鍵生成およびゾーン保守機能を使用した DNSSEC ゾーン署名

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links