ゾーン情報

summer.wakhok.ac.jp ドメインのゾーン情報ファイルの例を掲げる。

$TTL  86400
@    IN    SOA    dns.summer.wakhok.ac.jp.  admin.summer.wakhok.ac.jp.  (
     20000717001   ;  Serial
     10800         ;  Refresh after 3 hours
     3600          ;  Retry after 1 hours
     604800        ;  Expire after 1week
     86400 )       ;  Minimum TTL of 1day
             IN    NS         dns.summer.wakhok.ac.jp.
             IN    NS         dns2.summer.wakhok.ac.jp.
             IN    MX   10    dns.summer.wakhok.ac.jp.
             IN    MX   20    mail.summer.wakhok.ac.jp.
localhost    IN    A          127.0.0.1
dns          86400 IN    A          192.168.0.1
dns2         IN    A          192.168.0.2
mail         IN    A          192.168.0.3
hoge         IN    CNAME      dns
wak          IN    CNAME      dns2
hore         IN    CNAME      mail

ゾーンの情報ファイルのれぞれのエントリは DNS資源レコードと呼ばれる。資源レコード(RR)には本来順序はないが、 通常 SOAレコード、NSレコード、その他のホストに関するレコードの 順に書かれる（これは省略などの関係で守った方が良いであろう）。

各レコードは空白（スペース、タブ）によってフィールドに分けられる。 情報ファイルにおいては、フィールドの位置は固定であり、従って、 行頭に空白があるかないか（第一フィールドを省略したと見なす）は 決定的に重要である点に注意しなければならない。

コメントは;で始まり、行末までである。

各レコードは次のようなフィールドからなるが、第一フィールドが $ で始まるときはディレクティブと呼ぶ指令で、資源レコード とは異なる。

名前	. @ ドメイン名 空白
TTL	数値、空白
クラス	IN
資源レコードのタイプ	SOA NS A PTR CNAME MX など
レコードの情報

更に、レコードは行単位で記述されるが、行末が ( で終っている場合には 続く行は継続行とみなされ、 ) が出現するまで継続される。

1. $TTL
   全てのレコードはTTL(time-to-live)を持ち得るが、明示的に指定されて いない場合は、この $TTL で指定した値がデフォルトとして 利用される。$TTL文がない場合には、SOAの最小値が使用されるが、 警告がでるようになる。なお、ここで言う TTL は、全てのネームサーバ で該当レコードがどれだけの時間キャッシュしておいて良いかを示すもの で、この値が短ければ、自サイトのDNSレコードの変更は素早く他のサイト に反映されるが当然CPU資源はその分消費される。

2. $INCLUDE
   例には記述していないが、別のマスターファイルを $INCLUDEを 記述した位置に取り込む事が出来る。その際に、 オリジンの 解釈が変更されると困る場合があるので、取り込むファイルのオリジン を指定出来るようになっている。 もし、取り込んだファイル自身の内部にオリジンの記述も、このオプション でのオリジンの指定も無ければ、カレントオリジンが設定される。

       $INCLUDE  filename  [origin]  [comment]
   

   つまり、先程 view によってファイルが二重になり管理の問題が生じる かも知れない点について述べたが、この $INCLUDE を用いる 事でそれを回避出来るであろう。

       $INCLUDE  external.zone  summer.wakhok.ac.jp.
   

   とは言え、サーバの名前が view によって異なったり、 IPアドレスが異なる場合には残念だが使えない(当然、サーバの interfaceが異なる場合にはそうした事もある)。

   なお言わずもがなであるが、オリジンの指定には注意しなければならない。

