CNAME - みる会図書館


検索対象: UNIX MAGAZINE 2002年9月号
5件見つかりました。

1. UNIX MAGAZINE 2002年9月号

0 けつま 3 びっ u スは 1.2.3.4 " と書くと、あとで説明するような問題か起 こってしまいます。同し内容を正しく示すためには、 example.org/ IN NS うに、両方の名前に対して A レコードで直接 IP アドレ example ・ 0 て g. IN スを指定しましよう。 IN A IN A nsl 1 . 2 . 3 . 4 1 . 2 . 3 .4 A A yuzuko のように yuzuko IN IN 1 .2 . 3 .4 1 .2 . 3 .4 example.org の IP アドレスは 1.2.3.4 で、 同時に yuzuko というホストの IP アドレスは 1.2.3.4 " と書かなければなりません。 最初の例のように、 NS レコードと CNAME レコード カイ并記されていると、どんな問題か起こるのでしよう。し つは BIND などの DNS サーバーには、ある名前に対す る CNAME レコードをみつけると、同し名前に対する他 のレコードはすべて無視するという挙動があります。その ため最初の例では、 example ・ org ドメインに対するネー ムサーバーがみつからなくなってしまうわけです。 NS レコードは DNS 名前解決のためにもっとも重要な レコードです。十分に注意して設定しましよう。 より詳しく知りたい場合は RFC1912 の 2.4 節や RFC 2181 の 10.1 節を参考にしましよう。 8. MX レコードで CNAME を参照してい ないか ドメインに対する電子メールサーバーの位置を示す MX レコードでも、 CNAME レコードに関しては同し間 題があります。 mx という名前は機能を示しているので、 www や ftp 、 news などと同しように CNAME として扱いたくなりま す。しかし、 MX レコードの先の値を CNAME にする ことは RFC て禁止されています。 NS レコードの場合と同しように、 example.org/ IN MX yuzuko I N CNAME yuzuko IN A 1 . 2 . 3 .4 という DNS レコードを使ってはいけません。 MX レコー ドの値に mx という別名を指定すると、そこからさらに yuzuko という名前を角夬するためによぶんな DNS トラ フィックが発生してしまい、ネットワークやサーバーに負 担をかけるからです。 mx という名前と yuzuko という名前を両方とも使いた い場合は、 CNAME レコードを利用せす、以下の例のよ 96 この間題については、 RFC1912 の 2.4 節や RFC 2181 の 10.3 節で詳しく説明されています。 CNAME レコードは単独て使う CNAME レコードについて、もうすこし説明しておき ます。 NS レコードの説明でも述べたように、 CNAME レコ ードは基本的に単独で使うべきものです。 RFC2181 の 10.1 節では、 DNS のラベルとして正しい内容は、 ・ CNAME レコード 1 個のみ (SIG 、 NXT 、 KEY レ コードは同時に使ってもよい ) ・ CNAME レコード以汐 P ) 1 個または複数のレコード ・レコードなしで名前のみ ・名前も何もなし と定義しています。 この定義からも分かるように、 CNAME レコードは 1 度に 1 個しか使えません。さらに、基本的に他のレコード とは併記しないことになっています。 また、 CNAME レコードで CNAME を参照するこ とも避けましよう。このような状態は連鎖 ( チェーン ) と 呼ばれますが、最終的に IP アドレスに到達するまで何度 も間合せをしなければならす、検索の効率が下がってしま います。また、連鎖の設定に失敗して無ルレーフ。か起こっ ていたり、 IP アドレスにたどり着かない場合もあります。 CNAME の利用は 1 段階にとどめておくべきです。 UNIX MAGAZINE 2002.9 レス ) を使っているドメインが多いはずです。 RFC1918 IPv4 では、プライベート・アドレス ( RFC1918 アド ンに書いていないか 9. プライベート・アドレスを外から見えるゾー て使いましよう。 サーバーカ働いてくれなくなってしまいます。十分主意し りがちですが、使い方を間違うと、思ったとおりにネーム たいへんイ叫リな CNAME はついあちこちてイ吏いたくな

2. UNIX MAGAZINE 2002年9月号

0 けつま 3 びっ U ド ールアドレス中の、、@" を . に置き換えましよう。また、 メールアドレスのローカノレヾート (@の方ゴ則) で、、 . " を使 っている場合は、、、 . " の前に、 \ " を付けなけれはなりませ ん。これらは当駲田なことに思えるかもしれませんが、その 当田なことが自分にとっても他人にとっても大きな迷惑の 種になったりします。 ネームサーバーは、間合せに対する個々の応答の内容 に不備な点がないかどうかをチェックします。何かおか しな部分がある場合、その応答は、、 unauthoritative" な データとしてエラーになります。この、、おかしな部分 " に は、上記の、、メールアドレス中の@文字 " も含まれます。 1 文字直しそびれただけで、自分のネームサーバーを unau- thoritative なサーバーにし、さらに間伶を送った別の ネームサーバーの管理者にエラー処理をさせることになっ てしまうのです。 DNS 設定ファイルを書くときの文法には、細かいとこ ろまで気をつけましよう。 7. NS レコードで CNAME を参照していな いカ、 CNAME (Canonical name) レコードは、別名から正 式名への対応を示すためのレコードです。たとえは、 ns0. example.org という FQDN をもつホストに yuzuko と いう別名を付けたい場合、 BIND では、 IN CNAME ns0 .example.org ・ yuzuko のように、別名 (yuzuko) の正式名 (CNAME) が ns0. example ・ org. であることを示します。 CNAME レコードは、とくにサーバーホストに対して、 提供するサービスを示す男銘を付けるときにイリです。た とえは、 ftp.example.org や www.example.org といっ た、サービスを表す別名の付いた名前はよく見かけるはす このように、 CNAME はたいへん役に立つレコードで すが、取扱いに十分注意しなけ川まならないレコードでも あります。 NS レコードと CNAME レコードについては、 気をつけるべきポイントが 2 つあります。 NS レコードでは別名を参照すべきではない なによりもます注意すべきなのは、ドメインの NS レ コードが参照する値の先に CNAME を使わないようにす UNIX MAGAZINE 2002.9 ることです。このようにすると、名前を参照するたびに余 計な DNS の間合ぜか発生して、ネットワーク全体の負荷 を上げてしまうからです。 たとえば、 DNS レコードが以下のようになっていると します。 example ・ org ・ nsl yuzuko IN NS nsl IN CNAME yuzuko IN A 1 . 2 . 3 .4 このとき、 example.org というドメインのネームサー ーを解決するための間合せには、 yuzuko という別名 が返されることになります。そして、再度別の問合せに よって yuzuko の A レコードをみつける必要があるた め、よぶんな間合せが発生してしまいます。最悪の場合、 CNAME レコードだけが設定されていて最終的に A レ コード ( または他のアドレスを示すレコード ) に到達しな かったとしたら、 example ・ org ドメインに対するネーム サーバーの場所は分からないままになります。 よぶんなトラフィックを増やして他に迷惑をかけないた めにも、また自分のドメインが行方不明にならないために も、 NS レコードて参照する先の値には A レコードなどの アドレス情報を用いなけれはなりません。 この間題は、 RFC2181 [ 3 ] の 10.3 節「 MX and NS records 」で詳しく述べられています。 NS レコードと CNAME レコードを併記しない NS レコードと CNAME レコードに関するもう 1 つ の間題は、 DNS サーノヾーによる CNAME レコードの扱 い方に深くかかわっています。 CNAME レコードは基本 的に単一で使うべきレコードで、他のレコード ()S 、 MX など ) と併記してはいけません。 たとえは、以下のようなレコードは間違っています。 example.org/ IN NS nsl IN CNAME yuzuko yuzuko IN A 1 . 2 . 3 . 4 本来、、、 example. 。 rg. " の部分はドメイン名なので、 1 つのホストに対応づける必要はないはずです。しかし、ド メインにホストが 1 台しかないときには、そのままドメイ ン自体をホストに結びつけたくなることもあるでしよう。 そのような場合、上記のように、、 example.org は実際 は yuzuko というホストのことで、 yuzuko の IP アドレ 95

3. UNIX MAGAZINE 2002年9月号

0 けつま 3 びっ 表 1 ネームサーパーの言聢チェックリスト 不安な項目について該当する説明を読んでみましよう 10. 逆引きアドレスは正しく設定されているか いないか 9. プライベート・アドレスを外から見えるゾーンに書いて 8. MX レコードで CNAME を参照していないか 7. NS レコードで CNAME を参照していないか ていないか 6. SOA レコードのなかで使用すべきではない文字を使っ 5. SOA レコードの値に問題はないか 4. ドメインが lame delegation を起こしていないか 3. バージョンを間い合わせるコマンドへの応答は適切か 2. 使用している BIND のバージョンは最新か ワーク上に置いていないか 1. マスターとスレープのネームサーバーを同し物理ネット UNIX MAGAZINE 2002.9 ているネットワーク上に置き、スレープは友人のネームサ 私の場合は、マスター・ネームサ→ヾーを自分の管理し のネットワークに置くようにしましよう。 まいます。複数のネームサーバーを用意したときには、別 せつかく複数のネームサーバーを用意した意味カ囀れてし 合に、どちらにも問合せが届かなくなります。これでは、 か発生してこの物理ネットワークに到達できなくなった場 同し物理ネットワーク上に置いていると、なんらかの障害 マスター・ネームサーバーとスレープ・ネームサーバーを 別の物理ネットワーク上に配置すべきです。 まり複数のネームサーバーを用意する場合は、それぞれを ームサーノヾーとスレープ・ネームサーバーを置くとき、つ スレープがあります。あるドメインに対してマスター・ネ 前節で説明したように、ネームサーバーにはマスターと じ物理ネットワーク上に置いていないか 1. マスターとスレープのネームサーバーを同 資料にあたってみてください。 紹介している RFC を読んだり、最後に紹介している参考 以下の説明だけでは糸断等できないときは、参照先として 管理ができるようになるはずです。 ちろん全部読んで実践すれは、、、正しい " ネームサーノヾー よく知りたいポイントに関する説明を読んでください。も るネームサーバーについて不安に思うポイントや、もっと ます、表 1 のチェックリストを見て、自分の管理してい について説明します。 ・どの資料を参照すべきか ーバーに置カせてもらっています。複数の物理ネットワー クから構成される大規模ドメインは別として、小さなネッ トワークにとってスレープをどこに置くかは、しつは案外 難しい間題です。有料のネームサーバー設置サーピスもあ るようですが、本来は各ドメインてオは圧にスレープ・ネー ムサーバーを置き合うのか望ましいかたちだと思います。 ところで、ネームサーバーの数は多いはどよいというわ けではありません。あまりに数が多いと、ネームサーバー のデータの整合生のチェックなどもたいへんになります。 負荷分散の必要がある大莫なドメインでも、せいぜい 5 つぐらいにしておいたほうが無難でしよう。 2. 使用している BIND のバージョンは最新か 不一ムサーバー・ソフトウェアには、前節でも紹介した BIND3 や djbdns4 などがあります。なかでも BIND は、 現在もっともひろく使われているネームサーバーです。 BIND ( にかぎりませんか ) を使う場合に注意する点は、 かならず最新版を使うことです。ソフトウェアはバージョ ンアップによってセキュリティ・ホールやバグに対処す るため、できるだけ新しいものを使うはうがよいのは当然 です。とくに DNS はインターネットの基幹を支えるシ ステムですから、間題を大きくしないためにも、つねに最 新のバージョンを使うようにする必要があります。描丘も BIND のはとんどのバージョンにおける深刻なバグの報 告があったので、旧いノヾージョンの BIND を使ってい る場合は一刻も早く BIND 8.3.3 か BIND 9.2.1 にア ップグレードすべきです。 BIND のバク長告および使う べき山斤のノヾージョンについては、「 BIND Vulnerabil- ities 」という WWW ページ 5 て市忍できます (BIND 9 で DNSSEC の利用を考えている場合は、 OpenSSL の バージョンにも注意しましよう ) 。 DNSQC では、 JPNIC で管理している ac 、 ad 、 co 、 ed 、 go 、 gr 、 ne 、 or 、 jp の各ドメインについて、 DNS レコードの状況を調査しました。調査対象に ( お或ドメイ ンは含まれていません。 ネームサーバー・ソフトウェアのバージョンの調査に ついては、 dig コマンドへの応答からの抽出というガ去が 3 http://www.isc.org/pr0ducts/BIND/ 4 http://djbdns.org/ 5 http://www.isc.org/pr0ducts/BIND/bind-security.html 91

4. UNIX MAGAZINE 2002年9月号

, けつま 3 びっ u ド ネームサーバーに対し、 example ・ org ゾーンの情報をもっ ているネームサーバーを問い合わせます。こうして exam- ple.org ゾーンのネームサーバーにたどり着けば、 exam- ple.org ドメイン、またはこのドメイン内の各ホストに関 する情報を間い合わせられるようになるわけです。 ネームサーバ—-t ま、 DNS サーピスを提供するサーバー です。担当するゾーン内のドメイン名、 NS ( ネームサー ー ) 名、 MX (MaiI eXchanger) 名などの DNS を通 して解決されるさまざまな情報尉寺しており、問合迂に 対する応答のかたちで外部に提供しています。 もっとも有名なネームサーバー・ソフトウェアは BIND (Berkeley lnternet Name Domain) です。 BIND の設 ネームサーバー群を取得できるようになっています。 ムサーバーの一覧を間い合わせることで、山万のルート・ 重加与に、ここ日疋されたサーバーー見在のノレート・ネー ネームサーバーの位置か記載されています。 BIND は起 root. cache ファイルには、名前解決に必要なルート・ ・各ゾーンデータ・ファイル ・ named. C011f ・ root. cache 定ファイルには以下の 3 不頁があります。 景グするオプションなどを示すレコードです。その他のレ コードが置かれます。これは、その設定ファイル全体に ド ) になっています。設定ファイルの先頭には SOA レ BIND の設疋ファイル内の各行は個々の設定 ( レコー ファイルの 2 不頁があります。 き " ファイル、 IP アドレスを名前に対応づける、、逆引き " やホスト名などの名前を IP アドレスに対応つ、ける、、正引 ゾーンデータ・ファイルには大きく分けて、ドメイン名 タ・ファイルを対応づけるためのものです。 次の named. conf ファイルは、各ゾーンにゾーンデー ・ホスト名から IPv6 アドレスを示す AAAA レコード ・ホスト名から IPv4 アドレスを示す A レコード ・ドメインに対するメールサーバーを示す MX レコード ・ドメインに対するネームサーバーを示す NS レコード コードには以下のようなものがあります。 90 ・ IP アドレスから逆引き名を示す PTR レコード ・ホストの別名から正式名への対応を示す CNAME レ ネームサーバーには、マスターとスレープの 2 不鶤頁があ ります。マスター・ネームサーバーは、そのゾーンに対す る第一のネームサーバーで、 1 次情報を提供しています。 スレープ・ネームサーバーはマスター・ネームサーバーが 提供する情報のコピーで、通常は定期的にマスター・ネー ムサーバーの情報を反映するように設定されています。 の作業を、、ゾーン転送 " といいます。 つまり、管理者カ躾際に管理作業をおこなうのはマスタ ・ネームサーバーで、そオ人外はその結果をコピーして 動作するサーバーとなります。 なお、ゾーンに対してネームサーバーを 1 つ用意して あれは名前サーピスを提供できますが、 RFC1912 [ 1 ] で は、、ネームサーバーは 2 つ以上用意すること " と規定して います。 RFC を参照しよう IETF はインターネット標準の策定機関です。 IETF での議論を経て公開される文書は、 RFC (Request for Comments) と呼はれます。インターネットに関係する プロトコルのイ士様やその他の標準の多くは、 RFC として 公開、参照されています。 DNS も IETF で標準化されたプロトコルの 1 つで、現 在もさまざまな拡張や運用に関する取決めなどが追加され ており、それらの一部は RFC として公開されています。 を行でとりあげるチェックリストの角見のなかでも、参照 すべき RFC について触れています。より詳しく正確な説 明が必要なときは、ぜひ 1 次情報である RFC を読んでく ださい。 RFC はインターネットに関する重要な情報なので、イ ンターネット上の多くの場所て参照できます。詳しくは、 IETF の www サイト 2 を見てください。また、 IETF や RFC 自体については、本誌の「 RFC ダイジェスト」 でも紹介されています。 DNS チェックリスト UNIX MAGAZINE 2002.9 2 http://www.ietf.org/ ・どうやって直せばいいか ・何カ墹題なのか 以下のチェックリストの各項目では、

5. UNIX MAGAZINE 2002年9月号

, けつま 3 びっド 図 4 DNS Report ツールもどんどん活用していきましよう。 ます、 DNS Report ( 図 4 ) では、ドメイン名を入れる だけで、 NS レコードや MX レコードなどについて、ひ ととおりのチェックをおこなってくれます。 lame dele- gati 。 n があるかどうかも教えてくれます。結果も見やす くて、つい何度も試してみたくなるサイトです。 Squish ( 図 5 ) は、・箚重レコードについて個別にチェッ クしてく PTR レコードも調べられるので、違った角 度からネームサ→ヾーをチェックできます。 しつは私も、これらの WWW サイトで自分のドメイン の査をしたら、結果に、、 Warning" がいくつも出てしま い、あわてて直したところです。設定力絲冬ったからといっ て安じ、せす、つねに注意していないといけないなぁ・ 心から反省しました。 www.0NSr印0「な0m YO むい第“ . D 、な、 ( om 「メ准 rDNS に新レー町 DNS け m ー . な気し戸 5 ロ W 日 0 は響 , N を心、に ). Ⅱ S 燔・、 0 第 A 、 OPE 、 R 論 Y 〒 TER ! Ple 新を go 0 , SP D 載鹵、第し 0 つな第 ↑ 0 ( E 「 a m 第れを・ト第、町 40m11.2 第時 第 5 Ⅲはび′いⅵ山 aDNS 【 ) 代也 m ー A ヴーい諸ロ、可の m 仙第 5 tns : せ廳 3 朝鬮ゆ第協 tb> 0u0 れ新ⅸ m. Å目ッ地 tOdO 物きを ! !*dom nn 加いを霧れの物磚れ円れⅲを物れ You ー物 ! 0 它を物血ぬ am を . なせ第載 n に新「田 p , 口、衂 d 淡社こをを内を町 p に、 ( 新 m 、 Andp 額給 tnem レ「物誂 c ・い 6 対一をは 00m 0 町れ - NOtet\ ー DNS ー 4 第代 tn 写 0 ) nt : い 0 ー ハ 0 ) 町面第 : 醺驫 . t m ー ( 盟第 0 ( ? ル社督ー % 530 と第 レ町 6 心め ( 社 0 ト DNS 円代癶をいのまアー耨 an ”ート印 am を - に師れ響を度加れ町印に e ( 0 ⅵヒ 0 0 当当当当ドレ - T れ an ! 血物 7 名ⅱ 0 0 しト加 5 ? 毛ー新 U$ http://www.dnsreport.com/ 図 5 Squish 侊祐ー著こわ背ー滝ー第ト比物、写ー紀を物 ! 、第都′ tc ( 謝 0 、′ー興ー ( 層 . れを物ー洋を僕 1 望を物第 ( ーを 1 物丗ーを・ ! 材「 を & を都第を物市′ー物、を、ト物ょ第を新一を物第 ( 0 第“を 00 5 ー紋«d 種トにをー物 ☆ 3 「物 0 を 0 い 6. ツ、めせ第“第・第 0 行を ! 第物 物 tr 平を礰 ) 地物修一を第一ーこ第第、北ーツ ( し 1 物をは第「当健 . ま Åな′第、対” , いをを・、を問を当′朝 - 上市 CNAME 0 も一第一当第 C - 、・引 1 町日 ! A 第一′′・第 - ー第一 234 132 ー - 、プ第 今回は、 DNS チェックリストをお届けしました。私も ネームサーバー管理者の卵の 1 人として、 NetBSD 上で BIND 9 を使って DNS サーバーを構築しています。そ のために得た知識を読者の方々と共有したいと考えて、今 回の記事を書きました。みんなで正しい設定の DNS サ ーを増やして、インターネット資原を有効に使いまし 次回からは、また実際の自分のドメイン構築作業に戻る つもりです。ネームサーバーの管理はなんとかできるよう になったので、次は WWW サーバーを作ってみようと 思っています。 0 http://www.squish.net/dnscheck/ い」 8 というべージは、詳しいチェックリストになってい るので、便利に利用できます。 英語の WWW サイトでは、「 Domain Name Sys- tem (DNS) Configuration, Management and Trou- bleshooting 」 9 がよくまとまっていて、参考になります。 プレゼンテーション用の資料・なので、英語も簡単です。最 初に紹介した神明さんの資料と一緒に目をとおしておくと 理解しやすいと思います。 DNS チェッカー 今回は DNS のチェックポイントについて説明してき ました。しつは、串ヾたい DNS レコードについて自重加勺 に調査してくれる WWW サイトがあります。とても手軽 で便利なので、 1 人で悩んでいるだけでなく、このような 8 http://dns.qmail.jp/config-error.html 9 http://www.opusl.com/www/presentations/sanug/ ( もり・ゆすこ ) [ 赭文献 ] [ 1 ] D. Barr, Common DNS 〇 era 0 れ襯佖れ d Co れ五 9 社 ra ー 0 れ ET ァ 0 ” , RFC1912 , February 1996 [ 2 ] M. Andrews, 加 e C 佖 c 厖れ 4 可 DNS Queries ( 〃ル S NCACHE), RFC2308 , March 1998 [ 3 ] R. E レ , R. Bush, C 五 ca 0 れ s to the DNS Specifi- ca 0 れ , RFC2181 , July 1997 [ 4 ] H. Eidnes, G. de Groot, P. Vixie, ClassIess / ルー ス DD 月 . A 月 P. 員 deleg 佖 0 れ , RFC2317 , March 1998 99 UNIX MAGAZINE 2002.9