メインコンテンツまでスキップ

5. Master Files (マスターファイル)

マスターファイル (Master Files) は、RRをテキスト形式で含むテキストファイルです。ゾーンの内容はRRのリストの形式で表現できるため、マスターファイルは最も頻繁にゾーンを定義するために使用されますが、キャッシュの内容をリストするためにも使用できます。

このセクションでは、まずマスターファイル内のRRの形式について説明し、次にマスターファイルが一部のネームサーバーでゾーンを作成するために使用される場合の特別な考慮事項について説明します。

5.1. Format (形式)​

マスターファイルの形式は、エントリのシーケンスです。

一般規則​

行指向形式:

  • エントリは主に行指向です
  • 括弧を使用して、アイテムのリストを行の境界を越えて継続できます
  • テキストリテラルはテキスト内にCRLFを含むことができます

デリミタ:

  • タブとスペースの任意の組み合わせが、エントリを構成する個別のアイテム間のデリミタとして機能します

コメント:

  • 任意の行の末尾にコメントを付けることができます
  • コメントは; (セミコロン) で始まります
  • ;の後の行の残りは無視されます

空行:

  • コメントの有無にかかわらず、空行はファイル内の任意の場所に配置できます

エントリタイプ​

次のエントリが定義されています:

<blank>[<comment>]

$ORIGIN <domain-name> [<comment>]

$INCLUDE <file-name> [<domain-name>] [<comment>]

<domain-name><rr> [<comment>]

<blank><rr> [<comment>]

制御エントリ​

2つの制御エントリが定義されています: $ORIGINと$INCLUDE。

$ORIGIN:

  • ドメイン名が続きます
  • 相対ドメイン名の現在のオリジンを指定された名前にリセットします
  • 例: $ORIGIN example.com.

$INCLUDE:

  • 指定されたファイルを現在のファイルに挿入します
  • オプションで、インクルードされるファイルの相対ドメイン名オリジンを設定するドメイン名を指定できます
  • コメントを含めることもできます
  • 注意: $INCLUDEエントリは、インクルードされたファイル内で相対オリジンに加えられた変更に関係なく、親ファイルの相対オリジンを変更することはありません
  • 例: $INCLUDE /var/named/example.com.hosts

リソースレコードエントリ​

最後の2つのエントリ形式はRRを表します:

所有者名の規則:

  • RRのエントリが空白で始まる場合、RRは最後に述べられた所有者が所有していると見なされます
  • RRエントリが<domain-name>で始まる場合、所有者名がリセットされます

RR形式:

<rr>の内容は、次のいずれかの形式をとります:

[<TTL>] [<class>] <type> <RDATA>

[<class>] [<TTL>] <type> <RDATA>

フィールドの説明:

  • TTL: オプション、秒単位の生存時間を表す10進整数
  • Class: オプション、標準ニーモニック (例: IN)
  • Type: 必須、標準ニーモニック (例: A、NS、MX)
  • RDATA: 必須、タイプとクラスに適したデータ

デフォルト:

  • 省略されたクラスとTTL値は、最後に明示的に指定された値にデフォルト設定されます
  • タイプとクラスのニーモニックは素であるため、解析は一意です

注意: この順序は、例で使用される順序および実際のRRで使用される順序とは異なります。指定された順序により、解析とデフォルト設定が容易になります。

5.2. Domain Names in Master Files (マスターファイル内のドメイン名)​

<domain-name>は、マスターファイル内のデータの大部分を占めます。

ラベルの表現​

基本形式:

  • ドメイン名のラベルは文字列として表現され、ドットで区切られます
  • クォート規則により、任意の文字をドメイン名に格納できます

絶対名と相対名:

  • 絶対名 (Absolute Names): ドットで終わるドメイン名は絶対と呼ばれ、完全なものとして扱われます

    • 例: www.example.com.

  • 相対名 (Relative Names): ドットで終わらないドメイン名は相対と呼ばれます

    • 実際のドメイン名は、相対部分と$ORIGIN、$INCLUDE、またはマスターファイルロードルーチンへの引数で指定されたオリジンとの連結です
    • オリジンが利用できない場合、相対名はエラーです
    • 例: wwwとオリジンexample.com.でwww.example.com.になります

文字列​

<character-string>は2つの方法のいずれかで表現されます:

  1. クォートなし: 内部スペースのない連続した文字のセット
  2. クォート付き: "で始まり"で終わる文字列
    • "で区切られた文字列内では、"自体を除く任意の文字が出現できます
    • "は\ (バックスラッシュ) を使用してクォートする必要があります

5.3. Special Encodings (特殊エンコーディング)​

マスターファイルはテキストファイルであるため、任意のデータをロードできるようにするために、いくつかの特殊なエンコーディングが必要です。

特殊文字とシーケンス​

. (ドット):

  • 独立した.はルートを示します
  • 例: example.com.の末尾の.はルートを示します

@ (アットマーク):

  • 独立した@は現在のオリジンを示すために使用されます
  • 例: @ IN SOA ...はゾーンのオリジンを参照します

\X (バックスラッシュエスケープ):

  • Xは数字 (0-9) 以外の任意の文字です
  • その文字の特別な意味が適用されないようにクォートするために使用されます
  • 例:
    • \.を使用して、ラベルにドット文字を配置できます
    • \;を使用して、文字列にセミコロンを含めることができます (コメントとしてではなく)
    • \\はバックスラッシュ文字を表します

\DDD (10進エスケープ):

  • 各Dは数字です
  • DDDで記述された10進数に対応するオクテットを表します
  • 結果のオクテットはテキストとみなされ、特別な意味がチェックされません
  • 例: \065は文字'A' (ASCII 65) を表します

( ) (括弧):

  • 括弧は、行の境界を越えるデータをグループ化するために使用されます
  • 実際には、括弧内では行の終了が認識されません
  • SOAレコードやその他の複数行エントリに便利です

; (セミコロン):

  • セミコロンはコメントを開始するために使用されます
  • 行の残りは無視されます

5.4. Use of Master Files to Define Zones (ゾーンを定義するためのマスターファイルの使用)​

マスターファイルを使用してゾーンをロードする場合、マスターファイルでエラーが発生した場合は、操作を抑制すべきです (SHOULD)。

理論的根拠​

これの理論的根拠は、単一のエラーが広範囲にわたる結果をもたらす可能性があることです。例えば:

  • 委任を定義するRRに構文エラーがあるとします
  • その場合、サーバーはサブゾーン内のすべての名前に対して権威名エラーを返します
  • (サブゾーンもサーバーに存在する場合を除く)

妥当性チェック​

ファイルが構文的に正しいことを確認することに加えて、いくつかの妥当性チェックを実行すべきです (SHOULD):

  1. クラスの一貫性: ファイル内のすべてのRRは同じクラスを持つべきです (SHOULD)

  2. SOA要件: ゾーンの最上位に正確に1つのSOA RRが存在すべきです (SHOULD)

  3. グルー情報: 委任が存在し、グルー情報が必要な場合は、それが存在すべきです (SHOULD)

  4. 権威データ: ゾーン内の権威ノードの外側に存在する情報は、オリジンまたは類似のエラーの結果ではなく、グルー情報であるべきです (SHOULD)

5.5. Master File Example (マスターファイルの例)​

以下は、ISI.EDUゾーンを定義するために使用される可能性のあるファイルの例で、ISI.EDUのオリジンでロードされます:

@   IN  SOA     VENERA      Action\.domains (
                                 20     ; SERIAL
                                 7200   ; REFRESH
                                 600    ; RETRY
                                 3600000; EXPIRE
                                 60)    ; MINIMUM

        NS      A.ISI.EDU.
        NS      VENERA
        NS      VAXA
        MX      10      VENERA
        MX      20      VAXA

