DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。 各 DNS データファイルは、必ずリソースレコードを含む必要があります。 ここでは、DNS データファイルと各ファイルに含む必要があるリソースレコードについて説明します。
標準リソースレコード書式では、データファイルの各行は、「リソースレコード」(RR) と呼ばれます。リソースレコードには空白で区切られた次のようなフィールドがあります。
namettlclassrecord-typerecord-specific-data |
フィールドの順は常に同じですが、最初の 2 行は任意指定 (カッコ付きで示す) です。また、最後は record-type フィールドによって変化します。
最初のフィールドは、そのレコードに適用するドメイン名のフィールドです。 RR でこのフィールドが空白のままであれば、デフォルトとして直前の RR の name フィールドの値が用いられます。
ゾーンファイルのドメイン名は、ドットで終わる完全指定名でも、相対名でもかまいません。相対名の場合、現在のドメインが付加されます。
2 番目のフィールドは、任意指定の有効期限フィールドです。 このフィールドでは、データを破棄する前にデータベース内にデータをキャッシュしておく時間 (秒)、すなわちサーバーに新しい情報を次回要求するまでの時間を指定します。 このフィールドを空白のままにすると、ttl には、権限の開始 (SOA) リソースレコードで指定された最小時間がデフォルトとして用いられます。
ttl の設定値があまりにも小さいと、サーバーはデータ更新のための要求を頻繁に繰り返します。逆に、ttl の設定値があまりにも大きいと、情報の変更がタイムリーに反映されなくなります。
ほとんどの場合、ttl の値は、初期値として 1 日 (86400) から 1 週間 (604800) の間に設定するとよいでしょう。 そのあとで、実際の情報の変更の頻度にあわせて ttl の値を適切な値に変更してください。 また、ほとんど変化することがないデータと関連しているということで ttl の値を大きく設定していた場合、 そのデータが変更されるとわかった時点で、ttl の値を、データの変更が行われるまで小さな値 (3600 - 86400) にし、 その後またもとの大きな値に戻すこともできます。
同じ名前、クラス、タイプを持つすべての RR では、ttl は同じ値に設定してください。
3 番目のフィールドは、レコードのクラスです。 現在のところ、1 つのクラスだけがあります。 それは、TCP/IP プロトコルのファミリーであることを示す IN です。
4 番目のフィールドでは、リソースレコードのタイプを記述します。 RR にはたくさんのタイプがあります。最も一般的に使用されるタイプは、リソースレコードのタイプ に説明されています。
record-specific-data フィールドの内容は、そのリソースレコードのタイプによって異なります。
ネームフィールドとデータフィールドの大文字と小文字の区別は、ネームサーバーに読み込まれたときには保存されていますが、ネームサーバーのデータベースを比較して検索する際には大文字と小文字の区別はしません。 ただし、これは将来的には変更される可能性がありますので、大文字と小文字の使用に関しては一貫性を保つように心がけてください。
次に挙げる文字には特別な意味があります。
表 5–5 特殊なリソースレコード文字
文字 |
定義 |
---|---|
. |
ネームフィールドで、1 つのドットだけが指定された場合は現在のドメインを指す |
@ |
ネームフィールドで、1 つの @ だけが指定された場合は現在の起点を示す |
.. |
2 つのドットがネームフィールドに指定された場合は NULL ドメイン名を表す |
\X |
X は数字 (0 - 9) 以外の任意の文字で、\ を付けることによって文字に特別な意味を持たせないようにする。 たとえば、\. と指定して、ラベルにドット文字を入れることができる |
\DDD |
各 D は一桁の数字で、\ を付けることによって DDD で表される 10 進数に対応する 8 進数を表現する。 結果的に得られる 8 進数は、テキストとみなされ、そのテキストに特別な意味があるかどうかはチェックされない |
() |
データが 1 行に収まらないとき、データをグループ化するのにカッコを使用する。 結果的に、カッコの間では行の終わりが認識されない |
; |
セミコロンでコメントが開始する。その行でセミコロン以降は無視される |
* |
アスタリスクはワイルドカードを表す |
ほとんどのリソースレコードには、現在の起点があり、名前の最後にドット (.) が付いていなければ、現在の起点が名前に追加されます。 この機能は、マシン名などのデータに現在のドメイン名を追加する際には便利ですが、追加したくない場合には、問題を引き起こす可能性があります。 データファイルを作成しているドメイン内に名前がない場合は、ピリオドで終わる完全指定名を使用してください。
データファイルで制御エントリの行だけは標準 RR 書式に従わない行です。 制御エントリには、 $INCLUDE() と $ORIGIN() の 2 つのタイプがあります。
インクルード行は 1 列目の $INCLUDE で始まり、その後にファイル名 ($INCLUDE ファイル) が続きます。 次の例に示すように、この機能は異なるタイプのデータを複数のファイルに分けるのに特に便利です。
$INCLUDE /etc/named/data/mailboxes |
この行は、/etc/named/data/mailboxes ファイルを読み込む要求として解釈されます。 $INCLUDE コマンドでは、異なるゾーンまたはツリーにデータは読み込まれません。 このコマンドを使用しても、あるゾーンのデータが別々のファイルに格納されるだけです。 たとえば、メールボックスのデータはこの機能を使ってホストデータとは別に保存できます。
$INCLUDE の文とファイルは、 必要に応じて、必要な数だけ使用できます。
$ORIGIN() コマンドによって、データファイル内の起点を変更できます。 この行は 1 列目から始まり、ドメイン名が続きます。 これによって、相対ドメイン名 (たとえば、完全指定されていないドメイン名) の現在の起点を指定の名前に変更します。 これは、1 つのデータファイルに複数のドメインを入れるのに便利です。
1 つのデータファイルに複数のゾーンを入れるために $ORIGIN() を使うことはできません。
$ORIGIN() コマンドは、必要に応じて必要な数だけデータファイルで使用できます。 $ORIGIN() 文がない場合、DNS データファイルのデフォルトの起点は、named.conf ファイルの master または slave の各行の 2 番目のフィールドに指定されているドメイン名となります。
最も一般的に使用されるリソースレコードのタイプを表 5–6 に列挙します。 通常、表 5–6 に並んだ順で入力しますが、この順序は必須ではありません。
表 5–6 一般的に使用されるリソースレコードのタイプ
形式 |
説明 |
---|---|
SOA |
権限の開始 |
NS |
ネームサーバー |
A |
インターネットアドレス (名前からアドレス) |
PTR |
ポインタ (アドレスから名前) |
CNAME |
正規名 (ニックネーム) |
TXT |
テキスト情報 |
WKS |
既知サービス |
HINFO |
ホスト情報 |
MX |
メール交換 |
例 5–19 に権限の開始 (SOA) リソースレコードの構文を示します。
name class SOA origin person-in-charge ( serial number refresh retry expire ttl) |
SOA レコードは、ゾーンの開始を示します。 次の SOA レコードでそのゾーンは終了します。 以下に、SOA レコードの各フィールドについて説明します。
ゾーン名を指定するフィールドです。 ゾーン名の後にはドットを付ける必要があります。 たとえば、 doc.com. は正しいですが、doc.com は誤りです。
アドレスクラスのフィールドです。 たとえば IN はインターネットを示し、最も一般的に用いられるクラスです。
このリソースレコードのタイプを示します。
このデータファイルが存在するホスト名のフィールドです。 ホスト名の後にはドットを付ける必要があります。 たとえば、dnsmaster.doc.com. は正しいですが、dnsmaster.doc.com は誤りです。
ネームサーバーの責任者のメールアドレスのフィールドです。 たとえば、kjd.nismaster.doc.com. です。 この名前も終わりにドットを付ける必要があります。
データファイルのバージョン番号のフィールドです。 データを変更するたびにこの番号を増やしてください。 スレーブサーバーは serial フィールドを使って、最後にマスターサーバーからデータファイルをコピーしてから変更があったかどうかを検出します。
更新が必要かどうかを調べるためにスレーブネームサーバーがマスターネームサーバーをチェックする頻度を秒単位で指定します。 たとえば、7200 は 2 時間を意味します。
リフレッシュのためのチェックに失敗した後、スレーブサーバーが再試行する時間を秒単位で指定します。
リフレッシュが頻繁に行われない場合に、データの期限が切れる前に、スレーブネームサーバーがそのデータを使用する上限の時間を秒単位で指定します。
リソースレコードの time-to-live フィールドで使用されるデフォルトの秒数を指定します。このデフォルト値はリソースレコードで他に ttl が指定されていないときに適用されます。
SOA レコードは、各ゾーンに 1 つだけ指定してください。 例 5–20 に、SOA リソースレコードの例を示します。
;name class SOA origin person-in-charge doc.com. IN SOA dnsmaster.doc.com. root.nismaster.doc.com. ( 101 ;Serial 7200 ;Refresh 3600 ;Retry 432000 ;Expire 86400) ;Minimum ) |
例 5–21 に、ネームサーバー (NS) リソースレコードの構文を示します。
domainname [optional TTL] class NS name-server-name |
ネームサーバーレコードは、対象としているドメインを受け持つサーバーの名前を示します。 name フィールドには、指定したネームサーバーからサービスを受けるドメインを指定します。 name フィールドを指定しない場合は、デフォルトで、最後に指定された名前になります。 NS レコードは、そのドメインのマスターサーバーとスレーブサーバーにそれぞれ 1 つずつ必要です。 例 5–22 に、NS リソースレコードの例を示します。
;domainname [TTL] class NS nameserver doc.com 90000 IN NS sirius.doc.com. |
例 5–23 に、アドレス (A) リソースレコードの構文を示します。
machinename [optional TTL] class A address |
A レコードは、対象としているマシンのアドレスを示します。 name フィールドは、ホスト名のフィールドです。address は、IP アドレスです。 A レコードは、マシンの各アドレスに 1 つ必要です。つまり、ルーターやゲートウェイには 2 つ以上のエントリが必要で、IP アドレスを含む個々のエントリが各ネットワークインタフェースに割り当てられます。
;machinename [TTL] class A address sirius IN A 123.45.6.1 |
例 5–25 に、ホスト情報 (HINFO) リソースレコードの構文を示します。
[optional name] [optional TTL] class HINFO hardware OS |
HINFO には、ホスト固有のデータが含まれ、 ハードウェアとこのホストで動作しているオペレーティング環境を指定します。 マシン名や hardware フィールドのエントリに空白を含めるには、エントリを引用符で囲む必要があります。 name フィールドでは、ホスト名を指定します。 名前が指定されなければ、in.named での最後のホストがデフォルトになります。 HINFO レコードは、各ホストに 1 つ必要です。 例 5–26に、HINFO リソースレコードの例を示します。
;[name] [TTL] class HINFO hardware OS IN HINFO Sparc-10 UNIX |
HINFO フィールドにはネットワーク上のマシンについての情報が含まれているので、多くのサイトでは、この情報はセキュリティ上危険であると考えられ、現在はほとんど使われていません。
例 5–27 に、既知サービス (WKS) リソースレコードの構文を示します。
[Optional name] [TTL] class WKS address protocol-list-of-services |
WKS レコードは、指定されたアドレスの特定のプロトコルでサポートされているよく知られたサービスを示します。 サービスのリストとポート番号は、services データベースで指定されたサービスのリストから得られます。 WKS レコードは、各アドレスの各プロトコルに 1 つだけ存在している必要があります。 例 5–28 に、WKS リソースレコードの例を示します。
;[name] [TTL] class WKS address protocol-list-of-services altair IN WKS 123.45.6.1 TCP ( smtp discard rpc sftp uucp-path systat daytime netstat qotd nntp doc.com ) |
WKS レコードは任意指定です。 セキュリティ上の理由から、ほとんどのサイトでは現在この情報は提供していません。
例 5–29 に、正規名 (CNAME) リソースレコードの構文を示します。
nickname [optional TTL] class CNAME canonical-name |
CNAME は、正規名のニックネームまたはエイリアスを示します。 ニックネームは一意である必要があります。 他のすべてのリソースレコードは、ニックネームではなく正規名と結びつけるようにする必要があります。 ニックネームを作成して他のリソースレコードで使用することはしないでください。 ニックネームは、マシン名が変更されたけれども古い名前でのアクセスを許可する移行期に特に有用です。 また、ニックネームはメールサーバーなど特定の目的で使用するマシンを識別するためにも使用できます。 例 5–30に、CNAME リソースレコードの例を示します。
;nickname [TTL] class CNAME canonical-name mailhost IN CNAME antares.doc.com |
例 5–31 に、PTR リソースレコードの構文を示します。
special-name [optional TTL] class PTR-real-name |
ポインタレコードを使用すると、特殊な名前でドメイン内の他の場所を指すことができます。 次の例では、アドレス (特殊な名前) を実名に変換するために PTR は主に in-addr.arpa. レコードで使用されます。 アドレスを解釈するときはドメインが完全指定であれば、指定する必要があるのはマシンの識別番号だけです。 PTR の名前は、ゾーンに対して一意である必要があります。 例 5–32の PTR レコードでは、特殊なドメイン in-addr.arpa に対して逆ポインタを設定します。
;special name [TTL] class PTR-real-name 1 IN PTR sirius.doc.com. |
例 5–33 に、メール交換 (MX) リソースレコードの構文を示します。
name [optional TTL] class MX preference-value mailer-exchanger |
MX リソースレコードは、あるドメインまたはドメイン内の特定のマシンにメールを配信するマシンを指定するために使用します。 対象としている名前に対して複数の MX リソースレコードが作成される場合もあります。 例 5–34 では、Seismo.CSS.GOV Seismo.CSS.GOV (完全指定のドメイン名) は、Munnari.OZ.AU にメールを配信するメールゲートウェイです。 ネットワーク上の他のマシンは、Munnari に直接メールを配信できません。 Seismo と Munnari は、専用接続を持っている場合も、異なるトランスポート媒体を使用している場合もあります。 preference-value フィールドでは、メールプログラムが従う順序を指定します。このフィールドは、単一のマシンにメールを配信する方法が複数ある場合に指定します。 値が 0 (ゼロ) は最優先であることを意味します。 同じ名前に対して複数の MX リソースレコードがある場合、そのレコードの優先値 (preference-value) は同じであることも、同じでないこともあります。
メールを配信するために、MX レコードでワイルドカードであるアスタリスク ( *) を名前に使うこともできます。 あるドメイン宛のメールがすべてリレー経由で配信されるサーバーがネットワーク上にはよくあります。 例 5–34 では、foo.com ドメイン内のホスト宛のメールはすべて RELAY.CS.NET. を経由して送られます。 これを指定するには、ワイルドカードを用いて MX リソースレコードを作成し、*.foo.com のメール交換が RELAY.CS.NET. により行われることを指定します。 アスタリスクは foo.com のどのホストまたはサブドメインにも一致します。ただし、foo.com 自体には一致しません。
;name [TTL] class MX preference mailer-exchanger Munnari.OZ.AU. IN MX 0 Seismo.CSS.GOV. foo.com. IN MX 10 RELAY.CS.NET. *.foo.com. IN MX 20 RELAY.CS.NET. |