この章の内容は次のとおりです。
この節では、この章で説明する例を基にして、サンプルのインターネット接続ネットワークを想定し、そこで使う DNS を設定するために必要なファイルを示します。
このマニュアル内の例やコード例で使われている IP アドレスとネットワーク番号は、説明に具体性を持たせるために仮に決めたものです。 これらの情報は、実際のネットワークやホストに使われていることがあるので、そのまま使うのは避けてください。
この実例では、次のことを前提としています。
インターネットに接続されている
2 つのネットワークが存在していて、それぞれ個別のドメインを持つ (doc.com と sales.doc.com)。DNS ゾーンも別々に管理
doc.com ドメインおよび doc.com ゾーンが sales.doc.com サブドメインおよび sales.doc.com ゾーンの上の最上位ゾーンである
2 つのネットワークはそれぞれ個別のネットワーク番号を持つ
表 5–1 ネットワークドメインとゾーン構成の例
名前/ゾーン |
番号 |
---|---|
doc.com |
123.45.6 |
sales.doc.com |
111.22.3 |
各ゾーンにマスターサーバーとスレーブサーバーが 1 台ずつあり、doc.com のマスターサーバーが sales.doc.com のスレーブサーバーを兼ねている
表 5–2 ネットワーク DNS サーバーの例
ゾーン |
ホスト名 |
機能 |
アドレス | CNAME |
---|---|---|---|---|
doc.com |
sirius |
doc.com のマスターサーバー |
123.45.6.1 | dnsmaster |
doc.com |
deneb |
doc.com のスレーブサーバー |
111.22.3.5 | dnssecond |
sales.doc.com |
altair |
sales.doc.com のマスターサーバー |
111.22.3.4 | dnssales |
sales.doc.com |
altair |
sales.doc.com のスレーブサーバー |
123.45.6.1 | dnsmaster |
次に示すのは、2 つのネットワークで使われている 3 つのサーバーの構成ファイルです。
; ; Sample named.conf file on dnsmastr (sirius) name server ; ; global options and defaults ; options { directory "/var/named"; }; ; master zone definitions ; zone "doc.com" in { type master; file "db.doc.com"; }; zone "6.45.123.in-addr.arpa" in { type master; file "db.123.45.6"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; ; slave server definitions ; zone "sales.doc.com" in { type slave; file "tmp.db.sales"; masters { 111.22.3.4; }; }; zone "3.22.111.in-addr.arpa" in { type slave; file "tmp.db.111.22.3"; masters { 111.22.3.4; }; }; ; root hints zone "." in { type hint; file "named.ca"; }; |
; ; Sample named.conf file on the dnssales (altair) name server ; options { directory "/var/named"; }; zone "sales.doc.com" in { type master; file "db.sales.doc.com"; }; zone "3.22.111.in-addr.arpa" in { type master; file "db.111.22.3"; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; ; root hints zone "." in { type hint; file "named.ca"; }; |
; ;S ample named.conf file on the dnssecond (deneb) name server ; options { directory "/var/named"; }; zone "doc.com" in { type slave; file "tmp.db.doc.com"; masters { 123.45.6.1; }; }; zone "6.45.123.in-addr.arpa" in { type slave; file "tmp.db.123.45.6"; masters { 123.45.6.1; }; }; zone "0.0.127.in-addr.arpa" in { type master; file "db.127.0.0"; }; ; root hints zone "." in { type hint; file "named.ca"; }; |
次に示すのは、2 つのネットワークで使われている 3 つのサーバーの resolv.conf ファイルです。 そのホストが in.named を起動していない場合、そのローカルホストのアドレスをネームサーバーとして使用しないでください。
; ; /etc/resolv.conf file for dnsmaster (sirius) ; domain doc.com nameserver 0.0.0.0 nameserver 111.22.3.5 |
; ; /etc/resolv.conf file for dnssales (altair) ; domain sales.doc.com nameserver 111.22.3.4 nameserver 123.45.6.1 |
; ; /etc/resolv.conf for dnssecond ; domain doc.com nameserver 111.22.3.5 nameserver 123.45.6.1 |
次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている named.local ファイルです。 どちらのサーバーも同じファイルを持っています。
$TTL 5h ; SOA rec 0.0.127.in-addr.arpa. IN SOA siriusdoc.com. sysop.centauri.doc.com.( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com. 0.0.127.in_addr.arpa IN NS dnssecond.doc.com 1 IN PTR localhost. |
次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている db.doc ファイルと db.sales ファイルです。
$TTL 5h ; SOA rec doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses localhost IN A 127.0.0.1 sirius IN A 123.45.6.1 rigel IN A 123.45.6.112 antares IN A 123.45.6.90 polaris IN A 123.45.6.101 procyon IN A 123.45.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com. N A 111.22.3.4 ; aliases dnsmastr IN CNAME sirius.doc.com. dnssecond.doc.com IN CNAME deneb.doc.com |
$TTL 5h ; SOA rec sales.doc.com. IN SOA altair.sales.doc.com. sysop.polaris.doc.com. ( 19970332 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses altair IN A 111.22.3.4 localhost IN A 127.0.0.1 sirius.doc.com. IN A 123.45.6.1 luna IN A 192.168.8.22 phoebus IN A 192.168.8.24 deimos IN A 192.168.8.25 ganymede IN A 192.168.8.27 europa IN A 192.168.8.28 callisto IN A 192.168.8.29 ; ; aliases dnssales.sales.doc.com IN CNAME altair.sales.doc.com |
次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーで使われている hosts.rev ファイルです。
$TTL 5h ; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com. ;Pointer records for 123.45.6 1 IN PTR sirius.doc.com. 112 IN PTR rigel.doc.com. 90 IN PTR antares.doc.com. 101 IN PTR polaris.doc.com. 79 IN PTR procyon.doc.com. 69 IN PTR tauceti.doc.com. |
$TTL 5h ; SOA rec 3.22.111.in-addr.arpa. IN SOA altair.sales.doc.com. \ sysop.polaris.doc.com.( 19970331 ; serial number 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 3.22.111.in-addr.arpa. IN NS altair.sales.doc.com.; \ Pointer records for 111.22.3 22 IN PTR luna 23 IN PTR deneb 24 IN PTR phoebus 25 IN PTR deimos 26 IN PTR altair 27 IN PTR ganymede 28 IN PTR europa 29 IN PTR callisto |
次に示すのは、2 つのネットワーク上の 2 つのマスターサーバーにそれぞれ格納される named.ca ファイルです。 どちらのサーバーも同じ named.ca ファイルを使用します。
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File |
DNS のデーモン in.named によって使用されるすべてのデータファイルは標準リソースレコード書式で書かれます。 標準リソースレコード書式では、ファイルの各行は、リソースレコード (RR) と呼ばれるレコードです。 各 DNS データファイルには決められたリソースレコードが必要です。
最も一般的に使用されるリソースレコードのタイプを表 5–6 に列挙します。 通常、表 5–6 に並んだ順で入力しますが、この順序は必須ではありません。
これ以降に示すサンプルファイルでは、@ は現在のゾーンまたは現在の起点を示します。セミコロン (;) で始まる行はコメントです。
単一ゾーン内、また複数ゾーン内のサブドメインを設定できます。 次の節では、両方の方法について説明します。
最も簡単な方法は、サブドメインを親ドメインのゾーンに含めることです。 こうすると、1 セットの DNS サーバーとデータファイルでドメインに関係なくすべてのマシンを管理できます。
単一ゾーン方式の長所は、管理が簡素化され簡単なことです。 短所は 1 セットのサーバーですべてのゾーンのドメインにあるマシンを管理しなければならないということです。 マシンの数が多すぎると、サーバーの負荷が大きくなり過ぎ、パフォーマンスが低下することがあります。
複数のドメインで構成されているゾーンのデータファイルには、そのゾーンに含まれる各ドメインのすべてのマシンとサーバーに関わるレコードが必要です。
複数のドメインで構成されているゾーンを設定するのも、単一ドメインで構成されているゾーンを設定するのも、必要な作業は基本的に同じです。唯一の相違は、遠隔ドメインのマシンを識別できるようにするために、hosts ファイルには完全指定のドメイン名を使用しなければならないということです。 サーバーのローカルドメインにあるマシンであれば、hosts ファイルにマシン名しか指定されていなくても識別できます。 しかし、他のドメインにあるマシンを識別するには、完全指定のドメイン名、 つまり、machine.domain という書式で指定しなければなりません。
hosts.rev ファイルと named.local ファイルに指定するサーバー名やマシン名にも、完全指定のドメイン名を使用する必要があります。 ただし、これはゾーンがいくつのドメインで構成されているかには関係ありません。
複数ゾーン方式の長所は、ドメインごとにその中のマシンを管理するサーバーセットを割り当てられるということです。つまり、サーバーの負荷を分散させ、1 セットのサーバーに負荷が集中するのを防ぐことができます。 短所は、設定時の作業がより複雑になることです。
異なるゾーンのサブドメインを設定するのは、1 つのゾーンに複数のドメインを含めるのよりも複雑です。これは、さまざまなゾーンにあるクライアントが他のゾーンの DNS 情報を得る方法を指定しなければならないからです。
ネットワークを複数のドメインに分ける場合、ドメインを階層化します。 必ず最上位のドメインがあって、 その下に 1 つまたは複数のサブドメインがあります。 サブドメインの下にサブドメインを作ることもできます。 しかし、どのサブドメインにも階層構造の中で最上位のドメインから相対的に決まった場所があります。 ドメイン名は左から右に読んでいくと、階層内におけるドメインの位置を示していることがわかります。 たとえば、doc.com ドメインは sales.doc.com ドメインの上位にあり、west.sales.doc.com ドメインは sales.doc.com ドメインの下位にあることがわかります。
DNS ゾーンはそのゾーンが含むドメインから階層を取り込みます。 ネットワークの最上位ドメインを含むゾーンは最上位のゾーンになります。 最上位のドメインの下のサブドメインを 1 つ以上含むゾーンは、ゾーンの階層でいえば最上位のゾーンの下のゾーンになります。 DNS 情報をあるゾーンから別のゾーンへ移動させるということは、このゾーン階層の中を上下に移動させるということです。 つまり、各ゾーンでは、すぐ上のゾーンに情報を渡すにはどうするか、すぐ下のゾーンに情報を渡すにはどうするかを専用のデータファイルのレコードに指定しておく必要があります。
複数のゾーンで構成されているネットワークの中で、DNS 情報をあるゾーンから別のゾーンへ正確に転送させるために必要なことを以下に示します。
hosts.rev ファイル。 すぐ上のゾーンにある 1 つまたは複数のマスターサーバー名を指し示す PTR レコードが各 hosts.rev ファイルに必要です。 上位ゾーンのサーバーを指し示すということを除けば、この種の PTR レコードは、ファイル内のその他の PTR レコードとまったく同じのものです。
hosts ファイルの NS レコード。 すぐ下の各ゾーンにあるネームサーバー名を指し示すゾーン NS レコードが各 hosts ファイルに必要です。 この種の NS レコードは、その最初のフィールドに下のゾーン名が指定されていなければなりません。 (ゾーン名は、そのゾーンの host ファイルの SOA レコードに指定されています。)
hosts ファイルの A レコード。 すぐ下の各ゾーンにあるネームサーバーの IP アドレスを指し示す A レコードが各 hosts ファイルに必要です。 この種の A レコードは、その最初のフィールドに下のゾーン名が指定されていなければなりません。 ゾーン名は、そのゾーンの host ファイルの SOA レコードに指定されています。
この章のファイル例に、2 つのゾーンを持つネットワークが示してあります。
全世界の DNS 管理ドメインの集合全体は「DNS 名前空間」と呼ばれる階層構造を形成しています。 ここでは、名前空間の組織がどのようにローカルドメインやインターネットに影響するのか説明します。
DNS ドメインは、UNIX のファイルシステムと同様、木の根に似た下向きの枝分かれで構成されています。 各枝分かれがドメインであり、そこから分かれる各枝が「サブドメイン」です。 「ドメイン」と「サブドメイン」は相対的な関係を示します。 階層の中で、あるドメインは、その上にあるドメインに対するサブドメインになり、その下にあるサブドメインの親ドメインになります。
たとえば、図 5–1 において com は Acme、Ajax、AAA の各ドメインの親ドメインです。 あるいは、これらのドメインは com ドメインのサブドメインということもできます。 このように考えると、Ajax ドメインは 4 つのサブドメイン (Sales、Manf、QA、Corp) の親ドメインになっています。
あるドメインには、1 つの親 (または最上位) ドメインと、(存在する場合) その下のサブドメインが含まれます。 ドメインの名前は、最下位 (階層の底) のサブドメインから始まり、最後がルートドメインとなっています。
DNS は、名前のアドレス解決 で説明しているように、名前からアドレス (またはその逆のアドレスから名前) のマッピングを行う他に、インターネット上でメールを配信する sendmail や POP といったメール配信エージェントの役にも立っています。
インターネット上でメールを配信するのに、DNS は「メール交換レコード」(MX レコード) を用います。 ほとんどの組織は、その組織内にあるホストに宛てられたインターネットから来るメールを直接配信することを許可しません。 そのかわりに、1台の中央メールホスト (またはメールホストの集合) を使用して、入ってくるメールメッセージを途中で止めて宛先に振り分けます。
メール交換レコードで、ドメイン内の各マシンにサービスを提供しているメールホストが識別されるため、 メール交換レコードには遠隔組織の DNS ドメイン名と、その IP アドレスまたは対応するメールホストのホスト名のいずれかが列挙されています。
DNS のネームサーバーには、in.named デーモンに加えて、named.conf という構成ファイル、resolv.conf というリゾルバファイル、4 種類のゾーンデータファイルがあります。
内部で一貫性が取れていれば、ゾーンデータファイルには何でも好きな名前を付けることができます。 このため、異なるサイトで作業をしようとする場合や DNS 関連のマニュアルや本を参照する場合に、混乱するかもしれません。
たとえば、Sun のマニュアルや大多数の Solaris サイトで使われているファイル名は、『DNS and BIND』(Paul Albeltz & Criclcet Liu 著、浅羽登志也/上水流由香監訳 、アスキー出版局、1995年) で使われているファイル名とは異なります。 そしてこれら 2 派の命名方法は、『Name Server Operations Guide for BIND』(カリフォルニア州立大学刊、パブリックドメイン) の命名方法とも若干の相違があります。
さらに、本書とその他の DNS 関連のマニュアルでは、説明にはファイルの主な役割を表す総称名を使い、コード例には具体的な固有の名前を使っています。 たとえば、Solaris のネームサービスに関するマニュアルでは、ファイルの機能や役割を説明する場合は hosts という総称名を使い、コード例では db.doc や db.sales.doc といった名前を使っています。
参考のため、次の表で上で述べた 3 種類の BIND ファイル名を比較します。
表 5–3 BIND ファイル名の例
Solaris |
O'Reilly / その他 |
カリフォルニア州立大学バークレイ校 |
ファイルの内容と役割 |
---|---|---|---|
/etc/named.conf |
/etc/named.conf |
/etc/named.conf |
構成ファイルは、それが実行されるサーバーのタイプ、および「マスター」、「スレーブ」、または「スタブ」として機能するゾーンを指定する。 また、セキュリティ、ロギング、およびゾーンに適用されるオプションの細かい細分性を定義する |
/etc/resolv.conf |
/etc/resolv.conf |
/etc/resolv.conf |
各クライアント (DNS サーバーを含む) 上に存在するファイル。DNS 情報を探すためにクライアントが照会するサーバーを示す |
named.ca |
db.cache db.root |
root.cache |
ルートサーバー名とそのアドレスがリストされている |
総称名: hosts 例: db.doc db.sales |
総称名: db.domain 例: db.movie db.fx |
総称名: hosts 例: ucbhosts |
サーバーがサービスを提供するローカルゾーン内のマシンに関する全データが格納されている |
総称名: hosts.rev 例: doc.rev |
総称名: db.ADDR 例: db.192.249.249 db.192.249.253 |
hosts.rev |
逆マッピング (アドレスから名前) を行うための特殊なドメインin-addr.arpa. のゾーンを指定する |
named.local |
総称名: db.cache 例: db.127.0.0 |
named.local |
ローカルループバックインタフェースまたはローカルホスト用のアドレスを指定する |
$INCLUDE ファイル |
$INCLUDE ファイル |
$INCLUDE ファイル |
データファイル内の $INCLUDE() 文によって識別されるファイル |
このマニュアル内の例やコード例で使われている IP アドレスとネットワーク番号は、説明に具体性を持たせるために仮に決めたものです。 これらの情報は、実際のネットワークやホストに使われていることがあるので、そのまま使うのは避けてください。
BIND 構成ファイル /etc/named.conf は、サーバーをマスターサーバー、スレーブサーバー、またはキャッシュ専用サーバーとして設定します。 また、サーバーが権限を持つゾーンを指定し、どのデータファイルから初期データを取得するかを指定します。
/etc/named.conf ファイルには、次の機能を実装する文が含まれています。
アクセス制御リスト(ACL) によるセキュリティ。ACL には、NIS+ ホストが読み取り/書き込み権を持つ IP アドレスの集まりが定義されている
ロギング動作の指定
構成ファイルは、サーバーの起動スクリプト /etc/init.d/inetsvc によってデーモンが起動されるとき、in.named によって読み取られます。 構成ファイルにより、他のサーバー (マスター、スレーブまたはキャッシュ専用サーバー) として設定されるか、あるいは初期データを取得する構成ファイルが示されます。
named.conf ファイルは、いくつかの文とコメントで構成されています。 文はセミコロンで終わります。 一部の文は、文のブロックを含むことができます。 ブロック内の各文もセミコロンで終わります。
named.conf ファイルは、以下の文をサポートします。
表 5–4 named.conf 文
文 |
説明 |
---|---|
acl | アクセス制御に使用する、IP アドレスの一致リストを名前を付けて定義する。 アドレスの一致リストは、1 つ以上の IP アドレス (ドット形式の 10 進表記) または IP 接頭辞 (ドット形式の 10 進表記の後にスラッシュとネットマスクのビット数が付く) を示す。 名前を付けたIP アドレスの一致リストは、他の場所で使用する前に acl 文で定義されている必要がある。前方参照は不可。 |
include | include 文がある箇所にインクルードファイルを挿入する。 include を使用することで、管理しやすいまとまりに構成情報を分割することができる |
key | 特定のネームサーバーでの認証と承認に使用される鍵の ID を指定する。 server 文を参照 |
logging | サーバーが記録するログ情報と、ログメッセージの送り先を指定する |
options | グローバルなサーバー構成のオプションを制御して、他の文に対するデフォルト値を設定する |
server | 遠隔ネームサーバーに関して、指定された構成オプションを設定する。 すべてのサーバーに対してではなく、サーバーごとに選択的にオプションを適用する |
zone | ゾーンを定義する。 すべてのゾーンに対してではなく、ゾーンごとに選択的にオプションを適用する |
options { directory "/var/named"; datasize 2098; forward only; forwarders { 99.11.33.44; }; recursion no; transfers-in 10; transfers-per-ns 2; allow-transfer { 127.0.1.1/24; }; }; logging { category queries { default_syslog; }; }; include "/var/named/abcZones.conf" // here are the names of the master files zone "cities.zn" { type master; file "db.cities.zn"; }; zone "0.0.127.in-addr.arpa." { type master; file "db.127.cities.zn"; }; zone "168.192.in-addr.arpa" { type master; file "db.cities.zn.rev"; }; zone "sales.doc.com" { type slave; file "slave/db.sales.doc"; masters { 192.168.1.151; }; }; zone "168.192.in-addr.arpa" { type slave; file "slave/db.sales.doc.rev"; masters { 192.168.1.151; }; }; |
named.ca ファイルによって、ルートサーバー名が確立され、そのアドレスが列挙されます。 ネットワークがインターネットに接続されている場合は、named.ca には、インターネットのネームサーバーが表示されます。接続されていなければ、ローカルネットワークのルートドメインネームサーバーが表示されます。 in.named デーモンは、サーバーの 1 つに接続できるまで、サーバーのリストを一巡します。 そして、そのサーバーから現在のルートサーバーのリストを入手します。デーモンは、このリストを named.ca の更新のために用います。
ルートサーバー名は NS レコードに、アドレスは A レコードに示されています。 この named.ca ファイルを使用するルートサーバーごとに、NS レコードと A レコードを追加する必要があります。
named.ca ファイルの入手方法または作成方法は、ネットワークがインターネットに接続されているかどうかによって異なります。
ネットワークがインターネットに接続されている場合は、InterNIC Registration Service (本書執筆の時点) から次の手段で named.ca ファイルを入手できます。
匿名 FTP。 FTP サイトは ftp.rs.internic.net、 ファイルは /domain/named.root です。
Gopher。 Gopher サイトは rs.internic.net です。 ファイルは named.root であり、これは「InterNIC Registration Service」メニューの「InterNIC Registration Archives」サブメニューで見つけることができます。
本書で説明した命名規則に従う場合、named.root を /var/named/named.ca に移動します。
; ; formerly NS1.ISI.EDU . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; ; formerly TERP.UMD.EDU . 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ; ; formerly NS.NASA.GOV ;. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ; ; formerly NS.ISC.ORG . 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.21 ; ; formerly NS.NIC.DDN.MIL . 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ; ; formerly NIC.NORDU.NET . 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ; ; temporarily housed at NSI (InterNIC) . 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 198.41.0.11 ; ; temporarily housed at ISI (IANA) . 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ; ; temporarily housed at ISI (IANA) . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 198.32.65.12 ; End of File |
ネットワークがインターネットに接続されていない場合は、独自の named.ca ファイルを作成する必要があります。 そのためには、サーバーのどれか 1 つをルートサーバーとし、DNS サーバーごとにそのルートサーバーを指す named.ca ファイルを作成します。
たとえば、private というドメインで ourroot というマシンを非インターネットルートサーバーとして指定する場合を想定します。 ourroot の IP アドレスが 192.1.1.10 であるとすると、 named.ca ファイルには次の行を書き込みます。
ourroot.private. 999999 IN A 192.1.1.10 |
キャッシュファイルも SOA レコード、各ドメインおよびサブドメインの NS レコード、各サーバーの A レコードを必要とします。
たとえば、ourroot の他に、ourmaster と ourslave という 2 つの DNS ネームサーバーがあるとします。 その場合、DNS サーバー上の named.ca ファイルはすべて次のようになります。
; @ IN SOA ourroot.private. hermit.ourroot.private ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh after 3 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day ; ourroot.private. 999999 IN A 192.1.1.10 ; private. IN NS ourmaster.private. 1.1.192.in-addr.arpa IN NS ourmaster.private. ourprivate.private. IN A 192.1.1.1 ; private. IN NS ourslave.private. 1.1.192.in-addr.arpa IN NS ourslave.private. ourslave.private. IN A 192.1.1.2 |
hosts ファイルには、ローカルゾーン内のマシンに関するすべてのデータが含まれています。 このファイル名は、構成ファイル内で指定します。 /etc/hosts との混同を避けるために、hosts 以外の名前を付けます。たとえば、これらのファイルに db.domain パターンを使用して名前を付けることができます。 この命名方法により、doc.com と sales.doc.com ドメインのホストファイルは db.doc と db.sales になります。
hosts ファイルには、ゾーン内にある各マシンの全データが収められています。 ゾーンが複数のドメインにまたがっている場合は、そのゾーンを構成する全ドメインの全マシンがそのゾーンのホストファイルに列挙されます。 hosts ファイルの設定 を参照してください。
hosts という名前はファイルの役割や内容を表す総称名です。 ただし、この総称名をそのまま使うと /etc/hosts と紛らわしいので、この種のファイルは hosts 以外の名前にします。 ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts ファイルを置き、各ゾーンの hosts ファイルには一意の名前を付けなければなりません。 たとえば、DNS ドメイン内に doc.com と sales.doc.com という 2 つのゾーンがある場合は、1 つの hosts ファイルを db.doc、もう 1 つを sales.db.doc という名前にするとよいでしょう。
各ゾーンには個別の、一意の名前を持つ hosts ファイルが必要です。 複数のゾーンが存在する場合は、各ゾーンの hosts ファイルには他のゾーンのマスター (マスター、スレーブ) サーバーに関する情報も含める必要があります。詳細については、例 5–16 を参照してください。
$TTL 5h ; ; SOA rec doc.com. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers doc.com. IN NS sirius.doc.com. sales.doc.com. IN NS altair.sales.doc.com. ; Addresses localhost. IN A 127.0.0.1 sirius IN A 192.168.6.1 rigel IN A 192.168.6.112 antares IN A 192.168.6.90 polaris IN A 192.168.6.101 procyon IN A 192.168.6.79 tauceti IN A 123.45.6.69 altair.sales.doc.com. IN A 111.22.3.4 ; aliases durvasa IN CNAME sirius.doc.com. dnsmastr IN CNAME sirius.doc.com. dnssales IN CNAME altair.sales.doc.com. |
明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する
A (アドレス) レコード。ゾーン内の各ホストに必要
CNAME (正規名) レコード。ゾーン内の各ホストのエイリアスに必要
1 つまたは複数の MX (メール交換) レコード
hosts.rev ファイルで、逆 (アドレスから名前) マッピングを行うための特別な in-addr.arpa. ドメインのゾーンを指定します。 このファイル名は、構成ファイル内で指定します。
hosts.rev という名前は、ファイルの役割や中身を表す総称名です。 ドメイン内に複数のゾーンがある場合は、各ゾーンに 1 つずつ hosts.rev ファイルを置き、各ゾーンの hosts.rev ファイルには一意の名前を付けなければなりません。 たとえば、doc.com と sales.doc.com に分けられている DNS ドメインであれば、一方の hosts.rev ファイルの名前は doc.rev 、もう一方の名前は sales.rev とします。
$TTL 5h ; SOA rec 6.45.123.in-addr.arpa. IN SOA sirius.doc.com. sysop.centauri.doc.com. ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 6.45.123.in-addr.arpa. IN NS sirius.doc.com. 1 IN PTR sirius.doc.com. |
hosts.rev ファイルは、次の要素で構成されています。
明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する
サーバー名は省略形では指定できない
PTR レコード。ゾーン内の各ホストに 1 つ必要。
マシン名は完全指定する必要がある
(これらのリソースレコードの詳細については、リソースレコードのタイプ を参照してください。)
named.local ファイルではローカルループバックインタフェースのアドレスまたはローカルホストをネットワークアドレス 127.0.0.1 で指定します。このファイル名は、構成ファイル内で指定します。 他のファイルと同様、このマニュアルで使われていない名前を付けることもできます。
named.local ファイルは、ネームサーバーのローカルループバックインタフェースを設定します。
$TTL 5h ; SOA rec 0.0.127.in-addr.arpa. IN SOA sirius.doc.com sysop.centauri.doc.com ( 1997071401 ; serial number (YYYYMMDD##) 10800 ; refresh every 3 hours 10800 ; retry every 3 hours 604800 ; expire after a week 86400 ) ; TTL of 1 day ; Name Servers 0.0.127.in-addr.arpa. IN NS sirius.doc.com 1 IN PTR localhost. |
named.local ファイルは通常、次の要素で構成されています。
明示的な TTL (生存期間) セットを持たない、ファイル内の全レコードのデフォルト TTL
1 つの SOA (権限の開始) レコード
1 つまたは複数の NS (ネームサーバー) レコード。マスターおよびスレーブの DNS ネームサーバーを識別する
サーバー名およびドメイン名は完全指定する必要がある
1 つの PTR レコード。localhost に必要
インクルードファイルは、DNS データファイル内の $INCLUDE() 文で指定されているファイルのことです。 $INCLUDE ファイルを使ってデータを型ごとに別々のファイルに分割しておくと便利です。
たとえば、データファイルに次のような行が含まれているとします。
$INCLUDE /etc/named/data/mailboxes |
この行によって、/etc/named/data/mailboxes ファイルがその時点で読み込まれます。 この例では、/etc/named/data/mailboxes が、$INCLUDE ファイルです。 $INCLUDE ファイルは、 必要に応じて、必要な数だけ使用します。
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. |