[要約] RFC 4795は、リンクローカルマルチキャスト名解決（LLMNR）プロトコルに関する仕様です。LLMNRは、IPv4およびIPv6ネットワーク上でホスト名を解決するための方法を提供します。このRFCの目的は、LLMNRの機能と動作を定義し、ネットワーク上のホスト名解決の効率性と信頼性を向上させることです。
Network Working Group B. Aboba
Request for Comments: 4795 D. Thaler
Category: Informational L. Esibov
Microsoft Corporation
January 2007
Link-Local Multicast Name Resolution (LLMNR)
Link-Local Multicast Name Resolution（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).
著作権（c）The IETF Trust（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.
この文書はもともと、提案された基準として進歩を目的としていましたが、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-Local Multicast Name Resolution（LLMNR）の目標は、従来のDNS名解決が不可能なシナリオで名前解像度を有効にすることです。LLMNRは、DNSから別のポートで操作しながら、すべての現在および将来のDNS形式、タイプ、およびクラスをサポートし、個別のリゾルバーキャッシュを使用します。LLMNRはローカルリンクでのみ動作するため、DNSの代替と見なすことはできません。
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
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-Local Multicast Name Resolution（LLMNR）について説明します。これは、DNSパケット形式に基づいており、現在および将来のすべての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の代替と見なすことはできません。Link-Scopeマルチキャストアドレスは、ルーター間のLLMNRトラフィックの伝播を防ぐために使用され、ネットワークにあふれている可能性があります。LLMNRクエリは、セクション2.4で説明されているように、ユニキャストアドレスに送信することもできます。
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サーバーの発見は、このドキュメントの範囲外であり、非マルチカスト有能なメディアの名前解像度と同様です。
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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
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.
rutableアドレスリンクローカルアドレス以外のアドレス。これには、グローバルなルーティング可能なアドレスとプライベートアドレスが含まれます。
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.
到達可能なLLMNRレスポンダーは、アドレス解像度プロトコル（ARP）またはそのリンクで受信したアドレスの近隣発見クエリに応答する場合、リンクを介して到達可能なアドレスの1つを考慮します。
Responder A host that listens to LLMNR queries, and responds to those for which it is authoritative.
LLMNRクエリに耳を傾けるホストをレスポンダーし、それが権威あるものに応答します。
Sender A host that sends an LLMNR query.
LLMNRクエリを送信するホストを送信します。
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.
一意は、複数のレスポンダーが同じクエリに応答する場合がある場合、いくつかのシナリオがあります。クエリに応答するのは、1人のレスポンダーだけが応答できるシナリオがあります。単一のレスポンダーのみが予想される名前は、一意と呼ばれます。名前の一意性はレスポンダーで構成されているため、一意性検証は応答者の責任です。
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です。IPv6リンクスコープマルチキャストアドレス指定されたレスポンダーが耳を傾け、送信者がすべてのクエリを送信することは、FF02：0：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]を含むあらゆるメカニズムを介して発生する可能性があります。
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送信者は、セクション2.4で指定されているように、ユニキャストクエリが示されていない限り、LLMNRクエリをリンクスコープマルチキャストアドレス（ES）に送信します。
(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.
以下のセクションでは、送信者とレスポンダーの動作に関する詳細を提供します。
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の実装では、断片化を引き起こすことなく許容されることが知られていると知られているのと同じ大きさのUDPクエリと応答を送信する必要があります。疑わしい場合は、512オクテットの最大パケットサイズを使用する必要があります。LLMNRの実装は、リンクMTUまたは9194オクテットの小さい方と同じ大きさのUDPクエリと応答を受け入れる必要があります（イーサネットジャンボフレームサイズの9KB（9216）から、ヘッダー、VLANタグ、環状冗長チェック（CRC）の22オクテットを差し引いてください。
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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].
IDあらゆる種類のクエリを生成するプログラムによって割り当てられた16ビット識別子。この識別子はクエリから応答までコピーされ、送信者が傑出したクエリへの応答を一致させるために使用できます。クエリ内のIDフィールドは、擬似ランダム値に設定する必要があります。擬似ランダム値の生成に関するアドバイスについては、[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このメッセージの種類のクエリを指定する4ビットフィールド。この値は、クエリのオリジネーターによって設定され、応答にコピーされます。この仕様は、標準クエリと応答の動作（ゼロのオペコード値）を定義します。将来の仕様では、LLMNRを使用した他のオペコードの使用を定義する場合があります。LLMNR送信者とレスポンダーは、標準クエリ（ゼロのオペコード値）をサポートする必要があります。サポートされていないオペコード値を持つ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応答では、名前が一意と見なされる場合、「C」ビットは明確です。それ以外の場合は、設定されています。LLMNR送信者は、「C」ビットセットでクエリを再送信しません。応答者は、「C」ビットセットでLLMNRクエリに応答してはなりませんが、セクション4.2で説明されているように、一意性検証プロセスを開始する場合があります。
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応答で設定されている場合、送信者は、宛先アドレスとしてレスポンダーのユニキャストアドレスを使用してTCPを介してLLMNRクエリを再送信する必要があります。送信者がTCPクエリへの応答を受信した場合、TCビットセットでUDP応答を破棄する必要があります。「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 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.
t暫定。'the sentativeビットは、レスポンダーが名前に対して権威あるが、名前の一意性をまだ確認していない場合、応答に設定されます。レスポンダーは、設定されている場合、クエリの「t」ビットを無視する必要があります。「t」ビットセットの応答は、送信者によって静かに破棄されます。ただし、それが一意性クエリである場合を除き、その場合、競合が検出され、レスポンダーはセクション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クエリまたは応答で設定されている場合、この仕様の実装はそれらを無視する必要があります。予約済みのBITは、DNSとは異なる目的で使用できる可能性があるため、実装者は、DNSコードベースから始まるLLMNR実装でこれらのBITの処理を有効にしないことをお勧めします。
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応答コード。この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レスポンダーがマルチキャストクエリの名前に対して権威あるがエラーが発生した場合、レスポンダーはゼロのrcodeでLLMNR応答を送信する必要があります。これにより、TCPを使用してクエリがresし、TCPクエリへの応答にゼロ以外のRcodeを含めることができます。TCビットセットで応答することは、エラーを診断できるようにするため、応答を送信しない場合が望ましいです。これは、たとえば、LLMNRクエリに追加セクションにTSIG RRが含まれている場合に必要になる場合があり、レスポンダーがゼロ以外のRCodeを返す必要がある問題に遭遇します。[RFC2845]で定義されているTSIGエラー条件には、容認できない位置（rcode = 1）のTSIG RRまたは検証しないTSIG RR（TSIGエラー17（BadKey）または16（BADSIG）を使用してRCode = 9）が含まれます。
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値をサポートする必要があります。
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質問セクションのエントリの数を指定する署名されていない16ビット整数。送信者は、LLMNRクエリの質問セクションに1つの質問のみを配置する必要があります。LLMNRレスポンダーは、QDCountを使用してLLMNRクエリを静かに破棄する必要があります。llmnr送信者は、qdcountを1つに等しくない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 Answer Sectionセクションのリソースレコードの数を指定する署名されていない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 Authority Recordsセクションの名前サーバーリソースレコードの数を指定する符号なしの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追加レコードセクションのリソースレコードの数を指定する署名されていない16ビット整数。追加のレコードセクション処理については、セクション2.9で説明します。
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.
送信者は、LINK-SCOPEマルチキャストアドレスに、法的リソースレコードタイプ（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.
複数の有効なLLMNR応答が「C」ビットセットで受信される場合、同じDNSサーバーから受信した複数のRRSと同じ方法で連結および処理する必要があります。ただし、「C」ビットセットの応答は、「C」ビットが明確になった応答と連結してはなりません。代わりに、「C」ビットセットの応答のみを返す必要があります。有効な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を注文する可能性があるため、送信者はクエリアプリケーションへの応答の注文を維持する必要があります。
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アドレスを構成すると、レスポンダーは通常、対応するA、AAA、PTR RRSを合成して、これらのRRのLLMNRクエリに応答できるようにします。SOA RRは、SOA RRに加えてResponderが別のRRを持っている場合にのみ合成されます。SOA RRは、レスポンダーが持っている唯一の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」を持つように構成され、「example.com」ドメインのメンバーになるようにホスト。IPv4アドレス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.example.com. IN A 192.0.2.1
IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
1.2.0.192.in-addr.arpa. IN PTR host1. IN PTR host1.example.com.
1.2.0.192.in-addr.arpa。PTR HOST1で。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.f.3.0.2.0.1.0.0.0.0.0.0.0.0.8.d.0.1.0.0.2。PTR HOST1のIP6.ARPA。（フォーマットの理由のためのラインスプリット）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.
LLMNRレスポンダーは、「HOST1」にMX RRが含まれているローカルメールサーバーの名前でさらに手動で構成される場合があります。および「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) レスポンダーは、セクション2で定義されているリンクスコープマルチキャストアドレス（ES）と、応答者が応答したときにソースアドレスとして設定できるユニキャストアドレス（ES）のTCPポート5355で、UDPポート5355で聞く必要があります。LLMNRクエリ。
(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が受け取ったクエリの場合、レスポンダーはソースポートに注意し、それを応答の宛先ポートとして使用する必要があります。応答は、常に指示されたポートから送信する必要があります。
(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および空の回答セクションで応答する必要があります。
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」という名前で権威ある。「foo.example.com」という名前のA RRのLLMNRクエリを受信すると、ホストはリソースレコードのRDATAにIPアドレスを含むA RR（s）で権威あるAで応答します。ResponderにAAAA RRがあるが、RRがなく、RRクエリが受信された場合、Responderは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」。その結果、「foo.example.com」。「child.foo.example.com」のLLMNRクエリに応答することはできません。rcode = 3（権威ある名前エラー）。レスポンダーの名前当局の範囲を制限する目的は、たとえば、DNSツリーの子供と親（または祖父母）ノードを表す名前と2人以上のホストの共存によって引き起こされる可能性のある合併症を防ぐことです。たとえば、foo.example.com。 "および「child.foo.example.com」。
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
権限の制限がなければ、「child.foo.example.com」という名前のAリソースレコードのLLMNRクエリ。「foo.example.com」から受信したrcode = 3（権威ある名前エラー）の2つの権威ある応答が生じ、「child.foo.example.com」からレコードを要求しました。このあいまいさを防ぐために、LLMNR対応ホストは、子ゾーンへの代表団を使用して、親（または祖父母）ゾーンの動的な更新を実行できます。たとえば、ホスト
"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の動的アップデートを送信し、レコードを「foo.example.com」に接着できます。ただし、このアプローチはLLMNRの実装を大幅に複雑にし、軽量ホストには受け入れられません。
Unicast queries SHOULD be sent when:
ユニキャストクエリは、次の場合に送信する必要があります
(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) 「in-addr.arpa」または「ip6.arpa」ゾーン内の完全に形成されたIPアドレスのPTR RRの送信者クエリ。
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.
ユニキャストLLMNRクエリはTCPを使用して実行する必要があり、応答はクエリと同じTCP接続を使用して送信する必要があります。送信者はTCPクエリの送信をサポートする必要があり、レスポンダーは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クエリは応答を引き出すことはありませんが、代わりに、ICMP時間（TTL）またはホップ制限を超えたメッセージが受信されます。TCP接続セットアップの試行に応じてICMPメッセージを受信する実装は、すぐに返すことができ、これをそのような名前が存在しないという応答として扱います（RCode = 3は返されます）。ICMPメッセージを処理できない実装は、PTR RRのマルチキャストUDPクエリを送信する場合があります。TCPの実装はRTominの前に再送信されないため、TCPが複数回再送信する前にかなりの期間が経過し、TCP PTR RRクエリがオフリンク宛先に送信される長いタイムアウトになります。
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応答の宛先アドレスは、ユニキャストアドレスでなければなりません。
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では、LLMNRクエリと応答に対するTCPの使用について説明します。TCPを使用してLLMNRクエリを作成する際に、送信者はIPv6ヘッダーのホップ制限フィールドと1つの応答のIPv4ヘッダーにTTLフィールドを設定する必要があります（1）。Responderは、TCPのTTLまたはホップ制限設定を1つ（1）にリッスンソケットに設定して、Syn-ackパケットにTTL（IPv4）またはホップ制限（IPv6）が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ヘッダーのホップ制限フィールドとIPv4ヘッダーのTTLフィールドは、任意の値に設定できます。ただし、[RFC3927]の早期実装との互換性に値255を使用することをお勧めします。
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]のSockets APIでは、IP_TTLおよびIP_MULTICAST_TTLソケットオプションを使用して、発信ユニキャストおよびマルチキャストパケットのTTLを設定します。IP_RECVTTLソケットオプションは、一部のプラットフォームで利用でき、RecvMSG（）を使用して受信したパケットのIPv4 TTLを取得します。[RFC3542]は、IPv6ホップ制限を設定および取得するための同様のオプションを指定します。
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アドレスなど、ローカルインターフェイスで有効な値のみを含む必要があることのみを保証することは、レスポンダーの責任です。Link-Localアドレスは[RFC3927]で定義されています。IPv6 Link-Localアドレスは[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) リンクスコープIPv6アドレスがAAAA RRで返される場合、そのアドレスは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が使用されるローカルリンクで名前を解決できる必要があります。
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) クエリのソースアドレスがリンクスコープアドレスである場合、レスポンダーには、使用可能な場合は、応答に最初にリンクスコープアドレスを含める必要があります。
(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) クエリのソースアドレスがルーティング可能なアドレスである場合、レスポンダーには、使用可能な場合、応答に最初にルーティング可能なアドレスを含める必要があります。
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_TIMEOUTを使用して、LLMNRクエリをいつ再送信するかを決定します。LLMNR送信者は、各インターフェイスの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内で解決されない場合、送信者は、応答できるホストが受信したことを確認するために、クエリの送信を繰り返す必要があります。LLMNRクエリを3回以上送信しないでください。
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つの応答、または複数の応答を受け取らないかどうかを事前に知ることができません。LLMNR送信者は、応答がない場合、または一意性検証クエリが行われているかなど、すべての潜在的な応答を収集する必要がある場合、LLMNR_TIMEOUTを待つ必要があります。それ以外の場合、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」ビットが設定されている場合、送信者はすべての可能な応答を収集するためにllmnr_timeout jitter_intervalを待つ必要があります。複数の有効な回答が受信されると、最初に連結され、次に同じDNSサーバーから受信した複数のRRと同じ方法で扱われる場合があります。ユニキャストクエリ送信者は、最初の応答が受信された後に回答されたクエリを考慮します。
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.
「C」ビットの応答が「C」ビットセットでの応答が続くことが可能であるため、LLMNR送信者は、紛争検出の目的で追加の応答を処理する準備をする必要があります。質問に答えました。
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クエリと応答の送信は、間隔0からjitter_intervalにランダムに選択された時間によって遅延する必要があります。この遅延は、以前に一意であると判断した名前で応答するレスポンダーによって回避される場合があります（詳細についてはセクション4を参照）。
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秒のデフォルト値をお勧めします。非常に動的な環境（モバイルアドホックネットワークなど）では、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最小化のため、RRSet内のすべてのTTLを同じ値に設定する必要があります。
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レコードを応答の権限セクションに含めるべきではありません。
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.
応答者は、[RFC2308]で指定されているように、負のキャッシュを促進するために、否定的な応答の権限セクションにSOAレコードを挿入する必要があります。このレコードのTTLは、SOAレコードの最小フィールドとSOA自体のTTLの最小フィールドから設定されており、リゾルバーが否定的な答えをキャッシュする時間を示します。SOAレコード（MNAME）の所有者名は、クエリ名に設定する必要があります。RNAME、シリアル、更新、再試行、および期限切れの値は、送信者が無視する必要があります。SOAレコードのない否定的な応答は、キャッシュされるべきではありません。
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タイプを含むクエリの追加セクションを無視する必要があります。
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.
「C」ビットが設定されているクエリでは、送信者には追加セクションに競合するRRSを含める必要があります。競合通知はアドバイザリーであるため、レスポンダーは追加セクションから情報を記録する必要がありますが、それ以外の場合は追加セクションを無視する必要があります。
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.
送信者は、否定的なキャッシングなどの他の目的に使用される場合がありますが、当局からRRSまたは応答の追加セクションを回答としてキャッシュしてはなりません。
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送信者は、単一ラベル名のみのLLMNRクエリを送信する必要があります。不必要なDNSクエリを削減するために、DNSとLLMNRの両方をサポートするスタブリゾルバーは、シングルラベル名のDNSクエリの送信を避ける必要があります。LLMNR送信者は、セキュリティメカニズム（セクション5.3で説明）を利用できる場合を除き、任意の名前のクエリを送信するために有効にしないでください。LLMNRクエリは、当初要求された名前のみで送信する必要があります。検索リストは、追加の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名解決が不可能なシナリオで名前の解決を可能にします。セクション5.3で説明されているようにLLMNRセキュリティが有効になっていない場合、LLMNRが有効な名前解像度メカニズムの中でDNSよりも優先度が高い場合、これによりLLMNRキャッシュが毒されるとDNSキャッシュよりも優先されることがあります。その結果、LLMNRを一次名解像度メカニズムとして使用することは推奨されません。
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サーバーのアドレスでホストが構成されていない状況で使用されない状況で使用するために、llmnrを二次名解決メカニズムとして利用することをお勧めします。ホストの名前、または権威あるDNSサーバーに目的のRRSがない場合。
When LLMNR is configured as a secondary name resolution mechanism, LLMNR queries SHOULD only be sent when all of the following conditions are met: (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.
LLMNRがセカンダリネーム解像度メカニズムとして構成されている場合、LLMNRクエリは、次のすべての条件が満たされている場合にのみ送信する必要があります。（1）手動または自動DNS構成は実行されていません。DNSサーバーアドレスが構成されている場合、ホストはLLMNRクエリを送信する前に、DNSサーバーアドレスが構成されているすべてのプロトコルでDNSサーバーに到達しようとする必要があります。1つのプロトコルのDNSサーバーアドレスで構成されたデュアルスタックホストの場合、別のプロトコルではなく、これは、LLMNRクエリを送信する前に、DNSサーバーで構成されたプロトコルを介してDNSクエリを送信する必要があることを意味します。
(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) すべてのインターフェイスでDNSを介して名前を解決しようとするすべての試みは、検索リストを使い果たした後に失敗しました。これは、DNSサーバーが応答しなかったため、またはrcode = 3（権威ある名前エラー）または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（権威のある名前）エラーを減らす推奨検索リスト処理について説明し、それによって不要な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クエリを防ぐことができます。
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の使用は、インターフェイスごとに手動または自動的に構成できます。デフォルトでは、LLMNR応答者は常にすべてのインターフェイスで有効にする必要があります。これが望ましくないと見なされている場合、LLMNRは無効にする必要があります。そのため、ホストはリンクスコープマルチキャストアドレスで聞くことも、そのアドレスにクエリを送信しません。
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が実装されている場合、DHCPオプションを使用してインターフェイスでLLMNRを構成できます。[llmnrenable]で説明されているLLMNR有効なオプションを使用して、インターフェイスでLLMNRの使用を明示的に有効または無効にすることができます。LLMNR Enableオプションは、DNS自体が名前の解決に使用されるかどうか、またはどの順序で使用されているかを決定しません。NSSOデータに掲載されたLLMNR有効オプションコードを使用して、DHCP [RFC2937]の名前サービス検索オプション（NSSO）を使用して、さまざまな名前解像度メカニズムを使用する必要がある順序を指定できます。
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サーバーを使用していないまま、デュアルスタックホストをIPv4を介して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ダイナミックアップデートを実行できません。他のホストはその名前を解決することができません。
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サーバーが、権威ある名前エラー（rcode = 3）またはrcode = 0および空の回答セクションでIPv4またはIPv6を介して送信されたAAAA RRクエリに応答した場合、LLMNRを使用して送信されたAAAA RRクエリがIPv6を使用することができます。ローカルリンクで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.
同様に、DHCPV4サーバーがDNSサーバー構成を提供し、DNSサーバーが存在する場合、DNSサーバーはローカルホストのA RRを信頼し、IPv4またはDHCPV4ベースのダイナミックアップデートよりもダイナミッククライアントアップデートをサポートし、ローカルの名前をサポートします。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はLink-Local Name Resolutionのみを有効にするため、これは機能の劣化を表します。その結果、設定されたDNSサーバーのないホストは、使用中の構成メカニズムで許可されている場合、定期的にDNS構成を取得しようとする場合があります。他のガイダンスがない場合は、1分のデフォルトの再試行間隔を推奨します。
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).
デフォルトでは、LLMNRが有効になっている各インターフェイスでその名前が一意であるかのように、レスポンダーを動作させるように構成する必要があります。ただし、複数のレスポンダーを同じ名前に対して信頼できるように構成することもできます。たとえば、複数のレスポンダーは、クラスター名（クラスター内の複数のホストに割り当てられたAまたはAAAAタイプレコードのクエリに応答する場合があります。
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レスポンダーを介入して再構成する可能性があります。
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応答を送信する前に、一意の名前で構成されたレスポンダーは、そのインターフェイスの同じ名前を信頼できる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.
Responderがその名前が一意であることを確認したら、「C」ビットがクリアされてその名前のLLMNRクエリを受信した場合、「T」ビットで応答する必要があります。その名前が一意であることを確認する前に、応答者は応答に「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
- 追加の一意のリソースレコードを使用して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'.
一意性を検証するには、レスポンダーは、LLMNRクエリ（IPv4および/またはIPv6）に応答するすべてのプロトコルに対して、「C」ビットクリアでLLMNRクエリを送信する必要があります。type = 'any'で名前のクエリを送信することにより、レスポンダーが名前の一意性を確認することをお勧めします。
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で指定されているように、送信者はクエリを再送信します。応答が受信された場合、送信者は、ソースアドレスがそのインターフェイスのいずれかのアドレスと一致するかどうかを確認する必要があります。もしそうなら、応答は送信者から発生するため、対応は紛争とは見なされません。競合検出のトリガーを避けるために、複数のインターフェイス上の同じリンクに接続されていることを検出する応答者は、応答に「C」ビットを設定する必要があります。
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応答者は、定期的に一意性検証を試みるべきではありません。
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.
Disjoint Networkリンクのホストは、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.
同じ名前、タイプ、およびクラスの別のクエリを送信する必要があります。今回は「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.
クエリが一意の名前の場合、レスポンダーは、「C」ビットクリアで、同じ名前、タイプ、およびクラスの独自のクエリを送信する必要があります。応答が受信された場合、送信者は、ソースアドレスがそのインターフェイスのいずれかのアドレスと一致するかどうかを確認する必要があります。もしそうなら、応答は送信者から発生するため、対応は紛争とは見なされません。競合検出のトリガーを避けるために、複数のインターフェイス上の同じリンクに接続されていることを検出する応答者は、応答に「C」ビットを設定する必要があります。
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レスポンダーは、検出された競合を無視してはならず、それらを記録する必要があります。競合を検出すると、LLMNRレスポンダーは、応答のソースIPアドレスが一意性検証クエリのソースIPアドレスよりも辞書的に小さい場合、サポートされているプロトコルに対して受信したLLMNRクエリに応答して、競合する名前の使用をすぐに停止する必要があります。
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の有効期限が切れた後、一意性検証を再度試みることがあります。
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を構成することを選択できます。多くの状況では、これは適切です。ただし、ホストがそのアクティブなインターフェイスの複数でLLMNRを構成する必要がある場合は、必要な追加の予防策があります。複数のインターフェイスでLLMNRを同時にサポートすることを計画していない実装者は、このセクションをスキップする場合があります。
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.
ホストが複数のインターフェイスで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で説明されているように、一意のレコードの独自性をチェックします。状況を図1に示します。
---------- ----------
| | | |
[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つのインターフェイスで検出されますが、もう1つのインターフェイスでは検出されません。マルチホームのMyHostは、右側のインターフェイス上の「MyHost」のホストRRで応答することはできません（図1を参照）。ただし、マルチホームのホストは、左側のインターフェイスで「MyHost」名を使用するように構成されている場合があります。
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クライアントが複数のインターフェイスでクエリを送信し、複数のインターフェースから応答を受信した場合、クライアントに返される結果は実装によって定義されます。状況を図2に示します。
---------- ----------
| | | |
[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]
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.
これは、提案された名前の競合解像度メカニズムが、異なるリンク上のホスト間の競合の検出または解決をサポートしていないことを示しています。この問題は、マルチホームのホストが分離された名前スペースを持つ2つの異なるネットワークに接続されている場合に、DNSでも発生する可能性があります。DNS内の名前の一意性の問題に対処することは、このドキュメントの意図ではありません。
[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]は、sockaddr_in6構造が各スコープアドレスが存在する範囲を公開し、この構造を両方のIPv4に使用できるため、このAPIを使用するために書かれたアプリケーションの名前のあいまいさの問題を部分的に解決できるAPIを提供します。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 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.
図2の例に従って、「myhost」のアプリケーションは、ai_family = af_inet6およびai_flags = ai_all | ai_v4mappでリクエストgetaddrinfo（ "a"、...）を発行します。LLMNRクエリは両方のインターフェイスから送信され、Resolverライブラリは、それぞれ関連するSockaddr_in6構造を備えた複数のAddRINFO構造を含むリストを返します。したがって、このリストには、「A」という名前に応答する両方のホストのIPv4およびIPv6アドレスが含まれます。Link-Localアドレスには、どのインターフェイスを使用してアドレスに到達するかを明確にするSIN6_SCOPE_ID値があります。もちろん、アプリケーションには、図2と3はまだ区別できませんが、このAPIにより、アプリケーションはリスト内の任意のアドレスと正常に通信できます。
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.
パブリックの「ホットスポット」などのシナリオでは、攻撃者が同じリンクに存在する可能性があります。これらの脅威は、有線ネットワークの攻撃者がネットワークへの物理的なアクセスを必要とする一方で、ワイヤレス攻撃者が遠くから攻撃をマウントする可能性があるため、IEEE 802.11などのワイヤレスネットワークで最も深刻です。[IEEE-802.11i]などのリンク層のセキュリティは、これらの脅威が利用可能な場合、これらの脅威に反して支援することができます。
This section details security measures available to mitigate threats from on and off-link attackers.
このセクションでは、オンリンクおよびオフリンク攻撃者からの脅威を軽減するために利用可能なセキュリティ対策について詳しく説明しています。
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ホップ制限またはIPv4 TTLフィールドをLLMNR UDP応答の1つ以上の値に設定するレスポンダーは、インターネット上の被害者に到達できる場合があります。
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応答はクエリよりも大きく、攻撃者は複数のレスポンダーが使用する名前のクエリに対する複数の応答を生成できます。送信者は、静かにそれらを捨てることにより、未承諾の応答から身を守ることができます。
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接続のセットアップが成功するのを防ぐために、レスポンダーはTCP syn-ackを使用してTCP syn-ackを1つに設定してTCP syn-ackを受け取ります（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クエリなど）への応答をスプーフィングすることが可能です。また、TTLまたはホップ制限フィールドを1より大きい（1）より大きく使用することにより、Forged ResponseがLLMNR送信者に到達するようにします。鍛造応答は一致する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）の脅威分析（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を参照）。
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モバイルアドホックネットワーク用の安全なマルチキャストDNSに基づくDNSネームサービス」[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) ヌル暗号化アルゴリズムを使用したIPSECカプセルのセキュリティペイロード（ESP）を使用して、ユニキャスト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は、信頼できるグループ内のメンバーシップだけでなく、応答者に名前の所有権を示すことを許可します。その結果、偽造に対する保護を可能にします。
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.
LLMNRクエリへの応答がDNSキャッシュを汚染するのを防ぐために、LLMNR実装は、各インターフェイスでLLMNRに対して明確な分離キャッシュを使用する必要があります。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.
LLMNRをサポートするホストでDNSサーバーが実行されている場合、そのホストのLLMNRレスポンダーは、サーバーが実行されているホストに関連するrrsetsについてのみLLMNRクエリに応答する必要がありますが、DNSがDNSの他のレコードに応答してはなりません。サーバーは権威があります。DNSサーバーは、DNSクエリを解決するためにLLMNRクエリを送信してはなりません。
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.
LLMNR内で完全に適格なドメイン名（FQDN）を使用する権利は、DNS内でその名前を使用する権利を取得することにより取得されます。LLMNR内でFQDNを使用したい場合は、最初にDNS内で対応するFQDNを使用する権利を取得する必要があります。DNSの対応する名前の所有権なしでLLMNR内で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]で最初に定義されたシングルラベル名空間内の名前を自己割り当てる場合があります。単一ラベル名は一意ではないため、登録プロセスは必要ありません。
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_interval 100 ms llmnr_timeout 1秒（すべてのインターフェイスで静的に設定されている場合）100ミリ秒（IEEE 802.11を含むIEEE 802メディア）
[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.
[RFC1001]防衛先進研究プロジェクト局、インターネット活動委員会、およびエンドツーエンドサービスタスクフォースのNetBiosワーキンググループ、「TCP/UDP輸送に関するNetBIOSサービスのプロトコル標準：概念と方法」、STD 19、RFC 1001、1987年3月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「DNS仕様の説明」、RFC 2181、1997年7月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308] Andrews、M。、「DNSクエリの負のキャッシュ（DNS NCACHE）」、RFC 2308、1998年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、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.、Gudmundsson、O.、Eastlake 3rd、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、2000年5月、RFC 2845。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] EastLake 3rd、D。、「DNSリクエストおよびトランザクション署名（SIG（0）s）」、RFC 2931、2000年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年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] Jung、J.、et al。、「DNSパフォーマンスとキャッシュの有効性」、ネットワーキングに関するIEEE/ACMトランザクション、ボリューム10、番号5、pp。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] Durand、A.、Hagino、I。、およびD. Thaler、「再帰的なDNSサーバーと通信するためのよく知られているサイトローカルユニキャストアドレス」、2002年10月の作業。
[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/MAN固有の要件 - パート11：ワイヤレスLANメディアアクセス制御（MAC）および物理層（PHY）仕様：強化されたセキュリティの仕様」、IEEE 802.11i、2004年7月。
[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Work in Progress, April 2002.
[llmnrenable] Guttman、E。、「DHCP LLMNR Enable Option」、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. Kim、「IPv6モバイルアドホックネットワーク用の安全なマルチキャストDNSに基づくDNSネームサービス」、ICACT 2004、韓国、韓国、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/IEC 9945：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] Kumar、A.、Postel、J.、Neuman、C.、Danzig、P。、およびS. Miller、「一般的なDNS実装エラーと提案された修正」、RFC 1536、1993年10月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC 2937, September 2000.
[RFC2937]スミス、C。、「DHCPの名前サービス検索オプション」、RFC 2937、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、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] Stevens、W.、Thomas、M.、Nordmark、E。、およびT. Jinmei、「IPv6用Advanced Socketsアプリケーションプログラムインターフェイス（API）」、RFC 3542、2003年5月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、RFC 3927、2005年5月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
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で行われたオリジナルの作品に基づいています。ビル・マニングの仕事は、DARPA助成金＃F30602-99-1-0523の下で資金提供されました。著者は、現在の仕様への貢献に感謝します。建設的な入力は、マーク・アンドリュース、ロブ・オーストイン、ランディ・ブッシュ、スチュアート・チェシャー、ラルフ・ドロムズ、ロバート・エルツ、ジェームズ・ギルロイ、オラファー・グドムンドソン、アンドレアス・グスタフソン、エリック・グッツマン、マイロン・ハッティグ、クリスチャン・フイテマ、オラフ・コルクマン、ムーア、長島モアヒド、トーマス・ナルテン、エリック・ノードマーク、マークク・サヴェラ、マイク・セント・ジョンズ、サンダー・ヴァン・バルケンバーグ、ブライアン・ジル。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 706 6605
EMail: bernarda@microsoft.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052
Levon Esibov Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: levone@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は現在、インターネット協会によって提供されています。