この文書はRFC1536の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group A. Kumar
Request for Comments: 1536 J. Postel
Category: Informational C. Neuman
ISI
P. Danzig
S. Miller
USC
October 1993
Common DNS Implementation Errors and Suggested Fixes
よくあるＤＮＳ実装誤りと修正の提案
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 common errors seen in DNS implementations and
suggests some fixes. Where applicable, violations of recommendations
from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
also describes, where relevant, the algorithms followed in BIND
(versions 4.8.3 and 4.9 which the authors referred to) to serve as an
example.
このメモはＤＮＳ実装でよくある誤りを記述して、ある修理を示唆します。
適用可能な場合は、標準１３のRFC1034と標準１３のRFC1035の推薦の違反を
述べます。メモは、適切な場合はＢＩＮＤ（著者はバージョン４.８.３と
４.９を参照）のアルゴリズムを役立つ例として記述します。
Introduction
はじめに
The last few years have seen, virtually, an explosion of DNS traffic
on the NSFnet backbone. Various DNS implementations and various
versions of these implementations interact with each other, producing
huge amounts of unnecessary traffic. Attempts are being made by
researchers all over the internet, to document the nature of these
interactions, the symptomatic traffic patterns and to devise remedies
for the sick pieces of software.
これまでの数年でNSFnetのバックボーン上で、事実上、ＤＮＳトラフィック
が爆発しました。種々なＤＮＳ実装とこれらの実装の種々なバージョンがお
互いと相互に作用し、莫大な不要なトラフィックを引き起こしてます。イン
ターネットの様々な場所で、相互作用の性質の文書化や、トラヒックの前兆
パターンや、問題のあるソフトウェアの修正が研究者されています。
This draft is an attempt to document fixes for known DNS problems so
people know what problems to watch out for and how to repair broken
software.
このドラフトは周知のＤＮＳ問題の修正を文書化する試みで、人々が何の問
題を警戒するべきで、どのように壊れたソフトウェアを修繕するべきかを知
らせます。
1. Fast Retransmissions
1. 早すぎる再送
DNS implements the classic request-response scheme of client-server
interaction. UDP is, therefore, the chosen protocol for communication
though TCP is used for zone transfers. The onus of requerying in case
no response is seen in a "reasonable" period of time, lies with the
client. Although RFC 1034 and 1035 do not recommend any
retransmission policy, RFC 1035 does recommend that the resolvers
should cycle through a list of servers. Both name servers and stub
resolvers should, therefore, implement some kind of a retransmission
policy based on round trip time estimates of the name servers. The
client should back-off exponentially, probably to a maximum timeout
value.
ＤＮＳが古典的なクライアント・サーバ型の要求と応答を実行します。ＴＣ
Ｐがゾーン転送に使われますが、ＵＤＰが通信に選ばれたプロトコルです。
回答が「合理的」な期間内に来ない場合に再送する責任はクライアントにあ
ります。RFC1034とRFC1035が再送方針を勧ず、RFC1035がリゾルバがサーバー
リストに従って順番に試みることを勧めます。従ってネームサーバーとスタ
ブリゾルバの両方がネームサーバの往復遅延時間の見積もりに基づいた数種
類の再送方針を実装するべきです。クライアントは指数関数的に最大のタイ
ムアウト値までタイムアウト時間を延ばすべきです。
However, clients might not implement either of the two. They might
not wait a sufficient amount of time before retransmitting or they
might not back-off their inter-query times sufficiently.
しかし、クライアントがどちらかを実装しないかもしれません。クライアン
トは再送前に十分待たないかもしれないし、再送間隔を伸ばさないかもしれ
ません。
Thus, what the server would see will be a series of queries from the
same querying entity, spaced very close together. Of course, a
correctly implemented server discards all duplicate queries but the
queries contribute to wide-area traffic, nevertheless.
その結果サーバーには非常に短い間隔で同じ要求者から同じ質問が続いてく
ることになります。もちろん、正確に実装されたサーバーがすべての重複の
問合せを捨てますが、問合せは大きなエリアトラフィックを生じます。
We classify a retransmission of a query as a pure Fast retry timeout
problem when a series of query packets meet the following conditions.
我々は早すぎる再送問題を一連の問合せパケットがどのように来るかで分類
します。
a. Query packets are seen within a time less than a "reasonable
waiting period" of each other.
a. 問合せパケットが「合理的な待つべき期間」よりも短い間隔で来る。
b. No response to the original query was seen i.e., we see two or
more queries, back to back.
b. 元の問合せい対する回答がなかった、すなわち複数の問合せが後から
後から来る。
c. The query packets share the same query identifier.
c. 問合せパケットは同じ問合せ識別子を共有する。
d. The server eventually responds to the query.
d. サーバーは結局は問合せに返答する。
A GOOD IMPLEMENTATION:
よい実装
BIND (we looked at versions 4.8.3 and 4.9) implements a good
retransmission algorithm which solves or limits all of these
problems. The Berkeley stub-resolver queries servers at an interval
that starts at the greater of 4 seconds and 5 seconds divided by the
number of servers the resolver queries. The resolver cycles through
servers and at the end of a cycle, backs off the time out
exponentially.
BIND（我々はバージョン４.８.３と４.９を見てます）がこれらすべての問題
を解くか、制限する良い再送アルゴリズムを実装します。バークレイスタブ
リゾルバは、４秒か５秒以上の秒数を問い合わせできるサーバーの数で割っ
た秒数を、最初の再送間隔として問合せをします。リゾルバはサーバーを順
番にます、１周すると指数関数的にタイムアウトを増やします。
The Berkeley full-service resolver (built in with the program
"named") starts with a time-out equal to the greater of 4 seconds and
two times the round-trip time estimate of the server. The time-out
is backed off with each cycle, exponentially, to a ceiling value of
45 seconds.
バークレイの完全なサービスをするリゾルバ（「named」プログラムで組み入
こみ）は４秒以上でサーバーの往復遅延時間の見積もりの２倍から始めます。
タイムアウトは４５秒を上限に１回毎に指数関数的に増やされます。
FIXES:
修正
a. Estimate round-trip times or set a reasonably high initial
time-out.
a. 往復遅延時間を推測するか、合理的な大きめの最初のタイムアウ
トを設定してください。
b. Back-off timeout periods exponentially.
b. 指数関数的に再送タイムアウト期間を増やします。
c. Yet another fundamental though difficult fix is to send the
client an acknowledgement of a query, with a round-trip time
estimate.
c. 他の基本的な難しい決定はクライアントに問合せを往復遅延時間
の評価のために返事することです。
Since UDP is used, no response is expected by the client until the
query is complete. Thus, it is less likely to have information about
previous packets on which to estimate its back-off time. Unless, you
maintain state across queries, so subsequent queries to the same
server use information from previous queries. Unfortunately, such
estimates are likely to be inaccurate for chained requests since the
variance is likely to be high.
ＵＤＰが使われるので、問合せが完全できないかぎり、クライアントに回答
が期待できません。そのため再送間隔を見積もるのにそれより前のパケット
の情報を使える可能性は低いです。同じサーバに対する昔の問合せを管理し
てなければ、今の問合せ情報で問合せを再送する事になります。不幸にも、
このような連続的な問合せの見積もりは分散が大きいので不正確である可能
性が高いです。
The fix chosen in the ARDP library used by Prospero is that the
server will send an initial acknowledgement to the client in those
cases where the server expects the query to take a long time (as
might be the case for chained queries). This initial acknowledgement
can include an expected time to wait before retrying.
ProsperoによるARDPライブラリで選択された修正派、サーバーが問合せで最
初の回答はサーバで時間がかかると考えることです（一連の問合せで正しい
と思われる）。この最初の回答の前は再送前に想定される時間さらに待ちま
す。
This fix is more difficult since it requires that the client software
also be trained to expect the acknowledgement packet. This, in an
internet of millions of hosts is at best a hard problem.
この修正はクライアントソフトウェアが応答パケットの予測訓練を要求する
のでより難しいです。何百万というホストのインターネットでの、これはと
ても難しい問題です。
2. Recursion Bugs
2. 再帰バグ
When a server receives a client request, it first looks up its zone
data and the cache to check if the query can be answered. If the
answer is unavailable in either place, the server seeks names of
servers that are more likely to have the information, in its cache or
zone data. It then does one of two things. If the client desires the
server to recurse and the server architecture allows recursion, the
server chains this request to these known servers closest to the
queried name. If the client doesn't seek recursion or if the server
cannot handle recursion, it returns the list of name servers to the
client assuming the client knows what to do with these records.
サーバーがクライアントの要求を受取る時、最初に問合せに答えるためゾー
ンデータとキャッシュを検索します。もし答えがどこにもなければ、サーバー
はキャッシュかゾーンデータから情報を持つ可能性が高いサーバーに回答を
求めます。そして次のどちらかをします。もしクライアントが再帰問合せを
サーバーに要望し、サーバが再帰を許すなら、サーバーは問合せられた名前
に最も近い既知サーバーに問合せをつなぎます。もしクライアントが再帰を
求めないなら、あるいはサーバーが再帰を処理できないなら、クライアント
がこれらのレコードに関して何をするべきか知っていると想定してクライア
ントにネームサーバのリストを返します。
The client queries this new list of name servers to get either the
answer, or names of another set of name servers to query. This
process repeats until the client is satisfied. Servers might also go
through this chaining process if the server returns a CNAME record
for the queried name. Some servers reprocess this name to try and get
the desired record type.
クライアントは他の答えを得るために、この新しいネームサーバリストを使
います。このプロセスは、クライアントが答えを得るまで繰り返します。サー
バーが問合せ名にCNAMEを返すなら、サーバは問合せ連鎖を起こすかもしれま
せん。あるサーバーが望ましいレコードタイプを得るためにこの名前を再処
理します。
However, in certain cases, this chain of events may not be good. For
example, a broken or malicious name server might list itself as one
of the name servers to query again. The unsuspecting client resends
the same query to the same server.
しかし、ある特定の場合、このイベントの連鎖は良くないかもしれません。
例えば、壊れているか悪意があるネームサーバーが自分自身を再度といわせ
るネームサーバのリストに入れるかもしれません。怪しまないクライアント
は同じサーバーに同じ質問を再送します。
In another situation, more difficult to detect, a set of servers
might form a loop wherein A refers to B and B refers to A. This loop
might involve more than two servers.
他の場合、検出がより難しいが、サーバ群が、ＡがＢを参照しＢがＡを参照
するなどと、ループを作るかもしれません。このループは２つ以上のサーバー
を巻き込むかもしれません。
Yet another error is where the client does not know how to process
the list of name servers returned, and requeries the same server
since that is one (of the few) servers it knows.
他の誤りは、クライアントは返送されたネームサーバのリストを処理するべ
きか知らず、知ってる少数のサーバの１ととして同じサーバに問合せるかも
しれません。
We, therefore, classify recursion bugs into three distinct
categories:
我々は、従って、３つの別のカテゴリーの中に再帰問題を分類します：
a. Ignored referral: Client did not know how to handle NS records
in the AUTHORITY section.
a. 参照の無視：クライアントがどのように権威セクションのネームサー
バレコードを処理するべきか知りませんでした。
b. Too many referrals: Client called on a server too many times,
beyond a "reasonable" number, with same query. This is
different from a Fast retransmission problem and a Server
Failure detection problem in that a response is seen for every
query. Also, the identifiers are always different. It implies
client is in a loop and should have detected that and broken
it. (RFC 1035 mentions that client should not recurse beyond
a certain depth.)
b. 多すぎる参照：「合理的」な回数以上のあまりに多くの回数同じ質問
をサーバーにするクライアント。これは、回答がすべての問合せに対
してあるという点で、早すぎる再送の問題とサーバ誤り検出問題と異
なります。また、識別子は常に異なります。これはクライアントがルー
プにはまっていて、それを発見しとめるすべきことを意味します。
（RFC1035はクライアントがある回数以上再帰問合せをすべきではない
と述べます。）
c. Malicious Server: a server refers to itself in the authority
section. If a server does not have an answer now, it is very
unlikely it will be any better the next time you query it,
specially when it claims to be authoritative over a domain.
c. 悪意あるサーバー：サーバーが権威セクションでそれ自身を参照しま
す。もしサーバーが今答えを持たないなら、次に問合せた時に答えを
持ってる可能性は少ないです、特にそれがドメインの権威である場合
はなおさらです。
RFC 1034 warns against such situations, on page 35.
RFC1034のページ３５に以下の警告があります。
"Bound the amount of work (packets sent, parallel processes
started) so that a request can't get into an infinite loop or
start off a chain reaction of requests or queries with other
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
SOME DATA."
"誰かが間違ってデータを設定した場合でも、問合せが無限ループに入っ
たり、他の実装で問合せの連鎖反応が生じないように、行う仕事（送
信パケット数、平行プロセス数）の量を制限しなさい。"
A GOOD IMPLEMENTATION:
よい実装
BIND fixes at least one of these problems. It places an upper limit
on the number of recursive queries it will make, to answer a
question. It chases a maximum of 20 referral links and 8 canonical
name translations.
ＢＩＮＤが少なくともこれらの問題の１つを修正します。ＢＩＮＤは１つの
質問に対する再帰問合せの回数に上限を置きます。制限は２０の参照リンク
と８つの別名変換です。
FIXES:
修正：
a. Set an upper limit on the number of referral links and CNAME
links you are willing to chase.
a. 参照リンクとCNAMEリンクの回数の上限を決めます。
Note that this is not guaranteed to break only recursion loops.
It could, in a rare case, prune off a very long search path,
prematurely. We know, however, with high probability, that if
the number of links cross a certain metric (two times the depth
of the DNS tree), it is a recursion problem.
これが再帰ループをとめるのを保障しないことに注意してください。
これは時には長い探索パスを早く終わらせることが出来ます。しかし、
高い確率で、もしリンク回数がある数（ＤＮＳ木の深さの２倍）を超
えるなら、それが再帰問題と考えられます。
b. Watch out for self-referring servers. Avoid them whenever
possible.
b. 自己参照サーバーに注意してください。可能ならそれを避けてくださ
い。
c. Make sure you never pass off an authority NS record with your
own name on it!
c. 自分自身の名前の権威ネームサーバレコードを送らないように確認し
てください！
d. Fix clients to accept iterative answers from servers not built
to provide recursion. Such clients should either be happy with
the non-authoritative answer or be willing to chase the
referral links themselves.
d. サーバーが再帰供給しない応答を受け入れるようにクライアントを修
正してください。このようなクライアントは正式でない答えに満足す
るか、クライアント自身が照会リンクを追いかけるべきです。
3. Zero Answer Bugs:
3.ゼロ解答バグ：
Name servers sometimes return an authoritative NOERROR with no
ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
queried name is valid but it does not have a record of the desired
type. Of course, the server has authority over the domain.
ネームサーバーが解答セクションと権威セクションと追加セクションのレコー
ドなしで時々正式なエラーなしの回答を返します。これは、問合された名前
が正しいが、要求したタイプのレコードがない時、起きます。もちろん、サー
バーはドメインの権限を持っています。
However, once again, some implementations of resolvers do not
interpret this kind of a response reasonably. They always expect an
answer record when they see an authoritative NOERROR. These entities
continue to resend their queries, possibly endlessly.
しかし、あるリゾルバの実装がこの種類の回答を適切に通訳しません。それ
らは、正式なエラーなし回答で、常に解答レコードを期待します。これらの
リゾルは際限なく、質問を再送し続けます。
A GOOD IMPLEMENTATION
よい実装
BIND resolver code does not query a server more than 3 times. If it
is unable to get an answer from 4 servers, querying them three times
each, it returns error.
ＢＩＮＤリゾルバコードが３回以上サーバーに問い合わせません。もし４つ
のサーバに各３回問合せて回答を得られなければエラーを返します。
Of course, it treats a zero-answer response the way it should be
treated; with respect!
もちろん、ＢＩＮＤリゾルバは適切にゼロ解答の回答を扱います！
FIXES:
修正：
a. Set an upper limit on the number of retransmissions for a given
query, at the very least.
a. ある質問に対して、少なくとも再送上限数を決めてください。
b. Fix resolvers to interpret such a response as an authoritative
statement of non-existence of the record type for the given
name.
b. レコードが実在しない正式な回答を扱えるようにリゾルバを修正して
ください。
4. Inability to detect server failure:
4. サーバー失敗の検出不能：
Servers in the internet are not very reliable (they go down every
once in a while) and resolvers are expected to adapt to the changed
scenario by not querying the server for a while. Thus, when a server
does not respond to a query, resolvers should try another server.
Also, non-stub resolvers should update their round trip time estimate
for the server to a large value so that server is not tried again
before other, faster servers.
インターネットのサーバーは非常に信頼性が高くなく（時たま停止します）、
リゾルバはしばらくの間サーバーに問い合わせないように順応することを期
待されます。つまり、サーバーが問合せに返答しない時、リゾルバは他のサー
バーを試みるべきです。同じく、非スタブリゾルバは往復遅延時間の見積り
を大きな値に変更し、他のより早いサーバより前にそのサーバーに問合せな
いようにしなければなりません。
Stub resolvers, however, cycle through a fixed set of servers and if,
unfortunately, a server is down while others do not respond for other
reasons (high load, recursive resolution of query is taking more time
than the resolver's time-out, ....), the resolver queries the dead
server again! In fact, some resolvers might not set an upper limit on
the number of query retransmissions they will send and continue to
query dead servers indefinitely.
スタブリゾルバは動作しているサーバに問合せを繰り返し、もし不幸にもサー
バー他の理由で回答しなくなったら（高負荷か、再帰問合せがリゾルバタイ
ムアウト以上に時間がかかったなど、ダウンしていたリゾルバに再び問合せ
をはじめます！実際、あるリゾルバが再送数の上限を設けず、いつまでも死
んでいるサーバーに問い合わせ続けるかもしれません。
Name servers running system or chained queries might also suffer from
the same problem. They store names of servers they should query for a
given domain. They cycle through these names and in case none of them
answers, hit each one more than one. It is, once again, important
that there be an upper limit on the number of retransmissions, to
prevent network overload.
システムや問合せの連鎖を実行しているネームサーバーが同じ問題で苦しむ
かもしれません。サーバはあるドメインについて参照すべきサーバー名を登
録します。サーバはこれらのサーバ名を順番にためし、誰も答えなければ、
それぞれに再度問合せます。再度言いますが、再送回数に上限を置くことは
ネットワーク輻輳を避けるために重要です。
This behavior is clearly in violation of the dictum in RFC 1035 (page
46)
この行動は明らかにRFC1035（ページ４６）の見解の違反です。
"If a resolver gets a server error or other bizarre response
from a name server, it should remove it from SLIST, and may
wish to schedule an immediate transmission to the next
candidate server address."
"もしリゾルバがネームサーバーからサーバーエラーや他の奇異な反応を得
るなら、そのネームサーバをサーバリストから除き、次の候補サーバーア
ドレスに即刻送信することを望むかもしれません。"
Removal from SLIST implies that the server is not queried again for
some time.
SLISTからのサーバの削除はしばらくの間、再び問い合わせらないことを意
味します。
Correctly implemented full-service resolvers should, as pointed out
before, update round trip time values for servers that do not respond
and query them only after other, good servers. Full-service resolvers
might, however, not follow any of these common sense directives. They
query dead servers, and they query them endlessly.
正確に実装されたフルサービスリゾルバが、前に指摘したように、サーバの
往復遅延時間値を修正し返、他の良いサーバへの問い合わせ前に質問しない
ようにするべきです。しかし、フルサービスのリゾルバがこれらの常識命令
に従わないかもしれません。それらは死んでいるサーバーに問い合わせ、際
限なく質問します。
A GOOD IMPLEMENTATION:
よい実装
BIND places an upper limit on the number of times it queries a
server. Both the stub-resolver and the full-service resolver code do
this. Also, since the full-service resolver estimates round-trip
times and sorts name server addresses by these estimates, it does not
query a dead server again, until and unless all the other servers in
the list are dead too! Further, BIND implements exponential back-off
too.
BINDは、サーバーに問合せる時に上限を設けます。スタブリゾルバとフルサー
ビスリゾルバコードの両方がこれをします。同じく、フルサービスのリゾル
バが往復遅延時間を推測し、この見積もりでネームサーバアドレスをソート
するので、リストの他のサーバが止まるまで、止まってるサーバーに問い合
わしません！さらにＢＩＮＤは指数関数的にタイムアウト値を増やします。
FIXES:
修正：
a. Set an upper limit on number of retransmissions.
a. 再送回数の上限を設定します。
b. Measure round-trip time from servers (some estimate is better
than none). Treat no response as a "very large" round-trip
time.
b. サーバの往復遅延時間を測ります（ある評価が他よりよいなら）。無
回答は「非常に大きい」遅延時間と扱います。
c. Maintain a weighted rtt estimate and decay the "large" value
slowly, with time, so that the server is eventually tested
again, but not after an indefinitely long period.
c. 重み付き遅延時間見積もりを維持し、「大きい」値を時間毎に少しづ
つ減らし、サーバーがあまり長すぎない時間で再びテストされるよう
にします。
d. Follow an exponential back-off scheme so that even if you do
not restrict the number of queries, you do not overload the
net excessively.
d. 指数関数的に再送間隔を広げ、たとえ質問数を制限しなくても、過度
にネットワークに負担をかけ過ぎないようにします。
5. Cache Leaks:
5. キャッシュ漏えい：
Every resource record returned by a server is cached for TTL seconds,
where the TTL value is returned with the RR. Full-service (or stub)
resolvers cache the RR and answer any queries based on this cached
information, in the future, until the TTL expires. After that, one
more query to the wide-area network gets the RR in cache again.
すべてのサーバから返される資源レコードがＴＴＬ秒間キャッシュされ、Ｔ
ＴＬ値は資源レコードと一緒に返されます。フルサービス（かスタブ）リゾ
ルバは資源レコードをキャッシュし、ＴＴＬが期限切れになるまではその後
キャッシュ情報に基づき回答します。その後は、再度広域ネットワークへの
問合せて再びキャッシュに資源レコードを入れます。
Full-service resolvers might not implement this caching mechanism
well. They might impose a limit on the cache size or might not
interpret the TTL value correctly. In either case, queries repeated
within a TTL period of a RR constitute a cache leak.
フルサービスリゾルバがこのキャッシュしているメカニズムを上手に実装し
てないかもしれません。それらはキャッシュサイズに制限を課すかもしれな
いし、正確にＴＴＬ値を理解しないかもしれません。いずれかの場合も、資
源レコードのＴＴＬ期間内に繰り返された質問がキャッシュ漏れを作ります。
A GOOD/BAD IMPLEMENTATION:
よい実装と悪い実装
BIND has no restriction on the cache size and the size is governed by
the limits on the virtual address space of the machine it is running
on. BIND caches RRs for the duration of the TTL returned with each
record.
ＢＩＮＤはキャッシュサイズに制限を持たず、大きさはＢＩＮＤを動かすマ
シンの仮想アドレス空間の上限で決まります。ＢＩＮＤはレコードと共に帰っ
てきたＴＴＬの間資源レコードをキャッシュします。
It does, however, not follow the RFCs with respect to interpretation
of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
the minimum TTL value, for that zone, from the SOA record and caches
it for that duration. This, though it saves some traffic on the
wide-area network, is not correct behavior.
しかしＢＩＮＤは０のＴＴＬ値の解釈に関してＲＦＣに従いません。もしレ
コードが０秒のＴＴＬ値を持つなら、ＢＩＮＤはＳＯＡレコードから、その
ゾーンの最小ＴＴＬ値を得て、その間資源レコードをキャッシュします。こ
れは、広域ネットワーク上にトラフィックをいくらか減らしますが、正しい
行動ではありません。
FIXES:
修正：
a. Look over your caching mechanism to ensure TTLs are interpreted
correctly.
a. ＴＴＬが正確に翻訳されることを保証するためにキャッシュメカニズ
ムをざっと調べてください。
b. Do not restrict cache sizes (come on, memory is cheap!).
Expired entries are reclaimed periodically, anyway. Of course,
the cache size is bound to have some physical limit. But, when
possible, this limit should be large (run your name server on
a machine with a large amount of physical memory).
b. キャッシュサイズを限定しないで下さい（さあ早く、メモリは安いで
す！）。期限切れ項目が周期的にとにかく返還を要求されます。もち
ろん、キャッシュ大きさは何か物理的な限界があるに疑いがありませ
ん。しかし、可能なら、この制限は大きくあるべきです（ネームサー
バを大きな物理メモリを持つマシンで走らせてください）。
c. Possibly, a mechanism is needed to flush the cache, when it is
known or even suspected that the information has changed.
c. 多分、情報が変化したと思われるときにキャッシュを消去するメカニ
ズムが必要です。
6. Name Error Bugs:
6. 名前エラーバグ：
This bug is very similar to the Zero Answer bug. A server returns an
authoritative NXDOMAIN when the queried name is known to be bad, by
the server authoritative for the domain, in the absence of negative
caching. This authoritative NXDOMAIN response is usually accompanied
by the SOA record for the domain, in the authority section.
このバグはゼロ解答バグに非常に類似しています。ドメインのために正式な
サーバーによって、ネガティブキャッシュなしで、問合せられた名前が誤っ
てることを知られている時、正式なNXDOMAINを返します。この正式な
NXDOMAIN回答は通常権威セクションにドメインのＳＯＡレコードを伴います。
Resolvers should recognize that the name they queried for was a bad
name and should stop querying further.
リゾルバが質問した名前が良くなく、さらなる質問をやめるべきであること
を認識するべきです。
Some resolvers might, however, not interpret this correctly and
continue to query servers, expecting an answer record.
あるリゾルバが、正確にこれを解釈せず、解答レコードを期待してサーバー
に問い合わせ続けるかもしれません。
Some applications, in fact, prompt NXDOMAIN answers! When given a
perfectly good name to resolve, they append the local domain to it
e.g., an application in the domain "foo.bar.com", when trying to
resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
"usc.edu.bar.com" and finally the good name "usc.edu". This causes at
least two queries that return NXDOMAIN, for every good query. The
problem is aggravated since the negative answers from the previous
queries are not cached. When the same name is sought again, the
process repeats.
あるアプリケーションが、実際NXDOMAIN回答をします！完全に良い名前がリ
ゾルバに与えられる時、リゾルバはそれにローカルなドメインを付けてよう
とします、例えばドメイン"foo.bar.com"のアプリケーションがリゾルバに
"usc.edu"の名前の変換を求める場合、最初は"usc.edu.foo.bar.com"を試み、
次に"usc.edu.bar.com"を試し、最後に正しい名前"usc.edu"を試します。こ
れは、NXDOMAINが返る少なくとも２つの問い合わせを起こします。問題は、
前の問合せがネガティブキャッシュされない時に、悪化します。同じ名前が
再び探される時、プロセスは繰り返されます。
Some DNS resolver implementations suffer from this problem, too. They
append successive sub-parts of the local domain using an implicit
searchlist mechanism, when certain conditions are satisfied and try
the original name, only when this first set of iterations fails. This
behavior recently caused pandemonium in the Internet when the domain
"edu.com" was registered and a wildcard "CNAME" record placed at the
top level. All machines from "com" domains trying to connect to hosts
in the "edu" domain ended up with connections to the local machine in
the "edu.com" domain!
あるＤＮＳリゾルバ実装がこの問題で苦しみます。これらのリゾルバはある
条件が満たされるとローカルドメインの一部を追加する暗黙の検索リストメ
カニズムを使い、この問合せの繰返しが失敗した時だけ、オリジナルの名前
を試みます。この行動は、ドメイン"edu.com"が登録され、そしてワイルドカー
ド"CNAME"レコードが最上位レベルに置かれた時、インターネットで大混乱を
起こしました。すべての"edu"ドメインでホストに接続しようとする"com"の
マシンは"edu.com"ドメインのローカルマシンに接続して止まりました！
GOOD/BAD IMPLEMENTATIONS:
良い実装と悪い実装
Some local versions of BIND already implement negative caching. They
typically cache negative answers with a very small TTL, sufficient to
answer a burst of queries spaced close together, as is typically
seen.
あるＢＩＮＤのローカルバージョンがネガティブキャッシュを実装します。
これらは一般にネガティブキャッシュを、爆発的質問の回答間隔を十分取れ
る程度の、極めて短い時間キャッシュします。
The next official public release of BIND (4.9.2) will have negative
caching as an ifdef'd feature.
ＢＩＮＤ（４.９.２）の次の公式のリリースは、定義された機能として、ネ
ガティブキャッシュを持つでしょう。
The BIND resolver appends local domain to the given name, when one of
two conditions is met:
ＢＩＮＤリゾルバはは、いずれかの条件が満たされる時、名前にローカルな
ドメインを付加します：。
i. The name has no periods and the flag RES_DEFNAME is set.
i. 名前に期限がなく、RES_DEFNAMEフラグがでっていされている。
ii. There is no trailing period and the flag RES_DNSRCH is set.
ii. 後続するピリオドがなく、RES_DNSRCHフラグが設定されている。
The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
BIND, but can be changed at compile time.
ＢＩＮＤでRES_DEFNAMEとRES_DNSRCHフラグがデフォルトのリゾルバオプショ
ンですが、コンパイル時に変更できます。
Only if the name, so generated, returns an NXDOMAIN is the original
name tried as a Fully Qualified Domain Name. And only if it contains
at least one period.
生成された名前に対してNXDOMAINが返ってくる場合と、名前の最後にピリオ
ドを含む場合に限り、オリジナルの名前が完全に指定されたドメイン名とし
て問合されます。
FIXES:
修正
a. Fix the resolver code.
a. リゾルバコードを修正する。
b. Negative Caching. Negative caching servers will restrict the
traffic seen on the wide-area network, even if not curb it
altogether.
b. ネガティブキャッシュをする。ネガティブキャッシュサーバは例え抑
制がなくても広域エリアトラヒックを制限すると思われます。
c. Applications and resolvers should not append the local domain to
names they seek to resolve, as far as possible. Names
interspersed with periods should be treated as Fully Qualified
Domain Names.
c. アプリケーションとリゾルバが可能な限り検索しようとする名前にロー
カルドメイン名をつけるべきではありません。ピリオドが存在してい
る名前が完全に指定されたドメイン名と扱われるべきです。
In other words, Use searchlists only when explicitly specified.
No implicit searchlists should be used. A name that contains
any dots should first be tried as a FQDN and if that fails, with
the local domain name (or searchlist if specified) appended. A
name containing no dots can be appended with the searchlist right
away, but once again, no implicit searchlists should be used.
換言すれば、明示的に指定されるだけ時、検索リストを使ってくださ
い。暗示的な検索リストを使うべきではありません。ドットを含む名
前が最初はFQDNとして検索し、失敗した場合にローカルドメイン名
（か検索リスト）を付加すべきです。ドットを含まない名前がすぐに
検索リストを適用できますが、再度、暗示的な検索リストを使うべき
ではありません。
Associated with the name error bug is another problem where a server
might return an authoritative NXDOMAIN, although the name is valid. A
secondary server, on start-up, reads the zone information from the
primary, through a zone transfer. While it is in the process of
loading the zones, it does not have information about them, although
it is authoritative for them. Thus, any query for a name in that
domain is answered with an NXDOMAIN response code. This problem might
not be disastrous were it not for negative caching servers that cache
this answer and so propagate incorrect information over the internet.
サーバーが正当な名前の正式なNXDOMAINを返すもう１つの問題と名前エラー
バグが関連します。セカンダリサーバーが起動時に、プライマリサーバから
ゾーン転送でゾーン情報を読み取ります。ゾーンを読み込むプロセスの間、
セカンダリは正式であるが、情報を持ちません。そのため、どんなそのドメ
イン名の問合せにもNXDOMAIN応答コードを返します。この問題は、この答え
をキャッシュしてインターネット上に正しくない情報を伝えるネガティブ
キャッシュサーバーがなければ問題でないかもしれません。
BAD IMPLEMENTATION:
悪い実装
BIND apparently suffers from this problem.
ＢＩＮＤは明らかにこの問題をもちます。
Also, a new name added to the primary database will take a while to
propagate to the secondaries. Until that time, they will return
NXDOMAIN answers for a good name. Negative caching servers store this
answer, too and aggravate this problem further. This is probably a
more general DNS problem but is apparently more harmful in this
situation.
同じく、プライマリデータベースに追加した新しい名前がセカンダリに送ら
れる少しの間も付くでしょう。その時まで、セカンダリは正しい名前に
NXDOMAINを返すでしょう。ネガティブキャッシュサーバがこの答えをキャッ
シュしたら、さらにこの問題を悪化させます。これは恐らくより一般的なＤ
ＮＳの問題で、この状態は見たところではより有害です。
FIX:
修正：
a. Servers should start answering only after loading all the zone
data. A failed server is better than a server handing out
incorrect information.
a. サーバーがすべてのゾーンデータを読み込んだ後で答え始めるべきで
す。動いていないサーバーは正しくない情報を配るサーバーより良い
です。
b. Negative cache records for a very small time, sufficient only
to ward off a burst of requests for the same bad name. This
could be related to the round-trip time of the server from
which the negative answer was received. Alternatively, a
statistical measure of the amount of time for which queries
for such names are received could be used. Minimum TTL value
from the SOA record is not advisable since they tend to be
pretty large.
b. 誤った名前での問合せの爆発を保護するのに十分な程度の、非常に小
さい時間のレコードをネガティブキャッシュします。これは否定回答
を受け取ったサーバーの往復遅延時間と関係があります。代わりに、
このような名前の質問を受信するのにかかる時間の総量の統計的値を
使うことが出来ます。ＳＯＡレコードの最小ＴＴＬ値は、かなり大き
いくなる傾向があるので、賢明ではありません。
c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
and implemented, to allow the primary server to inform
secondaries that the database has been modified since it last
transferred zone data. To alleviate the problem of "too many
zone transfers" that this might cause, Incremental Zone
Transfers should also be part of DNS. Also, the primary should
not NOTIFY/PUSH with every update but bunch a good number
together.
c. プライマリサーバーがセカンダリサーバにデータベースが最後のゾー
ンデータ転送から変更になったと知らせることを許すために、「押し
こみ」（あるいは、少なくとも「通知」）機構が使えて実装されるべ
きである。これによる「あまりに多くのゾーン転送」の問題を軽減す
るため、逐次的ゾーン転送がＤＮＳに組み込まれるべきです。また、
プライマリはすべての更新に押しこむ／知らせるべきでなく、適当な
数に束ねるべきです。
7. Format Errors:
7. フォーマットエラー：
Some resolvers issue query packets that do not necessarily conform to
standards as laid out in the relevant RFCs. This unnecessarily
increases net traffic and wastes server time.
あるリゾルバが、適切なＲＦＣで説明されるように、必ずしも標準に従わな
い問合せパケットを発送します。これは不必要にネットワークトラフィック
を増やして、サーバー時間を浪費します。
FIXES:
修正：
a. Fix resolvers.
a. リゾルバを直す
b. Each resolver verify format of packets before sending them out,
using a mechanism outside of the resolver. This is, obviously,
needed only if step 1 cannot be followed.
b. 各リゾルバが送信前にリゾルバの外のメカニズムでパケットのフォー
マットを確認します。これは、明らかにステップ１ができない場合に
限り、必要とされます。
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] Beertema, P., "Common DNS Data File Configuration Errors", RFC
1537, CWI, October 1993.
Security Considerations
セキュリティの考察
Security issues are not discussed in this memo.
セキュリティ問題がこのメモで論じられません。
Authors' Addresses
著者のアドレス
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
Jon Postel
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6714
EMail: postel@isi.edu
Cliff Neuman
USC Information Sciences Institute
4676 Admiralty Way
Marina Del Rey CA 90292-6695
Phone:(310) 822-1511
FAX: (310) 823-6714
EMail: bcn@isi.edu
Peter Danzig
Computer Science Department
University of Southern California
University Park
EMail: danzig@caldera.usc.edu
Steve Miller
Computer Science Department
University of Southern California
University Park
Los Angeles CA 90089
EMail: smiller@caldera.usc.edu