RFC 6604 - xNAME RCODE and Status Bits Clarification 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6604
タイトル : RFC 6604 - xNAME RCODEおよびステータスビットの説明
翻訳編集 : 自動生成

[要約] RFC 6604は、DNSプロトコルのxNAME RCODEとステータスビットに関する説明と明確化を提供しています。このRFCの目的は、xNAME RCODEとステータスビットの使用方法と意味を明確にすることです。

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 6604                                        Huawei
Updates: 1035, 2308, 2672                                     April 2012
Category: Standards Track
ISSN: 2070-1721

xNAME RCODE and Status Bits Clarification

xNAME RCODEおよびステータスビットの説明

Abstract

概要

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles.

ドメインネームシステム（DNS）には、CNAME（正規名）などの手段が長く提供されており、DNSクエリを別の名前にリダイレクトできます。 DNS応答ヘッダーには、エラーを示すために使用されるRCODE（応答コード）フィールドと、応答ステータスビットがあります。このドキュメントでは、このようなリダイレクトされたクエリの場合、RCODEとステータスビットが最初のクエリサイクル（CNAMEなどが検出された場所）と後続または最終のクエリサイクルにどのように対応するかについて説明します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6604.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6604で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. Restatement of Status Bits and What They Mean ...................3
      2.1. The Authoritative Answer Bit ...............................3
      2.2. The Authentic Data Bit .....................................3
   3. RCODE Clarification .............................................3
   4. Security Considerations .........................................4
   5. References ......................................................4
      5.1. Normative References .......................................4
      5.2. Informative References .....................................5

1. Introduction

1. はじめに

The Domain Name System (DNS) has long provided means, such as the CNAME (Canonical Name [RFC1035]) and DNAME [RFC2672] RRs (Resource Records), whereby a DNS query can be redirected to a different name. In particular, CNAME normally causes a query to its owner name to be redirected, while DNAME normally causes a query to any lower-level name to be redirected. There has been a proposal for another redirection RR. In addition, as specified in [RFC2672], redirection through a DNAME also results in the synthesis of a CNAME RR in the response. In this document, we will refer to all RRs causing such redirection as xNAME RRs.

ドメインネームシステム（DNS）には、CNAME（正規名[RFC1035]）やDNAME [RFC2672] RR（リソースレコード）などの長い手段があり、それによってDNSクエリを別の名前にリダイレクトできます。特に、CNAMEは通常、所有者名へのクエリをリダイレクトさせ、DNAMEは通常、下位レベルの名前へのクエリをリダイレクトさせます。別のリダイレクトRRの提案がありました。さらに、[RFC2672]で指定されているように、DNAMEを介したリダイレクションでは、応答にCNAME RRも合成されます。このドキュメントでは、リダイレクトを引き起こすすべてのRRをxNAME RRと呼びます。

xNAME RRs can be explicitly retrieved by querying for the xNAME type. When a different type is queried and an xNAME RR is encountered, the xNAME RR (and possibly a synthesized CNAME) is added to the answer in the response, DNS Security Extensions (DNSSEC) [RFC4035] RRs applicable to the xNAME RR may be added to the response, and the query is restarted with the name to which it was redirected.

xNAME RRは、xNAMEタイプを照会することで明示的に取得できます。別のタイプが照会され、xNAME RRが検出されると、xNAME RR（および場合によっては合成されたCNAME）が応答の回答に追加されます。DNSセキュリティ拡張（DNSSEC）[RFC4035] xNAME RRに適用可能なRRが追加される場合があります応答に対して、クエリはリダイレクト先の名前で再起動されます。

An xNAME may redirect a query to a name at which there is another xNAME and so on. In this document, we use "xNAME chain" to refer to a series of one or more xNAMEs each of which refers to another xNAME except the last, which refers to a non-xNAME or results in an error.

xNAMEは、別のxNAMEが存在する名前などにクエリをリダイレクトする場合があります。このドキュメントでは、「xNAMEチェーン」を使用して、それぞれが別のxNAMEを参照する一連の1つ以上のxNAMEを参照します。最後のxNAMEは、非xNAMEを参照するか、エラーになります。

