DNS HOWTO <author>Nicolai Langfeldt (<tt/dns-howto(at)langfeldt.net/), <!--O Jamie Norrish and others --> Jamie Norrish 他 <date>Version 9.0, 2001-12-20 <trans>中野武雄 <tt/nakano(at)apm.seikei.ac.jp/ <tdate>v9.0j1, 2002-02-03 <abstract> <!--O HOWTO become a totally small time DNS admin. --> 短時間で DNS 管理者になる方法。 </abstract> <toc> <!--O <sect>Preamble --> <sect>前書き <p>Keywords: DNS, BIND, BIND 4, BIND 8, BIND 9, named, dialup, PPP, slip, ISDN, Internet, domain, name, resolution, hosts, caching. <!--O <p>This document is part of the Linux Documentation Project. --> <p>この文書は Linux Documentation Project の一部です。 (訳注: 翻訳版は Japanese FAQ Project の一部です) <!--O <sect1>Legal stuff --> <sect1>法的なこと <p>(C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. Do not modify without amending copyright, distribute freely but retain copyright message. <p> この文書の著作権は (C)opyright 1995-2001 Nicolai Langfeldt, Jamie Norrish & Co. にあります。 この文書を修正する場合は著作権表示にもその旨明記して下さい。 著作宣言を変更しなければ自由に再配布することができます。 <p> 訳注：翻訳は中野武雄が行いました。(C)opyright 1998-2002 Takeo Nakano <!--O <sect1>Credits and request for help. --> <sect1>謝辞とヘルプ募集 <!--O <p>I want to thank all the people that I have bothered with reading this HOWTO (you know who you are) and all the readers that have e-mailed suggestions and notes. --> <p>本 HOWTO の査読をお願いしたすべての人々 (それぞれの方がご存じのはず)、 提案や情報を電子メールで送ってくださったすべての読者に感謝します。 <!--O <p>This will never be a finished document; please send me mail about your problems and successes. You can help make this a better HOWTO. So please send comments and/or questions or money to janl(at)langfeldt.net. Or buy my DNS book (it's titled "The Concise Guide to DNS and BIND, the bibliography has ISBNs). If you send e-mail and want an answer please show the simple courtesy of <em/making sure/ that the return address is correct and working. Also, <bf/please/ read the <ref id="qanda" name="qanda"> section before mailing me. Another thing, I can only understand Norwegian and English. --> <p>この文書はまだ完成したものではありません。 この文書をより良い物にするために、 問題点や成功例などについて筆者にメールを送って下さい。 コメント・質問、現金などは janl(at)langfeldt.net まで。 あるいは私の DNS 本を買ってください (題名は "The Concise Guide to DNS and BIND です。 ISBN は参考文献リストにあります)。 メールを送り、返信を希望する場合には、 返信先のアドレスが正しいか、またちゃんと機能しているかどうかを 確認して下さるようにお願いします。 またメールする前には必ず <ref id="qanda" name="Q & A"> の セクションを読んでください。 なお、私が読めるのはノルウェー語と英語に限られます。 <!--O <p>This is a HOWTO. I have maintained it as part of the LDP since 1995. I have, during 2000, written a book on the same subject. I want to say that, though this HOWTO is in many ways much like the book it is <em>not</em> a watered down version concocted to market the book. The readers of this HOWTO have helped me understand what is difficult to understand about DNS. This has helped the book, but the book has also helped me to think more about what this HOWTO needs. The HOWTO begot the book. The book begot version 3 of this HOWTO. My thanks to the book publisher, Que, that took a chance on me :-) --> <p>これは HOWTO 文書です。 私は 1995 年から、この文書を LDP の一部として管理してきました。 2000 年に、私はこのトピックに関する書籍を書きました。 お断りしておきたいのですが、 この HOWTO はいろいろな点でその本と似ていますけれども、 本の売り上げを伸ばすためにこの HOWTO で手抜きをしたようなことはありません。 この HOWTO の読者は、DNS の理解がいかに難しいものであるかを 私に教えてくださいました。 それによってこの本は良いものになりましたし、また一方本を書くことで、 この HOWTO に何が必要なのかを考えさせられることにもなりました。 この HOWTO がその本を産み、 またその本がこの HOWTO の第三版を産むことになりました。 このチャンスを私に下さったことに対して、出版社の Que に感謝します :-) <!-- This is a comment meant for translators: If you're a translator you may put information about reaching someone speaking the language you translate to, and that can help with DNS problems, such as yourself, here (otherwise I get mail in chinese and spanish asking for help about DNS) If you want to translate this HOWTO please notify me so I can keep track of what languages it has been published in, and also I can notify you when the HOWTO has been updated. Please also do not replace "(at)" in my e-mail address above with and "@", but do translate it if needed. I hope to reduce the amount of spam I get in this way, or at least not increase it. --> <p>訳注: この文書の v1.0 は、 横田邦彦さんと藤原輝嘉さんとが翻訳されました。 中野が v2.1.1 にあわせて更新し、以降の管理を行っています。 更新の際には、ご意見をいただいた 藤原さん・遠藤さん・花高さん・水原さん、 校正をしてくださった長谷川さん・武井さんをはじめ、 JF-ML の皆さんにお世話になりました。 <p>翻訳に関するコメントは nakano(at)apm.seikei.ac.jp までお願いします。 DNS に関する日本語での質問先としては <url url="http://www.linux.or.jp/community/ml/linux-users/" name="linux-users メーリングリスト"> や <htmlurl url="news:fj.os.linux.networking" name="fj.os.linux.networking">, <htmlurl url="news:fj.net.ip.dns" name="fj.net.ip.dns"> などが適当でしょう。 <!--O <sect1>Dedication --> <sect1>献辞 <!--O <p>This HOWTO is dedicated to Anne Line Norheim Langfeldt. Though she will probably never read it since she's not that kind of girl. --> <p>この HOWTO 文書を Anne Line Norheim Langfeldt に捧げる。 といっても彼女がこの文書を読むことは無いだろうけど。 そういった類の女の子じゃないからなあ。 <!--O <sect1>Updated versions --> <sect1>最新版 <!--O <p>You should be able to find updated versions of this HOWTO both at <url url="http://langfeldt.net/DNS-HOWTO/"> and on <url url="http://www.linuxdoc.org/">. Go there if this document is dated more than 9 months ago. --> <p>この HOWTO の更新版は、 <url url="http://langfeldt.net/DNS-HOWTO/"> または <url url="http://www.linuxdoc.org/"> で見つかるはずです。 この文書が 9 か月以上前の日付だったら、こちらに行ってください。 <!--O <sect>Introduction.<label id="intro"> <p><bf/What this is and isn't./ --> <sect>はじめに<label id="intro"> <p> <bf>この文書は何であって何ではないか。</bf> <!--O <p>DNS is the Domain Name System. DNS converts machine names to the IP addresses that all machines on the net have. It translates (or "maps" as the jargon would have it) from name to address and from address to name, and some other things. This HOWTO documents how to define such mappings using Unix system, with a few things specific to Linux. --> <p>DNS とは Domain Name System のことです。 DNS はマシンの名前を IP 番号 (ネットワーク上のマシンには必ずこの番号が付いています) に変換します。 DNS は名前からアドレスへの、またアドレスから名前への翻訳 (あるいは仲間うちの言葉でいえば「マップ」) などを行います。 この HOWTO 文書では、Unix システムを用いて このようなマップを定義する方法について記述します。 なお Linux に特有なことがらもいくつか含まれています。 <!--O <p>A mapping is simply an association between two things, in this case a machine name, like <tt/ftp.linux.org/, and the machine's IP number (or address) <tt/199.249.150.4/. DNS also contains mappings the other way, from the IP number to the machine name; this is called a "reverse mapping". --> 「マップ」とは、単に二つのものを結びつけることです。 ここでは <tt/ftp.linux.org/ といったようなマシンの名前と、 そのマシンの IP 番号 (IP アドレス) である <tt/199.249.150.4/ のような値を結びつけることになります。 DNS には逆向きのマップも含まれます。 すなわち、IP 番号からマシンの名前への変換です。 これは「逆引き」と呼ばれています。 <!--O <p>DNS is, to the uninitiated (you ;-), one of the more opaque areas of network administration. Fortunately DNS isn't really that hard. This HOWTO will try to make a few things clearer. It describes how to set up a <em/simple/ DNS name server, starting with a caching only server and going on to setting up a primary DNS server for a domain. For more complex setups you can check the <ref id="qanda" name="qanda"> section of this document. If it's not described there you will need to <em/read/ the Real Documentation. I'll get back to what this Real Documentation consists of in <ref id="bigger" name="the last chapter">. --> <p>初心者 (あなた ;-) にとって DNS は、ネットワーク管理のなかでも わかりにくい部分の一つです。 幸い DNS は実際にはそれほど難しくはありません。 この HOWTO では、 いくつかの事柄を多少なりともわかるようにしたいと思っています。 <em/簡単な/ DNS ネームサーバを設定する方法も説明します。 まずキャッシュ専用のサーバからはじめて、 あるドメインに対するプライマリ DNS サーバを設定していきます。 もっと複雑な設定を行なう場合には、この文書の <ref id="qanda" name="Q & A"> の章を参照してください。そこにも書いていなかったら、 もっとちゃんとした文献を読む必要があるでしょう。 「ちゃんとした文献」については、 <ref id="bigger" name="より熟練した管理者になるために"> の章で説明します。 <!--O <p>Before you start on this you should configure your machine so that you can telnet in and out of it, and successfully make all kinds of connections to the net, and you should especially be able to do <tt/telnet 127.0.0.1/ and get your own machine (test it now!). You also need good <tt>/etc/nsswitch.conf</tt>, <tt>/etc/resolv.conf</tt> and <tt>/etc/hosts</tt> files as a starting point, since I will not explain their function here. If you don't already have all this set up and working the Networking-HOWTO and/or the Networking-Overview-HOWTO explains how to set it up. Read them. --> <p>DNS についての作業を始める前に、あなたのマシンを設定して、 telnet での出入りやネットへの各種接続ができるようにしておいてください。 特に <tt/telnet 127.0.0.1/ で、現在のマシン自身にログインできるように してください (今すぐテスト!)。また <tt>/etc/nsswitch.conf</tt> (あるい は <tt>/etc/host.conf</tt>)、 <tt>/etc/resolv.conf</tt>、 <tt>/etc/hosts</tt> などのファイルに対して、 正しい設定をしておいてください。 これらの機能についてはこの文書では説明しません。 以上の準備ができていない場合は、 Networking-HOWTO や Networking-Overview-HOWTO に説明がありますから、 ちゃんと読んで設定しておいてください。 <!--O <p>When I say `your machine' I mean the machine you are trying to set up DNS on, not any other machine you might have that's involved in your networking effort. --> <p> この文書で「あなたのマシン」と書いてあった場合、 それは DNS を動作させようとしているマシンを指すものとします。 他にもネットワークにつながっているあなたのマシンはあるでしょうけど、 それのことではありません。 <!--O <p>I assume you're not behind any kind of firewall that blocks name queries. If you are you will need a special configuration -\-\- see the section on <ref id="qanda" name="qanda">. --> <p>あなたのマシンが所属しているネットワークには、 名前引きをブロックするような防火壁 (ファイアウォール) は存在しないものとします。 ファイアウォール内部にいる場合には特別な設定が必要になります。 <ref id="qanda" name="Q & A"> の章を見てください。 <!--O <p>Name serving on Unix is done by a program called <tt/named/. This is a part of the ``BIND'' package which is coordinated by <em/The Internet Software Consortium/. <tt/Named/ is included in most Linux distributions and is usually installed as <tt>/usr/sbin/named</tt>, usually from a package called <tt/BIND/, in upper or lower case depending on the whim of the packager. --> <p>UNIX システムでの名前引きのサービスは <tt/named/ と呼ばれるプログラムによって実現されます。 これは <em/Internet Software Consortium/ の ``BIND'' パッケージに含まれるプログラムです。 <tt/named/ は、ほとんどの Linux ディストリビューションに含まれています。 たいていは <tt/BIND/ という名前のパッケージに入っていて (大文字小文字はメンテナの気分次第でしょうが)、 <tt>/usr/sbin/named</tt> としてインストールされます。 <!--O <p>If you have a named you can probably use it; if you don't have one you can get a binary off a Linux ftp site, or get the latest and greatest source from <url url="ftp://ftp.isc.org/isc/bind9/">. This HOWTO is about BIND version 9. The old versions of the HOWTO, about BIND 4 and 8, is still available at <url url="http://langfeldt.net/DNS-HOWTO/"> in case you use BIND 4 or 8 (incidentally, you will find this HOWTO there too). If the named man page talks about (at the very end, in the FILES section) <tt/named.conf/ you have BIND 8; if it talks about <tt/named.boot/ you have BIND 4. If you have 4 and are security conscious you really ought to upgrade to the latest version of BIND 8. Now. --> もし named がすでにあれば、それを使えばいいでしょう。 もし無い場合には Linux の ftp サイトからバイナリを入手するか、 最新の (そして最高の) ソースを <url url="ftp://ftp.isc.org/isc/bind9/"> から入手しましょう。 この HOWTO では BIND の version 9 を対象にしています。 BIND 4 や 8 を対象にした古いバージョンの HOWTO は <url url="http://www.math.uio.no/~janl/DNS/"> にありますので、 BIND 4 を使っている人はこちらを参照してください (ついでにこの HOWTO も一緒においてあります)。 named の man ページ (最後の方にある FILES セクション) に <tt/named.conf/ に関する記述があれば、 あなたの使っているのは BIND 8 または 9 です。 逆に <tt/named.boot/ に関する記述があれば BIND 4 です。 セキュリティに気を使わなければならない人で、 4 を使っている場合は、最新の BIND 8 や 9 にアップグレードするべきでしょう。 今すぐに、です。 (訳注) 最後はちょっと意見の分かれるところかも知れません。 例えばソースレベルでのセキュリティチェックを行っていることで知られる OpenBSD では、まだ依然として BIND 4 が現役の named だったりします。 <!--O <p>DNS is a net-wide database. Take care about what you put into it. If you put junk into it, you, and others, will get junk out of it. Keep your DNS tidy and consistent and you will get good service from it. Learn to use it, admin it, debug it and you will be another good admin keeping the net from falling to its knees by mismanagement. --> <p>DNS はネットワーク全体に広がるデータベースです。 データの登録は慎重に行ないましょう。変な内容を登録すると、 あなたも他の人達も迷惑します。 真面目にちゃんと運用すれば、 DNS は恩恵をもたらしてくれるはずです。 DNS の使い方、管理の仕方、デバッグのやりかたを学び、 良い管理者になってください。 設定ミスでネットを落としたりすることがないようにしましょうね。 <!--O <p><bf/Tip:/ Make backup copies of all the files I instruct you to change if you already have them, so that if after going through this nothing works you can get it back to your old, working state. --> <p> <bf>注意:</bf> 私が変更するように指示したファイルがすでに存在していたら、 これらのバックアップを取っておきましょう。 作業の結果がうまくいかなかった場合に、 元の動いている状態に戻すことができるようにするためです。 <!--O <sect1>Other nameserver implementations. --> <sect1>他のネームサーバの実装 <!--O <p>This section was written by Joost van Baal. --> <p>この節は Joost van Baal が書きました。 <!--O <p>Various packages exist for getting a DNS server on your box. There is the BIND package (<url url="http://www.isc.org/products/BIND/">); the implementation this HOWTO is about. It's the most popular nameserver around and it's used on the vast majority of name serving machines on the Internet, around and being deployed since the 1980's. It's available under a BSD license. Since it's the most popular package, loads of documentation and knowledge about BIND is around. However, there have been security problems with BIND. --> <p>あなたのマシンを DNS サーバにするパッケージは何種類か存在しています。 まず BIND パッケージ (<url url="http://www.isc.org/products/BIND/">)、 この HOWTO が対象としている実装です。 もっとも広く使われているネームサーバで、 1980 年代から登場、普及してきました。 現在インターネットでネームサービスを提供しているマシンの大部分が BIND を使っています。 BIND は BSD ライセンスで配布されています。 もっとも広く使われているパッケージですから、 BIND に関する文書や知識もたくさん存在します。 しかし、BIND にはセキュリティ上の問題が生じたこともありました。 <!--O <p>Then there is djbdns (<url url="http://djbdns.org/">), a relatively new DNS package written by Daniel J. Bernstein, who also wrote qmail. It's a very modular suite: various small programs take care of the different jobs a nameserver is supposed to handle. It's designed with security in mind. It uses a simpler zone-file format, and is generally easier to configure. However, since it's less well known, your local guru might not be able to help you with this. Unfortunately, this software is not Open Source. The author's advertisement is on <url url="http://cr.yp.to/djbdns/ad.html">. --> <p>それから djbdns (<url url="http://djbdns.org/">) というのもあります。 比較的新しい DNS パッケージで、Daniel J. Bernstein (qmail の作者でもあります) が書きました。 djbdns は非常にモジュール化されています。 いくつもの小さなプログラムが、 ネームサーバの扱うべき仕事のそれぞれの部分を扱うのです。 djbdns はセキュリティを念頭において設計されています。 ゾーンファイルのフォーマットはより単純で、 また大抵の場合は設定も簡単です。 しかしあまり有名ではないために、あなたの近くのグルによる助けは、 このプログラムに関しては得られないかもしれません。 残念ながら、このソフトウェアはオープンソースではありません。 作者による宣伝は <url url="http://cr.yp.to/djbdns/ad.html"> にあります。 <!--O <p>Whether DJBs software is really an improvement over the older alternatives is a subject of much debate. A discussion (or is it a flame-war?) of BIND vs djbdns, joined by ISC people, is on <url url="http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html"> --> <p>DJB のソフトウェアが、古い他のソフトウェアに比べ、 本当に進歩したものであるのかどうかは、活発な議論の対象になっています。 BIND vs djbdns に関する討論 (あるいはフレームウォー?) は、 <url url="http://www.isc.org/ml-archives/bind-users/2000/08/msg01075.html"> にあります。 <!--O <sect>A resolving, caching name server.<label id="caching"> --> <sect>名前解決とキャッシュを行うネームサーバ<label id="caching"> <!--O <p><bf/A first stab at DNS config, very useful for dialup, cable-modem, ADSL and similar users./ --> <p><bf>DNS 設定の最初の一歩。 ダイアルアップ・ケーブルモデム・ADSL などのユーザにはとても便利です。 </bf> <!--O <p>On Red Hat and Red Hat related distributions you can achieve the same practical result as this HOWTO's first section by installing the packages <tt/bind/, <tt/bind-utils/ and <tt/caching-nameserver/. If you use Debian simply install <tt/bind/ (or <tt/bind9/, as of this writing, BIND 9 is not supported by Debian Stable (potato)) and <tt/bind-doc/. Of course just installing those packages won't teach you as much as reading this HOWTO. So install the packages, and then read along verifying the files they installed. --> Red Hat や、Red Hat に関連したディストリビューションでは、 <tt/bind/ パッケージ・<tt/bind-utils/ パッケージ・ <tt/caching-nameserver/ パッケージをインストールするだけで、 この HOWTO の最初のセクションの結果と同じものが得られます。 Debian を使っているなら <tt/bind/ と <tt/bind-doc/ をインストールするだけです (あるいは前者に対しては <tt/bind9/。 この文書の執筆時では、Debian の安定版 (potato) は BIND 9 をサポートしていません)。 もちろんこれらのパッケージをインストールするだけでは、 この HOWTO を読むことによって得られる知識は手に入りません。 ですので、まずパッケージをインストールし、 そこでインストールされたファイルを調べながら、 読み進んでいくのが良いでしょう。 <!--O <p>A caching only name server will find the answer to name queries and remember the answer the next time you need it. This will shorten the waiting time the next time significantly, especially if you're on a slow connection. --> <p>キャッシュ専用のネームサーバとは、名前引きの結果を記憶しておき、 次回の問い合わせの時にその記憶を使って答えるものです。 次回からの問い合わせに対する応答は (特に遅い回線を使っている場合には) とても速くなります。 <!--O <p>First you need a file called <tt>/etc/named.conf</tt> (Debian: <tt>/etc/bind/named.conf</tt>). This is read when named starts. For now it should simply contain: --> <p>まず最初に <tt>/etc/named.conf</tt> というファイルが必要です (Debian では <tt>/etc/bind/named.conf</tt>)。 named は起動するとまずこのファイルを読み込みます。 現在のところは、次のような簡単なものでよいでしょう。 <code> // Config file for caching only name server // // The version of the HOWTO you read may contain leading spaces // (spaces in front of the characters on these lines ) in this and // other files. You must remove them for things to work. // // Note that the filenames and directory names may differ, the // ultimate contents of should be quite similar though. options { directory "/var/named"; // Uncommenting this might help if you have to go through a // firewall and things are not working out. But you probably // need to talk to your firewall admin. // query-source port 53; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; </code> <!--O <p>The Linux distribution packages may use different file names for each kind of file mentioned here; they will still contain about the same things. --> <p>Linux ディストリビューションのパッケージでは、 ここで紹介するそれぞれのファイルに、別の名前をつけているかもしれません。 でも内容は同じはずです。 <!--O <p>The `<tt/directory/' line tells named where to look for files. All files named subsequently will be relative to this. Thus <tt>pz</tt> is a directory under <tt>/var/named</tt>, i.e., <tt>/var/named/pz</tt>. <tt>/var/named</tt> is the right directory according to the <em/Linux File system Standard/. --> <p><tt/directory/ の行は、 named が参照するファイルの置き場所を 指定するものです。これ以降のすべてのファイル名はここからの相対パスとなります。 すなわちディレクトリ <tt/pz/ は <tt>/var/named</tt> 以下にあり、 フルパスで表記すれば <tt>/var/named/pz</tt> ということになります。 <tt>/var/named</tt> は <em>Linux Filesystem Standard</em> に準拠した正しいディレクトリ名です。 <!--O <p>The file named <tt>/var/named/root.hints</tt> is named in this. <tt>/var/named/root.hints</tt> should contain this: --> <p><tt>/var/named/root.hints</tt> というファイルの名前は ここで付けられています。 このファイルの中身は次のようになります。 <code> ; ; There might be opening comments here if you already have this file. ; If not don't worry. ; ; About any leading spaces in front of the lines here: remove them! ; Lines should start in a ;, . or character, not blanks. ; ; すでにこのファイルがあった場合は、ここに開始コメントがあるかも ; しれません。なくても問題はありません。 ; ; 行頭に空白文字があった場合は、削除してください! 各行は ;、. ; または文字で始まります。空白で始まることはありません。 ; . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107 C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12 D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90 E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4 H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53 I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17 J.ROOT-SERVERS.NET. 6D IN A 198.41.0.10 K.ROOT-SERVERS.NET. 6D IN A 193.0.14.129 L.ROOT-SERVERS.NET. 6D IN A 198.32.64.12 M.ROOT-SERVERS.NET. 6D IN A 202.12.27.33 </code> <!--O <p>The file describes the root name servers in the world. The servers change over time and must be maintained now and then. See the <ref id="maint" name="maintenance section"> for how to keep it up to date. --> <p>このファイルには世界中のルートネームサーバを記述します。 これは時間とともに変化していくので、 ときどき更新する必要があります。更新の方法は <ref id="maint" name="メンテナンス"> の章を見てください。 <!--O <p>The next section in <tt/named.conf/ is the last <tt/zone/. I will explain its use in a later chapter; for now just make this a file named <tt/127.0.0/ in the subdirectory <tt/pz/: (<em/Again, please remove leading spaces if you cut and paste this/) --> <p><tt/named.conf/ の末尾の方には <tt/zone/ セクションがあります。 <!--nakano key/control セクションのほうが先にある :-)--> この利用法については後の章で述べるつもりですので、今のところは 以下のような内容のファイルを <tt/pz/ サブディレクトリに <tt/127.0.0/ という名前で作っておいてください。 (<em/ここでもカットアンドペーストするときには 先頭のスペースを取り除くようにしてください/) <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. </code> <!--O <p>The sections called <tt/key/ and <tt/controls/ together specify that your named can be remotely controlled by a program called <tt/rndc/ if it connects from the local host, and identifis itself with the encoded secret key. This key is like a password. For rndc to work you need <tt>/etc/rndc.conf</tt> to match this: --> <p><tt/key/ や <tt/control/ といった名前がついたセクションは、 この二つでもって、 この named がリモートから制御できることを指定しています (<tt/rndc/ というプログラムが用いられます)。 ここではローカルホストからの接続でなければならず、 エンコードされた秘密鍵での認証が必要になります。 この鍵はパスワードのようなものです。 rndc が機能するには、この鍵にマッチする <tt>/etc/rndc.conf</tt> が必要になります。 <code> key rndc_key { algorithm "hmac-md5"; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; options { default-server localhost; default-key rndc_key; }; </code> <!--O <p>As you see the secret is identical. If you want to use <tt/rndc/ from other machines their times need to be within 5 minutes of eachother. I recommend using the ntp (<tt/xntpd/ and <tt/ntpdate/) software to do this. --> <p>見てわかるように、secret の指定は同一です。 <tt/rndc/ を他のマシンから使う場合は、 それらの時計は 5 分以内に会っていなければなりません。 この目的には ntp (<tt/xntpd/ や <tt/ntpdate/) ソフトウェアを用いることをおすすめします。 <!--O <p>Next, you need a <tt>/etc/resolv.conf</tt> looking something like this: (<em/Again: Remove spaces!/) --> <p>次に、以下のような内容の <tt>/etc/resolv.conf</tt>が必要です。 (<em/同じく空白を取り除くこと!/) <code> search subdomain.your-domain.edu your-domain.edu nameserver 127.0.0.1 </code> <!--O <p>The `<tt/search/' line specifies what domains should be searched for any host names you want to connect to. The `<tt/nameserver/' line specifies the address of your nameserver, in this case your own machine since that is where your named runs (127.0.0.1 is right, no matter if your machine has another address too). If you want to list several name servers put in one `<tt/nameserver/' line for each. (Note: Named never reads this file, the resolver that uses named does. Note 2: In some resolv.conf files you find a line saying "domain". That's fine, but don't use both "search" and "domain", only one of them will work). --> <p>`<tt>search</tt>' で始まっている行は、 問い合わせされたホストを探すドメインの指定です。`<tt>nameserver</tt>' で始まる行は、ネームサーバのアドレス指定です。 今は自分のマシンでネームサーバを動かすので、ローカルホストを指定します。 (注: named はこのファイルを参照しません。参照するのはレゾルバです。 注2: resolv.conf ファイルiには "domain" と書かれた行があるかもしれません。 あっても問題ありませんが、 "search" と "domain" の両方を同時には用いないようにしてください。 どちらかしか効力を持ちません。) <!--O <p>To illustrate what this file does: If a client tries to look up <tt>foo</tt>, then <tt>foo.subdomain.your-domain.edu</tt> is tried first, then <tt>foo.your-domain.edu</tt>, and finally <tt>foo</tt>. You may not want to put in too many domains in the search line, as it takes time to search them all. --> <p>このファイルの意味を説明しましょう。クライアントが <tt>foo</tt> の名前引きを行うと、まず最初に <tt>foo.subdomain.your-domain.edu</tt> を調べ、次に <tt>foo.your-domain.edu</tt> を試し、最後に <tt>foo</tt> を調べます。search 行にあまり多くのドメインを書くと、 すべてを調べるのに時間がかかるようになるので、 ほどほどにしておくのが良いでしょう。 <!--O <p>The example assumes you belong in the domain <tt>subdomain.your-domain.edu</tt>; your machine, then, is probably called <tt>your-machine.subdomain.your-domain.edu</tt>. The search line should not contain your TLD (Top Level Domain, `<tt/edu/' in this case). If you frequently need to connect to hosts in another domain you can add that domain to the search line like this: (<em/Remember to remove the leading spaces, if any/) --> <p>この例ではあなたのマシンが <tt>subdomain.your-domain.edu</tt> にあるとしていますので、あなたのマシンの名前はおそらく <tt>your-machine.subdomain.your-domain.edu</tt> となっているでしょう。 なお search 行にはあなたの TLD (Top Level Domain, この場合は `<tt/edu/') を含めるべきではありません。頻繁に接続するような特定のドメイン があれば、以下のように search 行にそのドメインを加えてもいいでしょう。 (<em/先頭にスペースがあったら取り去るのを忘れないように。/) <code> search subdomain.your-domain.edu your-domain.edu other-domain.com </code> <!--O and so on. Obviously you need to put real domain names in instead. Please note the lack of periods at the end of the domain names. This is important; please note the lack of periods at the end of the domain names. --> もちろん実際には本当のドメイン名を書く必要があります。 ドメイン名の最後にはピリオドを書かないことに注意してください。 これは重要なポイントです。 ドメイン名の最後にはピリオドを書かないことに注意してください。 <!--O <sect1>Starting named<label id="starting"> --> <sect1>named を起動する<label id="starting"> <!--O <p>After all this it's time to start named. If you're using a dialup connection connect first. Now run named, either by running the boot script: <tt>/etc/init.d/named start</tt> or named directly: <tt>/usr/sbin/named</tt>. If you have tried previous versions of BIND you're probably used to <tt/ndc/. I BIND 9 it has been replaced with <tt/rndc/, which can controll your named remotely, but it can't start named anymore. If you view your syslog message file (usually called <tt>/var/log/messages</tt>, Debian calls it <tt>/var/log/daemon</tt>, another directory to look is the other files <tt>/var/log</tt>) while starting named (do <tt>tail -f /var/log/messages</tt>) you should see something like: --> <!--nakano s/I/In/ to look is ... 以下おかしい? --> <p>これらの準備がすんだら named を立ち上げましょう。 ダイアルアップ接続をしている人は、まず先に接続してください。 では named を起動します。 ブートスクリプトから起動する場合は <tt>/etc/init.d/named start</tt>、 named を直接起動する場合は <tt>/usr/sbin/named</tt> とします。 以前の版の BIND で似たようなことを行ったときは、 おそらく <tt/ndc/ を使ったことと思います。 BIND 9 では、これは <tt/rndc/ に変わりました。 <tt/rndc/ は named をリモートから制御できますが、 named を起動することはできません。 named を動かしている最中に syslog のメッセージファイル (普通は <tt>/var/adm/messages</tt> ですが、 Debian では <tt>/var/log/daemin</tt> ですし、 ディレクトリが <tt>/var/log</tt> だったり、 ファイル名が別だったりするかもしれません) を見ると (<tt>tail -f /var/adm/messages</tt> とします)、 以下のような出力が表示されるはずです: <!--O <p>(the lines ending in \ continues on the next line) --> <p>(行末が \ の行は次の行に続きます) <tscreen><verb> Dec 23 02:21:12 lookfar named[11031]: starting BIND 9.1.3 Dec 23 02:21:12 lookfar named[11031]: using 1 CPU Dec 23 02:21:12 lookfar named[11034]: loading configuration from \ '/etc/named.conf' Dec 23 02:21:12 lookfar named[11034]: the default for the \ 'auth-nxdomain' option is now 'no' Dec 23 02:21:12 lookfar named[11034]: no IPv6 interfaces found Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface lo, \ 127.0.0.1#53 Dec 23 02:21:12 lookfar named[11034]: listening on IPv4 interface eth0, \ 10.0.0.129#53 Dec 23 02:21:12 lookfar named[11034]: command channel listening on \ 127.0.0.1#953 Dec 23 02:21:13 lookfar named[11034]: running </verb></tscreen> <!--O <p>If there are any messages about errors then there is a mistake. Named will name the file it is reading. Go back and check the file. Start named over when it is fixed. --> <p>エラーメッセージがあった場合は、何か間違えているのでしょう。 named は読んでいるそのファイルを名指ししてくれるはずです。 戻ってファイルをチェックしてください。 修正が終わったら再度 named を起動してください。 <!--O <p>Now you can test your setup. Traditionally a program called <tt/nslookup/ is used for this. These days <tt/dig/ is recommended: --> <p>さて、ここまで行ってきた設定を試してみましょう。 これまでは <tt/nslookup/ がテストのためのプログラムでした。 最近では <tt/dig/ が推奨されています。 <tscreen><verb> $ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26669 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 02:26:17 2001 ;; MSG SIZE rcvd: 91 </verb></tscreen> <!--O <p>If that's what you get it's working. We hope. Anything very different, go back and check everything. Each time you change a file you need to run <tt/rndc reload/. --> と表示されれば、うまく動いているはずです。こうなるといいですね。 非常に異なった表示が出たら、やり直し、全部再チェックです。 <tt/named.conf/ を変更したら、 そのたびに <tt/rndc reload/ コマンドを実行する必要があります。 <!--O <p>Now you can enter a query. Try looking up some machine close to you. <tt/pat.uio.no/ is close to me, at the University of Oslo: --> <p>では問い合わせをしてみましょう。 あなたの近くにあるマシンの名前を引いてみましょう。 私の近く (Oslo 大学) には pat.uio.noというマシンがあります。 <tscreen><verb> $ dig pat.uio.no ; <<>> DiG 9.1.3 <<>> pat.uio.no ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15574 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;pat.uio.no. IN A ;; ANSWER SECTION: pat.uio.no. 86400 IN A 129.240.130.16 ;; AUTHORITY SECTION: uio.no. 86400 IN NS nissen.uio.no. uio.no. 86400 IN NS nn.uninett.no. uio.no. 86400 IN NS ifi.uio.no. ;; Query time: 651 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 02:28:35 2001 ;; MSG SIZE rcvd: 108 </verb></tscreen> <!--O <p>This time <tt/dig/ asked your named to look for the machine <tt/pat.uio.no/. It then contacted one of the name server machines named in your <tt/root.hints/ file, and asked its way from there. It might take tiny while before you get the result as it may need to search all the domains you named in <tt>/etc/resolv.conf</tt>. --> <p> 今度は、<tt/dig/ はあなたのマシンで動いている named に <tt>pat.uio.no</tt> を探すよう依頼します。すると named は <tt>root.hints</tt> ファイルに書かれているネームサーバの一つに 接続して、問い合わせをします。 <tt>/etc/resolv.conf</tt> に書かれているドメインすべてについて 調べる必要があるかもしれないので、結果が得られるまでに 少々時間がかかることがあります。 <!-- Hum, this version of dig does not seem to show the aa flag. Odd. And nslookup always says "non-authoritative". A change in behaviour here, need to check if that is permanent or not. Please note the "aa" on the "flags:" line. It means that the answer is authoritative, that it is fresh from an authoritative server. I'll explain "authoritative" later. --> <!-- "flags" 行の "aa" に注目してください。 これは結果が「信頼できる (authoritative)」ことを示しています。 つまり、信頼できるサーバからの最新の結果である、と言うことです。 なにが「信頼できる」のかはのちほど説明します。 --> <!--O <p>If you ask the same again you get this: --> <p>ここでもう一度同じ問い合わせを行うと、 次のような結果になるでしょう。 <tscreen><verb> $ dig pat.uio.no ; <<>> DiG 8.2 <<>> pat.uio.no ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; pat.uio.no, type = A, class = IN ;; ANSWER SECTION: pat.uio.no. 23h59m58s IN A 129.240.130.16 ;; AUTHORITY SECTION: UIO.NO. 23h59m58s IN NS nissen.UIO.NO. UIO.NO. 23h59m58s IN NS ifi.UIO.NO. UIO.NO. 23h59m58s IN NS nn.uninett.NO. ;; ADDITIONAL SECTION: nissen.UIO.NO. 23h59m58s IN A 129.240.2.3 ifi.UIO.NO. 1d23h59m58s IN A 129.240.64.2 nn.uninett.NO. 1d23h59m58s IN A 158.38.0.181 ;; Total query time: 4 msec ;; FROM: lookfar to SERVER: default -- 127.0.0.1 ;; WHEN: Sat Dec 16 00:23:09 2000 ;; MSG SIZE sent: 28 rcvd: 162 </verb></tscreen> <!-- <p>Note the lack of a "aa" flag in this answer. That means that named did not go out on the network to ask this time, as the information is in the cache now. But the cached information <em/might/ be out of date (stale). So you are informed of this (very slight) possibility by the "aa" not being there. But, now you know that your cache is working. --> <!-- <p>今度は結果に "aa" フラグがないことにご注目ください。 これが意味するのは、今回この情報はすでにキャッシュに入っていたので、 named はネットワーク経由で調べたのではない、ということです。 でもキャッシュの情報はもしかすると古いことがある<em/かも/しれません。 ですからここでは "aa" を置かないことで、 この (ほんのわずかな) 可能性を知らされたわけです。 でも逆に、キャッシュが正しく動作していることがわかったことにもなります。 --> <!--O <p>As you can plainly see this time it was much faster, 4ms versus more than half a second earlier. The answer was cached. With cached answers there is the possibility that the answer is out of date, but the origin servers can control the time cached answers should be considered valid, so there is a high probability that the answer you get <em/is/ valid. --> <p>こんどはずっと速かったことがはっきりわかるでしょう。 前は 0.5 秒以上かかっていましたが、今回は 4ms ですみました。 サーバからの回答がキャッシュされたのです。 キャッシュされた回答は、古くなって現状と異なってしまう可能性もありますが、 キャッシュされた回答を正しいと見なせる期間は、 回答を返したサーバの側で制御できるので、 得られた回答が正しいものである可能性は高いでしょう。 <!--O <sect1>Resolvers --> <sect1>レゾルバ <!--O <p>All OSes implementing the standard C API has the calls gethostbyname and gethostbyaddr. These can get information from several different sources. Which sources it gets it from is configured in <tt>/etc/nsswitch.conf</tt> on Linux (and some other Unixes). This is a long file specifying from which file or database to get different kinds of data types. It usually contains helpful comments at the top, which you should consider reading. After that find the line starting with `<tt/hosts:/'; it should read: --> <p>標準的な C API を実装しているすべての OS には、 gethostbyname と gethostbyaddr というシステムコールが存在します。 これらは何種類かの異なる情報源から情報を取得できます。 どの情報源から取得するかは、Linux なら <tt>/etc/nsswitch.conf</tt> というファイルで設定できます (これを用いている Unix は他にもあります)。 これは長いファイルで、どのファイルから、あるいはどのデータベースから、 いろいろな種類のデータを取得するかを指定します。 通常は先頭にコメント形式の解説がありますので、読んでおきましょう。 読み終わったら `<tt/hosts:/' ではじまる行を探してください。 以下のようになっているはずです。 <code> hosts: files dns </code> <!--O (<em/You remembered about the leading spaces, right? I won't mention them again./) --> (<em/先頭のスペースのことは覚えていますね？ これ以上はもう言及しません。/) <!--O <p>If there is no line starting with `<tt/hosts:/' then put in the one above. It says that programs should first look in the <tt>/etc/hosts</tt> file, then check DNS according to <tt/resolv.conf/. --> <p>`<tt/hosts:/' ではじまる行が無ければ、 上記のような内容を書いておいてください。 これは、プログラムはまず <tt>/etc/hosts</tt> ファイルを見に行き、 次に DNS を <tt/resolv.conf/ にしたがってチェックせよ、 と言っています。 <!--O <sect1>Congratulations --> <sect1>おめでとう <!--O <p>Now you know how to set up a caching named. Take a beer, milk, or whatever you prefer to celebrate it. --> <p> さて、今やあなたはキャッシュ動作をする named の設定方法を知ったわけです。 ビールでもミルクでも、お好きなもので乾杯しましょう。 <!--O <sect>Forwarding --> <sect>フォワード (forwarding) <!--O <p>In large, well organized, academic or ISP (Internet Service Provider) networks you will sometimes find that the network people have set up a forwarder hierarchy of DNS servers which helps lighten the internal network load and the load on the outside servers as well. It's not easy to know if you're inside such a network or not. But by using the DNS server of your network provider as a ``forwarder'' you can make the responses to queries faster and less of a load on your network. This works by your nameserver forwarding queries to your ISP nameserver. Each time this happens you will dip into the big cache of your ISPs nameserver, thus speeding your queries up, your nameserver does not have to do all the work itself. If you use a modem this can be quite a win. For the sake of this example we assume that your network provider has two name servers they want you to use, with IP numbers <tt/10.0.0.1/ and <tt/10.1.0.1/. Then, in your <tt/named.conf/ file, inside the opening section called ``<tt/options/'', insert these lines: --> <p>学術機関や ISP (Internet Service Provider) などの、 上手に組織化された大きなネットワークでは、ネットワークのプロ達は DNS サーバに「フォワーダ (forwarder)」 と呼ばれる階層を設けていることがあるかもしれません。 こうすると、内部のネットワーク負荷や、 外部にあるサーバの負荷を下げる効果があるのです。 自分がそのようなネットワークの一部にいるのかどうかを知るのは それほど簡単ではありません。 しかしいずれにせよ、接続しているプロバイダの DNS サーバを「フォワーダ」として利用すれば、問い合わせの反応を速くでき、 ネットワークへの負荷を下げることができます。 これを用いると、あなたのネームサーバは、 問い合わせを ISP のネームサーバに行います。 問い合わせが起こるたび、 ISP のネームサーバの巨大なキャッシュからデータをすくい取ることになります。 よって問い合わせの速度は上がり、 あなたのネームサーバは自分で全部の仕事をこなさなくても良くなります。 モデムを使っている場合は、この効果はかなり大きいです。 ここで例として、お使いのネットワークプロバイダには 利用が推奨されているネームサーバが二つあるとします。 それぞれの IP 番号を <tt/10.0.0.1/ と <tt/10.1.0.1/ としましょう。 このような場合には、お手元の <tt/named.conf/ ファイルの最初のセクション、 ``<tt/options/'' という名前がついている部分に以下の行を挿入して下さい。 <code> forward first; forwarders { 10.0.0.1; 10.1.0.1; }; </code> <!--O <p>There is also a nice trick for dialup machines using forwarders, it is described in the <ref id="qanda" name="qanda"> section. --> <p>ダイアルアップマシン向けにも forwarders を使ったちょっと嬉しいトリックがあります。 <ref id="qanda" name="Q & A"> の章に書いてあります。 <!--O <p>Restart your nameserver and test it with <tt/dig/. Should still work fine. --> ネームサーバを再起動して、<tt/dig/ でテストしてください。 うまくいっていると思います。 <!--O <sect>A <em/simple/ domain.<label id="simple"> <p><bf>How to set up your own domain.</bf> --> <sect><em/単純な/ドメイン<label id="simple"> <p><bf>あなた自身のドメインの設定方法</bf> <!--O <sect1>But first some dry theory --> <sect1>でもまず最初に退屈な理論<label id="dry_theory"> <!--O <p>First of all: you read all the stuff before here right? You have to. --> <p>まず最初に: ここまでの内容はちゃんと読みましたか？ 読んでなければ読むように。 <!--O <p>Before we <em/really/ start this section I'm going to serve you some theory on and an example of how DNS works. And you're going to read it because it's good for you. If you don't want to you should at least skim it very quickly. Stop skimming when you get to what should go in your <tt/named.conf/ file. --> <p>このセクションを<em>実際に</em>始める前に、DNS の動作に関する 理論を少々と、実際の動作例を紹介しておきます。きっと役に立ちますから、 ぜひ読みましょう。 読みたくなくても、少なくとも流し読みくらいはしておいてください。 <tt>named.conf</tt> ファイルの設定に関する部分まできたら 流し読みはストップです。 <!--O <p>DNS is a hierarchical, tree structured system. The top is written `<tt/./' and pronounced `root', as is usual for tree data-structures. Under <tt/./ there are a number of Top Level Domains (TLDs); the best known ones are <tt/ORG/, <tt/COM/, <tt/EDU/ and <tt/NET/, but there are many more. Just like a tree it has a root and it branches out. If you have any computer science background you will recognize DNS as a search tree, and you will be able to find nodes, leaf nodes and edges. The dots are nodes, the edges are on the names. --> <p>DNS は階層的なツリー構造のシステムです。その頂点は `<tt/./' と記述され、 (ツリー型データ構造での慣例に従い) 「ルート (root)」と発音されます。 `.' の下にはたくさんの Top Level Domain (TLD) があります。 <tt/ORG/, <tt/COM/, <tt/EDU/, <tt/NET/ などが有名ですが、 他にもたくさんあります。 実際の木と同じように、このツリー構造は根を持ち、枝分かれします。 計算機科学の知識がある人には、 DNS は検索ツリーに見えるでしょう。 またそこには節点 (node)、端点 (leaf node)、枝 (edge) があることも見て取れるでしょう。 <!--O <p>When looking for a machine the query proceeds recursively into the hierarchy starting at the root. If you want to find the address of <tt/prep.ai.mit.edu./, your nameserver has to start asking somewhere. It starts by looking it its cache. If it knows the answer, having cached it before, it will answer right away as we saw in the last section. If it does not know it will see how closely it can match the requested name and use whatever information it has cached. In the worst case there is no match but the `.' (root) of the name, and the root servers have to be consulted. It will remove the leftmost parts one at a time, checking if it knows anything about <tt/ai.mit.edu./, then <tt/mit.edu./, then <tt/edu./, and if not that it does know about <tt/./ because that was in the hints file. It will then ask a <tt/./ server about <tt/prep.ai.mit.edu/. This <tt/./ server will not know the answer, but it will help your server on its way by giving a referral, telling it where to look instead. These referrals will eventually lead your server to a nameserver that knows the answer. I will illustrate that now. <tt/+norec/ means that dig is asking non-recursive questions so that we get to do the recursion ourselves. The other options are to reduce the amount of dig produces so this won't go on for too many pages: --> マシンの検索を行うとき、 問い合わせはルートから始まる階層に対して再帰的に行われます。 いまホスト <tt/prep.ai.mit.edu./ のアドレスを見つけたいとしましょう。 するとネームサーバはどこかに問い合わせを行う必要があります。 まずキャッシュにないかどうか探します。 もし以前の問合わせがキャッシュに残っていて、答を知っていた場合には、 直前の節で見たように、ただちに答を返します。 キャッシュに答がなかった場合は、問い合わせのあった名前に どのくらい近い答えが返せるかを調べ、 キャッシュされている情報をできるだけ使おうとします。 最悪の場合は `.' (ルート) だけがマッチすることになり、 よってルートサーバに尋ねる必要があります。 ネームサーバは名前の左側の部分を消していき、 自分が <tt/ai.mit.edu./, <tt/mit.edu./, <tt/edu./ について 知っているかチェックしていきます。これらを知らないと <tt/./ に行くわけですが、 この答は hints ファイルに書いてあるので、見つかります。 ここであなたのネームサーバは <tt/./ のサーバに <tt/prep.ai.mit.edu/ に関する問い合わせを行います。 この <tt/./ サーバは直接の答は知らないでしょうが、 あなたのサーバに参照先を提示し、次にどこに聞けばいいかを教えてくれます。 この参照先提示は同じように次々に行われ、 あなたのネームサーバは答を知っているネームサーバにまで導かれます。 これをいまからお見せしましょう。 <tt/+norec/ で dig に再帰的な問合わせをしないように命じ、 再帰を我々自身で行うことにします。 その他のオプションは、dig に生成する情報を減らすように命じるもので、 紙幅を節約します。 <!--nakano 先頭の dig コマンドが抜けている --> <tscreen><verb> $ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 980 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; AUTHORITY SECTION: . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. </verb></tscreen> <!--O <p>This is a referral. It is giving us an "Authority section" only, no "Answer section". Our own nameserver refers us to a nameserver. Pick one at random: --> <p>これは参照先の提示です。 ここには "Authority section" しかなく、"Answer section" がありません。 私たちの立てたネームサーバは、 私たちをこのネームサーバのどれかに指し向けます。 どれかひとつをランダムに選んでみましょう。 <tscreen><verb> $ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @D.ROOT-SERVERS.NET. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58260 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; AUTHORITY SECTION: mit.edu. 172800 IN NS BITSY.mit.edu. mit.edu. 172800 IN NS STRAWB.mit.edu. mit.edu. 172800 IN NS W20NS.mit.edu. ;; ADDITIONAL SECTION: BITSY.mit.edu. 172800 IN A 18.72.0.3 STRAWB.mit.edu. 172800 IN A 18.71.0.151 W20NS.mit.edu. 172800 IN A 18.70.0.160 </verb></tscreen> <!--O <p>It refers us to MIT.EDU servers at once. Again pick one at random: --> <p>MIT.EDU のサーバ群がいっぺんに提示されました。 ではまたどれかをランダムに選びましょう。 <tscreen><verb> $ dig +norec +noques +nostats +nocmd prep.ai.mit.edu. @BITSY.mit.edu. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29227 ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4 ;; ANSWER SECTION: prep.ai.mit.edu. 10562 IN A 198.186.203.77 ;; AUTHORITY SECTION: ai.mit.edu. 21600 IN NS FEDEX.ai.mit.edu. ai.mit.edu. 21600 IN NS LIFE.ai.mit.edu. ai.mit.edu. 21600 IN NS ALPHA-BITS.ai.mit.edu. ai.mit.edu. 21600 IN NS BEET-CHEX.ai.mit.edu. ;; ADDITIONAL SECTION: FEDEX.ai.mit.edu. 21600 IN A 192.148.252.43 LIFE.ai.mit.edu. 21600 IN A 128.52.32.80 ALPHA-BITS.ai.mit.edu. 21600 IN A 128.52.32.5 BEET-CHEX.ai.mit.edu. 21600 IN A 128.52.32.22 </verb></tscreen> <!--O <p>This time we got a "ANSWER SECTION", and an answer for our question. The "AUTHORITY SECTION" contains information about which servers to ask about <tt/ai.mit.edu/ the next time. So you can ask them directly the next time you wonder about <tt/ai.mit.edu/ names. Named also gathered information about <tt/mit.edu/, so of <tt/www.mit.edu/ is requested it is much closer to being able to answer the question. --> <p>今度は "ANSWER SECTION" がありました。 そして私たちの知りたかった答も見つかりました。 "AUTHORITY SECTION" には、次回 <tt/ai.mit.edu/ に尋ねる際にはどのサーバにすべきか、 という情報が含まれています。 したがって次に <tt/ai.mit.edu/ の名前について知りたいときには、 これらに直接聞けば良いわけです。 named は同時に <tt/mit.edu/ に関する情報も集めるので、 次に例えば <tt/www.mit.edu/ が問い合わされたときには、 答えにずっと近いところにいることになります。 <!--O <p>So starting at <tt/./ we found the successive name servers for each level in the domain name by referral. If you had used your own DNS server instead of using all those other servers, your named would of-course cache all the information it found while digging this out for you, and it would not have to ask again for a while. --> <p>というわけで、<tt/./ からスタートし、参照先提示を辿ることで、 ドメイン名の各レベルにおけるネームサーバを次々に見つけることができました。 自前の DNS サーバがあれば、これらの他のネームサーバを使わなくても、 あなたの named は、このように掘っていく段階で見つけた情報を すべてキャッシュし、しばらくは再び尋ねなくても良いようにしてくれます。 <!--O <p>In the tree analogue each ``<tt/./'' in the name is a branching point. And each part between the ``<tt/./''s are the names of individual branches in the tree. One climbs the tree by taking the name we want (<tt/prep.ai.mit.edu/) asking the root (<tt/./) or whatever servers father from the root toward <tt/prep.ai.mit.edu/ we have information about in the cache. Once the cache limits are reached the recursive resolver goes out asking servers, pursuing referrals (edges) further into the name. --> ツリーとのアナロジーでいうと、名前の各 ``<tt/./'' は 枝分かれのポイントに対応します。そして ``<tt/./'' に挟まれた部分はツリー中でのそれぞれの枝の名前になります。 欲しい名前 (<tt/prep.ai.it.edu/) の名前を得るには、 このツリーを昇っていくことになります。 root (<tt/./) や、root から <tt/prep.ai.mit.edu/ に至る途中のあらゆるサーバに情報を問い合わせ、 それらをキャッシュします。 キャッシュの制限に達すると、 この再帰的なレゾルバはそのサーバへの問合わせをやめ、 そこで参照提示された、名前の端のほうにある次のサーバへと進んでいきます。 <!--O <p>A much less talked about, but just as important domain is <tt/in-addr.arpa/. It too is nested like the `normal' domains. <tt/in-addr.arpa/ allows us to get the host's name when we have its address. A important thing to note here is that the IP addresses are written in reverse order in the <tt/in-addr.arpa/ domain. If you have the address of a machine: <tt/198.186.203.77/ named proceeds to find the named 77.203.168.198.in-addr.arpa/ just like it did for <tt/prep.ai.mit.edu/. Example: Finding no cache entry for any match but `.', ask a root server, <tt/m.root-servers.net/ refers you to some other root servers. <tt/b.root-servers.net/ refers you directly to <tt//bitsy.mit.edu/. You should be able to take it from there. --> <!--nakano named がへん?--> <p>いままでほとんど触れませんでしたが、 同じくらい非常に重要なドメインとして <tt/in-addr.arpa/ があります。 これは「普通の」ドメインのようにネストもします。 <tt/in-addr.arpa/ のおかげで、 アドレスがわかっている場合にホスト名を得ることができるようになります。 ここで重要なのは、 IP 番号は in-addr.arpa ドメインでは逆順に記述されることです。 あるマシンのアドレス <tt/192.186.203.77/ がわかっていた場合、 named は 先程の <tt/prep.ai.mit.edu/ の例と同じように <tt/77.203.168.198.in-addr.arpa/ を探そうとします。 <!--nakano この例のあたりもおかしい?--> いま例えば、 `.' 以外全くマッチしないような、 キャッシュにないエントリを探すとしましょう。 root サーバに訪ね、 <tt/m.root-servers.net/ は他の root サーバへの参照を返します。 <tt/b.root-servers.net/ は直接 <tt//bitsy.mit.edu/ への参照を返してくれるので、そこから情報を取得することになります。 <!--O <sect1>Our own domain --> <sect1>自分のドメインを作る <!--O <p>Now to define our own domain. We're going to make the domain <tt/linux.bogus/ and define machines in it. I use a totally bogus domain name to make sure we disturb no-one Out There. --> <p>さて、私たちのドメインを定義しましょう。ドメイン <tt>linux.bogus</tt> を作り、そこに私たちのマシンを定義しましょう。 ここでは完全に架空のドメイン名を使って、間違っても外部の人に迷惑が かからないようにしましょう。 <!--O <p>One more thing before we start: Not all characters are allowed in host names. We're restricted to the characters of the English alphabet: a-z, and numbers 0-9 and the character '-' (dash). Keep to those characters (BIND 9 will not bug you if you break this rule, BIND 8 will). Upper and lower-case characters are the same for DNS, so <tt/pat.uio.no/ is identical to <tt/Pat.UiO.No/. --> <p>始める前にもう一点。ホスト名に使える文字には制限があります。 英語のアルファベット a-z、数字 0-9、および '-' (ダッシュ) 文字 だけが使えます。守るようにしてください (この規則を破っても BIND 9 では大丈夫ですが、BIND 8 はダメです)。 大文字小文字は DNS では区別されません。 したがって <tt/pat.uio.no/ と <tt/Pat.UiO.No/ とは まったく同じように解釈されます。 <!--O <p>We've already started this part with this line in <tt/named.conf/: --> <p>実はこの章で最初に行うべき部分はすでに記述済みです。 <tt/named.conf/ には以下のような行がありますよね。 <code> zone "0.0.127.in-addr.arpa" { type master; file "pz/127.0.0"; }; </code> <!--O <p>Please note the lack of `<tt/./' at the end of the domain names in this file. This says that now we will define the zone <tt/0.0.127.in-addr.arpa/, that we're the master server for it and that it is stored in a file called <tt>pz/127.0.0</tt>. We've already set up this file, it reads: --> このファイルではドメイン名の最後に `<tt/./' を付けていない点に注意してください。 上記の内容から、これから私たちはゾーン <tt/0.0.127.in-addr.arpa/ を定義すること、そしてこの named が そのゾーンのマスターサーバになること、またその内容がファイル <tt>pz/127.0.0</tt> に保存されることなどがわかります。 このファイルはすでに設定済みで、以下のような内容のはずです。 <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 1 ; Serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR localhost. </code> <!--O <p>Please note the `<tt/./' at the end of all the full domain names in this file, in contrast to the <tt/named.conf/ file above. Some people like to start each zone file with a <tt/$ORIGIN/ directive, but this is superfluous. The origin (where in the DNS hierarchy it belongs) of a zone file is specified in the zone section of the <tt/named.conf/ file; in this case it's <tt/0.0.127.in-addr.arpa/. --> <p>先程の <tt/named.conf/ の場合とは対照的に、 こちらのファイルではすべてのドメイン名の最後に `<tt/./' があることに注意してください。 ゾーンファイルの先頭に <tt/$ORIGIN/ 命令を置くことを好む人たちもいるようですが、これは不要です。 ゾーンファイルの origin (このゾーンが 属する DNS の階層) は <tt/named.conf/ のゾーンセクションで指定されます。 この場合は <tt/0.0.127.in-addr.arpa/ です。 <!--O <p>This `zone file' contains 3 `resource records' (RRs): A SOA RR. A NS RR and a PTR RR. SOA is short for Start Of Authority. The `@' is a special notation meaning the origin, and since the `domain' column for this file says 0.0.127.in-addr.arpa the first line really means --> この「ゾーンファイル」には三つの 「リソースレコード (resource record: RR)」が含まれています。 SOA RR, NS RR, PTR RR です。 SOA は Start Of Authority の省略です。`@' は特別な記号で、 origin を意味します。 このファイルの `domain' カラムは 0.0.127.in-addr.arpa ですから、 最初の行の実際の意味は以下と同じになります。 <tscreen><verb> 0.0.127.in-addr.arpa. IN SOA ... </verb></tscreen> <!--O <p>NS is the Name Server RR. There is no '@' at the start of this line; it is implicit since the previous line started with a '@'. Saves some typing that. So the NS line could also be written --> <p>NS は Name Server RR の略です。 この行の先頭には `@' がありません。 これは暗黙のうちにすでに指定されたことになっています。 直前の行が `@' ではじまっていたからです。多少タイプの量が節約できますね。 したがって NS の行は以下のようにも記述できることになります。 <tscreen><verb> 0.0.127.in-addr.arpa. IN NS ns.linux.bogus </verb></tscreen> <!--O <p>It tells DNS what machine is the name server of the domain <tt/0.0.127.in-addr.arpa/, it is <tt/ns.linux.bogus/. 'ns' is a customary name for name-servers, but as with web servers who are customarily named <tt/www./<em/something/. The name may be anything. --> <p>この行は DNS に、どのマシンがこのドメイン <tt/0.0.127.in-addr.arpa/ のネームサーバであるかを教えます。 <tt/ns.linux.bogus/ というわけですね。 `ns' というのはネームサーバに良く用いられる名前ですが、 これは web サーバに <tt/www./<em/something/ という名前が付けられるのと 似たようなものです。実際にはどんな名前を用いてもかまいません。 <!--O <p>And finally the PTR (Domain Name Pointer) record says that the host at address 1 in the subnet <tt/0.0.127.in-addr.arpa/, i.e., 127.0.0.1 is named <tt/localhost/. --> <p>最後に PTR (Domain Name Pointer) レコードが、 サブネット <tt/0.0.127.in-addr.arpa/ のアドレス 1 のホスト、 すなわち 127.0.0.1 が <tt/localhost/ という名前であることを示しています。 <!--O <p>The SOA record is the preamble to <em/all/ zone files, and there should be exactly one in each zone file, at the top (but after the <tt/$TTL/ directive). It describes the zone, where it comes from (a machine called <tt/ns.linux.bogus/), who is responsible for its contents (<tt/hostmaster@linux.bogus/; you should insert your e-mail address here), what version of the zone file this is (serial: 1), and other things having to do with caching and secondary DNS servers. For the rest of the fields (refresh, retry, expire and minimum) use the numbers used in this HOWTO and you should be safe. Before the SOA comes a mandatory line, the <tt/$TTL 3D/ line. Put it in all your zone files. --> <p>SOA レコードはどんなゾーンファイルでも先頭に置かれます。 また各ゾーンファイルにつき一つ、先頭に (ただし <tt/$TTL/ 指定のあとに) 書きます。 このレコードはゾーンの説明です。 どこから得られるのか (<tt/ns.linux.bogus/というマシン)、 内容に関する責任者は誰か (<tt/hostmaster@linux.bogus/: ここにはあなたの電子メールアドレスを入れましょう)、 ゾーンファイルのバージョンはいくつか (シリアル番号: 1)、 その他キャッシュやセカンダリ DNS サーバなどに関連した内容などを書きます。 残りのフィールド (refresh, retry, expire, minimum) については、 この HOWTO の値をそのまま使えば特に問題ないでしょう。 SOA の前には必須の行、<tt/$TTL 3D/ と書かれた行があります。 これはすべてのゾーンファイルに書いてください。 <!--O <p>Now restart your named (<tt/rndc stop; named/) and use <tt/dig/ to examine your handy work. <tt/-x/ asks for the inverse query: --> <p>では、ここで named を再起動 (<tt/rndc stop; named/) して、 <tt/dig/ コマンドで今までの設定の確認を行いましょう。 <tt/-x/ を使うと逆引きの問合わせを行います。 <tscreen><verb> $ dig -x 127.0.0.1 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30944 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 259200 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:02:39 2001 ;; MSG SIZE rcvd: 91 </verb></tscreen> <!--O <p>So it manages to get <tt/localhost/ from 127.0.0.1, good. Now for our main task, the <tt/linux.bogus/ domain, insert a new 'zone' section in <tt/named.conf/: --> なんとか 127.0.0.1 から <tt/localhost/ が得られました。いい感じですね。 ではメインのお仕事である <tt/linux.bogus/ ドメインのために、 <tt/named.conf/ に新しい `zone' セクションを書きましょう。 <code> zone "linux.bogus" { type master; notify no; file "pz/linux.bogus"; }; </code> <!--O <p>Note again the lack of ending `<tt/./' on the domain name in the <tt/named.conf/ file. --> <p>ここでも <tt/named.conf/ ファイルに記述するドメイン名の最後には `<tt/./' が付いていないことに注目。 <!--O <p>In the <tt/linux.bogus/ zone file we'll put some totally bogus data: --> <p><tt/linux.bogus/ ゾーンファイルには、 まったく架空のデータを置くことにしましょう。 <code> ; ; Zone file for linux.bogus ; ; The full zone file ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds ; NS ns ; Inet Address of name server MX 10 mail.linux.bogus ; Primary Mail Exchanger MX 20 mail.friend.bogus. ; Secondary Mail Exchanger ; localhost A 127.0.0.1 ns A 192.168.196.2 mail A 192.168.196.4 </code> <!--O <p>Two things must be noted about the SOA record. <tt/ns.linux.bogus/ <em/must/ be a actual machine with a A record. It is not legal to have a CNAME record for the machine mentioned in the SOA record. Its name need not be `ns', it could be any legal host name. Next, <tt/hostmaster.linux.bogus/ should be read as hostmaster@linux.bogus. This should be a mail alias, or a mailbox, where the person(s) maintaining DNS should read mail frequently. Any mail regarding the domain will be sent to the address listed here. The name need not be `hostmaster', it can be your normal e-mail address, but the e-mail address `hostmaster' is often expected to work as well. --> <p>SOA レコードについては二つの点に注意する必要があります。 <tt/ns.linux.bogus/ は A レコードを持った<em/実際の/マシンでなければなりません。 CNAME レコードは、 SOA レコードのサーバマシンの部分には記述できません。 名前は `ns' でなくても、正しいホスト名であればかまいません。 次に <tt/hostmaster.linux.bogus/ は hostmaster@linux.bogus と読み替えてください。 これはメールエイリアスかメールボックスで、 この DNS をメンテナンスしている人が 頻繁にチェックしているところでなければなりません。 このドメインに関するメールは、 ここで記述されたアドレスに送ることになっています。 名前は `hostmaster' でなくあなたの e-mail アドレスでもかまいません。 でも `hostmaster' でももちろんちゃんと動くはずです。 <!--O <p>There is one new RR type in this file, the MX, or Mail eXchanger RR. It tells mail systems where to send mail that is addressed to <tt/someone@linux.bogus/, namely to <tt/mail.linux.bogus/ or <tt/mail.friend.bogus/. The number before each machine name is that MX RR's priority. The RR with the lowest number (10) is the one mail should be sent to if possible. If that fails the mail can be sent to one with a higher number, a secondary mail handler, i.e., <tt/mail.friend.bogus/ which has priority 20 here. --> このファイルには新しいタイプの RR があります。 MX (Mail eXchanger) RR です。これはメールシステムに対して <tt/someone@linux.bogus/ 宛メールの送り先を伝えるもので、 <tt/mail.linux.bogus/ または <tt/mail.friend.bogus/ がこれになります。 マシンの名前の前に書かれた数値は MX RR の優先度を示します。 最小の数値 (10) を持つホストに対して優先的にメールが送られます。 この配送に失敗すると、メールはより大きな数値を持つホストに配送されます。 すなわちここでは優先度 20 を持つ <tt/mail.friend.bogus/ です。 <!--O <p>Reload named by running <tt/rndc reload/. Examine the results with <tt/dig/: --> <p><tt/rndc reload/ を実行して、named に設定ファイルを再び読ませます。 ここまでの設定を <tt/dig/ で確認しましょう。 <tscreen><verb> $ dig any linux.bogus ; <<>> DiG 9.1.3 <<>> any linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55239 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;linux.bogus. IN ANY ;; ANSWER SECTION: linux.bogus. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:06:45 2001 ;; MSG SIZE rcvd: 184 </verb></tscreen> <!--O <p>Upon careful examination you will discover a bug. The line --> <p>よく見ると、バグがあることがわかると思います。 <tscreen><verb> linux.bogus. 259200 IN MX 10 mail.linux.bogus.linux.bogus. </verb></tscreen> <!--O <p>is all wrong. It should be --> <p>というのは全くおかしいですね。これは、 <tscreen><verb> linux.bogus. 259200 IN MX 10 mail.linux.bogus. </verb></tscreen> でなければなりません。 <!--O <p>I deliberately made a mistake so you could learn from it :-) Looking in the zone file we find this line: --> <p>読者の学習効果を慮って :-)、ここで私はわざと間違えました。 ゾーンファイルを見ると、以下の行があるはずです。 <tscreen><verb> MX 10 mail.linux.bogus ; Primary Mail Exchanger </verb></tscreen> <!--O <p>It is missing a period. Or has a 'linux.bogus' too many. If a machine name does not end in a period in a zone file the origin is added to its end causing the double <tt/linux.bogus.linux.bogus/. So either --> ここにはピリオドがないですね。 あるいは余計に 'linux.bogus' を書いてしまっている、とも言えます。 ゾーンファイルに書かれたホスト名の最後にピリオドがない場合には、 origin が最後に加えられます。つまり <tt/linux.bogus.linux.bogus/ と二重になってしまうのです。 ですから、 <code> MX 10 mail.linux.bogus. ; Primary Mail Exchanger </code> <!--O or --> または <code> MX 10 mail ; Primary Mail Exchanger </code> <!--O is correct. I prefer the latter form, it's less to type. There are some BIND experts that disagree, and some that agree with this. In a zone file the domain should either be written out and ended with a `<tt/./' or it should not be included at all, in which case it defaults to the origin. --> とするべきです。私は後者が好きです。タイプ量が少ないですから。 BIND の専門家にはこの書式に反対する人もいます (賛成する人もいます)。 ゾーンファイルでは、ドメインはすべて書き下して `<tt/./' で終えるか、 全く書かないかどちらかにします。 後者ではデフォルトで origin が付属します。 <!--O <p>I must stress that in the named.conf file there should <em/not/ be `<tt/./'s after the domain names. You have no idea how many times a `<tt/./' too many or few have fouled up things and confused the h*ll out of people. --> ひとつ強く注意しておきたいのですが、named.conf ファイルでは、 ドメイン名の後に `<tt/./' を<em/付けてはいけません/。 `<tt/./' が多すぎたり少なすぎたりしたおかげで、 どれだけ多くの物事がだめになり、人々が混乱させられたか、 きっとあなたには想像もつかないでしょう。 <!--O <p>So having made my point here is the new zone file, with some extra information in it as well: --> <p>では、この点を押さえて新たなゾーンファイルを書きましょう。 少々新しい情報も加わっていますが、以下のようになります。 <code> ; ; Zone file for linux.bogus ; ; The full zone file ; $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds ; TXT "Linux.Bogus, your DNS consultants" NS ns ; Inet Address of name server NS ns.friend.bogus. MX 10 mail ; Primary Mail Exchanger MX 20 mail.friend.bogus. ; Secondary Mail Exchanger localhost A 127.0.0.1 gw A 192.168.196.1 TXT "The router" ns A 192.168.196.2 MX 10 mail MX 20 mail.friend.bogus. www CNAME ns donald A 192.168.196.3 MX 10 mail MX 20 mail.friend.bogus. TXT "DEK" mail A 192.168.196.4 MX 10 mail MX 20 mail.friend.bogus. ftp A 192.168.196.5 MX 10 mail MX 20 mail.friend.bogus. </code> <!--OLD <p>ここでもいくつか新しい RR が登場します。 HINFO (Host INFOmation) には二つのデータが付属します。 それぞれを "" で括っておくのが良い習慣です。 最初のデータはマシンのハードウェアか CPU を示し、 二番目のデータはソフトウェアか OS を示します。 `ns' という名前のホストは Pentium CPU を搭載し、 Linux 2.0 が動いています。 CNAME (Canonical NAME) は一つのマシンに複数の名前を付けるやり方です。 www は ns の別名になります。 --> <!--O <p>CNAME (Canonical NAME) is a way to give each machine several names. So www is an alias for ns. CNAME record usage is a bit controversial. But it's safe to follow the rule that a MX, CNAME or SOA record should <em/never/ refer to a CNAME record, they should only refer to something with an A record, so it is inadvisable to have --> CNAME (Canonical NAME) は、各マシンを複数の名前で呼ぶ方法です。 よって www は ns の別名になります。CNAME レコードの利用については、 多少議論の余地があります。 でも以下のルールを守っておけば大丈夫でしょう。 MX, CNAME, SOA の 各レコードでは CNAME レコードを<em/参照してはいけません/。 これらは A レコードだけを参照すべきなのです。したがって <code> foobar CNAME www ; NO! </code> <!--O but correct to have --> という指定はすべきではなく、 <code> foobar CNAME ns ; Yes! </code> という指定が正しいものとなります。 <!--O <p>Load the new database by running <tt/rndc reload/, which causes named to read its files again. --> <p><tt/rndc reload/ を実行して新しいデータベースをロードしましょう。 すると named がファイルを読み込み直します。 <tscreen><verb> $ dig linux.bogus axfr ; <<>> DiG 9.1.3 <<>> linux.bogus axfr ;; global options: printcmd linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 linux.bogus. 259200 IN NS ns.linux.bogus. linux.bogus. 259200 IN MX 10 mail.linux.bogus. linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN A 192.168.196.3 donald.linux.bogus. 259200 IN MX 10 mail.linux.bogus. donald.linux.bogus. 259200 IN MX 20 mail.friend.bogus. donald.linux.bogus. 259200 IN TXT "DEK" ftp.linux.bogus. 259200 IN A 192.168.196.5 ftp.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ftp.linux.bogus. 259200 IN MX 20 mail.friend.bogus. gw.linux.bogus. 259200 IN A 192.168.196.1 gw.linux.bogus. 259200 IN TXT "The router" localhost.linux.bogus. 259200 IN A 127.0.0.1 mail.linux.bogus. 259200 IN A 192.168.196.4 mail.linux.bogus. 259200 IN MX 10 mail.linux.bogus. mail.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN MX 10 mail.linux.bogus. ns.linux.bogus. 259200 IN MX 20 mail.friend.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 www.linux.bogus. 259200 IN CNAME ns.linux.bogus. linux.bogus. 259200 IN SOA ns.linux.bogus. hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 41 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:12:31 2001 ;; XFR size: 23 records </verb></tscreen> <!--O <p>That's good. As you see it looks a bit like the zone file itself. Let's check what it says for <tt/www/ alone: --> <p>うまくいっていますね。 ご覧の通り、ゾーンファイルそのものとちょっと似ています。 <tt/www/ だけについても調べてみましょう。 <tscreen><verb> $ dig www.linux.bogus ; <<>> DiG 9.1.3 <<>> www.linux.bogus ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16633 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.linux.bogus. IN A ;; ANSWER SECTION: www.linux.bogus. 259200 IN CNAME ns.linux.bogus. ns.linux.bogus. 259200 IN A 192.168.196.2 ;; AUTHORITY SECTION: linux.bogus. 259200 IN NS ns.linux.bogus. ;; Query time: 5 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:14:14 2001 ;; MSG SIZE rcvd: 80 </verb></tscreen> <!--O <p>In other words, the real name of <tt/www.linux.bogus/ is <tt/ns.linux.bogus/, and it gives you some of the information it has about ns as well, enough to connect to it if you were a program. --> <p>つまり <tt/www.linux.bogus/ の本当の名前は <tt/ns.linux.bogus/ なわけです。 そして named が ns について持っている情報も示してくれています。 あなたがプログラムなら、この情報で接続できるはずです。 <!--O <p>Now we're halfway. --> <p>さて、ここまでが半分。 <!--O <sect1>The reverse zone --> <sect1>逆引きゾーン <!--O <p>Now programs can convert the names in linux.bogus to addresses which they can connect to. But also required is a reverse zone, one making DNS able to convert from an address to a name. This name is used by a lot of servers of different kinds (FTP, IRC, WWW and others) to decide if they want to talk to you or not, and if so, maybe even how much priority you should be given. For full access to all services on the Internet a reverse zone is required. --> <p>今やプログラムは、 linux.bogus にある名前を、 実際に接続すべきアドレスに変換できるようになったわけです。 でも逆引きのゾーンも必要です。 これは DNS でアドレスを名前に変換できるようにするためのものです。 この名前はさまざまな種類のたくさんのサーバ (FTP, IRC, WWW などなど) において、あなたとの通信を認めるか、 また認めた場合、どの程度の優先性を付与するかなどの判断に用いられます。 インターネットにあるサービスすべてにアクセスするためには、 逆引きのゾーンが必要になります。 <!--O <p>Put this in <tt/named.conf/: --> 以下を <tt/named.conf/ に記述してください。 <code> zone "196.168.192.in-addr.arpa" { type master; notify no; file "pz/192.168.196"; }; </code> <!--O <p>This is exactly as with the <tt/0.0.127.in-addr.arpa/, and the contents are similar: --> これは <tt/0.0.127.in-addr.arpa/ とまったく同じです。 ファイルの中身も同じようになります。 <code> $TTL 3D @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; Serial, todays date + todays serial 8H ; Refresh 2H ; Retry 4W ; Expire 1D) ; Minimum TTL NS ns.linux.bogus. 1 PTR gw.linux.bogus. 2 PTR ns.linux.bogus. 3 PTR donald.linux.bogus. 4 PTR mail.linux.bogus. 5 PTR ftp.linux.bogus. </code> <!--O <p>Now you reload your named (<tt/rndc reload/) and examine your work with <tt/dig/ again: --> <p>では <tt/rndc reload/ を実行し、named に設定ファイルを再び読ませ、 再び <tt/dig/ でこれまでの設定を確認しましょう。 <code> $ dig -x 192.168.196.4 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58451 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;4.196.168.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. ;; AUTHORITY SECTION: 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. ;; ADDITIONAL SECTION: ns.linux.bogus. 259200 IN A 192.168.196.2 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:05 2001 ;; MSG SIZE rcvd: 107 </code> <!--O <p>so, it looks OK, dump the whole thing to examine that too: --> <p>うん、良さそうですね。全体もダンプして調べてみましょう。 <code> $ dig 196.168.192.in-addr.arpa. AXFR ; <<>> DiG 9.1.3 <<>> 196.168.192.in-addr.arpa. AXFR ;; global options: printcmd 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 196.168.192.in-addr.arpa. 259200 IN NS ns.linux.bogus. 1.196.168.192.in-addr.arpa. 259200 IN PTR gw.linux.bogus. 2.196.168.192.in-addr.arpa. 259200 IN PTR ns.linux.bogus. 3.196.168.192.in-addr.arpa. 259200 IN PTR donald.linux.bogus. 4.196.168.192.in-addr.arpa. 259200 IN PTR mail.linux.bogus. 5.196.168.192.in-addr.arpa. 259200 IN PTR ftp.linux.bogus. 196.168.192.in-addr.arpa. 259200 IN SOA ns.linux.bogus. \ hostmaster.linux.bogus. 199802151 28800 7200 2419200 86400 ;; Query time: 6 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun Dec 23 03:16:58 2001 ;; XFR size: 9 records </code> <!--O <p>Looks good! If your output didn't look like that look for error-messages in your syslog, I explained how to do that in the first section under the heading <ref id="starting" name="Starting named"> --> <p>よさそうですね！このような出力にならなかった場合は、 syslog にエラーメッセージが出ていないか見てみましょう。 やり方は<ref id="starting" name="named を起動する"> 直下の最初のセクションで説明しましたね。 <!--O <sect1>Words of caution --> <sect1>気をつけてほしいこと <!--O <p>There are some things I should add here. The IP numbers used in the examples above are taken from one of the blocks of 'private nets', i.e., they are not allowed to be used publicly on the Internet. So they are safe to use in an example in a HOWTO. The second thing is the <tt/notify no;/ line. It tells named not to notify its secondary (slave) servers when it has gotten a update to one of its zone files. In BIND 8 and later the named can notify the other servers listed in NS records in the zone file when a zone is updated. This is handy for ordinary use. But for private experiments with zones this feature should be off -\-\- we don't want the experiment to pollute the Internet do we? --> <p>ここでいくつか付け加えておくことがあります。上記で用いた IP 番号は 'private net' のうちの一つのブロックから取ってきたものです。 つまりこれらの IP 番号はインターネットでパブリックに用いることはできません。 ですからこの HOWTO で例として表示しても安全なわけです。 次の点は <tt/notify no;/ の行です。これは named に対して、 「ゾーンファイルのどれかが更新されても、それをセカンダリ (スレーブ) サーバに伝えない」という指示をすることになります。 BIND 8 以降の named は、 ゾーンファイルの NS レコードにリストされている他のサーバに、 ゾーンの更新を知らせることができます。 これは通常は便利な機能ですが、 プライベートな実験ではこの機能は off にしておきましょう。 この実験によってインターネットに迷惑をかけたくはないでしょう？ <!--O <p>And, of course, this domain is highly bogus, and so are all the addresses in it. For a real example of a real-life domain see the next main-section. --> <p>そしてもちろん、このドメインは架空のいいかげんなもので、 使われているアドレスも同じく架空のものです。 現実の世界で用いられている本物の例は、次の章を見て下さい。 <!--O <sect1>Why reverse lookups don't work. --> <sect1>なぜ逆引きが動作しないのか <!--O <p>There are a couple of ``gotchas'' that normally are avoided with name lookups that are often seen when setting up reverse zones. Before you go on you need reverse lookups of your machines working on your own nameserver. If it isn't go back and fix it before continuing. --> <p>名前引きのシステムには、ちょっとした「できの悪い部分」がいくつか あります。通常これらが表に出てくることはありませんが、 逆引きゾーンの設定では良くお目にかかることがあります。 ここから以降を読み進める前には、あなたのマシンが 「あなたのネームサーバ」から逆引きできることを確認してください。 できない場合は戻ってやり直してからにしてください。 <!--O <p>I will discuss two failures of reverse lookups as seen from outside your network: --> <p>ここでは、逆引きを外部ネットワークから見た場合に生じやすい 二つの問題点について議論します。 <!--O <sect2>The reverse zone isn't delegated. --> <sect2>逆引きゾーンが代理されない <!--O <p>When you ask a service provider for a network-address range and a domain name the domain name is normally delegated as a matter of course. A delegation is the glue NS record that helps you get from one nameserver to another as explained in the dry theory section above. You read that, right? If your reverse zone doesn't work go back and read it. Now. --> <p>サービスプロバイダからネットワークアドレス空間とドメインネームを もらうときには、通常そのドメインネームは代理 (delegation) されます。 代理とは橋渡しの役目をする NS レコードのことで、 あるネームサーバから別のネームサーバを取得するときに用います。 先に <ref id="dry_theory" name="退屈な理論"> の節で説明しました。読んでます、よね？ 逆引きゾーンが動作していない場合は、今すぐ戻って読んでください。 <!--O <p>The reverse zone also needs to be delegated. If you got the <tt/192.168.196/ net with the <tt/linux.bogus/ domain from your provider they need to put <tt/NS/ records in for your reverse zone as well as for your forward zone. If you follow the chain from <tt/in-addr.arpa/ and up to your net you will probably find a break in the chain, most probably at your service provider. Having found the break in the chain contact your service-provider and ask them to correct the error. --> <p>逆引きゾーンにも代理が必要です。 例えば <tt/192.168.196/ のネットワークを <tt/linux.bogus/ ドメインと一緒にプロバイダからもらったとしたら、 プロバイダには <tt/NS/ レコードを正引きゾーンだけでなく 逆引きゾーンにも加えてもらう必要があります。 <tt/in-addr.arpa/ からあなたのネットワークまでの繋がりを辿っていくと、 おそらくどこかで鎖の輪が切れていることでしょう。 多分接続しているサービスプロバイダで。「切れている輪」が見付かったら、 サービスプロバイダに連絡してエラーを修正してもらいましょう。 <!--O <sect2>You've got a classless subnet --> <sect2>クラスレス (classless) のサブネットをもらった場合 <!--O <p>This is a somewhat advanced topic, but classless subnets are very common these days and you probably have one if you're a small company. --> <p>これはやや高度な話題になります。 しかしクラスレスのサブネットは最近非常に良く使われるようになってきたので、 小さな会社に所属している人なら、おそらく身近にあるでしょう。 <!--O <p>A classless subnet is what keeps the Internet going these days. Some years ago there was much ado about the shortage of IP numbers. The smart people in IETF (the Internet Engineering Task Force, they keep the Internet working) stuck their heads together and solved the problem. At a price. The price is in part that you'll get less than a ``C'' subnet and some things may break. Please see <url name="Ask Mr. DNS" url="http://www.acmebw.com/askmrdns/00007.htm"> for an good explanation of this and how to handle it. --> <p>最近のインターネットをなんとか維持できているのは、 実はクラスレスサブネットのおかげなのです。 数年前に IP 番号の枯渇についてちょっとした騒ぎになったことがありました。 その時 IETF (Internet Engineering Task Force: インターネットがちゃんと動いているのは彼らのおかげなのです) の賢人たちは、彼らの叡智を集めてこの問題を解決したのでした。 ただし相応の対価をもって。 その対価の一部は、``C'' 未満のサブネットを使わなければならないこと、 それによって動作しなくなるものが出てくること、です。 このあたりに関する説明と、その扱い方に関しては、 <url url="http://www.acmebw.com/askmrdns/00007.htm" name="Ask Mr. DNS"> にある優れた解説を見てください。 <!--O <p>Did you read it? I'm not going to explain it so please read it. --> <p>読みました？ここでは説明しませんから、ちゃんと読んでくださいね。 <!--O <p>The first part of the problem is that your ISP must understand the technique described by Mr. DNS. Not all small ISPs have a working understanding of this. If so you might have to explain to them and be persistent. But be sure you understand it first ;-). They will then set up a nice reverse zone at their server which you can examine for correctness with dig. --> <p>この問題の半分は、接続先の ISP が Mr. DNS に書いてあったテクニックを理解していなければならない、 というところにあります。 小さな ISP では、これを知らずに動かしているところもあるでしょう。 その場合は、あなたが彼らにがまん強く教えてあげなければいけません。 それに、まずあなたが理解しないといけませんね ;-) 理解してくれたら、きっとちゃんとした逆引きゾーンを設定してくれるでしょう。 dig を使って正しいかどうか確かめましょう。 <!--O <p>The second and last part of the problem is that you must understand the technique. If you're unsure go back and read about it again. Then you can set up your own classless reverse zone as described by Mr. DNS. --> 問題の残り半分は、あなたがこのテクニックを理解しなければならない、 というところです。自信がなければ、もう一度読みにいきましょう。 そして Mr. DNS の説明にしたがって、 自分のクラスレス逆引きゾーンを設定しましょう。 <!--O <p>There is another trap lurking here. (Very) Old resolvers will <em/not/ be able to follow the <tt/CNAME/ trick in the resolving chain and will fail to reverse-resolve your machine. This can result in the service assigning it an incorrect access class, deny access or something along those lines. If you stumble into such a service the only solution (that I know of) is for your ISP to insert your PTR record directly into their trick classless zone file instead of the trick CNAME record. --> <p>実はここにはもう一つトラップが待ち構えています。 (非常に) 古いレゾルバは、名前解決のチェーンの中に置かれた この <tt/CNAME/ トリックの部分をたどることができず、 あなたのマシンの逆引きに失敗してしまうことがあります。 この結果、そのレゾルバは正しくないアクセスクラスを返したり、 アクセスを拒否したり、とにかくそんなようなことになります。 この問題に引っかかってしまったら、 (私の知るかぎりでは) 接続先の ISP に頼むしかありません。 トリックを使ったクラスレスゾーンファイルに、 CNAME の代わりにあなたの PTR レコードを 直接書き込んでもらうことになります。 <!--O <p>Some ISPs will offer other ways to handle this, like Web based forms for you to input your reverse-mappings in or other automagical systems. --> <p>ISP によっては別の解法を提供していることもあります。 たとえば Web ベースの form によって逆引きのマップを 入力できるようになっているとか、 あるいは似たような全自動型登録システムとか。 <!--O <sect1>Slave servers --> <sect1>スレーブサーバ <!--O <p>Once you have set up your zones correctly on the master servers you need to set up at least one slave server. Slave servers are needed for robustness. If your master goes down the people out there on the net will still be able to get information about your domain from the slave. A slave should be as long away from you as possible. Your master and slave should share as few as possible of these: Power supply, LAN, ISP, city and country. If all of these things are different for your master and slave you've found a really good slave. --> <p>マスターサーバでゾーンが正しく設定できたら、 少なくとも 1 台のスレーブサーバが必要になります。 スレーブサーバはシステムを堅牢にするために必要なものです。 マスターが落ちても、ネットにいる外部の人が、 スレーブからあなたのドメインに関する情報を取得できるようになるのです。 スレーブは、あなたのいるところからできるだけ離れたところに置きます。 マスターとスレーブは、電力供給源・LAN・ISP・町・国、などを、 できる限り<em/共有していない/ことが望ましいのです。 これらがすべてマスターと異なっているスレーブが見つかったら、 それは非常に良いスレーブだと言えます。 <!--O <p>A slave is simply a nameserver that copies zone files from a master. You set it up like this: --> スレーブは、単にマスターからゾーンファイルをコピーするネームサーバです。 以下のように設定します。 <code> zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 192.168.196.2; }; }; </code> <!--O <p>A mechanism called zone-transfer is used to copy the data. The zone transfer is controlled by your SOA record: --> <p>データのコピーにはゾーン転送という仕組みを用います。 ゾーン転送は SOA レコードで制御します。 <code> @ IN SOA ns.linux.bogus. hostmaster.linux.bogus. ( 199802151 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds </code> <!--O <p>A zone is only transferred if the serial number on the master is larger than on the slave. Every refresh interval the slave will check if the master has been updated. If the check fails (because the master is unavailable) it will retry the check every retry interval. If it continues to fail as long as the expire interval the slave will remove the zone from it's filesystem and no longer be a server for it. --> <p>マスターのシリアル番号がスレーブよりも大きいときに限って ゾーンが転送されます。リフレッシュ (refresh) 時間に一回ずつ、 スレーブはマスターが更新されていないかどうかチェックします。 チェックできない (マスターに接続できない) と、 スレーブはリトライ (retry) 時間に一回ずつ再接続を試みます。 期限切れ (expire) 時間が経過しても失敗し続けた場合は、 スレーブはそのゾーンをファイルシステムから削除し、 それ以上はゾーン情報の提供を行わなくなります。 <!--O <sect>Basic security options. --> <sect>基本的なセキュリティオプション <label id="security"> <p><em/By Jamie Norrish/ <!--O <p><bf/Setting configuration options to reduce the possibility of problems./ --> <p><bf/問題を避けるためのオプション設定/ <!--O <p>There are a few simple steps that you can take which will both make your server more secure and potentially reduce its load. The material presented here is nothing more than a starting point; if you are concerned about security (and you should be), please consult other resources on the net (see <ref id="bigger" name="the last chapter">). --> <p> いくつか簡単な作業を行えば、サーバをより安全にでき、 またサーバの負荷を低減できます。 ここで紹介する内容は出発点に過ぎません。 セキュリティのことを考えるなら (考えるべきです)、 ネット上にある他のリソースにあたってください (<ref id="bigger" name="最後の章">をご覧ください)。 <!--O <p>The following configuration directives occur in <tt/named.conf/. If a directive occurs in the <tt/options/ section of the file, it applies to all zones listed in that file. If it occurs within a <tt/zone/ entry, it applies only to that zone. A <tt/zone/ entry overrides an <tt/options/ entry. --> <p> 以下の指定は <tt/named.conf/ に行います。 これらの指定をこのファイルの <tt/options/ の内部に書くと、 このファイルでリストされたすべてのゾーンに適用されます。 特定の <tt/zone/ エントリの内部に書くと、 そのゾーンだけに適用されます。 <tt/zone/ 内部に書かれたエントリは <tt/options/ に書かれたエントリよりも優先されます。 <!--O <Sect1>Restricting zone transfers --> <sect1>ゾーン転送の制限 <!--O <p>In order for your slave server(s) to be able to answer queries about your domain, they must be able to transfer the zone information from your primary server. Very few others have a need to do so. Therefore restrict zone transfers using the <tt/allow-transfer/ option, assuming 192.168.1.4 is the IP address of ns.friend.bogus and adding yourself for debugging purposes: --> <p> スレーブサーバがドメインに対する問合わせに応えるには、 プライマリサーバからゾーンの情報を転送してくる必要があります。 しかしスレーブサーバ以外のホストには、この転送の必要はないはずです。 ですからゾーン転送は <tt/allow-transfer/ オプションを使って制限しましょう。 例えば ns.friend.bogus の IP アドレスである 192.168.1.4 と、 それからデバッグ用の自分自身を追加するならば: <code> zone "linux.bogus" { allow-transfer { 192.168.1.4; localhost; }; }; </code> <!--O <p>By restricting zone transfers you ensure that the only information available to people is that which they ask for directly - no one can just ask for all the details about your set-up. --> ゾーン転送を制限すれば、外部の人々から見えるのは、 彼らが直接尋ねたホストに関する内容だけに限られます。 DNS 設定の詳細全体を問合わせることはできなくなるのです。 <!--O <Sect1>Protecting against spoofing --> <sect1>不正利用から守る <!--O <p>Firstly, disable any queries for domains you don't own, except from your internal/local machines. This not only helps prevent malicious use of your DNS server, but also reduces unnecessary use of your server. --> <p> まず、内部ネットワークとローカルのマシンからのものをのぞき、 あなたの管理するドメイン以外への問合わせは禁止しましょう。 これは、 悪意を持ってあなたの DNS サーバを利用しようとする試みを禁止するだけでなく、 本来不必要な問合わせを減らします。 <code> options { allow-query { 192.168.196.0/24; localhost; }; }; zone "linux.bogus" { allow-query { any; }; }; zone "196.168.192.in-addr.arpa" { allow-query { any; }; }; </code> <!--O <p>Further, disable recursive queries except from internal/local sources. This reduces the risk of cache poisoning attacks (where false data is fed to your server). --> <p> さらに内部/ローカルからのものを除き、再帰的な問合わせも禁止します。 これによりキャッシュ汚染攻撃 (cache poisoning attack: 間違ったデータをサーバに送りつけること) の危険性が減らせます。 <code> options { allow-recursion { 192.168.196.0/24; localhost; }; }; </code> <!--O <Sect1>Running named as non-root --> <sect1>named を root 以外で実行する <!--O <p>It is a good idea to run named as a user other than root, so that if it is compromised the privileges gained by the cracker are as limited as possible. You first have to create a user for named to run under, and then modify whatever init script you use that starts named. Pass the new user name and group to named using the -u and -g flags. --> <!--nakano -g は不要? --> <p>named を root 以外から実行するのは良い考えです。 破られたときに、クラッカーに奪われる権限を減らすことが出来ますから。 まず named を動作させるユーザを作り、 次に named を起動している init スクリプトを修正します。 新しく作ったユーザ名を、 named の -u フラグに指定します。 <!--O <p>For example, in Debian GNU/Linux 2.2 you might modify your <tt>/etc/init.d/bind</tt> script to have the following line (where user <tt/named/ have been created): --> <p> 例えば Debian GNU/Linux 2.2 なら、 <tt>/etc/init.d/bind</tt> スクリプトを以下の行のように修正します (ユーザ <tt/named/ はあらかじめ作成しておきます): <code> start-stop-daemon --start --quiet --exec /usr/sbin/named -- -u named </code> <!--O <p>The same can be done with Red Hat and the other distributions. --> Red Hat や他のディストリビューションでも同様にできるはずです。 <!--O <p>Dave Lugo has described a secure dual chroot setup <url url="http://www.etherboy.com/dns/chrootdns.html"> which you may find interesting to read, it makes the host your run your named on even more secure. --> Dave Lugo は、二つの chroot を用いたセキュアな設定を <url url="http://www.etherboy.com/dns/chrootdns.html"> で解説しています。きっと興味を持たれる読者が多いでしょう。 これを用いれば named を動かしているホストをさらに安全にできます。 <!--O <sect>A real domain example<label id="real-example"> <p><bf/Where we list some <em/real/ zone files/ --> <sect>実際のドメインの例<label id="real-example"> <p><bf/<em/実際に/用いられているゾーンファイルの例/ <!--O <p>Users have suggested that I include a real example of a working domain as well as the tutorial example. --> <p>チュートリアルの例だけでなく実際に動作している例を載せて欲しい、 という意見があったので、この章を設けました。 <!--O <p>I use this example with permission from David Bullock of LAND-5. These files were current 24th of September 1996, and were then edited to fit BIND 8 restrictions and use extensions by me. So, what you see here differs a bit from what you find if you query LAND-5's name servers now. --> <!--nakano BIND 9? --> <p>この例は LAND-5 の David Bullock の許可の下に用いています。 これらのファイルは、 1996 年 9 月 24 日現在のものを、私が BIND 9 の制限と拡張にあわせて編集したものです。 したがってここでの記述は、 実際に LAND-5 のネームサーバに問い合わせを行った結果とは多少異なります。 <!--O <sect1>/etc/named.conf (or /var/named/named.conf) --> <sect1>/etc/named.conf (または /var/named/named.conf) <!--O <p>Here we find master zone sections for the two reverse zones needed: the 127.0.0 net, as well as LAND-5's <tt/206.6.177/ subnet, and a primary line for land-5's forward zone <tt/land-5.com/. Also note that instead of stuffing the files in a directory called <tt/pz/, as I do in this HOWTO, he puts them in a directory called <tt/zone/. --> <p>マスターゾーンセクションとして、 必須の逆引きゾーンが二つ書かれています。 127.0.0 のネットと LAND-5 のサブネットである <tt/206.6.177/ です。 LAND-5 の正引きゾーンである <tt/land-5.com/ もプライマリとして指定されています。 ゾーンファイルは本 HOWTO のこれまでの例で用いていた <tt/pz/ ではなく、 <tt/zone/ というディレクトリに収められていることにも注意してください。 <code> // Boot file for LAND-5 name server options { directory "/var/named"; }; controls { inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key "rndc_key" { algorithm hmac-md5; secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K"; }; zone "." { type hint; file "root.hints"; }; zone "0.0.127.in-addr.arpa" { type master; file "zone/127.0.0"; }; zone "land-5.com" { type master; file "zone/land-5.com"; }; zone "177.6.206.in-addr.arpa" { type master; file "zone/206.6.177"; }; </code> <!--O <p>If you put this in your named.conf file to play with <bf/PLEASE/ put ``<tt/notify no;/'' in the zone sections for the two <tt/land-5/ zones so as to avoid accidents. --> このファイルをあなたの named.conf ファイルに用いるときには、 <bf/必ず/ ``<tt/notify no;/'' を <tt/land-5/ の二つの zone セクションに追加して、 事故が起こらないようにしてください。 <sect1>/var/named/root.hints <!--O <p>Keep in mind that this file is dynamic, and the one listed here is old. You're better off using a new one as explained earlier. --> <!--nakano not earlier?--> <p>このファイルは動的に変化するものですから、このリストは古いです。 以前に説明したようにして、新しく作ったものを使いましょう。 <code> ; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET. ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4 H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53 B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107 C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12 D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90 E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10 I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17 F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241 ;; Total query time: 215 msec ;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4 ;; WHEN: Sun Feb 15 01:22:51 1998 ;; MSG SIZE sent: 17 rcvd: 436 </code> <sect1>/var/named/zone/127.0.0 <!--O <p>Just the basics, the obligatory SOA record, and a record that maps 127.0.0.1 to <tt/localhost/. Both are required. No more should be in this file. It will probably never need to be updated, unless your nameserver or hostmaster address changes. --> <p>非常にシンプルなものです。まず絶対に必要な SOA レコード、 そして 127.0.0.1 を <tt/localhost/ にマップするレコードです。 これらは両方とも必須です。逆にこれ以上のものは置くべきではありません。 このファイルは、使っているネームサーバか hostmaster のメールアドレスが変更されない限り、 更新する必要はおそらくないでしょう。 <code> $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609203 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. 1 PTR localhost. </code> <!--O <p>If you look at a random BIND installation you will probably find that the <tt/$TTL/ line is missing as it is here. It was not used before, and only version 8.2 of BIND has started to warn about its absence. BIND 9 <em/requires/ the <tt/$TTL/. --> <p>適当にインストールされた BIND では、 ここでの例のように <tt/$TTL/ の行がないかもしれません。 この行は以前は用いられておらず、 8.2 の BIND だけが起動時にこの行が無い旨の警告を出します。 なお BIND 9 では <tt/$TTL/ は<em/必須/です。 <sect1>/var/named/zone/land-5.com <!--O <p>Here we see the mandatory SOA record, the needed NS records. We can see that he has a secondary name server at <tt/ns2.psi.net/. This is as it should be, <em/always/ have a off site secondary server as backup. We can also see that he has a master host called <tt/land-5/ which takes care of many of the different Internet services, and that he's done it with CNAMEs (a alternative is using A records). --> <p>まず必須である SOA レコードと、同じく必須の NS レコードがあります。 セカンダリのネームサーバが <tt/ns2.psi.net/ に用意されていることもわかりますね。 これは望ましい設定です。 <em/必ず/サイトの外にバックアップのセカンダリネームサーバを置くべきです。 マスターのホストは <tt/land-5/ で、 このホストは同時に各種のインターネットサービスを提供していることもわかります。 これには (A レコードでなく) CNAME が用いられています。 <!--O <p>As you see from the SOA record, the zone file originates at <tt/land-5.com/, the contact person is <tt/root@land-5.com/. <tt/hostmaster/ is another oft used address for the contact person. The serial number is in the customary yyyymmdd format with todays serial number appended; this is probably the sixth version of zone file on the 20th of September 1996. Remember that the serial number <em/must/ increase monotonically, here there is only <em/one/ digit for todays serial#, so after 9 edits he has to wait until tomorrow before he can edit the file again. Consider using two digits. --> <p>SOA レコードからわかるように、このゾーンファイルは <tt/land-5.com/ を origin にしており、連絡担当者は <tt/root@land-5.com/ です。 <tt/hostmaster/ も担当者のアドレスとして良く用いられます。 シリアル番号は yyyymmdd 形式で、 その日のうちのシリアル番号が追加されています。 これはきっと 1996 年 9 月 20 日の第 6 版なのでしょう。 シリアル番号は必ず<em/増加しなければならない/ことを思い出してください。 ここには当日中のシリアル番号として<em/一桁/しか使うことが できません。したがって 9 回変更を行ったら、次の変更を行うには 翌日まで待たなければなりません。二桁使う方が良いかもしれませんね。 <code> $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; serial, todays date + todays serial # 8H ; refresh, seconds 2H ; retry, seconds 4W ; expire, seconds 1D ) ; minimum, seconds NS land-5.com. NS ns2.psi.net. MX 10 land-5.com. ; Primary Mail Exchanger TXT "LAND-5 Corporation" localhost A 127.0.0.1 router A 206.6.177.1 land-5.com. A 206.6.177.2 ns A 206.6.177.3 www A 207.159.141.192 ftp CNAME land-5.com. mail CNAME land-5.com. news CNAME land-5.com. funn A 206.6.177.2 ; ; Workstations ; ws-177200 A 206.6.177.200 MX 10 land-5.com. ; Primary Mail Host ws-177201 A 206.6.177.201 MX 10 land-5.com. ; Primary Mail Host ws-177202 A 206.6.177.202 MX 10 land-5.com. ; Primary Mail Host ws-177203 A 206.6.177.203 MX 10 land-5.com. ; Primary Mail Host ws-177204 A 206.6.177.204 MX 10 land-5.com. ; Primary Mail Host ws-177205 A 206.6.177.205 MX 10 land-5.com. ; Primary Mail Host ; {Many repetitive definitions deleted - SNIP} ws-177250 A 206.6.177.250 MX 10 land-5.com. ; Primary Mail Host ws-177251 A 206.6.177.251 MX 10 land-5.com. ; Primary Mail Host ws-177252 A 206.6.177.252 MX 10 land-5.com. ; Primary Mail Host ws-177253 A 206.6.177.253 MX 10 land-5.com. ; Primary Mail Host ws-177254 A 206.6.177.254 MX 10 land-5.com. ; Primary Mail Host </code> <!--O <p>If you examine land-5s nameserver you will find that the host names are of the form <tt/ws_/<em/number/. As of late BIND 4 versions named started enforcing the restrictions on what characters may be used in host names. So that does not work with BIND 8 at all, and I substituted '-' (dash) for '_' (underline) for use in this HOWTO. But, as mentioned earlier, BIND 9 no longer enforces this restriction. --> <p>land-5 のネームサーバを試してみればわかりますが、 本当のホスト名は <tt/ws_/<em/number/ となっています。 BIND 4 の後の方のバージョンから、 ホスト名に用いることのできる文字が制限されるようになりました。 したがってこの名前は BIND 8 では全く動作しませんから、 この HOWTO に掲載する際には '_' (underline) を '-' (dash) で置き換えました。 しかし、先に述べたように、BIND 9 では再びこの制限はなくなりました。 <!--O <p>Another thing to note is that the workstations don't have individual names, but rather a prefix followed by the two last parts of the IP numbers. Using such a convention can simplify maintenance significantly, but can be a bit impersonal, and, in fact, be a source of irritation among your customers. --> <p>もう一つ気がつきましたか？ 各ワークステーションには固別の名前は付いておらず、 プレフィックスに IP 番号の最後の二つが付いた形式になっています。 このような命名方法を用いればメンテナンスはとても楽になりますが、 やや人間との相性は悪いので、 顧客をイライラさせる結果になってしまうかもしれません。 <!--O <p>We also see that <tt/funn.land-5.com/ is an alias for <tt/land-5.com/, but using an A record, not a CNAME record. --> <p><tt/funn.land-5.com/ も <tt/land-5.com/ のエイリアスになっていますが、 これは CNAME レコードではなく A レコードを用いています。 <sect1>/var/named/zone/206.6.177 <!--O <p>I'll comment on this file below --> <p>このファイルについては後でコメントします。 <code> $TTL 3D @ IN SOA land-5.com. root.land-5.com. ( 199609206 ; Serial 28800 ; Refresh 7200 ; Retry 604800 ; Expire 86400) ; Minimum TTL NS land-5.com. NS ns2.psi.net. ; ; Servers ; 1 PTR router.land-5.com. 2 PTR land-5.com. 2 PTR funn.land-5.com. ; ; Workstations ; 200 PTR ws-177200.land-5.com. 201 PTR ws-177201.land-5.com. 202 PTR ws-177202.land-5.com. 203 PTR ws-177203.land-5.com. 204 PTR ws-177204.land-5.com. 205 PTR ws-177205.land-5.com. ; {Many repetitive definitions deleted - SNIP} 250 PTR ws-177250.land-5.com. 251 PTR ws-177251.land-5.com. 252 PTR ws-177252.land-5.com. 253 PTR ws-177253.land-5.com. 254 PTR ws-177254.land-5.com. </code> <!--O <p>The reverse zone is the bit of the setup that seems to cause the most grief. It is used to find the host name if you have the IP number of a machine. Example: you are an FTP server and accept connections from FTP clients. As you are a Norwegian FTP server you want to accept more connections from clients in Norway and other Scandinavian countries and less from the rest of the world. When you get a connection from a client the C library is able to tell you the IP number of the connecting machine because the IP number of the client is contained in all the packets that are passed over the network. Now you can call a function called gethostbyaddr that looks up the name of a host given the IP number. Gethostbyaddr will ask a DNS server, which will then traverse the DNS looking for the machine. Supposing the client connection is from ws-177200.land-5.com. The IP number the C library provides to the FTP server is 206.6.177.200. To find out the name of that machine we need to find <tt/200.177.6.206.in-addr.arpa/. The DNS server will first find the <tt/arpa./ servers, then find <tt/in-addr.arpa./ servers, following the reverse trail through 206, then 6 and at last finding the server for the <tt/177.6.206.in-addr.arpa/ zone at LAND-5. From which it will finally get the answer that for <tt/200.177.6.206.in-addr.arpa/ we have a ``<tt/PTR ws-177200.land-5.com/'' record, meaning that the name that goes with <tt/206.6.177.200/ is <tt/ws-177200.land-5.com/. --> <p>逆引きのゾーンは、設定の中でも多くの悲劇を引き起こす部分と言えます。 これはマシンの IP 番号がわかっている場合に、 ホスト名を取得するために用いられます。 例えば、あなたが立てている FTP サーバが FTP クライアントから接続されたとしましょう。 あなたの FTP サーバはノルウェーにあるので、 ノルウェーと他のスカンジナビアの国々以外からの接続は多めに、 他の国々からの接続は少なめに制限したいとします。 クライアントから接続されると、 C ライブラリによって接続してきたマシンの IP 番号を知ることができます。 なぜならクライアントの IP 番号は、ネットワークを運ばれてきた IP パケットのそれぞれに書き込まれているからです。 ここで gethostbyaddr という関数を呼べば、 IP 番号からホストの名前を引くことができます。 gethostbyaddr は DNS サーバに尋ね、 DNS サーバは DNS からそのマシンを探します。 接続してきたクライアントは ws-177200.land-5.com だったとしてみましょう。 C ライブラリが IRC サーバに渡す IP 番号は 206.6.177.200 となります。 したがって名前を引くためには <tt/200.177.6.206.in-addr.arpa/ を見つける必要があります。 DNS サーバはまず <tt/arpa./ のサーバに問い合わせをし、 <tt/in-addr.arpa./ のサーバを教えてもらいます。 続いて 206, 6 を順次逆に辿って、最後に Land-5 のゾーンである <tt/177.6.206.in-addr.arpa/ ゾーンを発見します。 最後にサーバは、そこから <tt/200.177.6.206.in-addr.arpa/ に対する答えを入手します。 ``<tt/PTR ws-177200.land-5.com/'' レコードから、 <tt/206.6.177.200/ は <tt/ws-177200.land-5.com/ であることがわかります。 <!--O <p>The FTP server prioritizes connections from the Scandinavian countries, i.e., <tt/*.no/, <tt/*.se/, <tt/*.dk/, the name <tt/ws-177200.land-5.com/ clearly does not match any of those, and the server will put the connection in a connection class with less bandwidth and fewer clients allowed. If there was <em/no/ reverse mapping of <tt/206.2.177.200/ through the <tt/in-addr.arpa/ zone the server would have been unable to find the name at all and would have to settle to comparing <tt/206.2.177.200/ with <tt/*.no/, <tt/*.se/ and <tt/*.dk/, none of which will match at all, it may even deny the connection for lack of classification. --> <p>FTP サーバはスカンジナビアの国々、すなわち <tt/*.no/, <tt/*.se/, <tt/*.dk/ からの接続を優先しますが、 <tt/ws-177200.land-5.com/ は明らかに以上のどれにもマッチしませんから、 サーバはこの節続を、バンド幅がより小さく、 最大接続数も少ないクラスに割り当てます。 <tt/206.2.177.200/ に対する逆引きマップがそもそも <tt/in-addr.arpa/ ゾーンに存在しなければ、 サーバは決して名前を見つけることができませんから、 <tt/206.2.177.200/ そのものを <tt/*.no/, <tt/*.se/, <tt/*.dk/ と比較します。 どれにもマッチするわけはなく、 サーバはクラスの割り当てができないその節続を、 拒否することもあり得ます。 <!--O <p>Some people will tell you that reverse lookup mappings are only important for servers, or not important at all. Not so: Many ftp, news, IRC and even some http (WWW) servers will <em/not/ accept connections from machines of which they are not able to find the name. So reverse mappings for machines are in fact <em/mandatory/. --> <p>逆引きマップが重要なのはサーバだけだ、という人や、 そもそも逆引きマップなんて全然大事じゃないんだ、 なんていう人がいるかもしれません。 これは間違いです。 多くの ftp, news, IRC サーバでは逆引きのできないマシンからの接続を拒否します (WWW サーバにさえ拒否するものもあります)。 ですからマシン名の逆引きマップは実のところは<em/必須/なのです。 <!--O <sect>Maintenance<label id="maint"> <p><bf/Keeping it working./ --> <sect>メンテナンス<label id="maint"> <p><bf/動作を維持するために/ <!--O <p>There is one maintenance task you have to do on nameds, other than keeping them running. That's keeping the <tt/root.hints/ file updated. The easiest way is using <tt/dig/. First run <tt/dig/ with no arguments you will get the <tt/root.hints/ according to your own server. Then ask one of the listed root servers with <tt/dig @rootserver/. You will note that the output looks terribly like a <tt/root.hints/ file. Save it to a file (<tt/dig @e.root-servers.net . ns >root.hints.new/) and replace the old <tt/root.hints/ with it. --> <p>named には、ただ走らせる以外にも一つ保守作業があります。 <tt/root.hints/ ファイルを最新の状態に保つ作業です。 一番簡単なのは <tt/dig/ を使うやり方です。まず引き数なしで <tt/dig/ を動かすと、現在サーバで使っている <tt/root.hints/ の内容が表示されます。 次にリストされているルートサーバのいずれかに対して <tt/dig @rootserver/ のように問い合わせを行います。 出力結果は <tt/root.hints/ の内容にとてもよく似ているはずです。 この結果を <tt/dig @e.root-servers.net . ns > root.cache.new/ のように保存して、古い <tt/root.hints/ と置き換えます。 <!--O <p>Remember to reload named after replacing the cache file. --> <p>キャッシュファイルを入れ替えた後には named に再読み込みさせるのをお忘れなく。 <!--O <p>Al Longyear sent me this script that can be run automatically to update <tt/root.hints/. Install a crontab entry to run it once a month and forget it. The script assumes you have mail working and that the mail-alias `hostmaster' is defined. You must hack it to suit your setup. --> <p>Al Longyear がスクリプトを送ってくれました。自動的に <tt/root.hints/ を更新してくれるものです。 これを月に一度起動する crontab のエントリをインストールすれば、 後は全部おまかせです。スクリプトでは、メールがちゃんと動作していて、 メールエイリアスとして `hostmaster' が定義されていることを前提としています。 あなたの設定にあわせてハックする必要があります。 <code> #!/bin/sh # # Update the nameserver cache information file once per month. # This is run automatically by a cron entry. # # Original by Al Longyear # Updated for BIND 8 by Nicolai Langfeldt # Miscelanious error-conditions reported by David A. Ranch # Ping test suggested by Martin Foster # named up-test suggested by Erik Bryer. # ( echo "To: hostmaster <hostmaster>" echo "From: system <root>" # Is named up? Check the status of named. case `rndc status 2>&1` in *refused*) echo "named is DOWN. root.hints was NOT updated" echo exit 0 ;; esac PATH=/sbin:/usr/sbin:/bin:/usr/bin: export PATH # NOTE: /var/named must be writable only by trusted users or this script # will cause root compromise/denial of service opportunities. cd /var/named 2>/dev/null || { echo "Subject: Cannot cd to /var/named, error $?" echo echo "The subject says it all" exit 1 } # Are we online? Ping a server at your ISP case `ping -qnc 1 some.machine.net 2>&1` in *'100% packet loss'*) echo "Subject: root.hints NOT updated. The network is DOWN." echo echo "The subject says it all" exit 1 ;; esac dig @e.root-servers.net . ns >root.hints.new 2> errors case `cat root.hints.new` in *NOERROR*) # It worked :;; *) echo "Subject: The root.hints file update has FAILED." echo echo "The root.hints update has failed" echo "This is the dig output reported:" echo cat root.hints.new errors exit 1 ;; esac echo "Subject: The root.hints file has been updated" echo echo "The root.hints file has been updated to contain the following information:" echo cat root.hints.new chown root.root root.hints.new chmod 444 root.hints.new rm -f root.hints.old errors mv root.hints root.hints.old mv root.hints.new root.hints rndc restart echo echo "The nameserver has been restarted to ensure that the update is complete." echo "The previous root.hints file is now called /var/named/root.hints.old." ) 2>&1 | /usr/lib/sendmail -t exit 0 </code> <p> 訳注: 訳者はまだ BIND 8 なのでこのスクリプトを試していないのですが、 <tt>rndc restart</tt> というコマンドは <tt>rndc stop; named</tt> で置き換えないといけないような気がします。 <!--nakano rndc restart というのは OK なのか?--> <!--O <p>Some of you might have picked up that the <tt/root.hints/ file is also available by ftp from Internic. Please don't use ftp to update <tt/root.hints/, the above method is much more friendly to the net, and Internic. --> <p><tt/root.hints/ は Internic から ftp でも入手できる、 と言うことをすでにご存じの方もいるかもしれません。 ですが <tt/root.hints/ の更新に ftp は使わないようにしてください。 上記の方法のほうが、ずっと「ネット (と Internic) に優しい」のです。 <!--O <sect>Migrating to BIND 9 --> <sect>BIND 9 に移行する <!--O <p>The BIND 9 distribution, and the prepackaged versions too, contains a document called <tt/migration/ that contains notes about how to migrate from BIND 8 to BIND 9. The document is very straight forward. If you installed binary packages it's likely stored in <tt>/usr/share/doc/bind*</tt> or <tt>/usr/doc/bind*</tt> somewhere. --> <!--nakano straightforward--> <p>BIND 9 の配布アーカイブや、パッケージ化されたバージョンには、 <tt/migration/ という文書が含まれており、 そこに BIND 8 から BIND 9 に移行するための情報が記述されています。 この文書は非常にわかりやすく書かれています。 バイナリパッケージをインストールした場合は、 <tt>/usr/share/doc/bind*</tt> や <tt>/usr/doc/bind*</tt> あたりに置かれていると思います。 <!--O <p>If you're running BIND 4, you may find a document called <tt/migration-4to9/ in the same place. --> BIND 4 を使っている人は、同じ場所にある <tt/migration-4to9/ を見てください。 <!--O <sect>Questions and Answers<label id="qanda"> <p>Please read this section before mailing me. --> <sect>Q & A<label id="qanda"> <p>私にメールする前に、まずこの章を読んでください。 <enum> <!--O <item>My named wants a named.boot file <p>You are reading the wrong HOWTO. Please see the old version of this HOWTO, which covers BIND 4, at <url url="http://langfeldt.net/DNS-HOWTO/"> --> <item>私の named では named.boot ファイルが必要と言われます <p>読んでいる HOWTO が間違っています。この HOWTO の古い版では bind 4 のことを扱っていますので、そちらを読んでください。 <url url="http://langfeldt.net/DNS-HOWTO/"> にあります。 <!--O <item>How do use DNS from inside a firewall? <p>A hint: <tt/forward only;/. You might also need --> <item>ファイアウォールの中で DNS を使うには？ <p>ヒント。 <tt/forward only;/。また <code> query-source port 53; </code> <!--O inside the ``options'' part of the <tt/named.conf/ file as suggested in the example <ref id="caching" name="caching"> section. --> が <tt/named.conf/ ファイルの ``options'' の部分に必要になるでしょう。 <ref id="caching" name="キャッシュ専用のネームサーバ"> の節にある例でちょっと触れましたね。 <!--O <item>How do I make DNS rotate through the available addresses for a service, say <tt/www.busy.site/ to obtain a load balancing effect, or similar? <p>Make several <bf/A/ records for <tt/www.busy.site/ and use BIND 4.9.3 or later. Then BIND will round-robin the answers. It will <em/not/ work with earlier versions of BIND. --> <item>DNS によって、あるサービスに対するアドレスを順繰りにまわす (round-robin する) にはどうすれば良いですか？ つまり例えば <tt/www.busy.site/ に対する負荷を 分散させるようにするにはどうすれば良いでしょうか。 <p><tt/www.busy.site/ に対する <bf/A/ レコードを複数用意して、 4.9.3 以降の BIND を用いましょう。 BIND は回答を round-robin してくれます。古い版の BIND では、これは動作<em/しません/。 <!--O <item>I want to set up DNS on a (closed) intranet. What do I do? <p>You drop the <tt/root.hints/ file and just do zone files. That also means you don't have to get new hint files all the time. --> <item>(クローズな) イントラネットで DNS を使いたいのです。 どうすれば良いですか？ <p><tt/root.hints/ ファイルを使わないようにして、 ゾーンファイルだけを使いましょう。 <tt/root.hints/ ファイルをいちいち更新する必要もないわけです。 <!--O <item>How do I set up a secondary (slave) name server? <p>If the primary/master server has address 127.0.0.1 you put a line like this in the named.conf file of your secondary: --> <item>セカンダリ (スレーブ) のネームサーバを設定するには？ <p>プライマリ (マスタ) のサーバが、アドレス 127.0.0.1 だったと して、以下のような行をセカンダリの named.conf に記述します。 <code> zone "linux.bogus" { type slave; file "sz/linux.bogus"; masters { 127.0.0.1; }; }; </code> <!--O You may list several alternate master servers the zone can be copied from inside the <tt/masters/ list, separated by ';' (semicolon). --> zone 情報を取ってこれるマスタサーバが他にもある場合は、 <tt/masters/ リストに `;' (セミコロン) で区切って 追加することもできます。 <!--O <item>I want BIND running when I'm disconnected from the net. <p>There are four items regarding this: --> <item>net から切断されているときにも BIND を 動作させておきたいんですが。 <p>これに関連した記事を 4 つ紹介しましょう。 <itemize> <!--O <item>Specific to BIND 8/9, Adam L Rice has sent me this e-mail, about how to run DNS painlessly on a dialup machine: --> <item>BIND 8/9 に特化したやり方を Adam L Rice が電子メールで 教えてくれました。ダイアルアップのマシンで DNS を手間をかけずに 動作させる方法です。 <!--O <tscreen><verb> I have discovered with newer versions of BIND that this [<em/shuffeling files, -ed/] is no longer necessary. There is a "forward" directive in addition to the "forwarders" directive that controls how they are used. The default setting is "forward first", which first asks each of the forwarders, and then tries the normal approach of doing the legwork itself if that fails. This gives the familiar behaviour of gethostbyname() taking an inordinately long time when the link is not up. But if "forward only" is set, then BIND gives up when it doesn't get a response from the forwarders, and gethostbyname() returns immediately. Hence there is no need to perform sleight-of-hand with files in /etc and restart the server. In my case, I just added the lines forward only; forwarders { 193.133.58.5; }; to the options { } section of my named.conf file. It works very nicely. The only disadvantage of this is that it reduces an incredibly sophisticated piece of DNS software to the status of a dumb cache. To some extent, I would just like to run a dumb cache for DNS instead, but there doesn't seem to be such a piece of software available for Linux. </verb></tscreen> --> <tscreen><verb> 私は、最近のバージョンの BIND では、これ [編注: ファイルを切り 替える] がもう不必要であることに気がつきました。 "forwarders" 指定の他に"forward" 指定が可能になっていて、後者で前者の使われ方を 制御できるようになっていたんです。デフォルトの設定は "forward first" で、 最初にそれぞれの forwarders に問い合わせを行い、 失敗した場合にはじめて自分自身で聞き込み調査を始めます。これが ラインが切れている時に gethostbyname() にやたらと時間がかかって しまう、おなじみの振る舞いです。しかし "forward only" を設定して おくと、 BIND は forwarders から反応が帰ってこないとすぐに あきらめます。したがって gethostbyname() も速やかに返ってくる ことになります。ですから技巧を使って /etc のファイルを切り替え、 サーバを再起動する必要はないのです。 私の場合では、以下の行を named.conf ファイルの options { } セクションに追加するだけでした。 forward only; forwarders { 193.133.58.5; }; とってもうまく動作してます。この方法のただ一つの欠点は、非常に 洗練された DNS ソフトウェアを、キャッシュ動作だけしかしない 単機能なソフトにしてしまう、ということです。ただ DNS キャッシュ だけをするソフトがあれば私は実はそっちを使いたいんですけど、 Linux ではそのようなソフトはないみたいですね。 </verb></tscreen> <!--O <item>I have received this mail from Ian Clark <ic@deakin.edu.au> where he explains his way of doing this: --> <item>以下の記事は Ian Clard <ic@deakin.edu.au> から もらったメールです。彼のやり方を説明してくれています。 <!--O <tscreen><verb> I run named on my 'Masquerading' machine here. I have two root.hints files, one called root.hints.real which contains the real root server names and the other called root.hints.fake which contains... -\-\-\- ; root.hints.fake ; this file contains no information -\-\-\- When I go off line I copy the root.hints.fake file to root.hints and restart named. When I go online I copy root.hints.real to root.hints and restart named. This is done from ip-down & ip-up respectively. The first time I do a query off line on a domain name named doesn't have details for it puts an entry like this in messages.. Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN which I can live with. It certainly seems to work for me. I can use the nameserver for local machines while off the 'net without the timeout delay for external domain names and I while on the 'net queries for external domains work normally </verb></tscreen> --> <tscreen><verb> IP マスカレードをさせている手元のマシンで named を走らせています。 root.hints ファイルを二つ用意します。一つは root.hints.real で、 本物の root サーバの名前が書かれています。もう一つは root.hints.fake で、その内容は... ---- ; root.hints.fake ; this file contains no information ---- です。切断するときには root.hints.fake ファイルを root.hints に コピーして named を再起動します。 接続するときには root.hints.real ファイルを root.hints にコピー して named を再起動します。 これらは ip-down と ip-up でそれぞれ自動実行させています。 オフラインの時にドメイン名に対する問い合わせを行うと、named は それらに付いて知りませんから、以下のようなエントリを messages に 出力します。 Jan 28 20:10:11 hazchem named[10147]: No root nameserver for class IN これは気にしなくてもかまいません。 私のところではこれで全く問題なく動作しています。ネットから切断 されているときは、ローカルマシンのネームサーバを外部のドメイン名に 対するタイムアウトの待ち時間なしで使えますし、接続されているとき には外部のドメインに対する問い合わせを普通に行うことができています。 </verb></tscreen> <!--O <p>Peter Denison thought that Ian does not go far enough though. He writes: --> <p>しかし、Peter Denison は Ian のやり方がまだ充分でないと教えてくれました。 彼のメッセージによると: <!--O <tscreen><verb> When connected) serve all cached (and local network) entries immediately for non-cached entries, forward to my ISPs nameserver When off-line) serve local network queries immediately fail all other queries **immediately** The combination of changing the root cache file and forwarding queries doesn't work. So, I've set up (with some discussion of this on the local LUG) two nameds as follows: named-online: forwards to ISPs nameserver master for localnet zone master for localnet reverse zone (1.168.192.in-addr.arpa) master for 0.0.127.in-addr.arpa listens on port 60053 named-offline: no forwarding "fake" root cache file slave for 3 local zones (master is 127.0.0.1:60053) listens on port 61053 And combined this with port forwarding, to send port 53 to 61053 when off-line, and to port 60053 when online. (I'm using the new netfilter package under 2.3.18, but the old (ipchains) mechanism should work.) Note that this won't quite work out-of-the-box, as there's a slight bug in BIND 8.2, which I have logged wth the developers, preventing a slave having a master on the same IP address (even if a different port). It's a trivial patch, and should go in soon I hope. </verb></tscreen> --> <tscreen><verb> オンライン時) キャッシュされたエントリ (とローカルネットのエントリ) は ただちに提供する。キャッシュされていないエントリについては、 自分の ISP のネームサーバにフォワードする。 オフライン時) ローカルネットワーク関連の問合わせはただちに提供する。 その他の問合わせについては **ただちに** 失敗する。 root キャッシュファイルの変更と、問合わせのフォワードとの組み合わせは うまく動作しません。 そこで、私は二つの named を (地域 LUG で議論しながら) 以下のように 設定しました。 named-online: ISP のネームサーバへフォワード localnet ゾーンのマスター localnet の逆引きゾーン (1.168.192.in-addr.arpa) のマスター 0.0.127.in-addr.arpa のマスター ポート 60053 で待機 named-offline: フォワードを行わない root キャッシュファイルは「にせもの」にする 3 つのローカルゾーンのスレーブ (マスターは 127.0.0.1:60053) ポート 61053 で待機 そしてこれをポートフォワードと組み合わせ、ポート 53 をオフラインの時には 61053 に、オンラインの時には 60053 にフォワードします (私は 2.3.18 で 新しい netfilter パッケージを使いましたが、以前の (ipchains) の機構でも 動作するはずです。 ただしこれはマシンの外側からの問合わせには動作しません。 BIND 8.2 には 小さなバグがあって、スレーブをマスターと同じ IP アドレスでは (ポートが 異なっても) 同時に動作できないからです (開発者には知らせました)。 明らかなパッチなので、おそらくすぐに直るでしょう。 </verb></tscreen> <!--O <item>I have also received information about how BIND interacts with NFS and the portmapper on a mostly offline machine from Karl-Max Wanger: --> <item>切断されている時間の長いマシンにおいて、BIND がNFS や ポートマッパとどのように相互作用するのかに関する情報もいただきました。 Karl-Max Wanger からです。 <!--O <tscreen><verb> I use to run my own named on all my machines which are only occasionally connected to the Internet by modem. The nameserver only acts as a cache, it has no area of authority and asks back for everything at the name servers in the root.cache file. As is usual with Slackware, it is started before nfsd and mountd. With one of my machines (a Libretto 30 notebook) I had the problem that sometimes I could mount it from another system connected to my local LAN, but most of the time it didn't work. I had the same effect regardless of using PLIP, a PCMCIA ethernet card or PPP over a serial interface. After some time of guessing and experimenting I found out that apparently named messed with the process of registration nfsd and mountd have to carry out with the portmapper upon startup (I start these daemons at boot time as usual). Starting named after nfsd and mountd eliminated this problem completely. As there are no disadvantages to expect from such a modified boot sequence I'd advise everybody to do it that way to prevent potential trouble. </verb></tscreen> --> <tscreen><verb> インターネットに対してモデム経由でたまにしか接続しないマシンには、 私はすべて named を走らせていました。ネームサーバはキャッシュと してのみ動作し、 authority をもつ zone は保有せず、すべてを root.cache ファイルに書かれたネームサーバに問い合わせに行く設定に していました。 Slackware の流儀に従い、named は nfsd や mountd の 前に起動していました。 マシンのうちの一つ (Libretto 30 notebook) で、問題が起こりました。 私のローカルな LAN につながっている他のマシンから、そのマシンを mount できなくなってしまうのです (ごくたまにできる時もありますが)。 これは接続形式に依存せず、 PLIP でも PCMCIA のイーサネットカードでも、 シリアル経由の PPP でも同じように起こりました。 しばらく実験と考察を行った後、以下のような結論に達しました。 nfsd と mountd が起動時に portmapper に対して行った登録動作 (私はこれらのデーモンを、通常通りブート時にスタートしていました) を、 named はめちゃめちゃにしてしまうのです。 named の起動を nfsd と mountd のあとに行うようにしたところ、この問題は完全に 解決しました。 ブートの順序をこのように変更することによる不利はまったくありません から、潜在的な問題を避けるために、このようにすることをすべての 皆さんにお薦めしたいと思います。 </verb></tscreen> </itemize> <!--O <item>Where does the caching name server store its cache? Is there any way I can control the size of the cache? <p>The cache is completely stored in memory, it is <em/not/ written to disk at any time. Every time you kill named the cache is lost. The cache is <em/not/ controllable in any way. named manages it according to some simple rules and that is it. You cannot control the cache or the cache size in any way for any reason. If you want to you can ``fix'' this by hacking named. This is however not recommended. --> <item>キャッシュネームサーバはどこにキャッシュを保存しているの？ キャッシュのサイズは制御できますか？ <p>キャッシュはすべてメモリに保管されています。ディスクに 書き込まれることは<em/まったく/ありません。 named を kill すると、キャッシュも失われます。 キャッシュを制御する方法は<em/ありません/。 named のキャッシュ管理は単純なルールに従っているからです。 キャッシュそのものも、あるいはキャッシュのサイズも、 どんな理由があれ制御できません。 この点を「修正」したければ named をハックしても良いでしょう。 おすすめはできませんが。 <!--O <item>Does named save the cache between restarts? Can I make it save it? <p>No, named does <em/not/ save the cache when it dies. That means that the cache must be built anew each time you kill and restart named. There is <em/no/ way to make named save the cache in a file. If you want you can ``fix'' this by hacking named. This is however not recommended. --> <item>named は再起動されるときにキャッシュを保存してくれますか？ 保存するようにできますか？ <p>いいえ、 named は終了時にキャッシュを保存<em/しません/。 つまり named を kill して再起動するたびに、 キャッシュはゼロから再構成されます。 キャッシュをファイルに保存するように named に指示する方法は<em/ない/のです。 この点を「修正」したければ named をハックしても良いでしょう。 おすすめはできませんが。 <!--O <item>How can I get a domain? I want to set up my own domain called (for example) <tt/linux-rules.net/. How can I get the domain I want assigned to me? <p>Please contact your network service provider. They will be able to help you with this. Please note that in most parts of the world you need to pay money to get a domain. --> <item>ドメインを手に入れるにはどうすればいいですか？ 私は (例えば) <tt/linux-rules.net/ というドメインを立ち上げたいのですが、 このドメインを割り当ててもらうにはどうすればいいのでしょうか。 <p>ネットワークサービスプロバイダに連絡してみれば、 おそらく助けてもらえるでしょう。なお世界のほとんどの地域では、 ドメインの入手にはお金が必要であるはずです。 <!--O <item>How can I secure my DNS server? How do I set up split DNS? <p>Both of these are advanced topics. They are both covered in <url url="http://www.etherboy.com/dns/chrootdns.html">. I will not explain the topics further here. --> <item>DNS サーバを安全にするにはどうすればいいでしょう？ split DNS の設定のしかたは？ <p>両方とも高度な話題になります。 いずれも <url url="http://www.etherboy.com/dns/chrootdns.html"> で取り上げられています。この話題は、 これ以上ここでは扱いません。 </enum> <!--O <sect>How to become a bigger time DNS admin.<label id="bigger"> <p><bf>Documentation and tools.</bf> --> <sect>より熟練した DNS 管理者になるために<label id="bigger"> <p><bf>文献とツール</bf> <!--O <p>Real Documentation exists. Online and in print. The reading of several of these is required to make the step from small time DNS admin to a big time one. --> <p>しっかりした文献がちゃんと存在しています。 オンラインのものと印刷されているものとがそれぞれあります。 即席 DNS 管理者が熟練した DNS 管理者になるためのステップを踏むには、 この中のいくつかを読むことが必要です。 <!--O <p>I have written <em/The Concise Guide to DNS and BIND/ (by Nicolai Langfeldt, me), published by Que (ISBN 0-7897-2273-9). The book is much like this HOWTO, just more details, and a lot more of everything. It has also been translated to Polish and published as <em/DNS i BIND/ by Helion (<url url="http://helion.pl/ksiazki/dnsbin.htm">, ISBN 83-7197-446-9). Now in 4th edition is <em/DNS and BIND/ by Cricket Liu and P. Albitz from O'Reilly & Associates (ISBN 0-937175-82-X, affectionately known as the Cricket book). Another book is <em/Linux DNS Server Administration/, by Craig Hunt, published by Sybex (ISBN 0782127363), I have not read it yet. Another must for good DNS administration (or good anything for that matter) is <em/Zen and the Art of Motorcycle Maintenance/ by Robert M. Pirsig. --> <p>私は <em/The Concise Guide to DNS and BIND/ (by Nicolai Langfeldt, Que, ISBN 0-7897-2273-9) を書きました。この本はこの HOWTO と、とても似ていますが、 多少詳細に、そしてずっと幅広い話題を扱っています。 この本はポーランド語に翻訳され、Helion から <em/DNS i BIND/ として出版されています。 (<url url="http://helion.pl/ksiazki/dnsbin.htm">, ISBN 83-7197-446-9) C. Liu P. Albitz が書いた <em/DNS and BIND/ は、 今や第四版となりました (O'Reilly & Associates, ISBN 0-937175-82-X. バッタ本として知られています)。 また <em/Linux DNS Server Administration/ という本が Craig Hunt によって書かれ、Sybex から出版されています (ISBN 0782127363)。私はこれはまだ読んでいません。 良い DNS (その他なんでも) の管理者になるためには、 Robert M. Pirsig の <em/Zen and the Art of Motorcycle Maintenance/ も必読でしょう。 <p> 訳注: Langfeldt さんの本の日本語訳は、オーム社から <url url="http://www.ohmsha.co.jp/data/books/contents/4-274-06421-2.htm" name="『DNS & BIND 入門』"> というタイトルで出版されています。 オライリーの『DNS & BIND』の日本語版は、現在 <url url="http://www.oreilly.co.jp/BOOK/dns3/" name="第3版"> が出版されており、第4版も近々に発刊予定とのことです。 <!--O <p>Online you will find my book, along with tons of other books, available electronically as a subscription service at <url url="http://safari.informit.com/">. There is stuff on <url url="http://www.dns.net/dnsrd/"> (DNS Resources Directory), <url url="http://www.isc.org/bind.html">; A FAQ, a reference manual (the ARM should be enclosed in the BIND distribution as well) as well as papers and protocol definitions and DNS hacks (these, and most, if not all, of the RFCs mentioned below, are also contained in the BIND distribution). I have not read most of these. The newsgroup <url url="news:comp.protocols.tcp-ip.domains"> is about DNS. In addition there are a number of RFCs about DNS, the most important are probably the ones listed here. Those that have BCP (Best Current Practice) numbers are <em/highly recommended/. --> <p>オンラインでは、 私の本 (やその他の大量の本) を電子的に購読するサービスが <url url="http://safari.informit.com/"> にあります。 <url url="http://www.dns.net/dnsrd"> (DNS Resources Directory) や <url url="http://www.isc.org/bind.html"> でもいろいろ見つかります。 FAQ、リファレンスマニュアル、 論文やプロトコル定義や DNS のハックもあります (これらや、以下に示す RFC の (全部ではないにせよ) ほとんどは、 BIND の配布アーカイブに含まれています)。 私はこのあたりのほとんどは読んでいません。 ニュースグループ <htmlurl url="news:comp.protocols.tcp-ip.domains" name="comp.protocols.tcp-ip.domains"> では DNS の議論をしています。 また DNS に関する RFC もたくさん存在しています。 中でも重要なものを以下に挙げておきます。 BCP (Best Current Practice) の番号が付いているものは<em/必読/です。 <descrip> <tag/RFC 2671/ P. Vixie, <em/Extension Mechanisms for DNS (EDNS0)/ August 1999. <tag/RFC 2317/ BCP 20, H. Eidnes et. al. <em/Classless IN-ADDR.ARPA delegation/, March 1998. This is about CIDR, or classless subnet reverse lookups. <tag/RFC 2308/ M. Andrews, <em/Negative Caching of DNS Queries/, March 1998. About negative caching and the $TTL zone file directive. <tag/RFC 2219/ BCP 17, M. Hamilton and R. Wright, <em/Use of DNS Aliases for Network Services/, October 1997. About CNAME usage. <tag/RFC 2182/ BCP 16, R. Elz et. al., <em/Selection and Operation of Secondary DNS Servers/, July 1997. <tag/RFC 2052/ A. Gulbrandsen, P. Vixie, <em/A DNS RR for specifying the location of services (DNS SRV)/, October 1996 <tag/RFC 1918/ Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear, <em/Address Allocation for Private Internets/, 02/29/1996. <tag/RFC 1912/ D. Barr, <em/Common DNS Operational and Configuration Errors/, 02/28/1996. <tag/RFC 1912 Errors/ B. Barr <em/Errors in RFC 1912/. Only available at <url url="http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html"> <tag/RFC 1713/ A. Romao, <em/Tools for DNS debugging/, 11/03/1994. <tag/RFC 1712/ C. Farrell, M. Schulze, S. Pleitner, D. Baldoni, <em/DNS Encoding of Geographical Location/, 11/01/1994. <tag/RFC 1183/ R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, <em/New DNS RR Definitions/, 10/08/1990. <tag/RFC 1035/ P. Mockapetris, <em/Domain names - implementation and specification/, 11/01/1987. <tag/RFC 1034/ P. Mockapetris, <em/Domain names - concepts and facilities/, 11/01/1987. <tag/RFC 1033/ M. Lottor, <em/Domain administrators operations guide/, 11/01/1987. <tag/RFC 1032/ M. Stahl, <em/Domain administrators guide/, 11/01/1987. <tag/RFC 974/ C. Partridge, <em/Mail routing and the domain system/, 01/01/1986. </descrip> </article>