RFC4795 日本語訳
4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D.Thaler, L. Esibov. January 2007. (Format: TXT=71969 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba
Request for Comments: 4795 D. Thaler
Category: Informational L. Esibov
Microsoft Corporation
January 2007
Abobaがコメントのために要求するワーキンググループB.をネットワークでつないでください: 4795年のD.ターレルカテゴリ: 情報のL.Esibovマイクロソフト社2007年1月
Link-Local Multicast Name Resolution (LLMNR)
リンク地方のマルチキャスト名前解決(LLMNR)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
IESG Note
IESG注意
This document was originally intended for advancement as a Proposed Standard, but the IETF did not achieve consensus on the approach. The document has had significant review and input. At time of publication, early versions were implemented and deployed.
このドキュメントは元々、前進のためにProposed Standardとして意図しましたが、IETFはアプローチに関するコンセンサスを達成しませんでした。 ドキュメントには、重要なレビューと入力がありました。 公表の時に、早めのバージョンは、実行されて、配備されました。
Abstract
要約
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and future DNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.
Link地方のMulticast Name Resolution(LLMNR)の目標は従来のDNS名前解決が可能でないシナリオにおける名前解決を可能にすることです。 LLMNRはDNS、および異なったレゾルバキャッシュで別々のポートを作動させている間、すべての現在の、そして、将来のDNS形式、タイプ、およびクラスを支持します。 LLMNRが地方のリンクを作動させるだけであるので、DNSの代用品であるとそれを考えることができません。
Aboba, et al. Informational [Page 1] RFC 4795 LLMNR January 2007
Aboba、他 [1ページ]情報のRFC4795LLMNR2007年1月
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements ...............................................3
1.2. Terminology ................................................4
2. Name Resolution Using LLMNR .....................................4
2.1. LLMNR Packet Format ........................................5
2.1.1. LLMNR Header Format .................................5
2.2. Sender Behavior ............................................8
2.3. Responder Behavior .........................................9
2.4. Unicast Queries and Responses .............................11
2.5. "Off-Link" Detection ......................................11
2.6. Responder Responsibilities ................................12
2.7. Retransmission and Jitter .................................13
2.8. RR TTL ....................................................14
2.9. Use of the Authority and Additional Sections ..............14
3. Usage Model ....................................................15
3.1. LLMNR Configuration .......................................17
4. Conflict Resolution ............................................18
4.1. Uniqueness Verification ...................................19
4.2. Conflict Detection and Defense ............................20
4.3. Considerations for Multiple Interfaces ....................21
4.4. API Issues ................................................22
5. Security Considerations ........................................23
5.1. Denial of Service .........................................23
5.2. Spoofing ..................................................24
5.3. Authentication ............................................25
5.4. Cache and Port Separation .................................25
6. IANA Considerations ............................................26
7. Constants ......................................................26
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
9. Acknowledgments ................................................29
1. 序論…3 1.1. 要件…3 1.2. 用語…4 2. LLMNRを使用する名前解決…4 2.1. LLMNRパケット・フォーマット…5 2.1.1. LLMNRヘッダー形式…5 2.2. 送付者の振舞い…8 2.3. 応答者の振舞い…9 2.4. ユニキャスト質問と応答…11 2.5. 「オフリンク」検出…11 2.6. 応答者責任…12 2.7. Retransmissionとジター…13 2.8. RR TTL…14 2.9. 権威と追加セクションの使用…14 3. 用法モデル…15 3.1. LLMNR構成…17 4. 闘争決議…18 4.1. ユニークさの検証…19 4.2. 闘争検出とディフェンス…20 4.3. 複数のインタフェースへの問題…21 4.4. API問題…22 5. セキュリティ問題…23 5.1. サービス妨害…23 5.2. だまします…24 5.3. 認証…25 5.4. 分離をキャッシュして、移植してください…25 6. IANA問題…26 7. 定数…26 8. 参照…27 8.1. 標準の参照…27 8.2. 有益な参照…27 9. 承認…29
Aboba, et al. Informational [Page 2] RFC 4795 LLMNR January 2007
Aboba、他 [2ページ]情報のRFC4795LLMNR2007年1月
1. Introduction
1. 序論
This document discusses Link-Local Multicast Name Resolution (LLMNR), which is based on the DNS packet format and supports all current and future DNS formats, types, and classes. LLMNR operates on a separate port from the Domain Name System (DNS), with a distinct resolver cache.
このドキュメントは、Link地方のMulticast Name Resolution(LLMNR)について議論して、すべての現在の、そして、将来のDNS形式、タイプ、およびクラスを支持します。(Multicast Name ResolutionはDNSパケット・フォーマットに基づいています)。 LLMNRは異なったレゾルバキャッシュでドメインネームシステム(DNS)から別々のポートを作動させます。
Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS. Link-scope multicast addresses are used to prevent propagation of LLMNR traffic across routers, potentially flooding the network. LLMNR queries can also be sent to a unicast address, as described in Section 2.4.
LLMNRが地方のリンクを作動させるだけであるので、DNSの代用品であるとそれを考えることができません。 ネットワークを潜在的にあふれさせて、リンク範囲マルチキャストアドレスは、ルータの向こう側にLLMNR交通の伝播を防ぐのに使用されます。 また、セクション2.4で説明されるようにLLMNR質問をユニキャストアドレスに送ることができます。
Propagation of LLMNR packets on the local link is considered sufficient to enable name resolution in small networks. In such networks, if a network has a gateway, then typically the network is able to provide DNS server configuration. Configuration issues are discussed in Section 3.1.
地方のリンクにおけるLLMNRパケットの伝播は小さいネットワークで名前解決を可能にするために十分であると考えられます。 そのようなネットワークでは、ネットワークにゲートウェイがあるなら、通常、ネットワークはDNSサーバ構成を提供できます。 セクション3.1で構成問題について議論します。
In the future, it may be desirable to consider use of multicast name resolution with multicast scopes beyond the link-scope. This could occur if LLMNR deployment is successful, the need arises for multicast name resolution beyond the link-scope, or multicast routing becomes ubiquitous. For example, expanded support for multicast name resolution might be required for mobile ad-hoc networks.
将来、マルチキャスト範囲がリンク範囲を超えてある状態でマルチキャスト名前解決の使用を考えるのは望ましいかもしれません。 LLMNR展開がうまくいくなら、これが起こるかもしれませんか、必要性がリンク範囲を超えたマルチキャスト名前解決のために起こるか、またはマルチキャストルーティングは遍在するようになります。 例えば、マルチキャスト名前解決の拡張サポートが可動の臨時のネットワークに必要であるかもしれません。
Once we have experience in LLMNR deployment in terms of administrative issues, usability, and impact on the network, it will be possible to reevaluate which multicast scopes are appropriate for use with multicast name resolution. IPv4 administratively scoped multicast usage is specified in "Administratively Scoped IP Multicast" [RFC2365].
使用に、どのマルチキャストを再評価するかために、範囲がマルチキャスト名前解決で適切であることは、ネットワークへの管理問題、ユーザビリティ、および影響に関して私たちには一度、LLMNR展開の経験があるのが可能でしょう。 IPv4は、マルチキャスト用法が「行政上見られたIPマルチキャスト」[RFC2365]で指定されるのを行政上見ました。
Service discovery in general, as well as discovery of DNS servers using LLMNR in particular, is outside the scope of this document, as is name resolution over non-multicast capable media.
このドキュメントの範囲の外に特に一般に、サービス発見、およびLLMNRを使用するDNSサーバの発見があります、非マルチキャストのできるメディアの上の名前解決のように。
1.1. Requirements
1.1. 要件
In this document, several words are used to signify the requirements of the specification. 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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Aboba, et al. Informational [Page 3] RFC 4795 LLMNR January 2007
Aboba、他 [3ページ]情報のRFC4795LLMNR2007年1月
1.2. Terminology
1.2. 用語
This document assumes familiarity with DNS terminology defined in [RFC1035]. Other terminology used in this document includes:
このドキュメントは[RFC1035]で定義されるDNS用語への親しみを仮定します。 本書では使用される他の用語は:
Routable Address An address other than a link-local address. This
includes globally routable addresses, as well as
private addresses.
リンクローカルアドレス以外のRoutable Address Anアドレス。 これはグローバルに発送可能なアドレス、およびプライベート・アドレスを含んでいます。
Reachable An LLMNR responder considers one of its addresses
reachable over a link if it will respond to an
Address Resolution Protocol (ARP) or Neighbor
Discovery query for that address received on that
link.
そのリンクの上に受け取られたそのアドレスのためのAddress Resolutionプロトコル(ARP)かNeighborディスカバリー質問に応じるなら、届いているAn LLMNR応答者は、リンクの上にアドレスの1つに届いていると考えます。
Responder A host that listens to LLMNR queries, and responds
to those for which it is authoritative.
LLMNRを聞く応答者Aホストが、それが正式であるそれらに質問して、応じます。
Sender A host that sends an LLMNR query.
LLMNR質問を送る送付者Aホスト。
UNIQUE There are some scenarios when multiple responders
may respond to the same query. There are other
scenarios when only one responder may respond to a
query. Names for which only a single responder is
anticipated are referred to as UNIQUE. Name
uniqueness is configured on the responder, and
therefore uniqueness verification is the responder's
responsibility.
複数の応答者が同じ質問に応じるとき、UNIQUE Thereはいくつかのシナリオです。 1人の応答者だけが質問に応じるとき、他のシナリオがあります。 独身の応答者だけが予期される名前はUNIQUEと呼ばれます。 名前のユニークさは応答者の上で構成されます、そして、したがって、ユニークさの検証は応答者の責任です。
2. Name Resolution Using LLMNR
2. LLMNRを使用する名前解決
LLMNR queries are sent to and received on port 5355. The IPv4 link- scope multicast address a given responder listens to, and to which a sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast address a given responder listens to, and to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
LLMNR質問は、5355を送って、ポートの上に受け取ります。 IPv4は与えられた応答者が聞いて、送付者が質問を送る範囲マルチキャストアドレスをリンクして、あります。224.0 .0 .252。 当然のことの応答者が聞いて、どのa送付者がすべてを送るか質問するIPv6リンク範囲マルチキャストアドレスはFF02です:、0:、0:0:0、:、0:1:3
Typically, a host is configured as both an LLMNR sender and a responder. A host MAY be configured as a sender, but not a responder. However, a host configured as a responder MUST act as a sender, if only to verify the uniqueness of names as described in Section 4. This document does not specify how names are chosen or configured. This may occur via any mechanism, including DHCPv4 [RFC2131] or DHCPv6 [RFC3315].
通常、ホストはLLMNR送付者と応答者の両方として構成されます。 ホストは応答者ではなく、送付者として構成されるかもしれません。 しかしながら、応答者として構成されたホストは送付者として務めなければなりません、セクション4で説明されるように名前のユニークさについて確かめるために唯一なら。 このドキュメントは名前が選ばれているか、またはどう構成されるかを指定しません。 これはDHCPv4[RFC2131]かDHCPv6[RFC3315]を含むどんなメカニズムでも起こるかもしれません。
Aboba, et al. Informational [Page 4] RFC 4795 LLMNR January 2007
Aboba、他 [4ページ]情報のRFC4795LLMNR2007年1月
A typical sequence of events for LLMNR usage is as follows:
LLMNR用法のための出来事の典型的な系列は以下の通りです:
(a) An LLMNR sender sends an LLMNR query to the link-scope multicast
address(es), unless a unicast query is indicated, as specified
in Section 2.4.
(a) LLMNR送付者はリンク範囲マルチキャストアドレス(es)にLLMNR質問を送ります、ユニキャスト質問が示されない場合、セクション2.4で指定されるように。
(b) A responder responds to this query only if it is authoritative
for the name in the query. A responder responds to a multicast
query by sending a unicast UDP response to the sender. Unicast
queries are responded to as indicated in Section 2.4.
(b) 質問における名前に、それが正式である場合にだけ、応答者はこの質問に応じます。 応答者は、ユニキャストUDP応答を送付者に送ることによって、マルチキャスト質問に応じます。 セクション2.4にみられるようにユニキャスト質問に応じます。
(c) Upon reception of the response, the sender processes it.
(c) 応答のレセプションに、送付者はそれを処理します。
The sections that follow provide further details on sender and responder behavior.
従うセクションは送付者と応答者の振舞いに関する詳細を提供します。
2.1. LLMNR Packet Format
2.1. LLMNRパケット・フォーマット
LLMNR is based on the DNS packet format defined in [RFC1035] Section 4 for both queries and responses. LLMNR implementations SHOULD send UDP queries and responses only as large as are known to be permissible without causing fragmentation. When in doubt, a maximum packet size of 512 octets SHOULD be used. LLMNR implementations MUST accept UDP queries and responses as large as the smaller of the link MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22 octets for the header, VLAN tag and Cyclic Redundancy Check (CRC)).
LLMNRは質問と応答の両方のために[RFC1035]セクション4で定義されたDNSパケット・フォーマットに基づいています。 断片化を引き起こさないで、LLMNR実現SHOULDは許されるように単に知られているのと同じくらい大きい状態でUDP質問と応答を送ります。 いつが、中でSHOULDが使用されるのを512の八重奏の最大のパケットサイズに疑問に思っていますか? LLMNR実現は、UDP質問と応答がリンクMTUか9194年の八重奏(ヘッダー、VLANタグ、およびCyclic Redundancy Check(CRC)のための22の八重奏を引いた9KB(9216)のイーサネットジャンボフレーム・サイズ)で、より小さいとして大きいと受け入れなければなりません。
2.1.1. LLMNR Header Format
2.1.1. LLMNRヘッダー形式
LLMNR queries and responses utilize the DNS header format defined in [RFC1035] with exceptions noted below:
LLMNR質問と応答は例外が以下に述べられている状態で[RFC1035]で定義されたDNSヘッダー形式を利用します:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode| C|Tc| T| Z| Z| Z| Z| RCODE| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Aboba, et al. Informational [Page 5] RFC 4795 LLMNR January 2007
Aboba、他 [5ページ]情報のRFC4795LLMNR2007年1月
where:
どこ:
ID A 16-bit identifier assigned by the program that generates
any kind of query. This identifier is copied from the query
to the response and can be used by the sender to match
responses to outstanding queries. The ID field in a query
SHOULD be set to a pseudo-random value. For advice on
generation of pseudo-random values, please consult [RFC4086].
16ビットの識別子がプログラムでそれを割り当てたID Aはどんな種類の質問も発生させます。 この識別子を質問から応答までコピーして、送付者は、傑出している質問への応答に合うのに使用できます。 IDは擬似ランダムへのセットが値であったなら質問でSHOULDをさばきます。 擬似ランダム値の世代のアドバイスを求めて、[RFC4086]に相談してください。
QR Query/Response. A 1-bit field, which, if set, indicates that
the message is an LLMNR response; if clear, then the message
is an LLMNR query.
QR質問/応答。 1ビットの分野(設定されるならそれは、メッセージがLLMNR応答であることを示します)。 明確であるなら、メッセージはLLMNR質問です。
OPCODE A 4-bit field that specifies the kind of query in this
message. This value is set by the originator of a query and
copied into the response. This specification defines the
behavior of standard queries and responses (opcode value of
zero). Future specifications may define the use of other
opcodes with LLMNR. LLMNR senders and responders MUST
support standard queries (opcode value of zero). LLMNR
queries with unsupported OPCODE values MUST be silently
discarded by responders.
このメッセージの質問の種類を指定するOPCODEのA4ビットの分野。 この値は、質問の創始者によって設定されて、応答にコピーされます。 この仕様は標準の質問と応答(ゼロのopcode値)の振舞いを定義します。 将来の仕様はLLMNRとの他のopcodesの使用を定義するかもしれません。 LLMNR送付者と応答者は標準の質問(ゼロのopcode値)を支持しなければなりません。 応答者は静かにサポートされないOPCODE値があるLLMNR質問を捨てなければなりません。
C Conflict. When set within a query, the 'C'onflict bit
indicates that a sender has received multiple LLMNR responses
to this query. In an LLMNR response, if the name is
considered UNIQUE, then the 'C' bit is clear; otherwise, it
is set. LLMNR senders do not retransmit queries with the 'C'
bit set. Responders MUST NOT respond to LLMNR queries with
the 'C' bit set, but may start the uniqueness verification
process, as described in Section 4.2.
C闘争。 質問の中に設定されると、'C'onflictビットは、送付者が複数のLLMNR応答を受けたのをこの質問に示します'。 LLMNR応答では、名前がUNIQUEであると考えられるなら、'C'ビットは明確です。 さもなければ、それは設定されます。 'C'ビットがセットした状態で、LLMNR送付者は質問を再送しません。 応答者はセクション4.2で説明されるようにユニークさの検証の過程を始めるかもしれない以外に、設定された'C'ビットでLLMNR質問に応じてはいけません。
TC TrunCation. The 'TC' bit specifies that this message was
truncated due to length greater than that permitted on the
transmission channel. The 'TC' bit MUST NOT be set in an
LLMNR query and, if set, is ignored by an LLMNR responder.
If the 'TC' bit is set in an LLMNR response, then the sender
SHOULD resend the LLMNR query over TCP using the unicast
address of the responder as the destination address. If the
sender receives a response to the TCP query, then it SHOULD
discard the UDP response with the TC bit set. See [RFC2181]
and Section 2.4 of this specification for further discussion
of the 'TC' bit.
Tcトランケーション。 'TC'ビットは、このメッセージがそれがトランスミッションチャンネルの上に可能にしたより大きい長さのため先端を切られたと指定します。 'TC'ビットは、LLMNR質問で設定されてはいけなくて、設定されるなら、LLMNR応答者によって無視されます。 'TC'ビットがLLMNR応答で設定されるなら、送付者SHOULDは、送付先アドレスとして応答者のユニキャストアドレスを使用することでTCPの上にLLMNR質問を再送します。 送付者はTCP質問へのa応答を受けて、次に、それはTCビットによるUDP応答が設定するSHOULD破棄です。 'TC'ビットのさらなる議論のためのこの仕様の[RFC2181]とセクション2.4を見てください。
T Tentative. The 'T'entative bit is set in a response if the
responder is authoritative for the name, but has not yet
verified the uniqueness of the name. A responder MUST ignore
the 'T' bit in a query, if set. A response with the 'T' bit
T一時的です。 'T'entativeビットは、名前に、応答者が正式であるなら応答で設定されますが、まだ名前のユニークさについて確かめていません'。 設定されるなら、応答者は質問で'T'ビットを無視しなければなりません。 'T'ビットによる応答
Aboba, et al. Informational [Page 6] RFC 4795 LLMNR January 2007
Aboba、他 [6ページ]情報のRFC4795LLMNR2007年1月
set is silently discarded by the sender, except if it is a
uniqueness query, in which case, a conflict has been detected
and a responder MUST resolve the conflict as described in
Section 4.1.
ケース、闘争がそれがユニークさの質問である、どれであるかに検出されるのを除いて、セットは送付者によって静かに捨てられます、そして、応答者はセクション4.1で説明されるように対立を解決しなければなりません。
Z Reserved for future use. Implementations of this
specification MUST set these bits to zero in both queries and
responses. If these bits are set in a LLMNR query or
response, implementations of this specification MUST ignore
them. Since reserved bits could conceivably be used for
different purposes than in DNS, implementers are advised not
to enable processing of these bits in an LLMNR implementation
starting from a DNS code base.
今後の使用のために予約されたZ。 この仕様の実現は質問と応答の両方のゼロにこれらのビットを設定しなければなりません。 これらのビットがLLMNR質問か応答で設定されるなら、この仕様の実現はそれらを無視しなければなりません。 異なる役割に多分DNSより予約されたビットを使用できたので、implementersがDNSコードベースから始めるLLMNR実現における、これらのビットの処理を可能にしないようにアドバイスされます。
RCODE Response code. This 4-bit field is set as part of LLMNR
responses. In an LLMNR query, the sender MUST set RCODE to
zero; the responder ignores the RCODE and assumes it to be
zero. The response to a multicast LLMNR query MUST have
RCODE set to zero. A sender MUST silently discard an LLMNR
response with a non-zero RCODE sent in response to a
multicast query.
RCODE Responseコード。 この4ビットの分野はLLMNR応答の一部として設定されます。 LLMNR質問では、送付者はゼロにRCODEを設定しなければなりません。 応答者は、RCODEを無視して、それがゼロであると仮定します。 マルチキャストLLMNR質問への応答で、ゼロにRCODEを用意ができさせなければなりません。 送付者は静かに非ゼロRCODEをマルチキャスト質問に対応した送付でLLMNR応答を捨てなければなりません。
If an LLMNR responder is authoritative for the name in a
multicast query, but an error is encountered, the responder
SHOULD send an LLMNR response with an RCODE of zero, no RRs
in the answer section, and the TC bit set. This will cause
the query to be resent using TCP, and allow the inclusion of
a non-zero RCODE in the response to the TCP query.
Responding with the TC bit set is preferable to not sending a
response, since it enables errors to be diagnosed. This may
be required, for example, when an LLMNR query includes a TSIG
RR in the additional section, and the responder encounters a
problem that requires returning a non-zero RCODE. TSIG error
conditions defined in [RFC2845] include a TSIG RR in an
unacceptable position (RCODE=1) or a TSIG RR that does not
validate (RCODE=9 with TSIG ERROR 17 (BADKEY) or 16
(BADSIG)).
マルチキャスト質問における名前に、LLMNR応答者が正式ですが、誤りが遭遇するなら、応答者SHOULDはゼロのRCODEとのLLMNR応答を送ります、答え部でどんなRRs、そして、TCビットがセットしませんでした。 これは、TCP質問への応答で質問がTCPを使用するのが再送されることを引き起こして、非ゼロRCODEの包含を許容するでしょう。 TCビットがセットして応じるのはそれが、誤りが診断されるのを可能にするので応答を送らないより望ましいです。 LLMNR質問が追加セクションにTSIG RRを含んで、応答者が非ゼロRCODEを返すのを必要とする問題に行きあたるとき、例えば、これが必要であるかもしれません。 [RFC2845]で定義されたTSIGエラー条件は容認できない位置(RCODE=1)か(TSIG ERROR17(BADKEY)か16(BADSIG)があるRCODE=9)を有効にしないTSIG RRにTSIG RRを含んでいます。
Since LLMNR responders only respond to LLMNR queries for
names for which they are authoritative, LLMNR responders MUST
NOT respond with an RCODE of 3; instead, they should not
respond at all.
LLMNR応答者がそれらが正式である名前のためのLLMNR質問に応じるだけであるので、LLMNR応答者は3のRCODEと共に応じてはいけません。 代わりに、彼らは全く応じるべきではありません。
LLMNR implementations MUST support EDNS0 [RFC2671] and
extended RCODE values.
LLMNR実現はEDNS0[RFC2671]と拡張RCODE値を支持しなければなりません。
Aboba, et al. Informational [Page 7] RFC 4795 LLMNR January 2007
Aboba、他 [7ページ]情報のRFC4795LLMNR2007年1月
QDCOUNT An unsigned 16-bit integer specifying the number of entries
in the question section. A sender MUST place only one
question into the question section of an LLMNR query. LLMNR
responders MUST silently discard LLMNR queries with QDCOUNT
not equal to one. LLMNR senders MUST silently discard LLMNR
responses with QDCOUNT not equal to one.
質問部のエントリーの数を指定するQDCOUNT Anの無記名の16ビットの整数。 送付者はLLMNR質問の質問部に1つの質問だけを置かなければなりません。 LLMNR応答者は静かに1つと等しくないQDCOUNTとのLLMNR質問を捨てなければなりません。 LLMNR送付者は静かに1つと等しくないQDCOUNTとのLLMNR応答を捨てなければなりません。
ANCOUNT An unsigned 16-bit integer specifying the number of resource
records in the answer section. LLMNR responders MUST
silently discard LLMNR queries with ANCOUNT not equal to
zero.
答え部のリソース記録の数を指定するANCOUNT Anの無記名の16ビットの整数。 LLMNR応答者は静かにゼロに合わせるために等しくないANCOUNTとのLLMNR質問を捨てなければなりません。
NSCOUNT An unsigned 16-bit integer specifying the number of name
server resource records in the authority records section.
Authority record section processing is described in Section
2.9. LLMNR responders MUST silently discard LLMNR queries
with NSCOUNT not equal to zero.
権威における、ネームサーバリソース記録の数を指定するNSCOUNT Anの無記名の16ビットの整数がセクションを記録します。 権威記録断面処理はセクション2.9で説明されます。 LLMNR応答者は静かにゼロに合わせるために等しくないNSCOUNTとのLLMNR質問を捨てなければなりません。
ARCOUNT An unsigned 16-bit integer specifying the number of resource
records in the additional records section. Additional record
section processing is described in Section 2.9.
追加記録部のリソース記録の数を指定するARCOUNT Anの無記名の16ビットの整数。 追加記録断面処理はセクション2.9で説明されます。
2.2. Sender Behavior
2.2. 送付者の振舞い
A sender MAY send an LLMNR query for any legal resource record type (e.g., A, AAAA, PTR, SRV) to the link-scope multicast address. As described in Section 2.4, a sender MAY also send a unicast query.
送付者はどんな法的なリソースレコード種類(例えば、A、AAAA、PTR、SRV)のためのLLMNR質問もリンク範囲マルチキャストアドレスに送るかもしれません。 また、セクション2.4で説明されるように、送付者はユニキャスト質問を送るかもしれません。
The sender MUST anticipate receiving no responses to some LLMNR queries, in the event that no responders are available within the link-scope. If no response is received, a resolver treats it as a response that the name does not exist (RCODE=3 is returned). A sender can handle duplicate responses by discarding responses with a source IP address and ID field that duplicate a response already received.
送付者は、いくつかのLLMNR質問への応答を全く受けると予期してはいけません、どんな応答者もリンク範囲の中に手があいていない場合。 どんな応答も受け取られていないなら、名前がする応答が存在していなくて(RCODE=3を返します)、レゾルバはそれを扱います。 送付者は、既に受けられた応答をコピーするソースIPアドレスとID分野で応答を捨てることによって、写し応答を扱うことができます。
When multiple valid LLMNR responses are received with the 'C' bit set, they SHOULD be concatenated and treated in the same manner that multiple RRs received from the same DNS server would be. However, responses with the 'C' bit set SHOULD NOT be concatenated with responses with the 'C' bit clear; instead, only the responses with the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are received along with error response(s), then the error responses are silently discarded.
いつ'C'と共に複数の有効なLLMNR応答を受けるかに設定していた状態で噛み付いて、それらは連結されて、同じDNSサーバから受け取られた複数のRRsが方法でしょうが、同じくらいで扱われたSHOULDです。 しかしながら、'C'ビットセットSHOULD NOTが'C'ビットによる応答で連結される応答はクリアされます。 'C'ビットセットSHOULDを返している応答だけ。 誤り応答と共に有効なLLMNR応答を受けるなら、静かに誤り応答を捨てます。
Since the responder may order the RRs in the response so as to indicate preference, the sender SHOULD preserve ordering in the response to the querying application.
応答者が好みを示すために応答でRRsを注文するかもしれないので、送付者SHOULDは質問アプリケーションへの応答における注文を保存します。
Aboba, et al. Informational [Page 8] RFC 4795 LLMNR January 2007
Aboba、他 [8ページ]情報のRFC4795LLMNR2007年1月
2.3. Responder Behavior
2.3. 応答者の振舞い
An LLMNR response MUST be sent to the sender via unicast.
ユニキャストでLLMNR応答を送付者に送らなければなりません。
Upon configuring an IP address, responders typically will synthesize corresponding A, AAAA and PTR RRs so as to be able to respond to LLMNR queries for these RRs. An SOA RR is synthesized only when a responder has another RR in addition to the SOA RR; the SOA RR MUST NOT be the only RR that a responder has. However, in general, whether RRs are manually or automatically created is an implementation decision.
IPアドレスを構成すると、応答者は、これらのRRsのためにLLMNR質問に応じることができるように対応するA、AAAA、およびPTR RRsを通常統合するでしょう。 応答者がSOA RRに加えて別のRRを持っている場合にだけ、SOA RRは統合されます。 SOA RR MUST NOT、応答者が持っている唯一のRRになってください。 しかしながら、一般に、RRsが手動的か自動的に作成されるかどうかが、実現決定です。
For example, a host configured to have computer name "host1" and to be a member of the "example.com" domain, with IPv4 address 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6, might be authoritative for the following records:
そして、例えば、ホストが、コンピュータ名を持っているのを構成した、「host1"、IPv4がある"example.com"ドメインのメンバーに、なるように、192.0の.2の.1とIPv6アドレス2001: 0DB8を記述してください:、:、」1:2:3:FF:FE: 以下の記録に、4:5:6は正式であるかもしれません:
host1. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
host1。 A192.0.2.1IN AAAA2001: 0DB8で:、:1:2:3:ff:FE:4:5:6
host1.example.com. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
host1.example.com。 A192.0.2.1IN AAAA2001: 0DB8で:、:1:2:3:ff:FE:4:5:6
1.2.0.192.in-addr.arpa. IN PTR host1.
IN PTR host1.example.com.
addr.arpaの1.2.0.192.。 IN PTR host1。 IN PTR host1.example.com。
6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
ip6.arpa IN PTR host1. (line split for formatting reasons)
IN PTR host1.example.com.
6.0.5.0.4.0. E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b. d.0.1.0.0.2ip6.arpa IN PTR host1。 (形式理由で分けられた線) IN PTR host1.example.com。
An LLMNR responder might be further manually configured with the name of a local mail server with an MX RR included in the "host1." and "host1.example.com." records.
MX RRが"host1"に含まれている状態で、LLMNR応答者はローカルのメールサーバの名前によってさらに手動で構成されるかもしれません。. "host1.example.com" 記録。
In responding to queries:
質問に応じる際に:
(a) Responders MUST listen on UDP port 5355 on the link-scope
multicast address(es) defined in Section 2, and on TCP port 5355
on the unicast address(es) that could be set as the source
address(es) when the responder responds to the LLMNR query.
(a) 応答者は、リンク範囲マルチキャストアドレス(es)に関する5355がセクション2で定義したUDPポートの上で聴いて、応答者がLLMNR質問に応じるソースアドレス(es)として設定できたユニキャストアドレス(es)に関する5355年をTCPに移植しなければなりません。
(b) Responders MUST direct responses to the port from which the
query was sent. When queries are received via TCP, this is an
inherent part of the transport protocol. For queries received
by UDP, the responder MUST take note of the source port and use
that as the destination port in the response. Responses MUST
always be sent from the port to which they were directed.
(b) 応答者は質問が送られたポートへの応答を指示しなければなりません。 TCPを通して質問を受けるとき、これはトランスポート・プロトコルの固有の部分です。 UDPによって受けられた質問のために、応答者は、ソース港に注目して、仕向港として応答にそれを使用しなければなりません。 それらが向けられたポートから応答をいつも送らなければなりません。
Aboba, et al. Informational [Page 9] RFC 4795 LLMNR January 2007
Aboba、他 [9ページ]情報のRFC4795LLMNR2007年1月
(c) Responders MUST respond to LLMNR queries for names and addresses
for which they are authoritative. This applies to both forward
and reverse lookups, with the exception of queries with the 'C'
bit set, which do not elicit a response.
(c) 応答者はそれらが正式である名前とアドレスのためのLLMNR質問に応じなければなりません。 これはともにルックアップを進めて、逆にするのに申し込みます、'C'ビットがセットしたことでの質問を除いて。(質問は応答を引き出しません)。
(d) Responders MUST NOT respond to LLMNR queries for names for which
they are not authoritative.
(d) 応答者はそれらが正式でない名前のためのLLMNR質問に応じてはいけません。
(e) Responders MUST NOT respond using data from the LLMNR or DNS
resolver cache.
(e) LLMNRかDNSレゾルバキャッシュからのデータを使用して、応答者は応じてはいけません。
(f) If a responder is authoritative for a name, it MUST respond with
RCODE=0 and an empty answer section, if the type of query does
not match an RR that the responder has.
(f) 名前に、応答者が正式であるなら、RCODE=0と空の答え部で応じなければなりません、質問のタイプが応答者が持っているRRに合っていないなら。
As an example, a host configured to respond to LLMNR queries for the name "foo.example.com." is authoritative for the name "foo.example.com.". On receiving an LLMNR query for an A RR with the name "foo.example.com.", the host authoritatively responds with an A RR(s) that contain IP address(es) in the RDATA of the resource record. If the responder has an AAAA RR, but no A RR, and an A RR query is received, the responder would respond with RCODE=0 and an empty answer section.
例として、ホストが、名前"foo.example.com"のためにLLMNR質問に応じるのを構成した、"foo.example.com"という名前において、正式です。 A RRのために"foo.example.com"という名前でLLMNR質問を受けることに関して応じる、ホストはリソース記録のRDATAにIPアドレス(es)を含むA RR(s)と共に厳然と応じます。 AAAA RRを持っていますが、応答者がどんなA RRも持たないで、A RR質問が受け取られているなら、応答者はRCODE=0と空の答え部で応じるでしょう。
In conventional DNS terminology, a DNS server authoritative for a zone is authoritative for all the domain names under the zone apex except for the branches delegated into separate zones. Contrary to conventional DNS terminology, an LLMNR responder is authoritative only for the zone apex.
従来のDNS用語では、別々のゾーンへ代表として派遣されたブランチ以外のゾーンの頂点の下のすべてのドメイン名に、ゾーンに、正式のDNSサーバは正式です。 従来のDNS用語とは逆に、ゾーンの頂点だけに、LLMNR応答者は正式です。
For example, the host "foo.example.com." is not authoritative for the name "child.foo.example.com." unless the host is configured with multiple names, including "foo.example.com." and "child.foo.example.com.". As a result, "foo.example.com." cannot respond to an LLMNR query for "child.foo.example.com." with RCODE=3 (authoritative name error). The purpose of limiting the name authority scope of a responder is to prevent complications that could be caused by coexistence of two or more hosts with the names representing child and parent (or grandparent) nodes in the DNS tree, for example, "foo.example.com." and "child.foo.example.com.".
例えば、ホスト"foo.example.com"、正式でない、名前"child.foo.example.com" ホストが"foo.example.com" "child.foo.example.com"を含む複数の名前によって構成されない場合。 aが結果として生じる間、"foo.example.com"であることは"child.foo.example.com"のためにLLMNR質問に応じることができません。. RCODE=3(正式の名前誤り)と共に。 応答者の名前権威範囲を制限する目的は例えば、DNS木の"foo.example.com" "child.foo.example.com"という子供と親(または、祖父)ノードを表す名前との2人以上のホストの共存で引き起こされる場合があった複雑さを防ぐことです。
Without the restriction on authority, an LLMNR query for an A resource record for the name "child.foo.example.com." would result in two authoritative responses: RCODE=3 (authoritative name error) received from "foo.example.com.", and a requested A record from "child.foo.example.com.". To prevent this ambiguity, LLMNR-enabled hosts could perform a dynamic update of the parent (or grandparent) zone with a delegation to a child zone; for example, a host
権威における制限がなければ、AリソースのためのLLMNR質問は"child.foo.example.com"という名前のために記録します。2つの正式の応答をもたらすでしょう: RCODE=3(正式の名前誤り)は"foo.example.com" "child.foo.example.com"からの要求されたA記録から受信しました。 このあいまいさを防ぐために、LLMNRによって可能にされたホストは代表団との親(または、祖父)ゾーンのダイナミックなアップデートを子供ゾーンに実行できました。 例えば、ホスト
Aboba, et al. Informational [Page 10] RFC 4795 LLMNR January 2007
Aboba、他 [10ページ]情報のRFC4795LLMNR2007年1月
"child.foo.example.com." could send a dynamic update for the NS and glue A record to "foo.example.com.". However, this approach significantly complicates implementation of LLMNR and would not be acceptable for lightweight hosts.
"child.foo.example.com" NSと接着剤A記録のためのダイナミックなアップデートを"foo.example.com"に送ることができました。 しかしながら、このアプローチは、LLMNRの実現をかなり複雑にして、ライト級のホストにとって、許容できないでしょう。
2.4. Unicast Queries and Responses
2.4. ユニキャスト質問と応答
Unicast queries SHOULD be sent when:
ユニキャストはSHOULDについて質問します。いつを送ってくださいか:
(a) A sender repeats a query after it received a response with the TC
bit set to the previous LLMNR multicast query, or
または(a) 前のLLMNRマルチキャスト質問に設定されたTCビットで応答を受けた後に送付者が質問を繰り返す。
(b) The sender queries for a PTR RR of a fully formed IP address
within the "in-addr.arpa" or "ip6.arpa" zones.
(b) 完全に形成されたIPのPTR RRのための送付者質問は「addr.arpa」か"ip6.arpa"の中でゾーンを扱います。
Unicast LLMNR queries MUST be done using TCP and the responses MUST be sent using the same TCP connection as the query. Senders MUST support sending TCP queries, and responders MUST support listening for TCP queries. If the sender of a TCP query receives a response to that query not using TCP, the response MUST be silently discarded.
TCPを使用しユニキャストLLMNR質問を終わらなければなりません、そして、応答に質問と同じTCP接続を使用させなければなりません。 TCP質問の聞こうとして、SendersはTCPが質問して、応答者がサポートしなければならない発信をサポートしなければなりません。 TCP質問の送付者がTCPを使用しないことでその質問への応答を受けるなら、静かに応答を捨てなければなりません。
Unicast UDP queries MUST be silently discarded.
静かにユニキャストUDP質問を捨てなければなりません。
A unicast PTR RR query for an off-link address will not elicit a response, but instead, an ICMP Time to Live (TTL) or Hop Limit exceeded message will be received. An implementation receiving an ICMP message in response to a TCP connection setup attempt can return immediately, treating this as a response that no such name exists (RCODE=3 is returned). An implementation that cannot process ICMP messages MAY send multicast UDP queries for PTR RRs. Since TCP implementations will not retransmit prior to RTOmin, a considerable period will elapse before TCP retransmits multiple times, resulting in a long timeout for TCP PTR RR queries sent to an off-link destination.
PTR RRがオフリンクアドレスのために質問するユニキャストは応答を引き出すのではなく、代わりにLive(TTL)か超えられていたHop LimitへのICMP Timeを引き出すでしょう。メッセージを受け取るでしょう。 TCP接続設定試みに対応してICMPメッセージを受け取るとすぐに返すことができる実装、応答としてこれを扱って、そのようなものが命名するそのノーは存在しています(RCODE=3を返します)。 ICMPメッセージを処理できない実装はPTR RRsのためにマルチキャストUDP質問を送るかもしれません。 TCP実装がRTOminの前で再送されないので、TCPが複数の回を再送する前に、かなりの期間が経過するでしょう、オフリンクの目的地に送られたTCP PTR RR質問のための長いタイムアウトをもたらして。
2.5. "Off-Link" Detection
2.5. 「オフリンク」検出
A sender MUST select a source address for LLMNR queries that is assigned on the interface on which the query is sent. The destination address of an LLMNR query MUST be a link-scope multicast address or a unicast address.
送付者はLLMNR質問のための質問が送られるインタフェースで割り当てられるソースアドレスを選択しなければなりません。 LLMNR質問の送付先アドレスは、リンク範囲マルチキャストアドレスかユニキャストアドレスであるに違いありません。
A responder MUST select a source address for responses that is assigned on the interface on which the query was received. The destination address of an LLMNR response MUST be a unicast address.
応答者は応答のための質問が受けられたインタフェースで割り当てられるソースアドレスを選択しなければなりません。 LLMNR応答の送付先アドレスはユニキャストアドレスであるに違いありません。
Aboba, et al. Informational [Page 11] RFC 4795 LLMNR January 2007
Aboba、他 [11ページ]情報のRFC4795LLMNR2007年1月
On receiving an LLMNR query, the responder MUST check whether it was sent to an LLMNR multicast addresses defined in Section 2. If it was sent to another multicast address, then the query MUST be silently discarded.
LLMNR質問を受けると、応答者は、それがアドレスがセクション2で定義したLLMNRマルチキャストに送られたかどうかチェックしなければなりません。 別のマルチキャストアドレスにそれを送ったなら、静かに質問を捨てなければなりません。
Section 2.4 discusses use of TCP for LLMNR queries and responses. In composing an LLMNR query using TCP, the sender MUST set the Hop Limit field in the IPv6 header and the TTL field in the IPv4 header of the response to one (1). The responder SHOULD set the TTL or Hop Limit settings on the TCP listen socket to one (1) so that SYN-ACK packets will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming connection from off-link since the sender will not receive a SYN-ACK from the responder.
セクション2.4はTCPのLLMNR質問と応答の使用について論じます。 TCPを使用することでLLMNR質問を構成するのを、送付者は、1つ(1)への応答のIPv4ヘッダーのIPv6ヘッダーとTTL分野にHop Limit分野をはめ込まなければなりません。 SYN-ACKパケットで、TTL(IPv4)かHop Limit(IPv6)を1つ(1)に用意ができさせるように応答者SHOULDがTTLを設定するか、またはTCPでのHop Limit設定は、1つ(1)までソケットを聴きます。 送付者が応答者からSYN-ACKを受け取らないので、これはオフリンクから接続要求を防ぎます。
For UDP queries and responses, the Hop Limit field in the IPv6 header and the TTL field in the IPV4 header MAY be set to any value. However, it is RECOMMENDED that the value 255 be used for compatibility with early implementations of [RFC3927].
UDP質問と応答において、IPv6ヘッダーのHop Limit分野とIPV4ヘッダーのTTL分野はどんな値にも設定されるかもしれません。 しかしながら、値255が[RFC3927]の早めの実装との互換性に使用されるのは、RECOMMENDEDです。
Implementation note:
実装注意:
In the sockets API for IPv4 [POSIX], the IP_TTL and
IP_MULTICAST_TTL socket options are used to set the TTL of
outgoing unicast and multicast packets. The IP_RECVTTL socket
option is available on some platforms to retrieve the IPv4 TTL of
received packets with recvmsg(). [RFC3542] specifies similar
options for setting and retrieving the IPv6 Hop Limit.
IPv4[POSIX]のためのソケットAPIでは、IP_TTLとIP_MULTICAST_TTLソケットオプションは、外向的なユニキャストとマルチキャストパケットのTTLを設定するのに使用されます。 IP_RECVTTLソケットオプションはrecvmsg()で容認されたパケットのIPv4 TTLを検索するいくつかのプラットホームで利用可能です。 [RFC3542]はIPv6 Hop Limitを設定して、検索するための同様のオプションを指定します。
2.6. Responder Responsibilities
2.6. 応答者責任
It is the responsibility of the responder to ensure that RRs returned in LLMNR responses MUST only include values that are valid on the local interface, such as IPv4 or IPv6 addresses valid on the local link or names defended using the mechanism described in Section 4. IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local addresses are defined in [RFC4291]. In particular:
局所界面で有効であるのは、応答者が、LLMNR応答で返されたRRsが値を含むだけでよいのを保証する責任です、IPv4、地方のリンクで妥当なIPv6アドレスまたはセクション4で説明されたメカニズムを使用することで防御された名前のように。 IPv4 Linkローカルのアドレスは[RFC3927]で定義されます。 IPv6 Linkローカルのアドレスは[RFC4291]で定義されます。 特に:
(a) If a link-scope IPv6 address is returned in a AAAA RR, that
address MUST be valid on the local link over which LLMNR is used.
(a) AAAA RRでリンク範囲IPv6アドレスを返すなら、そのアドレスはLLMNRが使用されている地方のリンクで有効であるに違いありません。
(b) If an IPv4 address is returned, it MUST be reachable through the
link over which LLMNR is used.
(b) IPv4アドレスを返すなら、リンクを通ってLLMNRが使用されている届いているに違いありません。
(c) If a name is returned (for example in a CNAME, MX, or SRV RR),
the name MUST be resolvable on the local link over which LLMNR is
used.
(c) 名前を返すなら(例えば、CNAME、MX、またはSRV RRで)、名前はLLMNRが使用されている地方のリンクで溶解性であるに違いありません。
Aboba, et al. Informational [Page 12] RFC 4795 LLMNR January 2007
Aboba、他 [12ページ]情報のRFC4795LLMNR2007年1月
Where multiple addresses represent valid responses to a query, the order in which the addresses are returned is as follows:
複数のアドレスが有効回答を質問に表すところでは、アドレスが返されるオーダーは以下の通りです:
(d) If the source address of the query is a link-scope address, then
the responder SHOULD include a link-scope address first in the
response, if available.
(d) 応答者SHOULDは質問のソースアドレスがリンク範囲アドレスであるなら最初に、応答にリンク範囲アドレスを含んでいます、利用可能であるなら。
(e) If the source address of the query is a routable address, then
the responder MUST include a routable address first in the
response, if available.
(e) 応答者は質問のソースアドレスが発送可能アドレスであるなら最初に、応答で発送可能アドレスを入れなければなりません、利用可能であるなら。
2.7. Retransmission and Jitter
2.7. Retransmissionとジター
An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine when to retransmit an LLMNR query. An LLMNR sender SHOULD either estimate the LLMNR_TIMEOUT for each interface or set a reasonably high initial timeout. Suggested constants are described in Section 7.
LLMNR送付者は、いつLLMNR質問を再送するかを決定するのにタイムアウト間隔LLMNR_TIMEOUTを使用します。 LLMNR送付者SHOULDはLLMNR_がTIMEOUTであると各インタフェースに見積もっているか、またはかなり高い初期のタイムアウトを設定します。 提案された定数はセクション7で説明されます。
If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT, then a sender SHOULD repeat the transmission of the query in order to ensure that it was received by a host capable of responding to it. An LLMNR query SHOULD NOT be sent more than three times.
UDPの上に送られたLLMNR質問がLLMNR_TIMEOUTの中で決議されていないなら、送付者SHOULDは、それがそれに応じることができるホストによって受け取られたのを確実にするために質問の送信を繰り返します。 LLMNRは3送られた以上が回であったならSHOULD NOTについて質問します。
Where LLMNR queries are sent using TCP, retransmission is handled by the transport layer. Queries with the 'C' bit set MUST be sent using multicast UDP and MUST NOT be retransmitted.
LLMNR質問にTCPを使用させるところでは、「再-トランスミッション」はトランスポート層によって扱われます。 'C'ビットがセットしたことでの質問は、マルチキャストUDPを使用させなければならなくて、再送されてはいけません。
An LLMNR sender cannot know in advance if a query sent using multicast will receive no response, one response, or more than one response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response has been received, or if it is necessary to collect all potential responses, such as if a uniqueness verification query is being made. Otherwise, an LLMNR sender SHOULD consider a multicast query answered after the first response is received, if that response has the 'C' bit clear.
LLMNR送付者はあらかじめ、マルチキャストが使用させられた質問が応答を全く受けないだろうか、そして、1つの応答、または1つ以上の応答を知ることができません。 応答を全く受けていないか、またはすべての潜在的応答を集めるのが必要であるなら、LLMNR送付者はLLMNR_TIMEOUTを待たなければなりません、そのようなもの。まるでユニークさの検証質問をしているかのように。 さもなければ、最初の応答が受け取られていた後にSHOULDがマルチキャスト質問であると考えるLLMNR送付者は答えました、'C'ビットがその応答で明確になるなら。
However, if the first response has the 'C' bit set, then the sender SHOULD wait for LLMNR_TIMEOUT + JITTER_INTERVAL in order to collect all possible responses. When multiple valid answers are received, they may first be concatenated, and then treated in the same manner that multiple RRs received from the same DNS server would. A unicast query sender considers the query answered after the first response is received.
しかしながら、最初の応答で'C'ビットを設定するなら、送付者SHOULDは、すべての可能な応答を集めるためにLLMNR_TIMEOUT+JITTER_INTERVALを待っています。 複数の有効な答えが受け取られていると、それらは、最初に、同じDNSサーバから受け取られた複数のRRsがそうするのと同じ方法で連結されて、扱われるかもしれません。 ユニキャスト質問送付者は最初の応答が受け取られていた後に答えられた質問を考えます。
Aboba, et al. Informational [Page 13] RFC 4795 LLMNR January 2007
Aboba、他 [13ページ]情報のRFC4795LLMNR2007年1月
Since it is possible for a response with the 'C' bit clear to be followed by a response with the 'C' bit set, an LLMNR sender SHOULD be prepared to process additional responses for the purposes of conflict detection, even after it has considered a query answered.
以来、応答において、送付者SHOULDが闘争検出の目的のための追加応答を処理するように準備されて、考えた後にさえ'C'ビットがセットしたことでの応答、LLMNRによって続かれるようにはっきりと噛み付かれた'C'と共に質問に答えたのは、可能です。
In order to avoid synchronization, the transmission of each LLMNR query and response SHOULD be delayed by a time randomly selected from the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by responders responding with names that they have previously determined to be UNIQUE (see Section 4 for details).
同期を避けてください、トランスミッション。それぞれのLLMNR質問と応答SHOULDでは、間隔0からJITTER_INTERVALに手当たりしだいに選択された時間までに遅れてください。 この遅れは名前で以前にUNIQUEであることを決定したと(詳細に関してセクション4を見てください)応答している応答者によって避けられるかもしれません。
2.8. RR TTL
2.8. RR TTL
The responder should insert a pre-configured TTL value in the records returned in an LLMNR response. A default value of 30 seconds is RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc networks), the TTL value may need to be reduced.
応答者はLLMNR応答で返された記録にあらかじめ設定されたTTL値を挿入するべきです。 30秒のデフォルト値はRECOMMENDEDです。 非常にダイナミックな環境(モバイル臨時のネットワークなどの)で、TTL値は、減少する必要があるかもしれません。
Due to the TTL minimalization necessary when caching an RRset, all TTLs in an RRset MUST be set to the same value.
RRsetをキャッシュすると必要なTTL minimalizationのため、RRsetのすべてのTTLsが同じ値に用意ができなければなりません。
2.9. Use of the Authority and Additional Sections
2.9. 権威と追加セクションの使用
Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a concept of delegation. In LLMNR, the NS resource record type may be stored and queried for like any other type, but it has no special delegation semantics as it does in the DNS. Responders MAY have NS records associated with the names for which they are authoritative, but they SHOULD NOT include these NS records in the authority sections of responses.
DNSと異なって、LLMNRはピアツーピアプロトコルであり、委譲の概念を持っていません。 LLMNRでは、レコード種類がしかし、いかなる他のタイプ、それのようにも保存されて、質問されるかもしれないNSリソースはDNSでするようにどんな特別な委譲意味論も持っていません。 応答者には、それらが正式である名前に関連しているNS記録があるかもしれなくて、唯一のそれらはこれらのNSが応答の権威部に記録するSHOULD NOTインクルードです。
Responders SHOULD insert an SOA record into the authority section of a negative response, to facilitate negative caching as specified in [RFC2308]. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. The owner name of the SOA record (MNAME) MUST be set to the query name. The RNAME, SERIAL, REFRESH, RETRY, and EXPIRE values MUST be ignored by senders. Negative responses without SOA records SHOULD NOT be cached.
応答者SHOULDは、[RFC2308]での指定されるとしての否定的キャッシュを容易にするために否定応答の権威部にSOA記録を挿入します。 この記録のTTLは、SOA記録のMINIMUM分野とSOA自身のTTLの最小限から設定されて、どれくらい長いレゾルバが否定的な返答をキャッシュするかもしれないかを示します。 SOA記録(MNAME)の所有者名を質問名に設定しなければなりません。 送付者はRNAME、SERIAL、REFRESH、RETRY、およびEXPIRE値を無視しなければなりません。 SOAのない否定応答はSHOULD NOTを記録します。キャッシュされます。
In LLMNR, the additional section is primarily intended for use by EDNS0, TSIG, and SIG(0). As a result, unless the 'C' bit is set, senders MAY only include pseudo RR-types in the additional section of a query; unless the 'C' bit is set, responders MUST ignore the additional section of queries containing other RR types.
LLMNRでは、追加セクションは使用のためにEDNS0、TSIG、およびSIG(0)によって主として意図されます。 その結果、'C'ビットが設定されない場合、送付者は質問の追加セクションの疑似RRタイプを入れるだけであるかもしれません。 'C'ビットが設定されない場合、応答者は他のRRタイプを含む追加セクションの質問を無視しなければなりません。
Aboba, et al. Informational [Page 14] RFC 4795 LLMNR January 2007
Aboba、他 [14ページ]情報のRFC4795LLMNR2007年1月
In queries where the 'C' bit is set, the sender SHOULD include the conflicting RRs in the additional section. Since conflict notifications are advisory, responders SHOULD log information from the additional section, but otherwise MUST ignore the additional section.
質問では、送付者SHOULDは追加セクションに'C'ビットが設定されるところに闘争しているRRsを含んでいます。 闘争以来、通知は、追加セクションからの状況報告、応答者SHOULDログ情報ですが、別の方法で追加セクションを無視しなければなりません。
Senders MUST NOT cache RRs from the authority or additional section of a response as answers, though they may be used for other purposes, such as negative caching.
Sendersは答えとして応答の権威か追加セクションからRRsをキャッシュしてはいけません、それらが他の目的に使用されるかもしれませんが、否定的キャッシュなどのように。
3. Usage Model
3. 用法モデル
By default, an LLMNR sender SHOULD send LLMNR queries only for single-label names. Stub resolvers supporting both DNS and LLMNR SHOULD avoid sending DNS queries for single-label names, in order to reduce unnecessary DNS queries. An LLMNR sender SHOULD NOT be enabled to send a query for any name, except where security mechanisms (described in Section 5.3) can be utilized. An LLMNR query SHOULD only be sent for the originally requested name; a searchlist is not used to form additional LLMNR queries.
デフォルトで、LLMNR送付者SHOULDはただ一つのラベル名のためだけの質問をLLMNRに送ります。 DNSとLLMNR SHOULDの両方をサポートするスタッブレゾルバは、ただ一つのラベル名のための質問をDNSに送るのを避けます、不要なDNS質問を抑えるために。 セキュリティー対策(セクション5.3では、説明される)が利用できるのを除いて、LLMNR送付者SHOULD NOTがどんな名前のための質問も送るのが有効にされて、利用されてください。 LLMNRはSHOULDについて質問します。元々要求された名前のために単に送ってください。 searchlistは、追加LLMNR質問を形成するのに使用されません。
LLMNR is a peer-to-peer name resolution protocol that is not intended as a replacement for DNS; rather, it enables name resolution in scenarios in which conventional DNS name resolution is not possible. Where LLMNR security is not enabled as described in Section 5.3, if LLMNR is given higher priority than DNS among the enabled name resolution mechanisms, this would allow the LLMNR cache, once poisoned, to take precedence over the DNS cache. As a result, use of LLMNR as a primary name resolution mechanism is NOT RECOMMENDED.
LLMNRはDNSとの交換として意図しないピアツーピア名前解決プロトコルです。 むしろ、それは従来のDNS名前解決が可能でないシナリオにおける名前解決を可能にします。 LLMNRセキュリティがセクション5.3で説明されるように可能にされないところでは、LLMNRは可能にされた名前解決メカニズムが優先するなら、DNSより高い一度毒を入れられたLLMNRキャッシュがDNSキャッシュの上でこれで優先するでしょう。 その結果、プライマリ名前解決メカニズムとしてのLLMNRの使用はNOT RECOMMENDEDです。
Instead, it is recommended that LLMNR be utilized as a secondary name resolution mechanism, for use in situations where hosts are not configured with the address of a DNS server, where the DNS server is unavailable or unreachable, where there is no DNS server authoritative for the name of a host, or where the authoritative DNS server does not have the desired RRs.
代わりに、LLMNRがセカンダリ名前解決メカニズムとして利用されるのは、お勧めです、ホストがホストの名前に、正式のどんなDNSサーバもないか、または正式のDNSサーバが必要なRRsを持っていないDNSサーバが入手できないか、または手が届かないDNSサーバのアドレスによって構成されない状況における使用のために。
When LLMNR is configured as a secondary name resolution mechanism, LLMNR queries SHOULD only be sent when all of the following conditions are met:
セカンダリ名前解決メカニズム、LLMNRがSHOULDについて質問するときLLMNRを構成するときには、以下の条件のすべてに会うときには単に送ってください:
Aboba, et al. Informational [Page 15] RFC 4795 LLMNR January 2007
Aboba、他 [15ページ]情報のRFC4795LLMNR2007年1月
(1) No manual or automatic DNS configuration has been performed. If
DNS server address(es) have been configured, a host SHOULD
attempt to reach DNS servers over all protocols on which DNS
server address(es) are configured, prior to sending LLMNR
queries. For dual-stack hosts configured with DNS server
address(es) for one protocol but not another, this implies that
DNS queries SHOULD be sent over the protocol configured with a
DNS server, prior to sending LLMNR queries.
(1) どんな手動の、または、自動であるDNS構成も実行されていません。 DNSサーバアドレス(es)であるなら、構成されてください、そうした、すべてのプロトコルで上DNSサーバアドレス(es)が構成されているDNSサーバに達するホストSHOULD試み、送付LLMNR質問の前に。 別のものではなく、(es)が個人的には議定書の中で述べるDNSサーバアドレスによって構成されたデュアルスタックホストに関しては、これは、DNS質問SHOULDがDNSサーバで構成されたプロトコルの上に送られるのを含意します、送付LLMNR質問の前に。
(2) All attempts to resolve the name via DNS on all interfaces have
failed after exhausting the searchlist. This can occur because
DNS servers did not respond, or because they responded to DNS
queries with RCODE=3 (Authoritative Name Error) or RCODE=0, and
an empty answer section. Where a single resolver call generates
DNS queries for A and AAAA RRs, an implementation MAY choose not
to send LLMNR queries if any of the DNS queries is successful.
(2) searchlistを消耗させた後に、すべてのインタフェースのDNSを通して名前を決議するすべての試みが失敗しました。 DNSサーバが反応しなかったか、または彼らがRCODE=3(正式のName Error)かRCODE=0とのDNS質問、および空の答え部に応じたので、これは起こることができます。 ただ一つのレゾルバ呼び出しがどこでAとAAAA RRsのための質問、実装が送らないのを選ぶかもしれないDNSにもしあればDNS質問のLLMNR質問を生成するかは、うまくいっています。
Where LLMNR is used as a secondary name resolution mechanism, its usage is in part determined by the behavior of DNS resolver implementations; robust resolver implementations are more likely to avoid unnecessary LLMNR queries.
LLMNRがセカンダリ名前解決メカニズムとして使用されるところでは、用法はDNSレゾルバ実装の振舞いで一部決定します。 強健なレゾルバ実装は不要なLLMNR質問をより避けそうです。
[RFC1536] describes common DNS implementation errors and fixes. If the proposed fixes are implemented, unnecessary LLMNR queries will be reduced substantially, so implementation of [RFC1536] is recommended.
[RFC1536]は一般的なDNS実装誤りとフィックスについて説明します。 提案されたフィックスが実装されると、不要なLLMNR質問がかなり抑えられるので、[RFC1536]の実装はお勧めです。
For example, [RFC1536] Section 1 describes issues with retransmission and recommends implementation of a retransmission policy based on round trip estimates, with exponential back-off. [RFC1536] Section 4 describes issues with failover, and recommends that resolvers try another server when they don't receive a response to a query. These policies are likely to avoid unnecessary LLMNR queries.
例えば、[RFC1536]セクション1は、「再-トランスミッション」の問題について説明して、周遊旅行見積りに基づく「再-トランスミッション」方針の実装を推薦します、指数の後部が下にある状態で。 [RFC1536]セクション4は、フェイルオーバーの問題について説明して、彼らが質問への応答を受けないとき、レゾルバが別のサーバを試みることを勧めます。 これらの方針は不要なLLMNR質問を避けそうです。
[RFC1536] Section 3 describes zero answer bugs, which if addressed will also reduce unnecessary LLMNR queries.
[RFC1536]セクション3は答えバグについて全く説明しません。(扱われると、また、バグは不要なLLMNR質問を抑えるでしょう)。
[RFC1536] Section 6 describes name error bugs and recommended searchlist processing that will reduce unnecessary RCODE=3 (authoritative name) errors, thereby also reducing unnecessary LLMNR queries.
[RFC1536]セクション6は名前誤りバグと不要なRCODE=3(正式の名前)誤りを抑えるお勧めのsearchlist処理について説明します、その結果、また、不要なLLMNR質問を抑えます。
As noted in [DNSPerf], a significant fraction of DNS queries do not receive a response, or result in negative responses due to missing inverse mappings or NS records that point to nonexistent or inappropriate hosts. Therefore, a reduction in missing records can prevent many unnecessary LLMNR queries.
[DNSPerf]に述べられるように、DNS質問の重要な部分は実在しないか不適当なホストを示すなくなった逆マッピング変換かNS記録による否定応答で応答、または結果を受けません。 したがって、なくなった記録の減少は多くの不要なLLMNR質問を防ぐことができます。
Aboba, et al. Informational [Page 16] RFC 4795 LLMNR January 2007
Aboba、他 [16ページ]情報のRFC4795LLMNR2007年1月
3.1. LLMNR Configuration
3.1. LLMNR構成
LLMNR usage MAY be configured manually or automatically on a per- interface basis. By default, LLMNR responders SHOULD be enabled on all interfaces, at all times. Where this is considered undesirable, LLMNR SHOULD be disabled, so that hosts will neither listen on the link-scope multicast address, nor will they send queries to that address.
LLMNR用法がaで手動的か自動的に構成されるかもしれない、-、インタフェース基礎。 デフォルトで、LLMNR応答者SHOULD、すべてのインタフェースでいつも可能にされてください。 これがそうでは、好ましくない人、LLMNR SHOULDであると考えられて、ホストがリンク範囲マルチキャストアドレスでどちらも聴かないように、障害があってください、そして、彼らはそのアドレスに質問を送らないでしょう。
Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to configure LLMNR on an interface. The LLMNR Enable Option, described in [LLMNREnable], can be used to explicitly enable or disable use of LLMNR on an interface. The LLMNR Enable Option does not determine whether, or in which order, DNS itself is used for name resolution. The order in which various name resolution mechanisms should be used can be specified using the Name Service Search Option (NSSO) for DHCP [RFC2937], using the LLMNR Enable Option code carried in the NSSO data.
DHCPv4かDHCPv6が実装されるところでは、インタフェースのLLMNRを構成するのにDHCPオプションを使用できます。 明らかにインタフェースにおけるLLMNRの使用を可能にするか、または無効にするのに[LLMNREnable]で説明されたLLMNR Enable Optionは使用できます。 LLMNR Enable Optionが決定しない、どのオーダーで、DNS自身は名前解決に使用されるか。 DHCP[RFC2937]に、Name Service検索Option(NSSO)を使用することで様々な名前解決メカニズムが使用されるべきであるオーダーを指定できます、NSSOデータで運ばれたLLMNR Enable Optionコードを使用して。
In situations where LLMNR is configured as a secondary name resolution protocol on a dual-stack host, behavior will be governed by both IPv4 and IPv6 configuration mechanisms. Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is possible for a dual-stack host to be configured with the address of a DNS server over IPv4, while remaining unconfigured with a DNS server suitable for use over IPv6.
LLMNRがセカンダリ名前解決プロトコルとしてデュアルスタックホストの上で構成される状況で、振舞いはIPv4とIPv6構成メカニズムの両方によって管理されるでしょう。IPv4とIPv6が異なった構成メカニズムを利用するので、デュアルスタックホストがIPv4の上でDNSサーバのアドレスによって構成されるのは、IPv6の上に使用に適したDNSサーバで非構成されたままで残っている間、可能です。
In these situations, a dual-stack host will send AAAA queries to the configured DNS server over IPv4. However, an IPv6-only host unconfigured with a DNS server suitable for use over IPv6 will be unable to resolve names using DNS. Automatic IPv6 DNS configuration mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely deployed, and not all DNS servers support IPv6. Therefore, lack of IPv6 DNS configuration may be a common problem in the short term, and LLMNR may prove useful in enabling link-local name resolution over IPv6.
これらの状況で、デュアルスタックホストはIPv4の上の構成されたDNSサーバへの質問をAAAAに送るでしょう。 しかしながら、IPv6の上の使用に適したDNSサーバで非構成されたIPv6だけホストは、DNSを使用することで名前を決議できないでしょう。 自動IPv6 DNS構成メカニズム([RFC3315]や[DNSDisc]などの)はまだ広く配布されていません、そして、すべてのDNSサーバがIPv6をサポートするというわけではありません。 したがって、IPv6 DNS構成の不足は短期で共有する問題であるかもしれません、そして、LLMNRはIPv6の上のリンクローカルの名前解決を可能にする際に有用であることが分かるかもしれません。
Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315], IPv6-only hosts may not be configured with a DNS server. Where there is no DNS server authoritative for the name of a host or the authoritative DNS server does not support dynamic client update over IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not be able to do DNS dynamic update, and other hosts will not be able to resolve its name.
DHCPv4サーバがどこで入手できるか、しかし、DHCPv6サーバ[RFC3315]でない、IPv6だけホストはDNSサーバで構成されないかもしれません。次に、ホストの名前に、正式のどんなDNSサーバもないか、または正式のDNSサーバがIPv6かDHCPv6ベースのダイナミックなアップデートの上のダイナミックなクライアントアップデートをサポートしないところでIPv6だけホストはDNSのダイナミックなアップデートができないでしょう、そして、他のホストは名前を決議できないでしょう。
Aboba, et al. Informational [Page 17] RFC 4795 LLMNR January 2007
Aboba、他 [17ページ]情報のRFC4795LLMNR2007年1月
For example, if the configured DNS server responds to an AAAA RR query sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or RCODE=0 and an empty answer section, then an AAAA RR query sent using LLMNR over IPv6 may be successful in resolving the name of an IPv6-only host on the local link.
例えば、構成されたDNSサーバが正式の名前誤りと共にIPv4かIPv6の上に送られたAAAA RR質問(RCODE=3)かRCODE=0と空の答え部に反応するなら、LLMNRがIPv6の上で使用させられたAAAA RR質問は地方のリンクでIPv6だけホストの名前を決議するのに成功しているかもしれません。
Similarly, if a DHCPv4 server is available providing DNS server configuration, and DNS server(s) exist which are authoritative for the A RRs of local hosts and support either dynamic client update over IPv4 or DHCPv4-based dynamic update, then the names of local IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no DNS server is authoritative for the names of local hosts, or the authoritative DNS server(s) do not support dynamic update, then LLMNR enables link-local name resolution over IPv4.
同様に、ローカル・ホストのA RRsに正式であり、IPv4の上のダイナミックなクライアントアップデートかDHCPv4ベースのダイナミックなアップデートのどちらかをサポートするDNSサーバがDHCPv4サーバがDNSサーバ構成を提供しながら利用可能であり、存在しているなら、IPv4の上でLLMNRなしで地元のIPv4ホストの名前を決議できます。 しかしながら、ローカル・ホストの名前には、どんなDNSサーバも正式でないか、または正式のDNSサーバがダイナミックなアップデートをサポートしないなら、LLMNRはIPv4の上のリンクローカルの名前解決を可能にします。
It is possible that DNS configuration mechanisms will go in and out of service. In these circumstances, it is possible for hosts within an administrative domain to be inconsistent in their DNS configuration.
DNS構成メカニズムがサービスを内外に行かせるのは、可能です。 こういう事情ですから、管理ドメインの中のホストが彼らのDNS構成で矛盾しているのは、可能です。
For example, where DHCP is used for configuring DNS servers, one or more DHCP servers can fail. As a result, hosts configured prior to the outage will be configured with a DNS server, while hosts configured after the outage will not. Alternatively, it is possible for the DNS configuration mechanism to continue functioning while configured DNS servers fail.
例えば、DHCPがDNSサーバを構成するのに使用されるところでは、1つ以上のDHCPサーバが失敗できます。 その結果、供給停止の前に構成されたホストはDNSサーバで構成されるでしょう、供給停止の後に構成されたホストがそうしないでしょうが。 あるいはまた、DNS構成メカニズムが、構成されたDNSサーバが失敗している間、機能し続けているのは、可能です。
An outage in the DNS configuration mechanism may result in hosts continuing to use LLMNR even once the outage is repaired. Since LLMNR only enables link-local name resolution, this represents a degradation in capabilities. As a result, hosts without a configured DNS server may wish to periodically attempt to obtain DNS configuration if permitted by the configuration mechanism in use. In the absence of other guidance, a default retry interval of one (1) minute is RECOMMENDED.
DNS構成メカニズムにおける供給停止は供給停止がいったん修理さえされるとLLMNRを使用し続けているホストをもたらすかもしれません。 LLMNRがリンクローカルの名前解決を可能にするだけであるので、これは能力における退行を表します。 その結果、使用中の構成メカニズムによって受入れられるなら、構成されたDNSサーバのないホストは、定期的にDNS構成を得るのを試みたがっているかもしれません。 他の指導がないとき、1(1)分のデフォルト再試行間隔はRECOMMENDEDです。
4. Conflict Resolution
4. 紛争解決
By default, a responder SHOULD be configured to behave as though its name is UNIQUE on each interface on which LLMNR is enabled. However, it is also possible to configure multiple responders to be authoritative for the same name. For example, multiple responders MAY respond to a query for an A or AAAA type record for a cluster name (assigned to multiple hosts in the cluster).
デフォルトで、応答者SHOULD、まるで名前がLLMNRが有効にされる各インタフェースのUNIQUEであるかのように振る舞うには、構成されてください。 しかしながら、また、同じ名前に、複数の応答者が正式であることを構成するのも可能です。 例えば、複数の応答者がAのための質問に応じるかもしれませんか、またはAAAAタイプはクラスタ名(クラスタの複数のホストに割り当てられる)のために記録します。
Aboba, et al. Informational [Page 18] RFC 4795 LLMNR January 2007
Aboba、他 [18ページ]情報のRFC4795LLMNR2007年1月
To detect duplicate use of a name, an administrator can use a name resolution utility that employs LLMNR and lists both responses and responders. This would allow an administrator to diagnose behavior and potentially intervene and reconfigure LLMNR responders that should not be configured to respond to the same name.
管理者は、名前の写し使用を検出するために、LLMNRを使う名前解決ユーティリティを使用できて、応答と応答者の両方を記載します。 これで、管理者は、潜在的に同じ名前に応じるために構成されるべきでないLLMNR応答者を、振舞いを診断して、介入して、再構成するでしょう。
4.1. Uniqueness Verification
4.1. ユニークさの検証
Prior to sending an LLMNR response with the 'T' bit clear, a responder configured with a UNIQUE name MUST verify that there is no other host within the scope of LLMNR query propagation that is authoritative for the same name on that interface.
'T'ビットが明確な状態でLLMNR応答を送る前に、UNIQUE名によって構成された応答者は、他のホストが全く同じ名前に、そのインタフェースで正式のLLMNR質問伝播の範囲の中にいないことを確かめなければなりません。
Once a responder has verified that its name is UNIQUE, if it receives an LLMNR query for that name with the 'C' bit clear, it MUST respond with the 'T' bit clear. Prior to verifying that its name is UNIQUE, a responder MUST set the 'T' bit in responses.
応答者が、名前がUNIQUEであることをいったん確かめると、明確な'C'ビットのその名前のためのLLMNR質問を受けるなら、'T'ビットが明確な状態でそれは応じなければなりません。 名前がUNIQUEであることを確かめる前に、応答者は'T'ビットを応答にはめ込まなければなりません。
Uniqueness verification is carried out when the host:
ホストであるときに、ユニークさの検証が行われます:
- starts up or is rebooted
- 始動するか、またはリブートされます。
- wakes from sleep (if the network interface was inactive during
sleep)
- 睡眠からの航跡(ネットワーク・インターフェースが睡眠の間、不活発であったなら)
- is configured to respond to LLMNR queries on an interface enabled
for transmission and reception of IP traffic
- IPトラフィックのトランスミッションとレセプションのために可能にされたインタフェースでLLMNR質問に応じるために、構成されます。
- is configured to respond to LLMNR queries using additional UNIQUE
resource records
- 追加UNIQUEリソース記録を使用することでLLMNR質問に応じるために、構成されます。
- verifies the acquisition of a new IP address and configuration on
an interface
- インタフェースにおける新しいIPアドレスと構成の獲得について確かめます。
To verify uniqueness, a responder MUST send an LLMNR query with the 'C' bit clear, over all protocols on which it responds to LLMNR queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify uniqueness of a name by sending a query for the name with type='ANY'.
ユニークさについて確かめるために、'C'ビットが明確な状態で応答者はLLMNR質問を送らなければなりません、すべてのプロトコルで上それがLLMNR質問(IPv4、そして/または、IPv6)に応じる。 応答者が'少しも'タイプ=の名前のための質問を送ることによって名前のユニークさについて確かめるのは、RECOMMENDEDです。
If no response is received, the sender retransmits the query, as specified in Section 2.7. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. To avoid triggering conflict detection, a responder that detects that it is connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses.
どんな応答も受け取られていないなら、送付者はセクション2.7で指定されるように質問を再送します。 応答が受け取られているなら、送付者は、ソースアドレスがインタフェースのどれかのアドレスに合っているかどうかチェックしなければなりません。 そうだとすれば、そして、応答は、送付者から発するので、闘争であると考えられません。 それがそれが検出する応答者ですが、闘争検出の引き金となるのを複数のインタフェースで同じリンクに接続されていた状態で避けるために、SHOULDは'C'ビットを応答にはめ込みます。
Aboba, et al. Informational [Page 19] RFC 4795 LLMNR January 2007
Aboba、他 [19ページ]情報のRFC4795LLMNR2007年1月
If a response is received with the 'T' bit clear, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). If a response is received with the 'T' bit set, the responder MUST check if the source IP address in the response is lexicographically smaller than the source IP address in the query. If so, the responder MUST NOT use the name in response to LLMNR queries received over any protocol (IPv4 or IPv6). For the purpose of uniqueness verification, the contents of the answer section in a response is irrelevant.
'T'ビットが明確な状態で応答を受けるなら、応答者はどんなプロトコル(IPv4かIPv6)の上にも受けられたLLMNR質問に対応して名前を使用してはいけません。 'T'ビットがセットした状態で応答を受けるなら、応答者は、応答におけるソースIPアドレスが質問におけるソースIPアドレスより小さい辞書編集であるかどうかチェックしなければなりません。 そうだとすれば、応答者はどんなプロトコル(IPv4かIPv6)の上にも受けられたLLMNR質問に対応して名前を使用してはいけません。 ユニークさの検証の目的のために、応答における答え部のコンテンツは無関係です。
Periodically carrying out uniqueness verification in an attempt to detect name conflicts is not necessary, wastes network bandwidth, and may actually be detrimental. For example, if network links are joined only briefly, and are separated again before any new communication is initiated, temporary conflicts are benign and no forced reconfiguration is required. LLMNR responders SHOULD NOT periodically attempt uniqueness verification.
定期的に名前闘争を検出する試みにおけるユニークさの検証を行うのは必要でなく、廃棄物は、帯域幅をネットワークでつないで、実際に有害であるかもしれません。 例えば、ネットワークリンクが簡潔にだけ接合されて、どんな新しいコミュニケーションも開始される前に再び切り離されるなら、一時的な闘争は優しいです、そして、どんな無理矢理の再構成も必要ではありません。 LLMNR応答者SHOULD NOTは定期的にユニークさの検証を試みます。
4.2. Conflict Detection and Defense
4.2. 闘争検出とディフェンス
Hosts on disjoint network links may configure the same name for use with LLMNR. If these separate network links are later joined or bridged together, then there may be multiple hosts that are now on the same link, trying to use the same name.
ネットワークリンクはばらばらになります。ホスト、LLMNRとの使用のために同じ名前を構成するかもしれません。 これらの別々のネットワークリンクが一緒に後で接合されるか、またはブリッジされるなら、現在、同じリンクの上にいる複数のホストがいるかもしれません、同じ名前を使用しようとして。
In order to enable ongoing detection of name conflicts, when an LLMNR sender receives multiple LLMNR responses to a query, it MUST check if the 'C' bit is clear in any of the responses. If so, the sender
LLMNR送付者が質問への複数のLLMNR応答を受けるとき、名前闘争の進行中の検出を可能にするために、それは、'C'ビットが応答のどれかで明確であるかどうかチェックしなければなりません。 そうだとすれば、送付者
SHOULD send another query for the same name, type, and class, this time with the 'C' bit set, with the potentially conflicting resource records included in the additional section.
SHOULDは同じ名前、タイプ、およびクラスのために別の質問を送ります、'C'ビットがセットしたことでの今回、追加セクションに含まれているリソース記録が潜在的に闘争していた状態で。
Queries with the 'C' bit set are considered advisory, and responders MUST verify the existence of a conflict before acting on it. A responder receiving a query with the 'C' bit set MUST NOT respond.
'C'ビットがセットしたことでの質問は顧問であると考えられます、そして、それに影響する前に、応答者は闘争の存在について確かめなければなりません。 'C'ビットがセットした状態で質問を受ける応答者は応じてはいけません。
If the query is for a UNIQUE name, then the responder MUST send its own query for the same name, type, and class, with the 'C' bit clear. If a response is received, the sender MUST check if the source address matches the address of any of its interfaces; if so, then the response is not considered a conflict, since it originates from the sender. To avoid triggering conflict detection, a responder that detects that it is connected to the same link on multiple interfaces SHOULD set the 'C' bit in responses.
質問がUNIQUE名のためのものであるなら、応答者は同じ名前、タイプ、およびクラスのためにそれ自身の質問を送らなければなりません、'C'ビットが明確な状態で。 応答が受け取られているなら、送付者は、ソースアドレスがインタフェースのどれかのアドレスに合っているかどうかチェックしなければなりません。 そうだとすれば、そして、応答は、送付者から発するので、闘争であると考えられません。 それがそれが検出する応答者ですが、闘争検出の引き金となるのを複数のインタフェースで同じリンクに接続されていた状態で避けるために、SHOULDは'C'ビットを応答にはめ込みます。
Aboba, et al. Informational [Page 20] RFC 4795 LLMNR January 2007
Aboba、他 [20ページ]情報のRFC4795LLMNR2007年1月
An LLMNR responder MUST NOT ignore conflicts once detected, and SHOULD log them. Upon detecting a conflict, an LLMNR responder MUST immediately stop using the conflicting name in response to LLMNR queries received over any supported protocol, if the source IP address in the response is lexicographically smaller than the source IP address in the uniqueness verification query.
LLMNR応答者は一度検出された闘争を無視してはいけません、そして、SHOULDはそれらを登録します。 闘争を検出すると、LLMNR応答者は、すぐにどんなサポートしているプロトコルの上にも受けられたLLMNR質問に対応して闘争名を使用するのを止めなければなりません、応答におけるソースIPアドレスがユニークさの検証質問におけるソースIPアドレスより小さい辞書編集であるなら。
After stopping the use of a name, the responder MAY elect to configure a new name. However, since name reconfiguration may be disruptive, this is not required, and a responder may have been configured to respond to multiple names so that alternative names may already be available. A host that has stopped the use of a name may attempt uniqueness verification again after the expiration of the TTL of the conflicting response.
名前の使用を止めた後に、応答者は、新しい名前を構成するのを選ぶかもしれません。 しかしながら、名前再構成が破壊的であるかもしれないので、これは必要ではありませんでした、そして、応答者は代替名が既に利用可能であることができなるように複数の名前に応じるために構成されたかもしれません。 名前の使用を止めたホストは闘争応答のTTLの満了の後に再びユニークさの検証を試みるかもしれません。
4.3. Considerations for Multiple Interfaces
4.3. 複数のインタフェースへの問題
A multi-homed host may elect to configure LLMNR on only one of its active interfaces. In many situations, this will be adequate. However, should a host need to configure LLMNR on more than one of its active interfaces, there are some additional precautions it MUST take. Implementers who are not planning to support LLMNR on multiple interfaces simultaneously may skip this section.
マルチ、家へ帰り、ホストは、アクティブなインタフェースの1つだけのLLMNRを構成するのを選ぶかもしれません。 多くの状況で、これは適切になるでしょう。 しかしながら、アクティブなインタフェースの1つ以上のLLMNRを構成するホストの必要性、それが払わなければならないいくつかの追加注意があるべきです。 同時に複数のインタフェースのLLMNRをサポートするのを計画していないImplementersはこのセクションをスキップするかもしれません。
Where a host is configured to issue LLMNR queries on more than one interface, each interface maintains its own independent LLMNR resolver cache, containing the responses to LLMNR queries.
ホストが1つ以上のインタフェースでLLMNRに質問を発行するために構成されるところでは、各インタフェースはそれ自身の独立しているLLMNRレゾルバキャッシュを維持します、LLMNR質問への応答を含んでいて。
A multi-homed host checks the uniqueness of UNIQUE records as described in Section 4. The situation is illustrated in Figure 1.
マルチ、家へ帰り、ホストはセクション4で説明されるようにUNIQUE記録のユニークさをチェックします。 状況は図1で例証されます。
---------- ----------
| | | |
[A] [myhost] [myhost]
---------- ---------- | | | | [A][myhost][myhost]
Figure 1. Link-scope name conflict
図1。 リンク範囲名前闘争
In this situation, the multi-homed myhost will probe for, and defend, its host name on both interfaces. A conflict will be detected on one interface, but not the other. The multi-homed myhost will not be able to respond with a host RR for "myhost" on the interface on the right (see Figure 1). The multi-homed host may, however, be configured to use the "myhost" name on the interface on the left.
この状況でマルチ、家へ帰り、意志が調べて、防御するmyhost、両方のホスト名は連結します。 闘争はもう片方ではなく、1つのインタフェースに検出されるでしょう。 マルチ、家へ帰り、myhostは"myhost"のためにホストRRと共に右でインタフェースで応じることができないでしょう(図1を見てください)。 マルチ、家へ帰り、しかしながら、ホストは、左のインタフェースで"myhost"名を使用するために構成されるかもしれません。
Aboba, et al. Informational [Page 21] RFC 4795 LLMNR January 2007
Aboba、他 [21ページ]情報のRFC4795LLMNR2007年1月
Since names are only unique per link, hosts on different links could be using the same name. If an LLMNR client sends queries over multiple interfaces, and receives responses from more than one, the result returned to the client is defined by the implementation. The situation is illustrated in Figure 2.
名前がリンク単位でユニークであるだけであるので、異なったリンクの上のホストは同じ名前を使用できました。 LLMNRクライアントが複数のインタフェースにわたって質問を送って、1以上から応答を受けるなら、クライアントに返された結果は実装によって定義されます。 状況は図2で例証されます。
---------- ----------
| | | |
[A] [myhost] [A]
---------- ---------- | | | | [A][myhost][A]
Figure 2. Off-segment name conflict
図2。 オフセグメント名闘争
If host myhost is configured to use LLMNR on both interfaces, it will send LLMNR queries on both interfaces. When host myhost sends a query for the host RR for name "A", it will receive a response from hosts on both interfaces.
ホストmyhostが両方のインタフェースのLLMNRを使用するために構成されると、それは両方のインタフェースで質問をLLMNRに送るでしょう。 ホストmyhostが名前「A」のためにホストRRのための質問を送るとき、それは両方のインタフェースでホストから応答を受けるでしょう。
Host myhost cannot distinguish between the situation shown in Figure 2, and that shown in Figure 3, where no conflict exists.
ホストmyhostは図2に示された状況、および図3に示されたそれを見分けることができません。そこでは、闘争が全く存在していません。
[A]
| |
----- -----
| |
[myhost]
[A]| | ----- ----- | | [myhost]
Figure 3. Multiple paths to same host
図3。 同じホストへの複数の経路
This illustrates that the proposed name conflict-resolution mechanism does not support detection or resolution of conflicts between hosts on different links. This problem can also occur with DNS when a multi-homed host is connected to two different networks with separated name spaces. It is not the intent of this document to address the issue of uniqueness of names within DNS.
これは、提案された名前紛争解決メカニズムが異なったリンクの上にホストの間の闘争の検出か解決をサポートしないのを例証します。 また、aであるときにこの問題がDNSと共に起こることができる、マルチ、家へ帰り、ホストは切り離された名前空間で2つの異なったネットワークに接続されます。 DNSの中で名前のユニークさの問題を扱うのは、このドキュメントの意図ではありません。
4.4. API Issues
4.4. API問題
[RFC3493] provides an API that can partially solve the name ambiguity problem for applications written to use this API, since the sockaddr_in6 structure exposes the scope within which each scoped address exists, and this structure can be used for both IPv4 (using v4-mapped IPv6 addresses) and IPv6 addresses.
[RFC3493]は名前あいまいさ問題を部分的に解決できるAPIをこのAPIを使用するために書かれたアプリケーションに提供します、sockaddr_in6構造がそれぞれがアドレスが存在するのを見た範囲を暴露して、IPv4(v4によって写像されたIPv6アドレスを使用する)とIPv6アドレスの両方にこの構造は使用できるので。
Following the example in Figure 2, an application on 'myhost' issues
the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
ai_flags=AI_ALL|AI_V4MAPPED. LLMNR queries will be sent from both
interfaces, and the resolver library will return a list containing
multiple addrinfo structures, each with an associated sockaddr_in6
図2の例に倣っていて、'myhost'におけるアプリケーションは、ai_ファミリー=がある要求getaddrinfo(「A」、…)にAF_INET6を発行して、ai_旗=AIに_すべてを発行します。|AI_V4MAPPED。 両方のインタフェースからLLMNR質問を送るでしょう、そして、レゾルバライブラリは複数のaddrinfo構造を入れてあるリストを返すでしょう、それぞれ関連sockaddr_in6で
Aboba, et al. Informational [Page 22] RFC 4795 LLMNR January 2007
Aboba、他 [22ページ]情報のRFC4795LLMNR2007年1月
structure. This list will thus contain the IPv4 and IPv6 addresses of both hosts responding to the name 'A'. Link-local addresses will have a sin6_scope_id value that disambiguates which interface is used to reach the address. Of course, to the application, Figures 2 and 3 are still indistinguishable, but this API allows the application to communicate successfully with any address in the list.
構造。 その結果、このリストは名前'A'に応じている両方のホストのIPv4とIPv6アドレスを入れてあるでしょう。 リンクローカルのアドレスには、それがあいまいさを除くそれのインタフェースがアドレスに達するのにおいて使用されているsin6_範囲_イド価値があるでしょう。 もちろん、アプリケーションに、図2と3はまだ区別がつかないのですが、このAPIで、アプリケーションはリストのどんなアドレスでも首尾よく伝えます。
5. Security Considerations
5. セキュリティ問題
LLMNR is a peer-to-peer name resolution protocol designed for use on the local link. While LLMNR limits the vulnerability of responders to off-link senders, it is possible for an off-link responder to reach a sender.
LLMNRは地方のリンクにおける使用のために設計されたピアツーピア名前解決プロトコルです。 LLMNRは応答者の脆弱性をオフリンク送付者に制限しますが、オフリンク応答者が送付者に連絡するのは、可能です。
In scenarios such as public "hotspots", attackers can be present on the same link. These threats are most serious in wireless networks, such as IEEE 802.11, since attackers on a wired network will require physical access to the network, while wireless attackers may mount attacks from a distance. Link-layer security, such as [IEEE-802.11i], can be of assistance against these threats if it is available.
公共の「ホットスポット」などのシナリオでは、攻撃者は同じリンクに出席している場合があります。 ワイヤレス・ネットワークでこれらの脅威は最も重大です、IEEE802.11などのように、有線ネットワークの攻撃者がネットワークへの物理的なアクセスを必要とするので、ワイヤレスの攻撃者は遠方から攻撃を仕掛けるかもしれませんが。 それが利用可能であるなら、[IEEE-802.11i]などのリンクレイヤセキュリティはこれらの脅威に対して役に立つことができます。
This section details security measures available to mitigate threats from on and off-link attackers.
このセクションはリンクの上と、そして、リンクの攻撃者から脅威を緩和するために利用可能な安全策を詳しく述べます。
5.1. Denial of Service
5.1. サービス妨害
Attackers may take advantage of LLMNR conflict detection by allocating the same name, denying service to other LLMNR responders, and possibly allowing an attacker to receive packets destined for other hosts. By logging conflicts, LLMNR responders can provide forensic evidence of these attacks.
攻撃者は同じ名前を割り当てることによって、LLMNR闘争検出を利用するかもしれません、他のLLMNR応答者に対するサービスを否定して、ことによると攻撃者が他のホストのために運命づけられたパケットを受け取るのを許容して。 伐採闘争で、LLMNR応答者はこれらの攻撃の法廷の証拠を提供できます。
An attacker may spoof LLMNR queries from a victim's address in order to mount a denial of service attack. Responders setting the IPv6 Hop Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP response may be able to reach the victim across the Internet.
攻撃者は、サービス不能攻撃を仕掛けるために犠牲者のアドレスからLLMNRに質問を偽造するかもしれません。 IPv6 Hop LimitかIPv4 TTLを設定する応答者がLLMNR UDP応答における達することができるかもしれないより大きい値としてインターネット中の犠牲者をさばきます。
While LLMNR responders only respond to queries for which they are authoritative, and LLMNR does not provide wildcard query support, an LLMNR response may be larger than the query, and an attacker can generate multiple responses to a query for a name used by multiple responders. A sender may protect itself against unsolicited responses by silently discarding them.
LLMNR応答者はそれらが正式である質問に応じるだけです、そして、LLMNRはワイルドカード質問サポートを提供しませんが、LLMNR応答は質問より大きいかもしれません、そして、攻撃者は複数の応答者によって使用された名前のための質問への複数の応答を生成することができます。 送付者は、静かにそれらを捨てることによって、求められていない応答に対して我が身をかばうかもしれません。
Aboba, et al. Informational [Page 23] RFC 4795 LLMNR January 2007
Aboba、他 [23ページ]情報のRFC4795LLMNR2007年1月
5.2. Spoofing
5.2. スプーフィング
LLMNR is designed to prevent reception of queries sent by an off-link attacker. LLMNR requires that responders receiving UDP queries check that they are sent to a link-scope multicast address. However, it is possible that some routers may not properly implement link-scope multicast, or that link-scope multicast addresses may leak into the multicast routing system. To prevent successful setup of TCP connections by an off-link sender, responders receiving a TCP SYN reply with a TCP SYN-ACK with TTL set to one (1).
LLMNRは、オフリンク攻撃者によって送られた質問のレセプションを防ぐように設計されています。 LLMNRは、UDP質問を受ける応答者が、それらがリンク範囲マルチキャストアドレスに送られるのをチェックするのを必要とします。 しかしながら、いくつかのルータが適切にリンク範囲マルチキャストを実装しないかもしれないか、またはリンク範囲マルチキャストアドレスがマルチキャストルーティングシステムに漏れるのが、可能です。 オフリンク送付者によるTCP接続のうまくいっているセットアップを防ぐために、TTLと共にTCP SYN-ACKとのTCP SYN回答を受け取る応答者は1つ(1)にセットしました。
While it is difficult for an off-link attacker to send an LLMNR query to a responder, it is possible for an off-link attacker to spoof a response to a query (such as an A or AAAA query for a popular Internet host), and by using a TTL or Hop Limit field larger than one (1), for the forged response to reach the LLMNR sender. Since the forged response will only be accepted if it contains a matching ID field, choosing a pseudo-random ID field within queries provides some protection against off-link responders.
オフリンク攻撃者がLLMNR質問を応答者に送るのが、難しいのですが、オフリンク攻撃者が質問(ポピュラーなインターネット・ホストのためのAかAAAA質問などの)と、偽造応答がLLMNR送付者に届くのに1つ(1)より大きいTTLかHop Limit分野を使用することによって応答を偽造するのは、可能です。 合っているID分野を含んでいる場合にだけ偽造応答を受け入れるので、質問の中で擬似ランダムID分野を選ぶと、オフリンク応答者に対する何らかの保護が提供されます。
When LLMNR is utilized as a secondary name resolution service, queries can be sent when DNS server(s) do not respond. An attacker can execute a denial of service attack on the DNS server(s), and then poison the LLMNR cache by responding to an LLMNR query with incorrect information. As noted in "Threat Analysis of the Domain Name System (DNS)" [RFC3833], these threats also exist with DNS, since DNS- response spoofing tools are available that can allow an attacker to respond to a query more quickly than a distant DNS server. However, while switched networks or link-layer security may make it difficult for an on-link attacker to snoop unicast DNS queries, multicast LLMNR queries are propagated to all hosts on the link, making it possible for an on-link attacker to spoof LLMNR responses without having to guess the value of the ID field in the query.
セカンダリ名前解決サービスとしてLLMNRを利用するとき、DNSサーバが反応しないとき、質問を送ることができます。 攻撃者は、DNSサーバでサービス不能攻撃を実行して、不正確な情報でLLMNR質問に応じることによって、次に、LLMNRキャッシュに毒を入れることができます。 「ドメインネームシステム(DNS)の脅威分析」RFC3833に述べられるように、また、DNS応答スプーフィングツールがDNS利用可能であるので、攻撃者が遠方のDNSよりはやく質問に応じることができるこれらの脅威は存在しています。サーバしかしながら; リンクの上の攻撃者がユニキャストDNS質問を詮索するのが交換網かリンクレイヤセキュリティで難しくなっているかもしれない間、マルチキャストLLMNR質問はリンクの上のすべてのホストに伝播されます、リンクの上の攻撃者が、LLMNR応答が推測する必要はなくて質問で、ID分野の値であると偽造するのを可能にして。
Since LLMNR queries are sent and responded to on the local link, an attacker will need to respond more quickly to provide its own response prior to arrival of the response from a legitimate responder. If an LLMNR query is sent for an off-link host, spoofing a response in a timely way is not difficult, since a legitimate response will never be received.
LLMNR質問が地方でリンクするために送られて、反応するので、攻撃者は、正統の応答者からの応答の到着の前にそれ自身の応答を提供するために、よりすばやく応じる必要があるでしょう。 オフリンクホストのためにLLMNR質問を送るなら、タイムリーな方法で応答を偽造するのは難しくはありません、正統の応答を決して受けないので。
This vulnerability can be reduced by limiting use of LLMNR to resolution of single-label names as described in Section 3, or by implementation of authentication (see Section 5.3).
セクション3で説明されるようにLLMNRの使用をただ一つのラベル名の解決に制限するか、または認証の実装でこの脆弱性を減少させられることができます(セクション5.3を見てください)。
Aboba, et al. Informational [Page 24] RFC 4795 LLMNR January 2007
Aboba、他 [24ページ]情報のRFC4795LLMNR2007年1月
5.3. Authentication
5.3. 認証
LLMNR is a peer-to-peer name resolution protocol and, as a result, is often deployed in situations where no trust model can be assumed. Where a pre-arranged security configuration is possible, the following security mechanisms may be used:
LLMNRはピアツーピア名前解決プロトコルであり、信頼モデルを全く思うことができない状況でその結果しばしば配布されます。 根回しされたセキュリティ設定が可能であるところでは、以下のセキュリティー対策は使用されるかもしれません:
(a) LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
[RFC2931] security mechanisms. "DNS Name Service based on
Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec]
describes the use of TSIG to secure LLMNR, based on group keys.
While group keys can be used to demonstrate membership in a
group, they do not protect against forgery by an attacker that
is a member of the group.
(a) LLMNR実装は、TSIG[RFC2845]、そして/または、SIG(0)[RFC2931]がセキュリティー対策であるとサポートするかもしれません。「IPv6のモバイルAd Hoc NetworksのためのSecure Multicast DNSに基づくDNS Name Service」[LLMNRSec]はLLMNRを固定するためにTSIGの使用について説明します、グループキーに基づいて。 グループで会員資格を示すのにグループキーを使用できる間、それらはグループのメンバーである攻撃者による偽造から守りません。
(b) IPsec Encapsulating Security Payload (ESP) with a NULL
encryption algorithm MAY be used to authenticate unicast LLMNR
queries and responses, or LLMNR responses to multicast queries.
In a small network without a certificate authority, this can be
most easily accomplished through configuration of a group pre-
shared key for trusted hosts. As with TSIG, this does not
protect against forgery by an attacker with access to the group
pre-shared key.
(b) NULL暗号化アルゴリズムがあるIPsec Encapsulating Security有効搭載量(超能力)は、ユニキャストLLMNR質問と応答か、マルチキャスト質問へのLLMNR応答を認証するのに使用されるかもしれません。 信じられたホストにとって主要な状態であらかじめ共有されたグループの構成を通して認証局のない小さいネットワークでは、最も容易にこれを達成できます。 TSIGのように、これは攻撃者による主要な状態であらかじめ共有されたグループへのアクセスによる偽造から守りません。
(c) LLMNR implementations MAY support DNSSEC [RFC4033]. In order to
support DNSSEC, LLMNR implementations MAY be configured with
trust anchors, or they MAY make use of keys obtained from DNS
queries. Since LLMNR does not support "delegated trust" (CD or
AD bits), LLMNR implementations cannot make use of DNSSEC unless
they are DNSSEC-aware and support validation. Unlike approaches
[a] or [b], DNSSEC permits a responder to demonstrate ownership
of a name, not just membership within a trusted group. As a
result, it enables protection against forgery.
(c) LLMNR実装はDNSSEC[RFC4033]をサポートするかもしれません。 DNSSECをサポートするために、LLMNR実装が信頼アンカーに構成されるかもしれませんか、または彼らはDNS質問から入手されたキーを利用するかもしれません。 LLMNRが、「代表として派遣された信頼」が(CDかADビット)であるとサポートしないので、LLMNR実装は、それらがDNSSEC意識していない場合DNSSECを利用して、合法化をサポートすることができません。 アプローチ[a]か[b]と異なって、DNSSECは、応答者が信じられたグループの中に会員資格だけではなく、名前の所有権を示すのを可能にします。 その結果、それは偽造に対する保護を可能にします。
5.4. Cache and Port Separation
5.4. 分離をキャッシュして、移植してください。
In order to prevent responses to LLMNR queries from polluting the DNS cache, LLMNR implementations MUST use a distinct, isolated cache for LLMNR on each interface. LLMNR operates on a separate port from DNS, reducing the likelihood that a DNS server will unintentionally respond to an LLMNR query.
DNSキャッシュを汚染するのからのLLMNR質問への応答を防いで、LLMNR実装は各インタフェースのLLMNRにa異なって、孤立しているキャッシュを使用しなければなりません。 LLMNRはDNSから別々のポートを作動させます、DNSサーバがLLMNR質問に何気なく反応するという見込みを減少させて。
If a DNS server is running on a host that supports LLMNR, the LLMNR responder on that host MUST respond to LLMNR queries only for the RRSets relating to the host on which the server is running, but MUST NOT respond for other records for which the DNS server is authoritative. DNS servers MUST NOT send LLMNR queries in order to resolve DNS queries.
DNSサーバがLLMNRをサポートするホストで走っているなら、そのホストの上のLLMNR応答者は、サーバが稼働しているホストに関連するRRSetsのためだけにLLMNR質問に応じなければなりませんが、DNSサーバが正式である他の記録のために応じてはいけません。 DNSサーバは、DNS質問を決議するために質問をLLMNRに送ってはいけません。
Aboba, et al. Informational [Page 25] RFC 4795 LLMNR January 2007
Aboba、他 [25ページ]情報のRFC4795LLMNR2007年1月
6. IANA Considerations
6. IANA問題
This specification creates a new namespace: the LLMNR namespace.
この仕様は新しい名前空間を作成します: LLMNR名前空間。
In order to avoid creating any new administrative procedures, administration of the LLMNR namespace will piggyback on the administration of the DNS namespace.
どんな新しい行政手続も作成するのを避けるために、LLMNR名前空間の管理はDNS名前空間の管理で便乗するでしょう。
The rights to use a fully qualified domain name (FQDN) within LLMNR are obtained by acquiring the rights to use that name within DNS. Those wishing to use an FQDN within LLMNR should first acquire the rights to use the corresponding FQDN within DNS. Using an FQDN within LLMNR without ownership of the corresponding name in DNS creates the possibility of conflict and therefore is discouraged.
DNSの中でその名前を使用する権利を取得することによって、LLMNRの中で完全修飾ドメイン名(FQDN)を使用する権利を得ます。 LLMNRの中でFQDNを使用したがっている人は最初に、DNSの中で対応するFQDNを使用する権利を取得するべきです。 LLMNRの中でDNSの対応する名前の所有権なしでFQDNを使用するのは、闘争の可能性を作成して、したがって、お勧めできないです。
LLMNR responders may self-allocate a name within the single-label namespace first defined in [RFC1001]. Since single-label names are not unique, no registration process is required.
LLMNR応答者は自己に最初に[RFC1001]で定義された単一のラベル名前空間の中の名前を割り当てるかもしれません。 ただ一つのラベル名がユニークでないので、登録手続は全く必要ではありません。
7. Constants
7. 定数
The following timing constants are used in this protocol; they are not intended to be user configurable.
以下のタイミング定数はこのプロトコルに使用されます。 それらがユーザ構成可能であることを意図しません。
JITTER_INTERVAL 100 ms
LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
100 ms (IEEE 802 media, including IEEE 802.11)
JITTER_INTERVAL100ms LLMNR_TIMEOUT1の2(すべてのインタフェースが静的にけしかけられるなら)番目の100ms(IEEE802.11を含んでいるIEEE802メディア
Aboba, et al. Informational [Page 26] RFC 4795 LLMNR January 2007
Aboba、他 [26ページ]情報のRFC4795LLMNR2007年1月
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC1001] NetBIOS Working Group in the Defense Advanced Research
Projects Agency, Internet Activities Board, and End-
to-End Services Task Force, "Protocol standard for a
NetBIOS service on a TCP/UDP transport: Concepts and
methods", STD 19, RFC 1001, March 1987.
終わりまでの国防高等研究計画庁、インターネットActivities Board、およびEnd Services Task Forceの[RFC1001]NetBIOS作業部会、「NetBIOSのプロトコル標準はTCP/UDP輸送のときに以下を修理します」。 「概念とメソッド」、STD19、RFC1001、3月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2181] ElzとR.とR.ブッシュ、「DNS仕様への明確化」、RFC2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2308] アンドリュース、M.、「DNS質問(DNS NCACHE)の否定的キャッシュ」、RFC2308、1998年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[RFC2671] Vixie、P.、「DNS(EDNS0)のための拡張機能」、RFC2671、1999年8月。
[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.、グドムンソン、O.、イーストレーク3番目、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵トランザクション認証」、RFC2845)は2000がそうするかもしれません。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000.
2000年の[RFC2931]イーストレークD.、「DNS要求とトランザクション署名(SIG(0)s)」、RFC2931 9月3日。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
8.2. Informative References
8.2. 有益な参照
[DNSPerf] Jung, J., et al., "DNS Performance and the
Effectiveness of Caching", IEEE/ACM Transactions on
Networking, Volume 10, Number 5, pp. 589, October
2002.
[DNSPerf] ユングと、J.と、他と、「DNSパフォーマンスとキャッシュの有効性」、Networkingの上のIEEE/ACM Transactions、Volume10、Number5、ページ 589 2002年10月。
[DNSDisc] Durand, A., Hagino, I., and D. Thaler, "Well known
site local unicast addresses to communicate with
recursive DNS servers", Work in Progress, October
2002.
[DNSDisc] Progress(2002年10月)のジュランド、A.、Hagino、I.、およびD.Thaler、「再帰的なDNSサーバと伝えるよく知られているサイトローカルのユニキャストアドレス」、Work。
Aboba, et al. Informational [Page 27] RFC 4795 LLMNR January 2007
Aboba、他 [27ページ]情報のRFC4795LLMNR2007年1月
[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"Supplement to Standard for Telecommunications and
Information Exchange Between Systems - LAN/MAN
Specific Requirements - Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications: Specification for Enhanced Security",
IEEE 802.11i, July 2004.
[IEEE-802.11i]米国電気電子技術者学会、「システムの間のテレコミュニケーションと情報交換--LAN/男性決められた一定の要求--パート11の規格に補ってください」 ワイヤレスのLAN媒体アクセス制御(MAC)と物理的な層(PHY)の仕様: 「警備の強化のための仕様」、IEEE 802.11i、2004年7月。
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Work in
Progress, April 2002.
E.、「DHCP LLMNRはオプションを可能にする」という[LLMNREnable]Guttmanは進歩、2002年4月に働いています。
[LLMNRSec] Jeong, J., Park, J. and H. Kim, "DNS Name Service
based on Secure Multicast DNS for IPv6 Mobile Ad Hoc
Networks", ICACT 2004, Phoenix Park, Korea, February
9-11, 2004.
[LLMNRSec] Jeong、J.、Park、J.、およびH.キム、「DNS Name ServiceはIPv6のためにモバイルAd Hoc NetworksをSecure Multicast DNSに基礎づけました」、ICACT2004、フェニックスパーク(韓国)2004年2月9日〜11日。
[POSIX] IEEE Std. 1003.1-2001 Standard for Information
Technology -- Portable Operating System Interface
(POSIX). Open Group Technical Standard: Base
Specifications, Issue 6, December 2001. ISO/IEC
9945:2002. http://www.opengroup.org/austin
[POSIX]IEEE Std。 1003.1-2001、情報技術の規格--携帯用のオペレーティングシステムインタフェース(POSIX)。 グループ規格を開いてください: 2001年12月に仕様、問題6を基礎づけてください。 ISO/IEC9945: 2002 http://www.opengroup.org/austin
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and
Suggested Fixes", RFC 1536, October 1993.
[RFC1536] クマー、A.、ポステル、J.、ヌーマン、C.、ダンツィグ、P.、およびS.ミラー、「一般的なDNS実装誤りの、そして、提案されたフィックス」、RFC1536(1993年10月)。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[RFC2937] Smith, C., "The Name Service Search Option for DHCP",
RFC 2937, September 2000.
[RFC2937] スミス、C.、「DHCPのための名前サービス検索オプション」、RFC2937、2000年9月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and
W. Stevens, "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API)
for IPv6", RFC 3542, May 2003.
[RFC3542]スティーブンス(W.、トーマス、M.、Nordmark、E.、およびT.Jinmei)は、「2003年5月にIPv6"、RFC3542年のソケット適用業務プログラム・インタフェース(API)を進めました」。
Aboba, et al. Informational [Page 28] RFC 4795 LLMNR January 2007
Aboba、他 [28ページ]情報のRFC4795LLMNR2007年1月
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] アトキンスとD.とR.Austein、「ドメインネームシステム(DNS)の脅威分析」、RFC3833、2004年8月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC3927]チェーシャー州(S.、Aboba、B.、およびE.Guttman、「IPv4のリンクローカルのアドレスの動的設定」、RFC3927)は、2005がそうするかもしれません。
[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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
9. Acknowledgments
9. 承認
This work builds upon original work done on multicast DNS by Bill Manning and Bill Woodcock. Bill Manning's work was funded under DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge their contribution to the current specification. Constructive input has also been received from Mark Andrews, Rob Austein, Randy Bush, Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig, Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore, Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike St. Johns, Sander van Valkenburg, and Brian Zill.
この仕事はマルチキャストDNSでビル・マニングとビルWoodcockによって行われたオリジナルの仕事を当てにします。 DARPA交付金#F30602-99-1-0523の下でビル・マニングの仕事に資金を供給しました。 作者は感謝して現在の仕様への彼らの貢献を承諾します。 また、マーク・アンドリュース、ロブAustein、ランディ・ブッシュ、スチュアートチェーシャー州、ラルフDroms、ロバートElz、ジェームスGilroy、Olafurグドムンソン、アンドレアス・グスタファソン、エリックGuttman、マイロンHattig、クリスチャンのHuitema、オラフKolkman、ミカLiljeberg、キース・ムーア、Tomohide長島、トーマスNarten、エリックNordmark、マルックSavela、マイク通りジョーンズ、SanderバンValkenburg、およびブライアンZillから建設的な入力を受け取りました。
Aboba, et al. Informational [Page 29] RFC 4795 LLMNR January 2007
Aboba、他 [29ページ]情報のRFC4795LLMNR2007年1月
Authors' Addresses
作者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 706 6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 6605年の425 706メール: bernarda@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
デーヴターレルマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052
Levon Esibovマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
EMail: levone@microsoft.com
メール: levone@microsoft.com
Aboba, et al. Informational [Page 30] RFC 4795 LLMNR January 2007
Aboba、他 [30ページ]情報のRFC4795LLMNR2007年1月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Aboba, et al. Informational [Page 31]
Aboba、他 情報[31ページ]
一覧
スポンサーリンク
