この文書はRFC1537の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group P. Beertema
Request for Comments: 1537 CWI
Category: Informational October 1993
Common DNS Data File Configuration Errors
よくあるＤＮＳデータファイルの設定誤り
Status of this Memo
この文書の状態
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
このメモはインターネット共同体のための情報を供給します。これはインター
ネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This memo describes errors often found in DNS data files. It points
out common mistakes system administrators tend to make and why they
often go unnoticed for long periods of time.
このメモはＤＮＳデータファイルにしばしばあるエラーを記述します。これ
はシステム管理者がする傾向がある普通のミスと、システム管理者がしばし
ば長期間気付かない理由を指摘します。
Introduction
はじめに
Due to the lack of extensive documentation and automated tools, DNS
zone files have mostly been configured by system administrators, by
hand. Some of the rules for writing the data files are rather subtle
and a few common mistakes are seen in domains worldwide.
広範囲の文書と自動化ツールの欠如のために、ＤＮＳゾーンファイルがたい
てい、システム管理者によって手で設定されます。データファイルを書くた
めのある規則のどちらかと言うと微妙で、そして少数の一般的ミスが世界的
にあちこちのドメインであります。
This document is an attempt to list "surprises" that administrators
might find hidden in their zone files. It describes the symptoms of
the malady and prescribes medicine to cure that. It also gives some
general recommendations and advice on specific nameserver and zone
file issues and on the (proper) use of the Domain Name System.
この文書は管理者がゾーンファイル内で発見すするかもしれない「驚き」を
リストアップする試みです。これは弊害の症状を記述して、それを直すため
に薬を処方します。これはあるネームサーバとゾーンファイル問題とドメイ
ンネームシステムの（適切な）使用の一般的な推薦とアドバイスを与えます。
1. SOA records
1. SOAレコード
A problem I've found in quite some nameservers is that the various
timers have been set (far) too low. Especially for top level domain
nameservers this causes unnecessary traffic over international and
intercontinental links.
いくつかのネームサーバで見つけた問題は種々なタイマーがあまりにも小さ
く設定されていることです。特に最上位ドメインネームサーバのこれは国際
的大陸間リンクに不必要なトラフィックを起こします。
Unfortunately the examples given in the BIND manual, in RFC's and in
some expert documents give those very short timer values, and that's
most likely what people have modeled their SOA records after.
不幸にもＢＩＮＤマニュアルやＲＦＣやいくつかの専門文書で与えられた例
は非常に短いタイマー値を与え、人々がたいていの場合これでＳＯＡレコー
ドを設計したことです。
First of all a short explanation of the timers used in the SOA
record:
まず第一にＳＯＡレコードで使われたタイマーの短い説明をします：
- Refresh: The SOA record of the primary server is checked
every "refresh" time by the secondary servers;
if it has changed, a zone transfer is done.
- リフレッシュ：プライマリサーバーのＳＯＡレコードはすべて
の「リフレッシュ」時間毎にセカンダリサーバーによっ
てチェックされます；もしそれが変化したなら、ゾー
ン転送がされます。
- Retry: If a secondary server cannot reach the primary
server, it tries it again every "retry" time.
- 再送：もしセカンダリサーバーがプライマリサーバーと連絡を
取れなければ、「再送」時間毎に再送します。
- Expire: If for "expire" time the primary server cannot
be reached, all information about the zone is
invalidated on the secondary servers (i.e., they
are no longer authoritative for that zone).
- 期限切れ：もし「期限切れ」時間までプライマリサーバーに連
絡を取らないなら、すべてのゾーン情報がセカンダリ
サーバーで無効にされます（すなわちもうその地域の
権威ではない）。
- Minimum TTL: The default TTL value for all records in the
zone file; a different TTL value may be given
explicitly in a record when necessary.
(This timer is named "Minimum", and that's
what it's function should be according to
STD 13, RFC 1035, but most (all?)
implementations take it as the default value
exported with records without an explicit TTL
value).
- 最小ＴＴＬ：ゾーンファイルのすべてのレコードのデフォルト
ＴＴＬ値；異なったＴＴＬ値が必要な時、レコー
ドで明示的に与えられるかもしれません。（この
タイマーは「最小」と命名され、この機能はＳＴ
Ｄ１３、RFC1035によればその名の通りの機能で
すが、大部分の（全部の？）実装で明示的にＴＴ
Ｌを指定しない場合のデフォルトＴＴＬ値と扱い
ます）。
For top level domain servers I would recommend the following values:
最上位ドメインサーバーのために私は次の値を推薦します：
86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000 ; Expire 30 days
345600 ; Minimum TTL 4 days
For other servers I would suggest:
他のサーバーのために私は以下を提案します：
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day
but here the frequency of changes, the required speed of propagation,
the reachability of the primary server etc. play a role in optimizing
the timer values.
しかし変更の頻度や、普及に必要なスピードや、プライマリサーバーの到達
可能性などでタイマー値を最適化します。
2. Glue records
2. 接着剤レコード
Quite often, people put unnecessary glue (A) records in their zone
files. Even worse is that I've even seen *wrong* glue records for an
external host in a primary zone file! Glue records need only be in a
zone file if the server host is within the zone and there is no A
record for that host elsewhere in the zone file.
非常にしばしば、人々がゾーンファイルに不必要な接着剤(A)レコードを入れ
ました。最悪の場合、プライマリゾーンファイルで外部ホストの＊間違った
＊接着剤レコードを見たこともあります！接着剤レコードが必要なのは、も
しサーバーホストがゾーン内にあり、そのゾーンファイル以外にそのホスト
のＡレコードがない場合だけです。
Old BIND versions ("native" 4.8.3 and older versions) showed the
problem that wrong glue records could enter secondary servers in a
zone transfer.
古いＢＩＮＤバージョン（「ネイティブ」４.８.３とより古いバージョン）
が間違った接着剤レコードをゾーン転送でセカンダリサーバーに送る問題を
示しました。
3. "Secondary server surprise"
3. 「セカンダリサーバー驚き」
I've seen it happen on various occasions that hosts got bombarded by
nameserver requests without knowing why. On investigation it turned
out then that such a host was supposed to (i.e., the information was
in the root servers) run secondary for some domain (or reverse (in-
addr.arpa)) domain, without that host's nameserver manager having
been asked or even been told so!
私はなぜか知わからないがネームサーバリクエストで攻めたてられてホスト
を様々な機会に偶然発見しました。調査の結果このようなホストは、ホスト
ネームサーバの管理者による言われていないのに、あるドメイン（又は逆引
きドメイン（in-addr.arpa)）のセカンダリに指名されていました（この情報
はルートサーバにある）！
Newer BIND versions (4.9 and later) solved this problem. At the same
time though the fix has the disadvantage that it's far less easy to
spot this problem.
新しいＢＩＮＤバージョン（４．９以降）がこの問題を解決しました。この
修正と同時にこの問題を監視することがはるかに難しくなります。
Practice has shown that most domain registrars accept registrations
of nameservers without checking if primary (!) and secondary servers
have been set up, informed, or even asked. It should also be noted
that a combination of long-lasting unreachability of primary
nameservers, (therefore) expiration of zone information, plus static
IP routing, can lead to massive network traffic that can fill up
lines completely.
たいていのドメイン登録係が習慣的に調査せずに、プライマリやセカンダリ
ネームサーバの登録を受け入れること（！）がわかりました。プライマリネー
ムサーバの長い切断と、（それ故に）ゾーン情報が期限切れとスタティック
ＩＰルーティングが、回線を一杯にする大規模なネットワークトラフィック
を導くことを指摘されるべきです。
4. "MX records surprise"
4. 「ＭＸレコード驚き」
In a sense similar to point 3. Sometimes nameserver managers enter MX
records in their zone files that point to external hosts, without
first asking or even informing the systems managers of those external
hosts. This has to be fought out between the nameserver manager and
the systems managers involved. Only as a last resort, if really
nothing helps to get the offending records removed, can the systems
manager turn to the naming authority of the domain above the
offending domain to get the problem sorted out.
ある意味でポイント３に類似しています。時々ネームサーバ管理者が、外部
ホストの管理者に知らせることなく、MXレコードを外部のホストを指定して
ゾーンファイルに設定します。これはネームサーバ管理者と巻き込まれたシ
ステム管理者間で戦って解決されなければなりません。ただ最後の手段とし
てだけ、もし本当に不快なレコードを除去する手段がないなら、システム管
理者は不快なドメインの権威にドメインの問題を解決するのを頼ることがで
きます。
5. "Name extension surprise"
5. 「名前拡張驚き」
Sometimes one encounters weird names, which appear to be an external
name extended with a local domain. This is caused by forgetting to
terminate a name with a dot: names in zone files that don't end with
a dot are always expanded with the name of the current zone (the
domain that the zone file stands for or the last $ORIGIN).
時々奇妙な名前に遭遇します、これはローカルドメインで拡張された外部名
と思われます。これは名前をドットで終了させることを忘れた場合に起きま
す：ドットで終わらないゾーンファイルでの名前が常に現在のゾーン名前
（ゾーンファイルが表すドメインあるいは最後の$ORIGIN ）で拡張されます。
Example: zone file for foo.xx:
例: zone file for foo.xx:
pqr MX 100 relay.yy.
xyz MX 100 relay.yy (no trailing dot!)
When fully written out this stands for:
完全な書き方をするとこうなります
pqr.foo.xx. MX 100 relay.yy.
xyz.foo.xx. MX 100 relay.yy.foo.xx. (name extension!)
6. Missing secondary servers
6. 行方不明のセカンダリサーバ
It is required that there be a least 2 nameservers for a domain. For
obvious reasons the nameservers for top level domains need to be very
well reachable from all over the Internet. This implies that there
must be more than just 2 of them; besides, most of the (secondary)
servers should be placed at "strategic" locations, e.g., close to a
point where international and/or intercontinental lines come
together. To keep things manageable, there shouldn't be too many
servers for a domain either.
ドメインに少なくとも２つのネームサーバが要求されます。明白な理由で最
上位ドメインのネームサーバはインターネット中から確実に到達可能である
必要があります。これは２つよりかなり多くがあるに違いないことを意味し
ます；その上、（セカンダリ）サーバーの大部分が「戦略的」場所に置かれ
るべきです、例えば、国際的や大陸間の回線がある場所の近くです。扱いや
すくするため、ドメインに対して多すぎるサーバーが存在すべきではありま
せん。
Important aspects in selecting the location of primary and secondary
servers are reliability (network, host) and expedient contacts: in
case of problems, changes/fixes must be carried out quickly. It
should be considered logical that primary servers for European top
level domains should run on a host in Europe, preferably (if
possible) in the country itself. For each top level domain there
should be 2 secondary servers in Europe and 2 in the USA, but there
may of course be more on either side. An excessive number of
nameservers is not a good idea though; a recommended maximum is 7
nameservers. In Europe, EUnet has offered to run secondary server
for each European top level domain.
プライマリとセカンダリサーバーの場所を選択する重要な観点は信頼性（ネッ
トワーク、ホスト）と接続のよさです：問題があった場合に変更／修理がす
ばやく実行されなくてはなりません。論理的に、ヨーロッパの最上位ドメイ
ンのプライマリサーバーがヨーロッパのホストであるべきで、なるべく(可能
なら）国その自身にあるべきです。それぞれの最上位ドメインで、アメリカ
合衆国とヨーロッパと２つづつセカンダリサーバがあるべきです、しかしい
ずれかにさらに多くあるかもしれません。ネームサーバの極端な数は良い考
えではありません；推薦された最大限は７つのネームサーバです。ヨーロッ
パで、EUnetはヨーロッパの各最上位ドメインのセカンダリサーバを動かそう
と申し出ました。
7. Wildcard MX records
7. ワイルドカードＭＸレコード。
Wildcard MX records should be avoided where possible. They often
cause confusion and errors: especially beginning nameserver managers
tend to overlook the fact that a host/domain listed with ANY type of
record in a zone file is NOT covered by an overall wildcard MX record
in that zone; this goes not only for simple domain/host names, but
also for names that cover one or more domains. Take the following
example in zone foo.bar:
ワイルドカードＭＸレコードは可能な限り避けるべきです。それらはしばし
ば混乱とエラーを起こします：特に初心者のネームサーバ管理者がゾーンファ
イル内の任意のタイプで示されるホスト／ドメイン名がゾーン全体のワイル
ドカードＭＸレコードの対象にならないという事実を見落とす傾向がありま
す；これは単純なドメイン／ホスト名でだけではなく、複数のドメインを対
称にする名前にも当てはまります。foo.barゾーンの次の例を見てください：
* MX 100 mailhost
pqr MX 100 mailhost
abc.def MX 100 mailhost
This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
domains, but the wildcard MX record covers NONE of them, nor anything
below them. To cover everything by MX records, the required entries
are:
これはpqr.foo.barとdef.foo.barとabd.def.foo.barを正当なドメインにしま
す、しかしワイルドカードＭＸレコードはこれらを対象にしません、以下の
同様です。ＭＸレコードで全てを対象にするのに必要な項目は以下です：
* MX 100 mailhost
pqr MX 100 mailhost
*.pqr MX 100 mailhost
abc.def MX 100 mailhost
*.def MX 100 mailhost
*.abc.def MX 100 mailhost
An overall wildcard MX record is almost never useful.
全体的ワイルドカードＭＸレコードがほとんどの場合に有用ではありません。
In particular the zone file of a top level domain should NEVER
contain only an overall wildcard MX record (*.XX). The effect of such
a wildcard MX record can be that mail is unnecessarily sent across
possibly expensive links, only to fail at the destination or gateway
that the record points to. Top level domain zone files should
explicitly list at least all the officially registered primary
subdomains.
特に最上位ドメインのゾーンファイルは決して全体的ワイルドカードＭＸレ
コードを含むべきではありません（*.XX）。このようなワイルドカードＭＸ
レコードの効果はメールが多分高価なリンク上で不必要に送られるが、結局
レコードが指し示す目的地あるいはゲートウェイに到達できないということ
です。最上位ドメインゾーンファイルが明示的に、少なくともすべての公式
に登録されたプライマリサブドメインをリストアップするべきです。
Whereas overall wildcard MX records should be avoided, wildcard MX
records are acceptable as an explicit part of subdomain entries,
provided they are allowed under a given subdomain (to be determined
by the naming authority for that domain).
全体的ワイルドカードＭＸレコードが避けられるべきであるが、ワイルドカー
ドＭＸレコードはあるサブドメインの下で許されるなら（そのドメインの命
名権威が決定する）、サブドメイン項目の明白な部分として受容できます。
Example:
例：
foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
*.foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
8. Hostnames
8. ホスト名
People appear to sometimes look only at STD 11, RFC 822 to determine
whether a particular hostname is correct or not. Hostnames should
strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
with *addresses* in addition conforming to RFC 822. As an example
take "c&w.blues" which is perfectly legal according to RFC 822, but
which can have quite surprising effects on particular systems, e.g.,
"telnet c&w.blues" on a Unix system.
人々が特定のホスト名が正しいかどうか決定するために時々ＳＴＤ１１、
RFC822をだけ見るように思われます。ホスト名が厳密にＳＴＤ１３、RFC1034
（ページ１１）、で与えられた構文に従うべきで、＊アドレス＊がさらに
RFC822に従うべきです。例えば"c&w.blues"はRFC822に従えば完全に正しいが、
特定システムに対して非常に驚くべき効果を持ちます、例えばＵＮＩＸシス
テム上で"telnet c&w.blues"としてください。
9. HINFO records
9. ホスト情報レコード
There appears to be a common misunderstanding that one of the data
fields (usually the second field) in HINFO records is optional. A
recent scan of all reachable nameservers in only one country revealed
some 300 incomplete HINFO records. Specifying two data fields in a
HINFO record is mandatory (RFC 1033), but note that this does *not*
mean that HINFO records themselves are mandatory.
HINFOレコードでのデータフィールドの１つ（通常２番目のフィールド）が任
意であると間違って理解するのがよくあるように思われます。ひとつの国だ
けで到達可能な全てのネームサーバを調査したところ、およそ３００の不完
全なHINFOレコードがありました。HINFOレコードで２つのデータフィールド
を指定するのは必須ですが(RFC 1033)、これはHINFOレコード自身が必須であ
る事を意味しません。
10. Safety measures and specialties
10. 安全基準と専門
Nameservers and resolvers aren't flawless. Bogus queries should be
kept from being forwarded to the root servers, since they'll only
lead to unnecessary intercontinental traffic. Known bogus queries
that can easily be dealt with locally are queries for 0 and broadcast
addresses. To catch such queries, every nameserver should run
primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
files need only contain a SOA and an NS record.
ネームサーバとリゾルバは完ぺきではありません。にせの問合せが、不必要
な大陸間のトラフィックを導かないように、ルートサーバーに転送されるこ
とから保護されるべきです。容易にローカルに発生する既知のにせの問い合
わせは０とブロードキャストアドレスです。このような質問を捉えるために、
すべてのネームサーバが0.in - addr.arpaと255.in-addr.arpaゾーンのプラ
イマリとして稼働すべきです；ゾーンファイルはSOAとNSレコードを含んでい
ることが必要なだけです。
Also each nameserver should run primary for 0.0.127.in-addr.arpa;
that zone file should contain a SOA and NS record and an entry:
同じく各ネームサーバが0.0.127.in-addr.arpa;のプライマリとして動作すべ
きです；そのゾーンファイルはSOAとNSレコードと以下の項目を含むべきです：
1 PTR localhost.
There has been extensive discussion about whether or not to append
the local domain to it. The conclusion was that "localhost." would be
the best solution; reasons given were:
それにローカルドメインを追加すべきかどうかの大規模な論議がありました。
結論は"localhost."が最も良い解決という事でした、与えられた理由が以下
でした：
- "localhost" itself is used and expected to work on some systems.
- "localhost"自身が利用されていて、あるシステムで期待されてます。
- translating 127.0.0.1 into "localhost.my_domain" can cause some
software to connect to itself using the loopback interface when
it didn't want to.
- 127.0.0.1を"localhost.my_domain"に変換すると、そうと望まないのに
loopbackインタフェースを使うあるソフトウェアがそこに接続すること
がありえます。
Note that all domains that contain hosts should have a "localhost" A
record in them.
ホストを含むすべてのドメインでその中に"localhost"Aレコードを含むべき
ことに注意してください。
People maintaining zone files with the Serial number given in dotted
decimal notation (e.g., when SCCS is used to maintain the files)
should beware of a bug in all BIND versions: if the serial number is
in Release.Version (dotted decimal) notation, then it is virtually
impossible to change to a higher release: because of the wrong way
that notation is turned into an integer, it results in a serial
number that is LOWER than that of the former release.
小数点付きでゾーンファイルを管理する人々は（例えば、 SCCSでファイルを
保守する時）、全ＢＩＮＤバージョンのバグに用心するべきである：もし通
し番号がRelease.Version （小数点表記）なら、高いリリースに変更するの
は事実上不可能です：それを整数に変換する間違った方法のために、結果的
に前のリリースより低いシリアル番号をもたらします。
For this reason and because the Serial is an (unsigned) integer
according to STD 13, RFC 1035, it is recommended not to use the
dotted decimal notation. A recommended notation is to use the date
(yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
or can be more than one change per day in a zone file.
この理由とシリアル番号が（符号なし）整数であるからＳＴＤ１３、
RFC1035に従って少数点表記を使わないことが勧められます。推薦された記述
は日付(yyyymmdd)で、１日に１回以上変更がありもし余分の桁が必要なら
(yyymmddn)を使う事です。
Very old versions of DNS resolver code have a bug that causes queries
for A records with domain names like "192.16.184.3" to go out. This
happens when users type in IP addresses and the resolver code does
not catch this case before sending out a DNS query. This problem has
been fixed in all resolver implementations known to us but if it
still pops up it is very serious because all those queries will go to
the root servers looking for top level domains like "3" etc. It is
strongly recommended to install the latest (publicly) available BIND
version plus all available patches to get rid of these and other
problems.
ＤＮＳリゾルバコードの非常に古いバージョンにバグがあり、"192.16.184.3"
の様なドメイン名でＡレコードの問合せを起こします。これは、ユーザーが
ＩＰアドレスをタイプし、リゾルバコードがＤＮＳ問合せを送る前にこれに
気づかないときにおきます。この問題はすべての我々の知っているリゾルバ
実装で直っていますが、もしそれがまだ起きる"3"などの最上位ドメインを探
すためルートサーバーに問合せが行くであろうから、非常に重大です。これら
や他の問題を除くため、最新の（公式）利用可能なＢＩＮＤバージョンとすべ
ての利用可能なパッチとをインストールすることが強く勧められます。
Running secondary nameserver off another secondary nameserver is
possible, but not recommended unless really necessary: there are
known cases where it has led to problems like bogus TTL values. This
can be caused by older or flawed implementations, but secondary
nameservers in principle should always transfer their zones from the
official primary nameserver.
セカンダリネームサーバからセカンダリネームサーバを動かすことは、本当
に必要でなら可能ですが、推薦されません：それがにせのＴＴＬ値のような
問題に導いた周知のケースがあります。これはもっと古いか欠陥がある実装
で起きますが、原則的にセカンダリネームサーバが常に公式のプライマリネー
ムサーバからゾーンを得るべきです。
11. Some general points
11. ある一般的問題
The Domain Name System and nameserver are purely technical tools, not
meant in any way to exert control or impose politics. The function of
a naming authority is that of a clearing house. Anyone registering a
subdomain under a particular (top level) domain becomes naming
authority and therewith the sole responsible for that subdomain.
Requests to enter MX or NS records concerning such a subdomain
therefore always MUST be honored by the registrar of the next higher
domain.
ドメインネームシステムとネームサーバは純粋な技術的道具で、制御をした
りポリシーを課すことを意図していません。命名権威機能はクリアリングハ
ウスと同じです。最上位ドメイン下にあるサブドメインを登録をしてる人は
命名権威になり、サブドメインの唯一の責任者です。従って サブドメインの
最上位のＭＸやＮＳレコードについて登録係は重んじなければなりません。
Examples of practices that are not allowed are:
認められない習慣の例が以下です：
- imposing specific mail routing (MX records) when registering
a subdomain.
- サブドメインを登録する時、特定のメールルーティング（ＭＸレコー
ド）を押し付けます。
- making registration of a subdomain dependent on to the use of
certain networks or services.
- ある特定のネットワークやサービスの利用に依存してサブドメインの
登録します。
- using TXT records as a means of (free) commercial advertising.
- TXTレコードを（自由な）コマーシャル広告手段として用います。
In the latter case a network service provider could decide to cut off
a particular site until the offending TXT records have been removed
from the site's zone file.
後の事例でネットワークサービスプロバイダが、不快なTXTレコードがサイト
のゾーンファイルから取り除かれるまで、特定のサイトを切断すると決める
ことができます。
Of course there are obvious cases where a naming authority can refuse
to register a particular subdomain and can require a proposed name to
be changed in order to get it registered (think of DEC trying to
register a domain IBM.XX).
もちろん命名権威が特定のサブドメインの登録を拒否し、登録できる名前に
申込むだ名前を変更するように要求できる明白な場合があります（ＤＥＣが
ドメインIBM.XXを登録しようとした場合）。
There are also cases were one has to probe the authority of the
person: sending in the application - not every systems manager should
be able to register a domain name for a whole university. The naming
authority can impose certain extra rules as long as they don't
violate or conflict with the rights and interest of the registrars of
subdomains; a top level domain registrar may e.g., require that there
be primary subdomain "ac" and "co" only and that subdomains be
registered under those primary subdomains.
権威の人を探さなければならない場合があります：アプリケーションを使っ
て−すべてのシステムマネージャーが大学全体のドメイン名を登録可能であ
るべきではありません。命名権威は、違反がないように、権利を侵害しない
ように、サブドメインの登録理由にあうように、特定の余分の規則を課すこ
とができます；最上位ドメイン登録係がしてもよい例は、第１のサブドメイ
ンが"ac"と"co"だけで、サブドメインが第１サブドメイン下に登録されるこ
とを要求する事です。
The naming authority can also interfere in exceptional cases like the
one mentioned in point 4, e.g., by temporarily removing a domain's
entry from the nameserver zone files; this of course should be done
only with extreme care and only as a last resort.
命名権威は同じくポイント４で言ったような特別の事例に干渉できます、例
えば、一時的にドメインの項目をネームサーバゾーンファイルから取り除く
ことです、これはもちろん極限の注意を払ってそして最後の手段としてだけ
だけされるべきです。
When adding NS records for subdomains, top level domain nameserver
managers should realize that the people setting up the nameserver for
a subdomain often are rather inexperienced and can make mistakes that
can easily lead to the subdomain becoming completely unreachable or
that can cause unnecessary DNS traffic (see point 1). It is therefore
highly recommended that, prior to entering such an NS record, the
(top level) nameserver manager does a couple of sanity checks on the
new nameserver (SOA record and timers OK?, MX records present where
needed? No obvious errors made? Listed secondary servers
operational?). Things that cannot be caught though by such checks
are:
サブドメインのためＮＳレコードを追加するとき、最上位ドメインネームサー
バ管理者はネームサーバをサブドメインに設置する人々がどちらかと言うと
未熟であり、容易に完全に到達不可能なサブドメインを作り、不必要なＤＮ
Ｓトラフィックを起こしすミスができる事を悟るべきです（ポイント１参照
）。従ってＮＳレコードを登録する前に（最上位）ネームサーバ管理者は新
しいネームサーバの２つのチェックをすることが大いに勧められます。（Ｓ
ＯＡレコードとタイマーに問題がないか？必要なＭＸレコードは存在してい
るか？された明白なエラーはありませんか？使用可能なセカンダリサーバを
リストアップします？）。このようなチェックで捕えられないものが以下で
す：。
- resolvers set up to use external hosts as nameservers
- リゾルバが外部ホストをネームサーバとして用いるように設定される。
- nameservers set up to use external hosts as forwarders
without permission from those hosts.
- ネームサーバが外部ホストの権限設定なしで、外部ホストを転送者に用
いる様に設定します。
Care should also be taken when registering 2-letter subdomains.
Although this is allowed, an implication is that abbreviated
addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
and under that subdomain. When requested to register such a domain,
one should always notify the people of this consequence. As an
example take the name "cs", which is commonly used for Computer
Science departments: it is also the name of the top level domain for
Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
ambiguous in that in can denote both a user on the host
host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
(This example does not take into account the recent political changes
in the mentioned country).
２ラベルサブドメインを登録するときに注意をすべきです。これが許される
が、省略アドレスがそのサブドメインで可能でありません（ＳＴＤ１１、
RFC822、６.２.２章参照）。このようなドメインを登録するように要求され
たときは、常にこの結果を通知するべきです。例えば、として一般に使われ
る名前"cs"をコンピュータサイエンス課のために登録した場合：これはチェ
コスロバキア(Czecho-Slovakia) の最上位ドメイン名で、cs.foo.barでのユー
ザuser@host.csがhost.cs.foo.barのユーザかチェコスロバキアのユーザかあ
いまいです。（この例はこの国の最近の政治的な変更を考慮していません）。
References
参考文献
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[2] Mockapetris, P., "Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[4] Gavron, E., "A Security Problem and Proposed Correction With
Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
October 1993.
[5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
"Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
USC/Information Sciences Institute, USC, October 1993.
Security Considerations
セキュリティの考慮
Security issues are not discussed in this memo.
セキュリティ問題がこのメモで論じられません。
Author's Address
著者のアドレス
Piet Beertema
CWI
Kruislaan 413
NL-1098 SJ Amsterdam
The Netherlands
Phone: +31 20 592 4112
FAX: +31 20 592 4199
EMail: Piet.Beertema@cwi.nl
Editor's Address
エディタのアドレス
Anant Kumar
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6741
EMail: anant@isi.edu