Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

19.3.2. ゾーンファイルリソースレコード

ゾーンファイルのプライマリーコンポーネントは、リソースレコードです。
ゾーンファイルリソースレコードには多くのタイプがあります。以下は、最も頻繁に使用されます。
A
以下の例のように、名前に割り当てる IP アドレスを指定する Address レコードを参照します。 
<host> IN A <IP-address>
Copy to Clipboard Toggle word wrap
&lt ;host&gt; 値を省略すると、A レコードは namespace の上部にあるデフォルトの IP アドレスを参照します。このシステムは、FQDN 以外のすべての要求のターゲットです。
example.com ゾーンファイルの以下の A レコードの例を見てみましょう。 
server1		IN	A	10.0.1.3
		IN	A	10.0.1.5
Copy to Clipboard Toggle word wrap
example.com の要求は 10.0.1.3 または 10.0.1.5 を参照します。
CNAME
これは、名前を別の名前にマップする正規名レコードを参照します。このタイプのレコード は、エイリアスレコード とも呼ばれます。
以下の例では、< alias-name> に送信された要求がホスト < real-name > を参照する必要があることを named に指示し ます。CNAME レコードは、Web サーバーの www など、共通の命名スキームを使用するサービスを参照するために最も一般的に使用されます。 
<alias-name> IN CNAME <real-name>
Copy to Clipboard Toggle word wrap
以下の例では、A レコードはホスト名を IP アドレスにバインドし、CNAME レコードが一般的に使用される www ホスト名をこれにポイントします。 
server1		IN	A	10.0.1.5
www		IN	CNAME	server1
Copy to Clipboard Toggle word wrap
MX
これはメール eXchange レコードを指し、このゾーンによって制御される特定の名前空間に送信されたメールの移動先を指示します。 
 IN MX <preference-value> <email-server-name>
Copy to Clipboard Toggle word wrap
ここで、& lt;preference-value > は namespace のメールサーバーの数値ランクを許可し、一部のメールシステムを他のシステムよりも優先されます。最も低い < preference-value> を 持つ MX リソースレコードは、他よりも優先されます。しかし複数メールサーバーが同じ値を持つ可能性があり、その場合はメールトラフィックをサーバー間で均等に分配することになります。
&lt ;email-server-name&gt; はホスト名または FQDN です。 
IN     MX     10     mail.example.com.
IN     MX     20     mail2.example.com.
Copy to Clipboard Toggle word wrap
この例では、example.com ドメイン宛てのメールを受信する際に、最初の mail.example.com メールサーバーは mail2. example.com メールサーバーよりも優先されます。
NS
これは、特定ゾーンの権威ネームサーバーをアナウンスする NameServer レコードを参照します。
以下は、NS レコードのレイアウトを示しています。 
 IN NS <nameserver-name>
Copy to Clipboard Toggle word wrap
ここで、& lt;nameserver-name> は FQDN である必要があります。
次に、2 つのネームサーバーがドメインに対して権威として一覧表示されます。これらのネームサーバーがスレーブであるか、マスターであるかが重要ではなく、いずれも権威があると見なされます。 
IN     NS     dns1.example.com.
IN     NS     dns2.example.com.
Copy to Clipboard Toggle word wrap
PTR
これは、名前空間の別の部分をポイントするように設計された PoinTeR レコードを参照します。
PTR レコードは、主に IP アドレスを特定の名前に戻すため、逆引き名前解決に使用されます。使用中の PTR レコードの他の例については、「逆引き名前解決ゾーンファイル」 を参照してください。
SOA
これは Start Of Authority リソースレコードを参照します。これは、名前空間に関する重要な信頼できる情報をネームサーバーに提案します。
SOA リソースレコードは、ディレクティブの後に配置され、ゾーンファイルの最初のリソースレコードです。
以下の SOA リソースレコードの基本構造を表示します。 
@  IN	SOA  <primary-name-server>  <hostmaster-email> (
	<serial-number>
	<time-to-refresh>
	<time-to-retry>
	<time-to-expire>
	<minimum-TTL> )
Copy to Clipboard Toggle word wrap
@ 記号は、$ORIGIN ディレクティブ（または $ORIGIN ディレクティブが設定されていない場合はゾーンの名前）をこの SOA リソースレコードで定義されている名前空間として配置します。このドメインに対して権威のあるプライマリーネームサーバーのホスト名は < primary-name-server > ディレクティブで、この namespace と通信するユーザーの電子メールは < hostmaster-email> ディレクティブ です。
&lt ;serial-number&gt; ディレクティブは、named がゾーンを再ロードする時間であることを示すためにゾーンファイルが変更されるたびに増加する数値です。& lt;time-to-refresh > ディレクティブは、ゾーンに変更を加えたかどうかをマスターネームサーバーに尋ねるまでの待機時間を判断するために使用する数値スレーブサーバーです。&lt ;serial-number > ディレクティブは、古いゾーンデータを使用しているかどうかを判断するためにスレーブサーバーが使用する数値であるため、更新する必要があります。
& lt;time-to-retry > ディレクティブは、マスターネームサーバーが応答しない場合に更新要求を発行するまでの待機時間を判断するためにスレーブサーバーが使用する数値です。マスターが <time-to -expire> ディレクティブで指定された時間が経過する前に更新要求に 応答しなかった場合、スレーブサーバーはその名前空間に関する要求の権威として応答しなくなります。
BIND 4 および 8 では、& lt;minimum-TTL& gt; ディレクティブは amount of time のネームサーバーでゾーンの情報をキャッシュします。ただし、BIND 9 では、< minimum-TTL> ディレクティブ は、負の応答がキャッシュされる期間を定義します。負の回答のキャッシュは、最大 3 時間 (3H) に設定できます。
BIND の設定時には、すべての時間は秒で指定されます。ただし、秒以外の時間単位を指定する場合は省略形を使用できます。たとえば、分(M)、時間(H)、日(D)、および週(W)などです。表19.1「秒表示とその他の時間単位」 の表は、秒単位で、同等の時間を別の形式で示しています。
Expand
表19.1 秒表示とその他の時間単位
秒 他の時間単位
60 1M
1800 30M
3600 1H
10800 3H
21600 6H
43200 12H
86400 1D
259200 3D
604800 1W
31536000 365D
以下の例は、実際の値が入力されると SOA リソースレコードが取る可能性のあるフォームを示しています。 
@	IN	SOA	dns1.example.com.	hostmaster.example.com. (
		2001062501 ; serial
		21600      ; refresh after 6 hours
		3600       ; retry after 1 hour
		604800     ; expire after 1 week
		86400 )    ; minimum TTL of 1 day
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat