この文書はRFC2181の日本語訳です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Elz
Request for Comments: 2181 University of Melbourne
Updates: 1034, 1035, 1123 R. Bush
Category: Standards Track RGnet, Inc.
July 1997
Clarifications to the DNS Specification
ＤＮＳ仕様書の解釈
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
1. Abstract
1. 概要
This document considers some areas that have been identified as
problems with the specification of the Domain Name System, and
proposes remedies for the defects identified. Eight separate issues
are considered:
この文書はドメインネームシステム仕様の問題を考え、その欠陥の対処を提
案します。８つの異なる問題が検討されます：
+ IP packet header address usage from multi-homed servers,
マルチホームサーバーからのＩＰパケットヘッダーアドレスの使い方、
+ TTLs in sets of records with the same name, class, and type,
同じ名前とクラスとタイプのレコードのＴＴＬ、
+ correct handling of zone cuts,
ゾーン分割の正しい取り扱い、
+ three minor issues concerning SOA records and their use,
SOAレコードとその使い方に関する３つの細かな問題、
+ the precise definition of the Time to Live (TTL)
生存時間（ＴＴＬ）の正確な定義、
+ Use of the TC (truncated) header bit
ＴＣ（切り落とし）ヘッダビットの使い方、
+ the issue of what is an authoritative, or canonical, name,
何が正式名で何が標準名かの問題、
+ and the issue of what makes a valid DNS label.
正しいＤＮＳラベルの作り方の問題。
The first six of these are areas where the correct behaviour has been
somewhat unclear, we seek to rectify that. The other two are already
adequately specified, however the specifications seem to be sometimes
ignored. We seek to reinforce the existing specifications.
最初の６つは正しい行動が幾分（今まで）不明確だった所で、これを直した
いと思います。他の２は、仕様書がしばしば無視されるようですが、すでに
十分に示されています。我々は既存の仕様書を補強しようと努めます。
Contents
目次
1. Abstract
1. 概要
2. Introduction
2. はじめに
3. Terminology
3. 専門用語
4. Server Reply Source Address Selection
4. サーバーの応答ソースアドレスの選択
5. Resource Record Sets
5. 資源レコード集合
6. Zone Cuts
6. ゾーン分割
7. SOA RRs
7. SOA資源レコード
8. Time to Live (TTL)
8. 生存時間(TTL)
9. The TC (truncated) header bit
9. ヘッダのＴＣ（切り落し）ビット
10. Naming issues
10. 名づけの問題
11. Name syntax
11. 名前文法
12. Security Considerations
12. セキュリティの考慮
13. References
13. 参考文献
14. Acknowledgements
14. 謝辞
15. Authors' Addresses
15. 著者のアドレス
2. Introduction
2. はじめに
Several problem areas in the Domain Name System specification
[RFC1034, RFC1035] have been noted through the years [RFC1123]. This
document addresses several additional problem areas. The issues here
are independent. Those issues are the question of which source
address a multi-homed DNS server should use when replying to a query,
the issue of differing TTLs for DNS records with the same label,
class and type, and the issue of canonical names, what they are, how
CNAME records relate, what names are legal in what parts of the DNS,
and what is the valid syntax of a DNS name.
ドメインネームシステム仕様書[RFC1034, RFC1035]にいくつか問題点につい
て以前に気づかれました[RFC1123]。この文書はいくつかの追加の問題点を扱
います。問題の問題は独自です。これらの問題は、マルチホームＤＮＳサー
バーが問合せに答えにどのソースアドレスを使うべきかの問い、同じラベル
とクラスとタイプでＴＴＬが異なるＤＮＳレコードの問題、標準名の問題、
それは何か、CNAMEレコードとどう関係させるか、ＤＮＳのどの部分でどの名
前が正しいか、ＤＮＳ名の正当な構文は何か、です。
Clarifications to the DNS specification to avoid these problems are
made in this memo. A minor ambiguity in RFC1034 concerned with SOA
records is also corrected, as is one in the definition of the TTL
(Time To Live) and some possible confusion in use of the TC bit.
これらの問題を避けるためのＤＮＳ仕様書の解釈がこのメモでされます。SOA
レコードに関係したRFC1034細かなあいまい性が修正され、同じくＴＴＬ（生
存時間）の定義の問題が修正され、ＴＣビットの扱いの混乱が修正されます。
3. Terminology
3. 専門用語
This memo does not use the oft used expressions MUST, SHOULD, MAY, or
their negative forms. In some sections it may seem that a
specification is worded mildly, and hence some may infer that the
specification is optional. That is not correct. Anywhere that this
memo suggests that some action should be carried out, or must be
carried out, or that some behaviour is acceptable, or not, that is to
be considered as a fundamental aspect of this specification,
regardless of the specific words used. If some behaviour or action
is truly optional, that will be clearly specified by the text.
この文書はよく使われるMUSTやSHOULDやMAYやその否定の表現を使いません。
仕様書のある章は表現が穏やかな言葉で表現されるように思え、そのためそ
の仕様は任意と思われます。これは正しくありません。この文書はある行動
を実行すべきか、実行してはならないか、許容できるか、できないかを、使
う言葉に関係なく明確に示すのが仕様書の重要な機能と考ます。もしある行
動が本当に任意なら、明確に文書で示します。
4. Server Reply Source Address Selection
4. サーバーの応答ソースアドレスの選択
Most, if not all, DNS clients, expect the address from which a reply
is received to be the same address as that to which the query
eliciting the reply was sent. This is true for servers acting as
clients for the purposes of recursive query resolution, as well as
simple resolver clients. The address, along with the identifier (ID)
in the reply is used for disambiguating replies, and filtering
spurious responses. This may, or may not, have been intended when
the DNS was designed, but is now a fact of life.
全てではないがほとんどのＤＮＳクライアントは、問合せを送ったアドレス
から回答が返ってくることを期待します。これは単純なクライアントだけせ
はなく、クライアントとして再帰問い合わせをしているサーバーについても
言えます。アドレスは、識別子とともに答えのあいまいさを排除し、誤った
回答をフィルターすることに使われます。これはＤＮＳの設計で意図された
かどうかわかりませんが、現実です。
Some multi-homed hosts running DNS servers generate a reply using a
source address that is not the same as the destination address from
the client's request packet. Such replies will be discarded by the
client because the source address of the reply does not match that of
a host to which the client sent the original request. That is, it
appears to be an unsolicited response.
あるＤＮＳサーバが動いてるマルチホームホストはクライアントの問合せパ
ケットの宛先と異なるソースアドレスで答えを生成します。このような答え
は、答えのソースアドレスがクライアントが元の問合せを送ったホストのと
一致しなため、クライアントに捨てられるでしょう。すなわち、これは望ま
れない回答に思われます。
4.1. UDP Source Address Selection
4.1. ＵＤＰソースアドレス選択
To avoid these problems, servers when responding to queries using UDP
must cause the reply to be sent with the source address field in the
IP header set to the address that was in the destination address
field of the IP header of the packet containing the query causing the
response. If this would cause the response to be sent from an IP
address that is not permitted for this purpose, then the response may
be sent from any legal IP address allocated to the server. That
address should be chosen to maximise the possibility that the client
will be able to use it for further queries. Servers configured in
such a way that not all their addresses are equally reachable from
all potential clients need take particular care when responding to
queries sent to anycast, multicast, or similar, addresses.
これらの問題を避けるために、ＵＤＰで問合せに返答するサーバは、ＩＰヘッ
ダのソースアドレスフィールドに、返答の元になった問合せを送ってきたＩ
Ｐパケットのヘッダの宛先アドレスを、設定します。もしこの目的に合わな
いＩＰアドレスで回答を送るなら、サーバーの正しいＩＰアドレスのどれか
から回答が送られるでしょう。そのアドレスはクライアントがその後の問合
せで使うことが最大限可能なアドレスを選ぶべきです。自分のアドレスでは
ないが受取り可能なアドレスを設定されたサーバは、エニキャストやマルチ
キャストや類似のアドレスへ送られた問合せの回答に特別な注意が必要です。
4.2. Port Number Selection
4.2. ポート番号選択
Replies to all queries must be directed to the port from which they
were sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the
server must take note of the source port and use that as the
destination port in the response. Replies should always be sent from
the port to which they were directed. Except in extraordinary
circumstances, this will be the well known port assigned for DNS
queries [RFC1700].
すべての問合せの答えは、問合せの送信元のポートに送らなければなりませ
ん。問合せがＴＣＰで送られてきた場合、これは転送プロトコルの機能です。
ＵＤＰで問合せを受け取ったサーバはソースポートをメモし、回答でそのポー
トを宛先ポートとして用いなくてはなりません。答えが常に指定されたポート
から送られるべきです。特別な場合を除きこれはＤＮＳに割当てられた既知
ポートでしょう[RFC1700]。
5. Resource Record Sets
5. 資源レコード集合
Each DNS Resource Record (RR) has a label, class, type, and data. It
is meaningless for two records to ever have label, class, type and
data all equal - servers should suppress such duplicates if
encountered. It is however possible for most record types to exist
with the same label, class and type, but with different data. Such a
group of records is hereby defined to be a Resource Record Set
(RRSet).
各ＤＮＳ資源レコード(RR)はラベルとクラスとタイプとデータを持っていま
す。これまでラベルとクラスとタイプがすべて同じ２つのは無意味でした−
サーバーはもし重複を見つけたらこれを隠すべきでした。しかしたいていレ
コードタイプでは同じラベルとクラスとタイプでデータの異なるレコードが
可能です。このようなレコードのグループは資源レコードセット(RRSet)と
ここで定義します。
5.1. Sending RRs from an RRSet
5.1. 資源レコード集合から資源レコードを送る
A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be
one or more RRs. The response must be marked as "truncated" if the
entire RRSet will not fit in the response.
特定の（あるいは不特定の）ラベルとクラスとタイプの問い合わせでは常に
資源レコード集合の全てのレコードを返送します、これは１つ以上の資源レ
コードでしょう。もし全部の資源レコード集合が応答に載らなければ「切り
落し」が設定されます。
5.2. TTLs of RRs in an RRSet
5.2. TTLs of RRs in an RRSet
Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a
caching server, where the TTLs for some but not all the RRs in the
RRSet have expired.
資源レコードが生存時間（TTL）を持ちます。資源レコード集合の資源レコー
ドがそれぞれ異なるTTLを持つことは可能です。他の方法で達成できない異な
るＴＴＬの使い方は見つかりませんでした。異なるＴＴＬは資源レコード集
合の一部だけがキャッシュから消えた状態を発生し、キャッシュサーバーか
らの不完全な回答（「切り落し」とマークされない）を生じます。
Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.
従って資源レコード集合で異なるTTLを使うのはよくなく、資源レコード集合
内のすべての資源レコードは同じTTLでなければなりません。
Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Clients
that are configured to send all queries to one, or more, particular
servers should treat those servers as authoritative for this purpose.
Should an authoritative source send such a malformed RRSet, the
client should treat the RRs for all purposes as if all TTLs in the
RRSet had been set to the value of the lowest TTL in the RRSet. In
no case may a server send an RRSet with TTLs not all equal.
もしクライアントが異なるＴＴＬの資源レコードを含む資源レコード集合の
回答を受け取ったら、これをエラーと扱うべきです。もしその資源レコード
集合が正式でないデータ情報源から来たなら、クライアントは資源レコード
集合を無視し、もし値が必要なら正式な情報源から得るように努めるべきで
す。全ての問合せを特定のサーバに送るクライアントが、これらのサーバを
この目的で正式なサーバと扱うべきです。もし正式な情報源が障害のある資
源レコード集合を送ったなら、クライアントはすべての目的すべての資源レ
コード集合のＴＴＬを資源レコード集合内で最も小さいＴＴＬ値であるかの
ように扱うべきです。サーバは平しくないＴＴＬの資源レコード集合を送っ
てはなりません。
5.3. DNSSEC Special Cases
5.3. DNSSECの特別な場合
Two of the record types added by DNS Security (DNSSEC) [RFC2065]
require special attention when considering the formation of Resource
Record Sets. Those are the SIG and NXT records. It should be noted
that DNS Security is still very new, and there is, as yet, little
experience with it. Readers should be prepared for the information
related to DNSSEC contained in this document to become outdated as
the DNS Security specification matures.
ＤＮＳセキュリティ(DNSSEC)[RFC2065]で追加した２つのレコードタイプが、
資源レコード集合を作るときに特別な注意が必要です。２つのレコードタイ
プは署名とＮＸＴです。ＤＮＳセキュリティがまだ非常に新しいことで、ほ
とんど経験がありません。読者は、ＤＮＳセキュリティ仕様が完成すると、
この文書に含むDNSSECに関係する情報が古くなるのに対応できるべきです。
5.3.1. SIG records and RRSets
5.3.1. 署名レコードと資源レコード集合
A SIG record provides signature (validation) data for another RRSet
in the DNS. Where a zone has been signed, every RRSet in the zone
will have had a SIG record associated with it. The data type of the
RRSet is included in the data of the SIG RR, to indicate with which
particular RRSet this SIG record is associated. Were the rules above
applied, whenever a SIG record was included with a response to
validate that response, the SIG records for all other RRSets
associated with the appropriate node would also need to be included.
In some cases, this could be a very large number of records, not
helped by their being rather large RRs.
署名レコードがＤＮＳの他の資源レコード集合の署名（認証）データを提供
します。署名されたゾーンで、ゾーン内の全ての資源レコード集合に署名レ
コードがあります。資源レコード集合のデータタイプが署名資源レコードの
データに含められます、この署名レコードと特定の資源レコード集合が関連
づけられます。もし上記の規則が適用され、署名レコードが回答を検証する
ために回答に含まれた時は、完全な署名資源レコードの集合を生成するため
にそのノードに関する他の全ての署名レコードを含む必要があります。ある
場合には、これは大きなレコードというより、大量のレコードになり得ます。
Thus, it is specifically permitted for the authority section to
contain only those SIG RRs with the "type covered" field equal to the
type field of an answer being returned. However, where SIG records
are being returned in the answer section, in response to a query for
SIG records, or a query for all records associated with a name
(type=ANY) the entire SIG RRSet must be included, as for any other RR
type.
そこで、返答する答えのタイプと同じ「カバータイプ」の署名資源レコード
だけを権威セクションに持つことが特に認められます。しかし、署名資源レ
コードが署名資源レコードの検索の答えとして解答セクションに含まれる場
合や、名前に関する全てのレコードを返す場合（タイプ＝ANY）、他の資源レ
コードに関する全ての署名資源レコードが含まれます。
Servers that receive responses containing SIG records in the
authority section, or (probably incorrectly) as additional data, must
understand that the entire RRSet has almost certainly not been
included. Thus, they must not cache that SIG record in a way that
would permit it to be returned should a query for SIG records be
received at that server. RFC2065 actually requires that SIG queries
be directed only to authoritative servers to avoid the problems that
could be caused here, and while servers exist that do not understand
the special properties of SIG records, this will remain necessary.
However, careful design of SIG record processing in new
implementations should permit this restriction to be relaxed in the
future, so resolvers do not need to treat SIG record queries
specially.
権威セクションや（恐らく間違って）追加セクションに署名レコードを含む
回答を受け取るサーバーは、全部の署名資源レコードを受取っているのでな
いことを理解しなければなりません。そのためもし署名レコードの問合せを
サーバーが受け取るなら、署名レコードの問合せの回答用として署名レコー
ドをキャッシュしてはなりません。RFC2065は署名の問合せの問題を避けるた
め正式なサーバーにだけ問合せることを要求します、そして署名レコードの
特別な特性を理解しないサーバーが存在する間はこれが必要でしょう。しか
し将来の注意深い署名資源レコード処理の実装ではこの制限を外すべきで、
リゾルバが署名レコードの質問を特別扱いする必要がありません。
It has been occasionally stated that a received request for a SIG
record should be forwarded to an authoritative server, rather than
being answered from data in the cache. This is not necessary - a
server that has the knowledge of SIG as a special case for processing
this way would be better to correctly cache SIG records, taking into
account their characteristics. Then the server can determine when it
is safe to reply from the cache, and when the answer is not available
and the query must be forwarded.
署名レコードの問合せはキャッシュで答えるより正式なサーバーに転送され
るべきと何度か述べました。これは必要ではありません−署名の知識を持つ
サーバーが特別な処理としてその特徴を含めて署名レコードをキャッシュす
るのがより望ましいです。サーバーはキャッシュで返事するのが安全か判断
し、利用可能でない時だけ転送する事ができます。
5.3.2. NXT RRs
5.3.2. NXT署名レコード
Next Resource Records (NXT) are even more peculiar. There will only
ever be one NXT record in a zone for a particular label, so
superficially, the RRSet problem is trivial. However, at a zone cut,
both the parent zone, and the child zone (superzone and subzone in
RFC2065 terminology) will have NXT records for the same name. Those
two NXT records do not form an RRSet, even where both zones are
housed at the same server. NXT RRSets always contain just a single
RR. Where both NXT records are visible, two RRSets exist. However,
servers are not required to treat this as a special case when
receiving NXT records in a response. They may elect to notice the
existence of two different NXT RRSets, and treat that as they would
two different RRSets of any other type. That is, cache one, and
ignore the other. Security aware servers will need to correctly
process the NXT record in the received response though.
次の資源レコード（NXT）が更に奇妙です。ゾーンの特定のラベルのNXTレコー
ドは１つだけなので表面的には資源レコード集合の問題はありません。しか
し、ゾーン分割で親ゾーンと子ゾーン（RFC2065の用語ではスーパーゾーンと
サブゾーン）の両方に同じ名前のNXTレコードがあります。そしてこの２つの
NXTレコードは、両方のゾーンが同じサーバーにあっても、資源レコード集合
を形成しません。NXT資源レコード集合は常に１つの資源レコード を含みま
す。両方のNXTレコードが見えるところでは、２つの資源レコード集合が存在
します。しかし、サーバーが回答でNXTレコードを受け取った時、これを特別
な場合と扱うように要求されません。サーバはそれらが２つの異なるNXT資源
レコード集合の存在に注意して、異なるタイプの資源レコード集合と扱って
もかまいません。あるいは１つをキャッシュし、他を無視します。セキュリ
ティの認識のあるサーバが受取た回答のNXTレコードを正確に処理する必要が
あるでしょう。
5.4. Receiving RRSets
5.4. 資源レコード集合の受信
Servers must never merge RRs from a response with RRs in their cache
to form an RRSet. If a response contains data that would form an
RRSet with data in a server's cache the server must either ignore the
RRs in the response, or discard the entire RRSet currently in the
cache, as appropriate. Consequently the issue of TTLs varying
between the cache and a response does not cause concern, one will be
ignored. That is, one of the data sets is always incorrect if the
data from an answer differs from the data in the cache. The
challenge for the server is to determine which of the data sets is
correct, if one is, and retain that, while ignoring the other. Note
that if a server receives an answer containing an RRSet that is
identical to that in its cache, with the possible exception of the
TTL value, it may, optionally, update the TTL in its cache with the
TTL of the received answer. It should do this if the received answer
would be considered more authoritative (as discussed in the next
section) than the previously cached answer.
サーバーは応答の資源レコード集合とキャッシュの資源レコード集合を統合
してはなりません。もし回答に、サーバーがキャッシュしている資源レコー
ド集合と同じ資源レコード集合があるなら、サーバーは回答の資源レコード
を無視するか、キャッシュの資源レコード集合を捨てなくてはなりません。
従ってキャッシュと回答の間のＴＴＬの差は問題を起こしません、１つは無
視されます。回答とキャッシュのデータとは違うなら、どちらかが正しくあ
りません。サーバーはどちらのデータが正しいか決定し、正しいデータを残
し、他を無視します。もしサーバーがキャッシュとまったく同じの資源レコー
ド集合を含む回答を受け取るなら、新しいＴＴＬでキャッシュのＴＴＬを更
新するかもしれないことに注意してください。もし受信した答えが前にキャッ
シュされた答えより（次章で論じられるように）より正しいと思われるなら、
これをするべきです。
5.4.1. Ranking data
5.4.1. データを並べる
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
答えの資源レコード集合を受け取るか、その代わりにキャッシュの資源レコー
ド集合を保持すべきか考える時、サーバーが種々のデータの相対的な信用度
を考慮するべきです。正式な答えは追加データから得られたキャッシュデー
タを置き換えるべきです。しかし、もしキャッシュが正式なデータかゾーン
ファイルのデータを含むなら、追加情報は無視されるでしょう。
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
利用可能なデータの正確さはその情報源から仮定されます。信用度は信用が
高い順から以下のとおりです：
+ Data from a primary zone file, other than glue data,
接着剤データを除くプライマリゾーンファイルからのデータ、
+ Data from a zone transfer, other than glue,
接着剤データを除くゾーン転送からのデータ、
+ The authoritative data included in the answer section of an
authoritative reply.
正式な答えの解答セクションにある正式データ、
+ Data from the authority section of an authoritative answer,
正式な答えの権威セクションのデータ、
+ Glue from a primary zone, or glue from a zone transfer,
プライマリゾーンの接着剤や、ゾーン転送からの接着剤、
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
正式でない答えの解答セクションからのデータと、正式な答えの解答セ
クションからの正式でないデータ、
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
正式な答えからの追加情報、
正式でない答えの権威セクションのデータ、
正式でない答えからの追加情報。
Note that the answer section of an authoritative answer normally
contains only authoritative data. However when the name sought is an
alias (see section 10.1.1) only the record describing that alias is
necessarily authoritative. Clients should assume that other records
may have come from the server's cache. Where authoritative answers
are required, the client should query again, using the canonical name
associated with the alias.
正式な答えの解答セクションが通常ただ正式なデータだけを含むことに注意
してください。しかし見つかった名前が別名（１０．１．１章参照）の時、
別名レコードだけが正式です。クライアントが他のレコードがサーバーの
キャッシュから来たかもしれないと想定するべきです。正式な答えが必要な
らばクライアントは、別名と結び付いた標準名を使って、再び質問するべき
です。
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.
追加データセクションからや正式でない回答の権威セクションからの認証さ
れていない受信資源レコードが最低の信用度でキャッシュされた場合、これ
は問合せの回答の解答セクションで使うべきでありません。これは、適切な
場合、追加情報として返送できます。これを無視すると、比較的信用できな
いデータが理由もなしに信用度を上げることになります。
When DNS security [RFC2065] is in use, and an authenticated reply has
been received and verified, the data thus authenticated shall be
considered more trustworthy than unauthenticated data of the same
type. Note that throughout this document, "authoritative" means a
reply with the AA bit set. DNSSEC uses trusted chains of SIG and KEY
records to determine the authenticity of data, the AA bit is almost
irrelevant. However DNSSEC aware servers must still correctly set
the AA bit in responses to enable correct operation with servers that
are not security aware (almost all currently).
ＤＮＳセキュリティ[RFC2065]が使われ、正式な答えを受け取り認証された時、
認証されたデータは同じタイプの認証されていないデータよりも信頼性が高
いと思われるべきです。この文書で「正式」がＡＡビットを設定した答えを
意味することに注意してください。ＤＮＳＳＥＣ署名と鍵レコードの信頼の
連鎖を使い、ＡＡビットはほとんど無関係です。しかしＤＮＳＳＥＣをサポー
トするサーバは、セキュリティの認識のないサーバ（現在ほとんど全て）に
対して正しく動作するため、正しくＡＡを設定しなければなりません。
Note that, glue excluded, it is impossible for data from two
correctly configured primary zone files, two correctly configured
secondary zones (data from zone transfers) or data from correctly
configured primary and secondary zones to ever conflict. Where glue
for the same name exists in multiple zones, and differs in value, the
nameserver should select data from a primary zone file in preference
to secondary, but otherwise may choose any single set of such data.
Choosing that which appears to come from a source nearer the
authoritative data source may make sense where that can be
determined. Choosing primary data over secondary allows the source
of incorrect glue data to be discovered more readily, when a problem
with such data exists. Where a server can detect from two zone files
that one or more are incorrectly configured, so as to create
conflicts, it should refuse to load the zones determined to be
erroneous, and issue suitable diagnostics.
接着剤を除くことに注意してください、接着剤は２つの正確に設定されたプ
ライマリゾーンファイルや２つの正確に設定されたセカンダリゾーン（ゾー
ン転送からのデータ）からのデータや正確に設定されたプライマリとセカン
ダリのデータで常に矛盾することは不可能な事に注意してください。同じ名
前の接着剤が多数のゾーンに存在し、値が違うなら、ネームサーバーはセカ
ンダリよりプライマリゾーンファイルのデータを優先すべきで、そうでなけ
ればどれを選択してもかまいません。正式なデータ情報源に近い情報源を選
ぶのがもっともな決定かもしれません。セカンダリがプライマリデータを選
択すると、データに問題がある場合に、正しくない接着剤データを容易に発
見できます。サーバーが２つのゾーンファイルからいくつかの矛盾した誤設
定を検出でき、サーバーは誤ったゾーンの読み込みを拒否し、適当な診断を
するべきです。
"Glue" above includes any record in a zone file that is not properly
part of that zone, including nameserver records of delegated sub-
zones (NS records), address records that accompany those NS records
(A, AAAA, etc), and any other stray data that might appear.
「接着剤」はゾーンファイル上のゾーンの一部でないレコード、委任サブゾー
ンのネームサーバレコード（NSレコード）やNSレコードに関するアドレスレ
コード（AやAAAAなど）や他に現れるかもしれないレコードを含みます。
5.5. Sending RRSets (reprise)
5.5. 資源レコード集合の送信（繰り返し）
A Resource Record Set should only be included once in any DNS reply.
It may occur in any of the Answer, Authority, or Additional
Information sections, as required. However it should not be repeated
in the same, or any other, section, except where explicitly required
by a specification. For example, an AXFR response requires the SOA
record (always an RRSet containing a single RR) be both the first and
last record of the reply. Where duplicates are required this way,
the TTL transmitted in each case must be the same.
ある資源レコード集合はＤＮＳ応答の中で１度だけ含まれるべきです。これ
は解答セクションや権威セクションや追加情報セクションでおきるかもしれ
ません。しかし仕様書で明記されない限り、同じセクションや違うセクショ
ンで繰り返されるべきではありません。例えば、AXFR応答がSOAレコード
（常に１つの資源レコードからなる資源レコード集合）が回答の最初と最後
にあることを要求します。この様に重複が要求された場合、それぞれのＴＴ
Ｌは同じであるに違いありません。
6. Zone Cuts
6. ゾーン分割
The DNS tree is divided into "zones", which are collections of
domains that are treated as a unit for certain management purposes.
Zones are delimited by "zone cuts". Each zone cut separates a
"child" zone (below the cut) from a "parent" zone (above the cut).
The domain name that appears at the top of a zone (just below the cut
that separates the zone from its parent) is called the zone's
"origin". The name of the zone is the same as the name of the domain
at the zone's origin. Each zone comprises that subset of the DNS
tree that is at or below the zone's origin, and that is above the
cuts that separate the zone from its children (if any). The
existence of a zone cut is indicated in the parent zone by the
existence of NS records specifying the origin of the child zone. A
child zone does not contain any explicit reference to its parent.
ＤＮＳ木は「ゾーン」に分割され、各ゾーンはドメインの集合体で、特定の
管理をする単位と扱われます。ゾーンが「ゾーン分割」によって限定されま
す。各ゾーン分割が「子」ゾーン（分割の下）と「親」ゾーン（分割の上）
にゾーンを分離します。ゾーンの頂上（親からのゾーン分割の直下）にある
ドメイン名をゾーンの「起点」と呼びます。ゾーンの名前はゾーンの起点の
ドメイン名と同じです。各ゾーンはＤＮＳ木の部分木で、ゾーンの起点とそ
の下にあり、子ゾーンを分割するゾーン分割（もしあれば）の上にあります。
親ゾーンでのゾーン分割の存在は子ゾーンの起点を指定するNSレコードの存
在によって示されます。子ゾーンには親に関する明示的な情報を含んでいま
せん。
6.1. Zone authority
6.1. ゾーン権威
The authoritative servers for a zone are enumerated in the NS records
for the origin of the zone, which, along with a Start of Authority
(SOA) record are the mandatory records in every zone. Such a server
is authoritative for all resource records in a zone that are not in
another zone. The NS records that indicate a zone cut are the
property of the child zone created, as are any other records for the
origin of that child zone, or any sub-domains of it. A server for a
zone should not return authoritative answers for queries related to
names in another zone, which includes the NS, and perhaps A, records
at a zone cut, unless it also happens to be a server for the other
zone.
ゾーンの正式なサーバーはゾーンの起点のNSレコードのリストで、これは正
式な開始（SOA）レコードと共にゾーンに必須なレコードです。このような
サーバーはゾーンの、他のゾーンにはない、資源レコードの権威です。ゾー
ン分割を示すレコードは子ゾーンの資源であり、子ゾーンの起点かそのサブ
ドメインのレコードです。他のゾーンに関する名前、NSや多分Aなどのゾー
ン分割のレコードに、サーバーは正式な回答をすべきでありません、サーバー
が子ゾーンの正式なサーバであれば別です。
Other than the DNSSEC cases mentioned immediately below, servers
should ignore data other than NS records, and necessary A records to
locate the servers listed in the NS records, that may happen to be
configured in a zone at a zone cut.
すぐ下に書いてあるＤＮＳＳＥＣの場合以外、サーバーはゾーン分割された
ゾーンのデータを、NSレコードと必要なAレコードを除き無視するべきです。
6.2. DNSSEC issues
6.2. ＤＮＳＳＥＣ問題
The DNS security mechanisms [RFC2065] complicate this somewhat, as
some of the new resource record types added are very unusual when
compared with other DNS RRs. In particular the NXT ("next") RR type
contains information about which names exist in a zone, and hence
which do not, and thus must necessarily relate to the zone in which
it exists. The same domain name may have different NXT records in
the parent zone and the child zone, and both are valid, and are not
an RRSet. See also section 5.3.2.
ＤＮＳセキュリティ機構[RFC2065]は、追加した新しい資源レコードタイプが
他のＤＮＳ資源レコードと比べて非常に異なるため、幾分複雑です。特にNXT
（「次」）資源レコードタイプはゾーンに存在する名前の情報を含み、それ
ゆえゾーンのデータではないがゾーンに関連する名前も存在します。同じド
メイン名で親ゾーンと子ゾーンで異なるNXTレコードがあるかもしれません、
そして両方とも正しく、そして資源レコード集合ではありません。同じ
５．３．２章を見てください。
Since NXT records are intended to be automatically generated, rather
than configured by DNS operators, servers may, but are not required
to, retain all differing NXT records they receive regardless of the
rules in section 5.4.
NXTレコードはＤＮＳオペレータが設定するのではなく自動生成を意図し、
サーバは５．４章の規則に関係なく受信した異なるNXTレコードを持ってい
てもよいです、必須ではありません。
For a secure parent zone to securely indicate that a subzone is
insecure, DNSSEC requires that a KEY RR indicating that the subzone
is insecure, and the parent zone's authenticating SIG RR(s) be
present in the parent zone, as they by definition cannot be in the
subzone. Where a subzone is secure, the KEY and SIG records will be
present, and authoritative, in that zone, but should also always be
present in the parent zone (if secure).
安全な親ゾーンがサブゾーンが安全でないことを示すため、ＤＮＳＳＥＣは
サブゾーンを示す鍵資源レコードがサブゾーンは安全でないと示し、サブゾー
ンにはない親ゾーンの認証署名資源レコードが親ゾーンにある事を要求しま
す。サブゾーンが安全ならば、鍵と署名レコードがゾーンに存在し正式で、
（親ゾーンも安全なら）親ゾーンにもあるべきです。
Note that in none of these cases should a server for the parent zone,
not also being a server for the subzone, set the AA bit in any
response for a label at a zone cut.
親ゾーンのサーバーがサブゾーンのサーバーでなければ、ゾーン分割のラベ
ルの回答でＡＡビットを設定する事がないことに注意してください。
7. SOA RRs
7. SOA資源レコード
Three minor issues concerning the Start of Zone of Authority (SOA)
Resource Record need some clarification.
正式なゾーンの開始（SOA）資源レコードの３つの些細な問題の解釈が必要
です。
7.1. Placement of SOA RRs in authoritative answers
7.1. 正式な回答でのSOA資源レコードの配置
RFC1034, in section 3.7, indicates that the authority section of an
authoritative answer may contain the SOA record for the zone from
which the answer was obtained. When discussing negative caching,
RFC1034 section 4.3.4 refers to this technique but mentions the
additional section of the response. The former is correct, as is
implied by the example shown in section 6.2.5 of RFC1034. SOA
records, if added, are to be placed in the authority section.
RFC1034の３．７章が正式な答えの権威セクションに答えが得られたゾーンの
SOAレコードを含むかもしれないことを示します。ネガティブキャッシュを論
じる時、RFC1034の４．３．４章がこのテクニックを参照しますが、回答の追
加セクションと言います。前者はRFC1034の６．２．５章の例で暗示されるよ
うに正しいです。SOAレコードを追加するなら、権威セクションに置かれるは
ずです。
7.2. TTLs on SOA RRs
7.2. TTLs on SOA RRs
It may be observed that in section 3.2.1 of RFC1035, which defines
the format of a Resource Record, that the definition of the TTL field
contains a throw away line which states that the TTL of an SOA record
should always be sent as zero to prevent caching. This is mentioned
nowhere else, and has not generally been implemented.
Implementations should not assume that SOA records will have a TTL of
zero, nor are they required to send SOA records with a TTL of zero.
資源レコードのフォーマットを定義するRFC1035の３．２．１章でＴＴＬフィー
ルドの定義で、ＳＯＡレコードのＴＴＬがキャッシュをされないように常に
ゼロである、との１行抜けていています。これは他のどこにも述べられてい
ませんが、一般に実行されました。ＤＮＳの実装はSOAレコードがゼロのＴＴ
Ｌを持つと想定するべきではなく、同様にゼロのＴＴＬでSOAレコードを送る
ように要求します。
7.3. The SOA.MNAME field
7.3. SOA.MNAMEフィールド
It is quite clear in the specifications, yet seems to have been
widely ignored, that the MNAME field of the SOA record should contain
the name of the primary (master) server for the zone identified by
the SOA. It should not contain the name of the zone itself. That
information would be useless, as to discover it, one needs to start
with the domain name of the SOA record - that is the name of the
zone.
SOAレコードのMNAMEフィールドはSOAを定義したゾーンのプライマリ（マス
ター）サーバの名前を含むべきであり、仕様書にも非常に明記されてるのに、
広く無視されてるように思います。MNAMEにはゾーン自身の名前を含むべきで
はありません。その情報は情報を検索する際に無意味です、ドメイン名のSOA
レコードを必要な人はドメイン名を知っています。
8. Time to Live (TTL)
8. 生存時間(TTL)
The definition of values appropriate to the TTL field in STD 13 is
not as clear as it could be, with respect to how many significant
bits exist, and whether the value is signed or unsigned. It is
hereby specified that a TTL value is an unsigned number, with a
minimum value of 0, and a maximum value of 2147483647. That is, a
maximum of 2^31 - 1. When transmitted, this value shall be encoded
in the less significant 31 bits of the 32 bit TTL field, with the
most significant, or sign, bit set to zero.
標準１３のTTLフィールドの定義は、値が何ビットか、符号付か符合なしかど
んな値が設定できるかはっきりしていません。ＴＴＬ値は最小０で最大
２１４７４８３６４７で、符号なしの数とここで明記します。すなわち、
２^３１−１が最大値です。転送する際に３２ビットのＴＴＬ値に対して、
有効桁数３１ビットで符号化され、最上位ビットはゼロになります。
Implementations should treat TTL values received with the most
significant bit set as if the entire value received was zero.
ＤＮＳの実装は最上位ビットが１のＴＴＬ値を０と扱うべきです。
Implementations are always free to place an upper bound on any TTL
received, and treat any larger values as if they were that upper
bound. The TTL specifies a maximum time to live, not a mandatory
time to live.
ＤＮＳ実装は受信したＴＴＬ値に自由に上限を決めることが出来、大きな値
は全て最大値と同じと扱うことが出来ます。ＴＴＬはキャッシュに残してお
く義務を示すのではなく、残せる限界を指定します。
9. The TC (truncated) header bit
9. ヘッダのＴＣ（切り落し）ビット
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room. This
includes the results of additional section processing. In such cases
the entire RRSet that will not fit in the response should be omitted,
and the reply sent as is, with the TC bit clear. If the recipient of
the reply needs the omitted data, it can construct a query for that
data and send that separately.
ＴＣビットは資源レコード集合が回答の一部として必要だが、全部を含む事
が出来なかった時だけ設定するべきです。ＴＣビットは追加情報を回答に含
めたかったスペースが足りなかった場合に設定されるべきではありません。
これは追加セクション処理の結果を含みます。このような場合、応答にある
資源レコード集合を完全に設定する事ができなければ、その資源レコード集
合は設定せずＴＣビットを設定せずに送信します。もし答えの受信者が設定
しなかったデータを必要とするなら、受信者はそのデータの問合せを作り、
別に問合せる事ができます。
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
ＴＣが設定される場合、回答に不完全な資源集合が残っています。ＤＮＳク
ライアントはＴＣビットが設定された答えを受取るとその回答を無視し、Ｔ
ＣＰ接続のようなより大きな回答を受取れる方法で問合せなおします。
10. Naming issues
10. 名づけの問題
It has sometimes been inferred from some sections of the DNS
specification [RFC1034, RFC1035] that a host, or perhaps an interface
of a host, is permitted exactly one authoritative, or official, name,
called the canonical name. There is no such requirement in the DNS.
ＤＮＳ仕様[RFC1034, RFC1035]のいくつかの章を見ると、ホストやホストの
インタフェースは標準名と呼ばれる正式なあるいは公式な名前が正確に１つ
だけ許されるように思われます。ＤＮＳにこのような必要条件はありません。
10.1. CNAME resource records
10.1. CNAME資源レコード
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though there are some rare
applications for aliases with the accompanying canonical name
undefined in the DNS. An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
other data. That is, for any label in the DNS (any domain name)
exactly one of the following is true:
ＤＮＳのCNAME （「標準名」）レコードは別名に結び付く標準名を供給する
ために存在します。ある別名に対して標準名は１つだけです。ＤＮＳで定義
されていない標準名を使うアプリケーションが若干ありますが、通常は別名
に対する標準名はＤＮＳのどこかで定義されているべきです。別名（CNAME
レコードのラベル）は、もしＤＮＳＳＥＣを使っているならば、署名とＮＸ
Ｔと鍵資源レコードを持ち、他のデータを持たないでしょう。すなわち、Ｄ
ＮＳのラベルで（どんなドメイン名でも）正確に次のどれか１つが正解です：
+ one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
１つのCNAMEレコードが存在、署名とＮＸＴと鍵資源レコードはあって
もよい。
+ one or more records exist, none being CNAME records,
１つ以上の資源レコードが存在し、CNAMEレコードが存在しない、。
+ the name exists, but has no associated RRs of any type,
名前はあるが、資源レコードは存在しない。
+ the name does not exist at all.
名前は存在しない。
10.1.1. CNAME terminology
10.1.1. CNAME用語
It has been traditional to refer to the label of a CNAME record as "a
CNAME". This is unfortunate, as "CNAME" is an abbreviation of
"canonical name", and the label of a CNAME record is most certainly
not a canonical name. It is, however, an entrenched usage. Care
must therefore be taken to be very clear whether the label, or the
value (the canonical name) of a CNAME resource record is intended.
In this document, the label of a CNAME resource record will always be
referred to as an alias.
CNAMEレコードのラベルを「CNAME」というのが伝統的です。これは「CNAME」
が「標準名」の省略なので残念です、CNAMEレコードのラベルは間違いなく
標準名ではありません。しかし習慣化した使い方です。従ってCNAMEと言った
場合、CNAME資源レコードのラベルを言ってるのか値（標準名）を言ってるか
気を付けないといけません。この文書で、CNAME資源レコードのラベルは常に
別名と述べられるでしょう。
10.2. PTR records
10.2. ポインタレコード
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
標準名に関する混乱がPTRレコードは正確に１つの資源レコードからなる資源
レコード集合であるべきとの信念を生みました。これは正しくありません、
RFC1034の適切な章（３.６.２章）はPTRレコードの値が標準名であるべきで
あることを示します。すなわち、それは別名であるべきではありません。こ
の章に１つの名前にPTRレコードが１つだけ認められるというほのめかしはあ
りません。このような制限を推定すべきではありません。
Note that while the value of a PTR record must not be an alias, there
is no requirement that the process of resolving a PTR record not
encounter any aliases. The label that is being looked up for a PTR
value might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, which it should not be,
will give the location where the PTR record is found. That record
gives the result of the PTR type lookup. This final result, the
value of the PTR RR, is the label which must not be an alias.
PTRレコードの値は別名ではありませんが、PTRレコードに解決処理中に別名
に遭遇しないという条件がないことに注意して下さい。PTR値を調べるための
ラベルはCNAMEレコードを持つかもしれません。すなわち、別名かもしれませ
ん。CNAME資源レコードの値がPTRレコードの場所を示すでしょう、値が他の
別名であれば別ですが別名にすべきでありません。そのレコードは PTR タイ
プ検索の結果を与えます。この最終の結果PTR資源レコードの値は別名でない
ラベルです。
10.3. MX and NS records
10.3. MXとNSレコード
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.
NS資源レコードの値やMX資源レコードの値の部分のドメイン名は別名であっ
てはなりません。単に仕様書でこの点が明記されているだけではなく、これ
らの場所に別名を使うと予想外の動作が発生し、考えていた事が果たせませ
ん。このドメイン名は１つ以上のアドレスレコードをその値と示さなくては
なりません。現在それらはＡレコードであるでしょうが、将来他のアドレス
情報を与えるレコードが許されるかもしれません。これは他の資源レコード
を持つことも出来ますが、CNAME資源レコードはだめです。
Searching for either NS or MX records causes "additional section
processing" in which address records associated with the value of the
record sought are appended to the answer. This helps avoid needless
extra queries that are easily anticipated when the first was made.
NSやMXレコード検索はレコード値と結び付くアドレスレコードを回答に設定
する「追加セクション処理」を起こします。これは最初の質問が来た際に、
容易に予期される不要な質問を避けます。
Additional section processing does not include CNAME records, let
alone the address records that may be associated with the canonical
name derived from the alias. Thus, if an alias is used as the value
of an NS or MX record, no address will be returned with the NS or MX
value. This can cause extra queries, and extra network burden, on
every query. It is trivial for the DNS administrator to avoid this
by resolving the alias and placing the canonical name directly in the
affected record just once when it is updated or installed. In some
particular hard cases the lack of the additional section address
records in the results of a NS lookup can cause the request to fail.
追加のセクション処理はCNAMEレコードを含みません、言うまでもなく別名か
ら生じる標準名にアドレスレコードがあります。それで、もし別名がNSやMX
レコードの値として用いられるなら、NS値やMX値と一緒にアドレスが返らな
いでしょう。これは余計な問合せを生じ、全ての問合せで余分なネットワー
ク負荷を生じます。ＤＮＳ管理者にとって、更新やインストールの際に別名
の変換をして標準名を設定しこの問題を避けるのは簡単です。若干の特定の
場合にNS検索の結果の追加セクションにアドレスレコードがないと問合せが
失敗します。
11. Name syntax
11. 名前文法
Occasionally it is assumed that the Domain Name System serves only
the purpose of mapping Internet host names to data, and mapping
Internet addresses to host names. This is not correct, the DNS is a
general (if somewhat limited) hierarchical database, and can store
almost any kind of data, for almost any purpose.
時々ドメインネームシステムはただインターネットホスト名をデータに変換
し、インターネットアドレスをホスト名に変換する目的だけを満たすと想定
されます。これは正しくありません、ＤＮＳは（いくらか限定されてるが）
一般的な階層的なデータベースであり、ほとんどの目的のいろんな種類のデー
タを登録できます。
The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one restriction
relates to the length of the label and the full name. The length of
any one label is limited to between 1 and 63 octets. A full domain
name is limited to 255 octets (including the separators). The zero
length full name is defined as representing the root of the DNS tree,
and is typically written and displayed as ".". Those restrictions
aside, any binary string whatever can be used as the label of any
resource record. Similarly, any binary string can serve as the value
of any record that includes a domain name as some or all of its value
(SOA, NS, MX, PTR, CNAME, and any others that may be added).
Implementations of the DNS protocols must not place any restrictions
on the labels that can be used. In particular, DNS servers must not
refuse to serve a zone because it contains labels that might not be
acceptable to some DNS client programs. A DNS server may be
configurable to issue warnings when loading, or even to refuse to
load, a primary zone containing labels that might be considered
questionable, however this should not happen by default.
ＤＮＳは資源レコードの識別に使うあるラベルで１つだけの制限をします。
その制限はラベルの長さと名前全体の長さに関連しています。どのラベルも
長さは１から６３オクテットです。名前全体の長さが（区切りを含めて）
２５５のオクテットに制限されます。長さゼロの名前はＤＮＳ木のルートを
表すと定義され、一般的に"."と記述します。この制限は、資源レコードのラ
ベルに使えるバイナリ列には適用しません。同様に、ドメイン名を含むもの
も含め（SOAやNSやMXやPTRやCNAMEや将来追加されるものも含め）、バイナリ
のレコード値にも適用しません。ＤＮＳプロトコルの実装は使用できるラベ
ルの上限をつけてはなりません。特に、ＤＮＳサーバーはあるＤＮＳクライ
アントプログラムが受け入れないラベルを含むゾーンのサポートを拒否して
はなりません。ＤＮＳサーバーは、疑わしいラベルを含むプライマリゾーン
の読み込みや読み込みを拒否した際に、デフォルトでは警告しなくても警告
するように設定できるかもしれません。
Note however, that the various applications that make use of DNS data
can have restrictions imposed on what particular values are
acceptable in their environment. For example, that any binary label
can have an MX record does not imply that any binary name can be used
as the host part of an e-mail address. Clients of the DNS can impose
whatever restrictions are appropriate to their circumstances on the
values they use as keys for DNS lookup requests, and on the values
returned by the DNS. If the client has such restrictions, it is
solely responsible for validating the data from the DNS to ensure
that it conforms before it makes any use of that data.
しかしＤＮＳデータを利用する様々なアプリケーションが、どの値を受け入
れるかについて制限を持てることに注意してください。例えば、MXレコード
にバイナリラベルが使えるのは電子メールアドレスのホスト名にバイナリの
名前が使える事を意味しません。ＤＮＳクライアントはＤＮＳ検索の問合せ
やＤＮＳの返す値に、クライアントの事情に応じてどんな制限を課すことも
できます。もしクライアントがこのような制限を持つなら、クライアントは
データの使用でもする前に、データが制限に従うか保障するため検査する責
任があります。
See also [RFC1123] section 6.1.3.5.
[RFC1123]の６．１．３．５章も参照してください。
12. Security Considerations
12. セキュリティの考慮
This document does not consider security.
この文書はセキュリティを考慮しません。
In particular, nothing in section 4 is any way related to, or useful
for, any security related purposes.
特に４章はセキュリティの目的に関係したり役に立ったりしません。
Section 5.4.1 is also not related to security. Security of DNS data
will be obtained by the Secure DNS [RFC2065], which is mostly
orthogonal to this memo.
５.４.１章は同じくセキュリティと関係がありません。ＤＮＳデータのセキュ
リティがセキュリティＤＮＳ[RFC2065]で得られるでしょうが、ほとんどこの
メモに無関係です。
It is not believed that anything in this document adds to any
security issues that may exist with the DNS, nor does it do anything
to that will necessarily lessen them. Correct implementation of the
clarifications in this document might play some small part in
limiting the spread of non-malicious bad data in the DNS, but only
DNSSEC can help with deliberate attempts to subvert DNS data.
この文書の内容は既存のＤＮＳにセキュリティ問題を追加したりセキュリティ
問題を解決するとは信じられません。この文書の解釈の正しい実装がＤＮＳ
の悪意はないが良くないデータの蔓延を防ぐかもしれません、しかしＤＮＳ
ＳＥＣだけがＤＮＳデータを倒壊させる故意の試みを防ぐことができます。
13. References
13. 参考文献
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - application
and support", STD 3, RFC 1123, January 1989.
[RFC1700] Reynolds, J., Postel, J., "Assigned Numbers",
STD 2, RFC 1700, October 1994.
[RFC2065] Eastlake, D., Kaufman, C., "Domain Name System Security
Extensions", RFC 2065, January 1997.
14. Acknowledgements
14. 謝辞
This memo arose from discussions in the DNSIND working group of the
IETF in 1995 and 1996, the members of that working group are largely
responsible for the ideas captured herein. Particular thanks to
Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
DNSSEC issues in this document, and to John Gilmore for pointing out
where the clarifications were not necessarily clarifying. Bob Halley
suggested clarifying the placement of SOA records in authoritative
answers, and provided the references. Michael Patton, as usual, and
Mark Andrews, Alan Barrett and Stan Barber provided much assistance
with many details. Josh Littlefield helped make sure that the
clarifications didn't cause problems in some irritating corner cases.
このメモは１９９５年と１９９６年のＩＥＴＦのＤＮＳＩＮＤワークグルー
プの論議から生じました、そのワークグループのメンバーは主にここに獲得
する考えに関して責任があります。この文書でＤＮＳＳＥＣ問題の助けに対
してDonald E. Eastlake, 3rdとOlafur Gudmundssonに、そして解釈がはっ
きりしていなかった所に指摘に対してJohn Gilmoreに感謝します。
Bob Halleyは正式な答えでのSOAレコードの配置を明確にすることを提案し
て、参照を供給しました。Michael Pattonと同じくMark Andrewsと
Alan BarrettとStan Barberは多くの細部のたくさんの援助に提供しました。
Josh Littlefieldは解釈があるばかばかしい重箱の隅で問題がおきない事を
確かにするのを手伝いました。
15. Authors' Addresses
15. 著者のアドレス
Robert Elz
Computer Science
University of Melbourne
Parkville, Victoria, 3052
Australia.
EMail: kre@munnari.OZ.AU
Randy Bush
RGnet, Inc.
5147 Crystal Springs Drive NE
Bainbridge Island, Washington, 98110
United States.
EMail: randy@psg.com