3. SOAレコード
   SOAはStart Of Authority の略で、そのゾーンに関するもっとも信頼出来る 情報源であることを示し、必ず一つのエントリが各ゾーンファイルに対して 必要である。例のSOAレコードでは、( )で囲むことによって、 レコードを複数行に拡張しているが、何もなければ通常一行が一レコード に対応する。第一フィールドの @はカレントオリジン（起点名）の省略で、 例では conf ファイルで指定したこのゾーンのドメイン名 summer.wakhok.ac.jp. のことである。第４フィールドはこのデータを作成したホストマシン名であり、 第５フィールドは最初の .を @ に変更すると、通常 DNSマスターのメイルアドレスとなる。ここまで、FQDNが絶対名で(つまり、末尾に .がついた形で）書かれていることに気づいただろう。DNSでは、 FQDNで書く場合には必ず絶対名で書かねばならないからであり、理由は後述 する。

   括弧 (( ))で囲まれた値のうち、Serialはnamedが読み込み記憶する データに対して付けられるシリアル番号であり、もし、ゾーンファイルを修正して それらを実行中のnamedに反映させたい場合には必ずシリアルを変更した上で、 kill -HUPをnamedに送らなければならない。シリアルが変更されていない 場合には、そのゾーン情報には変更がないと見なされ、データの再初期化が 行われないからである。その他の値は全てセカンダリサーバとのゾーン転送 に関するもので、ここでは詳しくは触れない。

4. NSレコード
   NSレコードはネームサーバに関する情報である。この例では、第一フィールドが 空白であることに注意して欲しい。これは省略記法で、空白である場合には、 直前のレコードの名前が適用される。今の場合には、直前のレコードは、SOA レコードであるので、@ (つまり起点名 - summer.wakhok.ac.jp.)が使われる。 第４フィールドはネームサーバのFQDNである（ここでも絶対名が使われている 点に注意）。この名前は後のホスト情報のレコードで解決されている。 また、ネームサーバは複数を指定することができ、例のように順に列挙すれば その順にアクセスされる。

5. MXレコード
   MX(Mail eXchanger)レコードはメイル配送のための特殊なもので、他のレコード とは違い第4フィールドにプリファレンスという非負の整数値を持つ。メイルの配送 において、配送プログラムはメイルアドレスのホスト部をDNSから決定しようとする が、もし、そのメイルサーバが落ちていた場合は配送されずエラーとなってしまう。 こうした事態を避けるために、複数のメイルサーバを用意するのは良い考えで あるが、送る側はどうやってそのメイルサーバを検出したら良いのであろうか。 この問いに答える仕組みがMXなのである。つまり、具体的なホスト名ではなく、 仮の名前を用いることにし、DNSを使ってその仮の名前に対する実際のホストを 答えるようにしているのである。もし、そうやって得られた最初のメイルサーバが 応答しない場合には、次のホストを答える。つまり、先のプリファレンス値はその 優先順位を表すものであったのである。では、この仮の名前はどういう名前が 良いのかという事であるが、通常はドメイン名そのものにしておけば良いであろう。 つまり、この例では、MXレコードの第一フィールドは空白なので、それ以前の 名前である summer.wakhok.ac.jpが使われる。従って、メイルアドレスは kanayama@summer.wakhok.ac.jp のようなものになる。勿論、仮の名前は dummy.summer.wakhok.ac.jpのようなものでも良い。メイル配送プログラムは 最初はこれがホスト名だと仮定してDNSを検索し、失敗したら次にMXレコード から検索するからである。しかし、もし、この名前が実際に存在するホスト名 だったら困ったことになるであろう。そうした事態を避けるために、通常はドメイン 名そのものを用いるのであり、ユーザーから見ても簡便なメイルアドレスとなって いる。なお、プリファレンス値は０以上であれば小さいものから順になるので、 0,1,2...とつけても良いし、この例のようにしても良い。ただ、現実には、 緊急時に他のMXを追加出来るように例のような書き方の方が推奨されている。

6. Aレコード
   Aレコードはホスト情報に関係するものであり、実際のIPアドレスはここに記述 する。ここで、第一フィールドに単なる一語のホスト名を使っている点に注意 しよう。ゾーン情報では絶対名（末尾に.がつかない）を 使ってない場合には、自動的にカレントオリジン（起点名）が自動的に 補われるようになっている。先に、絶対名を強調したのはこのためであった。 実際に、もしここで第一フィールドに dns.summer.wakhok.ac.jpと 書いてしまうと、 dns.summer.wakhok.ac.jp.summer.wakhok.ac.jp.と解釈されるのである。

7. CNAMEレコード
   別名を定義するレコードである。第4フィールドのホスト名はAレコードで 解決できなければならない。特殊なマルチホームルータなどの場合について はCNAMEレコードの第4フィールドにIPアドレスが用いられる場合もある。