RFC1537 日本語訳
1537 Common DNS Data File Configuration Errors. P. Beertema. October 1993. (Format: TXT=19825 bytes) (Obsoleted by RFC1912) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Beertema Request for Comments: 1537 CWI Category: Informational October 1993
Beertemaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1537年のCWIカテゴリ: 情報の1993年10月
Common DNS Data File Configuration Errors
一般的なDNSデータファイル構成誤り
Status of this Memo
この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.
このメモはDNSデータファイルでしばしば見つけられた誤りについて説明します。 作って、それが、指摘する一般的な誤りシステム管理者が、傾向がある彼らは長期間の間、しばしば見つからずに済みます。
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.
大量のドキュメンテーションと自動化されたツールの不足のため、DNSゾーンファイルはシステム管理者によってほとんど構成されました、手で。 データファイルを書くための規則のいくつかがかなり微妙です、そして、いくつかの一般的な誤りが世界中のドメインで見られます。
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.
残念ながら、BINDでRFCといくつかの専門のドキュメントで手動で出された例はそれらの非常に短いタイマ値を与えます、そして、それはたぶん人々が彼らのSOA記録に倣ったことです。
First of all a short explanation of the timers used in the SOA record:
まずSOA記録で使用されるタイマの短い説明:
Beertema [Page 1] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[1ページ]RFC1537
- 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.
- リフレッシュします: プライマリサーバに関するSOA記録は「リフレッシュしてください」という毎回セカンダリサーバによってチェックされます。 変化したなら、ゾーン転送をします。
- 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).
- 最小のTTL: ゾーンファイルでのすべての記録のためのデフォルトTTL価値。 必要であるときに、記録で明らかに異なったTTL値を与えるかもしれません。 (このタイマは「最小限」と命名されます、そして、STD13によると、それはそれの機能が何であるかということであるべきです、RFC1035、しかし、デフォルト値が記録で明白なTTL値なしでエクスポートしたので、ほとんどの(すべて?)実装がそれを取ります。)
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
86400 ; 7200年の24時間、リフレッシュしてください。 再試行2時間2592000。 30日間、345600を吐き出してください。 最小のTTL4日間
For other servers I would suggest:
他のサーバのために、私は示すでしょう:
28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800 ; Expire 7 days
86400 ; Minimum TTL 1 day
28800 ; 7200年の8時間、リフレッシュしてください。 再試行2時間604800。 7日間、86400を吐き出してください。 最小のTTL1日
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)記録を自分達のゾーンファイルに入れます。 さらに悪いのは、私がプライマリゾーンファイルの外部のホストのために*間違った*接着剤記録を見さえしたということです! サーバー・ホストがゾーンの中にいて、そのホストへのA記録は全くゾーンファイルのほかの場所になければ、接着剤記録がゾーンファイルにあるだけでよいです。
Beertema [Page 2] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[2ページ]RFC1537
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.
古いBINDバージョン(「ネイティブ4.8」.3と旧式のバージョン)は間違った接着剤記録がゾーン転送にセカンダリサーバを入れるかもしれないという問題を示しました。
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!
私は、それがホストが理由を知らないでネームサーバ要求で砲撃させた様々な時に起こるのを見ました。 調査のときに、その時そのようなホストは何らかのドメイン((コネ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.
より新しいBINDバージョン(4.9以降)はこの問題を解決しました。 同じくらいでは、フィックスですが、時間はこの問題を見つけるのがはるかに簡単でない不都合を持っています。
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.
習慣は、ほとんどのドメインレジストラが、プライマリ(!)とセカンダリサーバが用意ができていたかどうかチェックすることのないネームサーバの登録証明書が上がる、知識がある、または尋ねられさえすると受け入れるのを示しました。 また、プライマリネームサーバの持続的な「非-可到達性」の組み合わせ((したがって、)ゾーン情報、および静的なIPルーティングの満了)が系列を完全に満たすことができる大規模なネットワークトラフィックに通じることができることに注意されるべきです。
4. "MX records surprise"
4. 「MX記録驚き」
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.
3を指すためにある意味で同様です。 時々、ネームサーバマネージャは外部のホストを示すそれらのゾーンファイルでの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).
時々、1つは奇妙な名前に遭遇します。(名前は局所領域で広げられた外部名であるように見えます)。 ドットの名前を終えるのを忘れることによって、これは引き起こされます: ドットで終わらないゾーンファイルの名前はいつも現在のゾーン(ゾーンファイルが表すドメインか最後の$ORIGIN)の名前で広げられます。
Example: zone file for foo.xx:
例: foo.xxのためのゾーンファイル:
pqr MX 100 relay.yy. xyz MX 100 relay.yy (no trailing dot!)
pqr MX100relay.yy xyz MX100relay.yy(引きずっているドットがありません!)
Beertema [Page 3] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[3ページ]RFC1537
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!)
pqr.foo.xx。 MX100relay.yy xyz.foo.xx。 MX100relay.yy.foo.xx。 (名前拡大!)
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.
そこに、いてください。それが必要である、それ、ドメインへの最少の2つのネームサーバ。 明白な理由によって、トップ・レベル・ドメインへのネームサーバは、インターネットから非常によく届く必要があります。 これは、ちょうどそれらの2つ以上があるに違いないのを含意します。 そのうえ、(セカンダリ)のサーバの大部分は「戦略」の位置に置かれるべきです、例えば、国際的な、そして/または、大陸間な系列が集まるポイントの近くで。 事態を処理しやすく保つために、ドメインへのあまりに多くのサーバがあるべきではありません。
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.
プライマリの、そして、セカンダリのサーバの位置を選択することにおける重要な一面は、信頼性(ネットワーク、ホスト)と好都合な接触です: 問題の場合には、すばやく変化/フィックスを行わなければなりません。 ヨーロッパのトップ・レベル・ドメインへのプライマリサーバがヨーロッパでホストで走るべきであるのは論理的であると考えられるべきです、望ましくは(できれば)国自体で。 各トップ・レベル・ドメインには、2つのセカンダリサーバがヨーロッパにあるべきです、そして、もちろんさらにどちらかにあるかもしれない2に面があります。 もっとも、過度の数のネームサーバは名案ではありません。 お勧めの最大は7つのネームサーバです。 ヨーロッパでは、EUnetが、それぞれのヨーロッパのトップ・レベル・ドメインにセカンダリサーバを実行すると申し出ました。
7. Wildcard MX records
7. ワイルドカードMX記録
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:
ワイルドカードMX記録は可能であるところで避けられるべきです。 彼らはしばしば混乱と誤りを引き起こします: 特に始まっているネームサーバマネージャは、どんなタイプに関する記録もゾーンファイルにある状態で記載されたホスト/ドメインがそのゾーンで総合的なワイルドカードMX記録でカバーされていないという事実を見落とす傾向があります。 これは簡単なドメイン/ホスト名に行くだけではなく、1つ以上のドメインをカバーする名前にも行きます。 ゾーンfoo.barの以下の例を取ってください:
* MX 100 mailhost
pqr MX 100 mailhost
abc.def MX 100 mailhost
* MX100mailhost pqr MX100mailhost abc.def MX100mailhost
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記録はそれらのNONE、およびそれらの下の何でもカバーしています。 MX記録ですべてをカバーするために、必要なエントリーは以下の通りです。
Beertema [Page 4] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[4ページ]RFC1537
* 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
* MX100mailhost pqr MX100mailhost*.pqr MX100mailhost abc.def MX100mailhost*.def MX100mailhost*.abc.def MX100mailhost
An overall wildcard MX record is almost never useful.
総合的なワイルドカードMX記録はほとんど役に立ちません。
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.
特に、トップ・レベル・ドメインのゾーンファイルは総合的なワイルドカードMX記録(*.XX)だけを決して、含むはずがありません。 そのようなワイルドカードMX記録の効果はことによると高価なリンクの向こう側に不必要にメールを送りますが、記録が示す目的地かゲートウェイで失敗するということであるかもしれません。 トップ・レベル・ドメインゾーンファイルは明らかに少なくともすべての公式に登録されたプライマリサブドメインをリストアップするはずです。
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).
総合的なワイルドカードMX記録は避けられるべきですが、ワイルドカードMX記録はサブドメインエントリーの明白な部分として許容できます、それらが与えられたサブドメイン(命名権威でそのドメインに決定する)の下で許容されているなら。
Example:
例:
foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
*.foo.xx. MX 100 gateway.xx.
MX 200 fallback.yy.
8. Hostnames
foo.xx。 MX100gateway.xx。 MX200fallback.yy。 *.foo.xx。 MX100gateway.xx。 MX200fallback.yy。 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.
人々は、時々単にSTD11(特定のホスト名が正しいかどうか決定するRFC822)を見るように見えます。 ホスト名は厳密にSTD13で与えられた構文に従うべきです、RFC1034(11ページ)、*アドレス*がさらに、RFC822に従っていて。 例として、RFC822によると、完全に法的ですが、Unixシステムの上に特定のシステムへのかなり驚異的な効果、例えば、「telnet cとw.ブルース」を持つことができる「cとw.ブルース」を取ってください。
9. HINFO records
9. HINFO記録
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記録のデータ・フィールド(通常2番目の分野)の1つがそうである一般的な誤解はあるように見えます。任意。 1つの国だけのすべての届いているネームサーバの最近のスキャンはおよそ300の不完全なHINFO記録を明らかにしました。 データがHINFO記録でさばく指定twoは義務的ですが(RFC1033)、これが*ではなく、*をするというメモは、HINFO記録自体が義務的であることを意味します。
Beertema [Page 5] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[5ページ]RFC1537
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のための質問と放送演説です。 そのような質問を捕らえるために、あらゆるネームサーバが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.
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_ドメイン」に、何らかのソフトウェアがそれ自体に接続することを使用したがっていなかったとき、ループバックインタフェースを使用することで引き起こす場合があります。
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.
ドット付き10進法でSerial番号を与えている(例えば、SCCSはいつファイルを保守するのに使用されますか)ゾーンファイルを保守している人々はすべてのBINDバージョンでバグに注意するべきです: 通し番号がRelease.Version(ドット付き10進法)記法であるなら、より高いリリースに変化するのは実際には不可能です: 記法が整数に変えられる間違った方法のために、それは前のリリースのものよりLOWERである通し番号をもたらします。
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.
この理由、STD13、RFC1035に従ってSerialが(未署名)の整数であるので、ドット付き10進法を使用しないのはお勧めです。 お勧めの記法が日付(yyyymmdd)を使用することであり、必要なら付加的なケタで、そこであるなら、(yyyymmddn)は、あるか、ゾーンファイルの日あたり1回以上の変化であるかもしれません。
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
ドメイン名でA記録のための質問を引き起こすバグがDNSレゾルバコードの非常に古いバージョンで好きである、「192.16 .184 碁のアウトへの0.3インチ」 ユーザがIPアドレスをタイプするとき、これは起こります、そして、DNS質問を出す前に、レゾルバコードは本件を捕らえません。 私たちにとって知られているすべてのレゾルバ実装でこの問題を修正してありますが、まだ急に現れているなら、それらのすべての質問が許可していた状態で望んでいるので、非常に重大です。
Beertema [Page 6] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[6ページ]RFC1537
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.
トップ・レベル・ドメインを探す根のサーバは「3インチなど」が好きです。 それがこれらと他の問題を取り除くために最新(公的である)の利用可能なBINDバージョンとすべての利用可能なパッチをインストールすることが強く勧められます。
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.
本当に必要でない場合、別のセカンダリネームサーバにセカンダリネームサーバを流出するのは、可能であって、しかし、お勧めではありません: それがにせのTTL値のような問題を引き起こしたケースは知られています。 これは、より古いか失敗する実装によって引き起こされる場合がありますが、セカンダリネームサーバは原則として公式のプライマリネームサーバからそれらのゾーンをいつも移すべきです。
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.
コントロールを及ぼすか、または政治を課すことを何らかの方法で意味するのではなく、ドメインネームシステムとネームサーバは純粋に技術的なツールです。 命名権威の機能はクリアリングハウスのものです。 特定(最高レベル)のドメインの下でサブドメインを登録するだれでもそのほかに権威を命名するようになります。そのサブドメインに原因となるしたびらめ。 したがって、次の、より高いドメインの記録係はいつもそのようなサブドメインに関してMXかNS記録を入力するという要求を光栄に思わなければなりません。
Examples of practices that are not allowed are:
許容されていない習慣に関する例は以下の通りです。
- imposing specific mail routing (MX records) when registering
a subdomain.
- サブドメインを登録するとき、特定のメールルーティング(MX記録)を課します。
- 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を登録しようとする12月を考えてください)。
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
あります、また、ケースは1つが人の権威を調べなければならないということでした: アプリケーションを送ります--すべてのシステム・マネージャはどんな全体の大学のためにドメイン名を登録できないべきです。 サブドメインの記録係の権利と関心と違反しないか、または衝突しない限り、命名権威はある余分な規則を課すことができます。 トップ・レベル・ドメインの記録係が必要であるかもしれません、例えば、そこでそれを必要としてください。
Beertema [Page 7] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[7ページ]RFC1537
be primary subdomain "ac" and "co" only and that subdomains be registered under those primary subdomains.
そして、"ac"という第一のサブドメインになってください、「共同、」、唯一、そして、サブドメインはそれらの第一のサブドメインの下で登録されます。
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.
また、あるものが、ネームサーバゾーンからのドメインのエントリーがファイルされるとポイント4、例えば、一時取り外すことによって言及したように命名権威は例外的なケースに干渉できます。 極端な注意だけと切り札としてだけもちろんこれをするべきです。
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:
サブドメインのためのNS記録を加えるとき、トップ・レベル・ドメインのネームサーバマネージャは、サブドメインのためにネームサーバをセットアップしている人々がしばしばかなり未経験であるとわかるべきであり、容易に完全に手が届かなくなるサブドメインにつながることができる場合があるか、または不要なDNSを引き起こす場合がある誤りを交通にすることができます(点1がわかってください)。 したがって、そのようなNS記録を入力する前に(トップレベル)ネームサーバマネージャが新しいネームサーバにおける2、3の健全度チェックをするのは、非常にお勧めです。(SOA記録とタイマOK(MXは必要であるところにプレゼントを記録します) 誤りはされませんでしたか?明白な 操作上でセカンダリサーバを記載しましたか?). もっともそのようなチェックで捕らえることができないものは以下の通りです。
- 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).
また、2文字のサブドメインを登録するとき、注意するべきです。 これは許容されていますが、含意は簡略化されたアドレシング(STD11、RFC822、パラグラフ6.2.2を見る)がサブドメインとそのサブドメインの下で可能でないということです。 そのようなドメインを登録するよう要求されているとき、いつもこの結果について人々に通知するべきです。 例として、コンピュータScience部に一般的に使用される名前「Cs」を取ってください: また、それがCzecho-スロバキアへのトップ・レベル・ドメインの名前であるので、コネがCzecho-スロバキアのホスト「ホスト」でホストhost.cs.foo.barの上のユーザとユーザの両方を指示できるので、ドメインcs.foo.barの中では、 user@host.cs はあいまいです。 (この例は言及された国の最近の政変を考慮に入れません。)
References
参照
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
RFC 1034, USC/Information Sciences Institute, November 1987.
[1]Mockapetrisと、P.と、「ドメイン名概念と施設」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[2] Mockapetris, P., "Domain Names Implementation and Specification",
STD 13, RFC 1035, USC/Information Sciences Institute, November
1987.
[2]Mockapetrisと、P.と、「ドメイン名実現と仕様」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
Beertema [Page 8] RFC 1537 Common DNS Data File Configuration Errors October 1993
DNSデータファイル構成誤り1993年10月に一般的なBeertema[8ページ]RFC1537
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
974, CSNET CIC BBN, January 1986.
[3] ヤマウズラと、C.と、「メールルート設定とドメインシステム」、STD14、RFC974、CSNET CIC BBN、1月1986日
[4] Gavron, E., "A Security Problem and Proposed Correction With
Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
October 1993.
[4] Gavronと、E.と、「広く配備されたDNSソフトウェアとの警備上の問題と提案された修正」(RFC1535)は研究株式会社(1993年10月)を負かします。
[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.
[5] クマー、A.、ポステル、J.、ヌーマン、C.、ダンツィグ、P.、およびS.ミラー、「一般的なDNS実現誤りの、そして、提案されたフィックス」、RFC1536、科学が設けるUSC/情報、USC、1993年10月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Piet Beertema CWI Kruislaan 413 NL-1098 SJ Amsterdam The Netherlands
ピートBeertema CWI Kruislaan413NL-1098 SJアムステルダムオランダ
Phone: +31 20 592 4112 FAX: +31 20 592 4199 EMail: Piet.Beertema@cwi.nl
以下に電話をしてください。 +31 20 592 4112Fax: +31 20 592 4199はメールされます: Piet.Beertema@cwi.nl
Editor's Address
エディタのアドレス
Anant Kumar USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey CA 90292-6695
AnantクマーUSC情報科学は4676の海軍省方法でマリーナデル・レイカリフォルニア90292-6695を設けます。
Phone:(310) 822-1511 FAX: (310) 823-6741 EMail: anant@isi.edu
電話: (310) 822-1511 ファックスで以下を送ってください。 (310) 823-6741 メールしてください: anant@isi.edu
Beertema [Page 9]
Beertema[9ページ]
一覧
スポンサーリンク