A       A       26.3.0.103

VENERA  A       10.1.0.52
        A       128.9.0.32

VAXA    A       10.2.0.27
        A       128.9.0.33


$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT

例の分析​

SOAレコード:

  • @はゾーンオリジン (ISI.EDU.) を表します
  • VENERAはプライマリネームサーバー (相対名、VENERA.ISI.EDU.になります)
  • Action\.domainsは責任者のメールボックス ([email protected])
    • メールアドレスのドットをエスケープするために\を使用していることに注意してください
  • シリアル番号: 20
  • リフレッシュ: 7200秒 (2時間)
  • リトライ: 600秒 (10分)
  • 有効期限: 3600000秒 (約41.67日)
  • 最小: 60秒

NSレコード:

  • 3つのネームサーバー: A.ISI.EDU. (絶対)、VENERA (相対)、VAXA (相対)

MXレコード:

  • プライマリメール交換: 優先度10のVENERA
  • セカンダリメール交換: 優先度20のVAXA

Aレコード:

  • A.ISI.EDU.には1つのIPv4アドレスがあります
  • VENERA.ISI.EDU.には2つのIPv4アドレスがあります (マルチホーム)
  • VAXA.ISI.EDU.には2つのIPv4アドレスがあります (マルチホーム)

$INCLUDEディレクティブ:

  • メールボックスレコードを含む外部ファイルをインクルードします

インクルードされたファイルの例​

ファイル<SUBSYS>ISI-MAILBOXES.TXTには以下が含まれます:

    MOE     MB      A.ISI.EDU.
    LARRY   MB      A.ISI.EDU.
    CURLEY  MB      A.ISI.EDU.
    STOOGES MG      MOE
            MG      LARRY
            MG      CURLEY

説明:

  • MBレコードは個々のメールボックスを定義します
  • MGレコードはメールグループを定義します
  • STOOGESメールグループには3人のメンバーが含まれます
  • 空行は前の所有者名の継続を示します

5.6. Common Master File Patterns (一般的なマスターファイルパターン)​

パターン1: シンプルなゾーンファイル​

$ORIGIN example.com.
$TTL 86400

@   IN  SOA ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            1800        ; Retry
            604800      ; Expire
            86400 )     ; Minimum

    IN  NS  ns1.example.com.
    IN  NS  ns2.example.com.

ns1 IN  A   192.0.2.1
ns2 IN  A   192.0.2.2
www IN  A   192.0.2.10

パターン2: 委任されたサブドメイン​

; サブドメインへの委任
subdomain       IN  NS  ns1.subdomain.example.com.
                IN  NS  ns2.subdomain.example.com.

; グルーレコード (ネームサーバーがサブドメイン内にある場合は必須)
ns1.subdomain   IN  A   192.0.2.20
ns2.subdomain   IN  A   192.0.2.21

パターン3: 複数のAレコード (負荷分散)​

; 負荷分散のためのラウンドロビンDNS
www     IN  A   192.0.2.10
        IN  A   192.0.2.11
        IN  A   192.0.2.12

5.7. Best Practices (ベストプラクティス)​

  1. 外部参照には常に絶対名を使用する: ゾーン外の名前はドットで終わるべきです

  2. $ORIGINを慎重に使用する: 最初に設定し、不必要に変更しないようにします

  3. シリアル番号を含める: 変更を加えるときは常にシリアル番号を増やします

  4. コメントを使用する: コメントでゾーンファイルを文書化します

  5. デプロイ前にテストする: named-checkzoneなどのツールを使用して構文を検証します

  6. 一貫性を保つ: 可読性のために一貫した書式を保ちます

  7. バックアップ: 変更を加える前に、必ず動作しているゾーンファイルのバックアップを保持します

次: 6. Name Server Implementation (ネームサーバー実装)

に最終更新