アドレスレコードを示します。名前に割り当てる IP アドレスを次の例のように指定します:

              <host> IN A <IP-address>
            

この <host> 値が省略された場合、 A レコードはネーム空間の一番上にデフォルト IP アドレスをポイントします。このシステムは、すべての非 FQDN 要求の対象となります。

example.com ゾーンファイルについて、以下の A レコード例を考えてみましょう：

              server1 IN A 10.0.1.3 IN A 10.0.1.5
            

example.com へのリクエストは 10.0.1.3 又は 10.0.1.5 にポイントされています。

Canonical Name レコードを示します。1つのネームを別のネームにマップします。このタイプのレコードは エイリアス(別名)レコード として知られています。

次の例では、 named に対して、 <alias-name> に送信された要求はすべてホスト、 <real-name> をポイントすることを知らせます。 CNAME レコードは、最も一般的に Web サーバーの www などの共通名スキームを使用するサービスをポイントするのに使用されます。

              <alias-name> IN CNAME <real-name>
            

次の例で、1つの A レコードがあるホスト名をある IP アドレスにバインドし、 CNAME レコードが一般的に使用される www ホスト名をそれにポイントしています。

              server1 IN A 10.0.1.5 www IN CNAME server1
            

Mail eXchangeレコードを示します。このゾーンによって制御される特定のネーム空間に送られたメールがどこへ行くのかを知らせます。

               IN MX <preference-value><email-server-name>
            

ここでは、 <preference-value> により、このネーム空間の E メールサーバーを数値的にランク付けすることが出来るため、幾つかの E メールシステムに、他の E メールシステムよりも優先させることが出来ます。最低の <preference-value> を持つ MX リソースレコードは、他のものよりも優先されますが、複数の E メールサーバーが同じ値を所持して、 E メールのトラフィックを平等に分散させることができます。

<email-server-name> はホスト名か、 FQDN とすることが出来ます。

               IN MX 10 mail.example.com. IN MX 20 mail2.example.com.
            

この例では、最初の mail.example.com E メールサーバーは example.com ドメイン宛の E メールを受信する場合に、 mail2.example.com E メールサーバーよりも優先されています。

NameServer レコードを示します。ある特定のゾーンに対して権限のあるネームサーバーを表明します。

以下に NS レコードのレイアウトを示します：

               IN NS <nameserver-name>
            

ここでは、 <nameserver-name> は FQDN でなければなりません。

次に、2つのネームサーバーがあるドメインについて権限を持っていることが示されます。これらのネームサーバーがどちらもスレーブであるか、それとも1つはマスターであるかは重要ではありません。これらは両方とも権限があると考えられます。

               IN NS dns1.example.com. IN NS dns2.example.com.
            

PoinTeR レコードを示します。ネーム空間の別の部分を指すよう設計されています。

PTR レコードは、 IP アドレスから逆に特定の名前を指すため、主に逆引き名前解決に使用されます。使用中の PTR レコードの例については 項5.3.4. 「逆引き名前解決ゾーンファイル」 を参照してください。

これは 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> )
            

@ 記号は、この SOA リソースレコードによって定義されているネーム空間として $ORIGIN ディレクティブ （$ORIGIN ディレクティブが設定されていない場合にはゾーンの名前） を置きます。このドメインの権限であるプライマリネームサーバーのホスト名は <primary-name-server> ディレクティブであり、このネーム空間に関して連絡する人の E メールは <hostmaster-email> ディレクティブです。

<serial-number> ディレクティブは、 named がゾーンをリロードするべきであることを知らせるためにゾーンファイルが変更されるたび数が増えていく数値です。 <time-to-refresh> ディレクティブは、ゾーンに変更が行われた場合に、マスターネームサーバーに問い合わせるまでの待機時間を決定するためにスレーブサーバーが使用する数値です。 <serial-number> ディレクティブは、スレーブが古いゾーンデータを使用しているかどうか、それに従いリフレッシュすべきなのかどうかを判断するためにスレーブサーバーによって使用される数値です。

<time-to-retry> ディレクティブは、マスターネームサーバーが応答していない場合に、リフレッシュ要求を発行するまでの待機間隔をスレーブサーバーが決定するのに使用する数値です。マスターが、 <time-to-expire> ディレクティブで指定された時間内にリフレッシュ要求に応答しなかった場合、スレーブサーバーはそのネーム空間についての要求の権限を持つものとして応答を停止します。

<minimum-TTL> ディレクティブは、他のネームサーバーがゾーンの情報をキャッシュする時間数です。

BIND を設定する際は、時間はすべて秒数で指定します。しかし、分（M）、時間（H）、日（D）、週（W）など秒以外の時間単位を指定するときに短縮形を使用することもできます。 表 5.1. 「他の時間単位と比較した秒数」 の表は、秒数での時間数と他の形式による相当時間を示します。

以下の例は、 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