A DNS response header has an RCODE (Response Code) field, used for indicating errors, and status bits that indicate whether an answer is authoritative and/or authentic. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the (first) xNAME was detected) and subsequent or final query cycles.

DNS応答ヘッダーには、エラーを示すために使用されるRCODE（応答コード）フィールドと、回答が信頼できるものか本物であるかを示すステータスビットがあります。このドキュメントでは、このようなリダイレクトされたクエリの場合、RCODEとステータスビットが最初のクエリサイクル（（最初の）xNAMEが検出された場所）と後続または最終のクエリサイクルにどのように対応するかを説明します。

1.1. Conventions Used in This Document

1.1. このドキュメントで使用される規則

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. Restatement of Status Bits and What They Mean

2. ステータスビットの再表示とその意味

There are two status bits returned in query responses for which a question could arise as to how, in the case of an xNAME chain, they relate to the first, possible intermediate, and/or last queries, as below. Note that the following is unchanged from [RFC1035] and [RFC4035]. The meaning of these bits is simply restated here for clarity, because of observations of released implementations that did not follow these meanings.

クエリ応答で返される2つのステータスビットがあり、xNAMEチェーンの場合、以下のように、最初、可能な中間、および/または最後のクエリにどのように関係するかについての質問が発生する可能性があります。以下は[RFC1035]と[RFC4035]から変更されていないことに注意してください。これらの意味に従わなかったリリースされた実装の観察のため、これらのビットの意味は、明確にするためにここで単純に再記載されています。

2.1. The Authoritative Answer Bit

2.1. 信頼できる回答ビット

The AA, or Authoritative Answer bit, in the DNS response header indicates that the answer returned is from a DNS server authoritative for the zone containing that answer. For an xNAME chain, this "authoritative" status could be different for each answer in that chain.

DNS応答ヘッダーのAA、つまりAuthoritative Answerビットは、返された回答が、その回答を含むゾーンに対して信頼できるDNSサーバーからのものであることを示しています。 xNAMEチェーンの場合、この「権限のある」ステータスは、そのチェーンの回答ごとに異なる可能性があります。

[RFC1035] states that the AA bit is to be set based on whether the server providing the answer with the first owner name in the answer section is authoritative. This specification of the AA bit has not been changed.

[RFC1035]は、回答セクションの最初の所有者名で回答を提供するサーバーが信頼できるかどうかに基づいてAAビットが設定されることを述べています。このAAビットの仕様は変更されていません。

2.2. The Authentic Data Bit

2.2. Authentic Data Bit

The AD, or Authentic Data bit, indicates that the response returned is authentic according to the dictates of DNSSEC [RFC4035]. [RFC4035] unambiguously states that the AD bit is to be set in a DNS response header only if the DNSSEC-enabled server believes all RRs in the answer and authority sections of that response to be authentic. This specification of the AD bit has not been changed.

AD、つまりAuthentic Dataビットは、返された応答がDNSSEC [RFC4035]の指示に従って真正であることを示します。 [RFC4035]は、DNSSEC対応サーバーがその応答の回答セクションと権限セクションのすべてのRRが本物であると信じる場合にのみ、DNS応答ヘッダーでADビットが設定されることを明確に述べています。このADビットの仕様は変更されていません。

3. RCODE Clarification

3. RCODEの明確化

The RCODE field in a DNS query response header is non-zero to indicate an error. Section 4.3.2 of [RFC1034] has a resolution algorithm that includes CNAME processing but has been found to be unclear concerning the ultimate setting of RCODE in the case of such redirection. Section 2.1 of [RFC2308] implies that the RCODE should be set based on the last query cycle in the case of an xNAME chain, but Section 2.2.1 of [RFC2308] says that some servers don't do that! When there is an xNAME chain, the RCODE field is set as follows:

DNSクエリ応答ヘッダーのRCODEフィールドは、エラーを示すためにゼロ以外です。 [RFC1034]のセクション4.3.2には、CNAME処理を含む解決アルゴリズムがありますが、そのようなリダイレクトの場合のRCODEの最終的な設定については不明確であることが判明しています。 [RFC2308]のセクション2.1は、xNAMEチェーンの場合、最後のクエリサイクルに基づいてRCODEを設定する必要があることを示唆していますが、[RFC2308]のセクション2.2.1は、一部のサーバーがそれを実行しないと述べています！ xNAMEチェーンがある場合、RCODEフィールドは次のように設定されます。

When an xNAME chain is followed, all but the last query cycle necessarily had no error. The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response. If the xNAME chain was terminated by an error, it will be that error code. If the xNAME chain terminated without error, it will be zero.

xNAMEチェーンがフォローされている場合、最後のクエリサイクルを除くすべてでエラーは発生しませんでした。最終的なDNS応答のRCODEは、その応答につながる最終クエリサイクルに基づいて設定する必要があります。 xNAMEチェーンがエラーによって終了した場合、それはそのエラーコードになります。 xNAMEチェーンがエラーなしで終了した場合、ゼロになります。

4. Security Considerations

4. セキュリティに関する考慮事項

The AA header flag bit is not protected by DNSSEC [RFC4033]. To secure it, secure communications are needed between the querying resolver and the DNS server. Such security can be provided by DNS transaction security, either TSIG [RFC2845] or SIG(0) [RFC2931].

AAヘッダーフラグビットはDNSSEC [RFC4033]によって保護されていません。これを保護するには、クエリを実行するリゾルバとDNSサーバーの間で安全な通信が必要です。このようなセキュリティは、TSIG [RFC2845]またはSIG（0）[RFC2931]のいずれかのDNSトランザクションセキュリティによって提供できます。

An AD header flag bit and the RCODE in a response are not, in general, protected by DNSSEC, so the same conditions as stated in the previous paragraph generally apply to them; however, this is not always true. In particular, if the following apply, then the AD bit and an NXDOMAIN RCODE are protected by DNSSEC in the sense that the querier can calculate whether they are correct:

ADヘッダーフラグビットと応答のRCODEは、通常、DNSSECによって保護されないため、前の段落で述べたのと同じ条件が一般にそれらに適用されます。ただし、これは常に正しいとは限りません。特に、次の条件が当てはまる場合、クエリアが正しいかどうかを計算できるという意味で、ADビットとNXDOMAIN RCODEはDNSSECによって保護されます。

1. The zone where an NXDOMAIN RCODE occurs or all the zones where the data whose authenticity would be indicated by the AD flag bit are signed zones.

1. NXDOMAIN RCODEが発生するゾーン、またはADフラグビットによって信頼性が示されるデータが署名されたゾーンであるすべてのゾーン。

2. The query or queries involved indicate that DNSSEC RRs are OK in responses.

2. 関連するクエリは、DNSSEC RRが応答でOKであることを示しています。

3. The responses providing these indications are from servers that include the additional DNSSEC RRs required by DNSSEC.

3. これらの指標を提供する応答は、DNSSECに必要な追加のDNSSEC RRを含むサーバーからのものです。

4. The querier has appropriate trust anchor(s) and appropriately validates and processes the DNSSEC RRs in the response.

4. クエリアには適切なトラストアンカーがあり、応答でDNSSEC RRを適切に検証および処理します。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999.

[RFC2672]クロフォード、M。、「非端末DNS名リダイレクト」、RFC 2672、1999年8月。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、2005年3月。

5.2. Informative References

5.2. 参考引用

[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.

[RFC2308]アンドリュースM。、「DNSクエリのネガティブキャッシング（DNS NCACHE）」、RFC 2308、1998年3月。

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.

[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSの秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。

[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.

[RFC2931] Eastlake 3rd、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、2000年9月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。

Author's Address

著者のアドレス

Donald E. Eastlake 3rd Huawei R&D USA 155 Beaver Street Milford, MA 01757

ドナルドE.イーストレイク第3ファーウェイR＆D USA 155 Beaver Street Milford、MA 01757

   Phone: +1-508-333-2270
   EMail: d3e3e3@gmail.com