[要約] RFC 6762は、マルチキャストDNS（mDNS）プロトコルに関する仕様であり、ローカルネットワーク内でのホスト名解決とサービス発見を可能にする。mDNSは、DNSのクエリとレスポンスをマルチキャストで行い、インターネット接続なしでのデバイス間の通信を容易にすることを目的としている。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6762 M. Krochmal
Category: Standards Track Apple Inc.
ISSN: 2070-1721 February 2013
Multicast DNS
マルチキャストDNS
Abstract
概要
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
ネットワーク化されたデバイスがより小さく、よりポータブルで、よりユビキタスになるにつれて、より少ない構成のインフラストラクチャで動作する機能がますます重要になっています。特に、従来のマネージドDNSサーバーがない場合にDNSリソースレコードデータタイプ（ホスト名を含むがこれに限定されない）を検索する機能は便利です。
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
マルチキャストDNS（mDNS）は、従来のユニキャストDNSサーバーがなくても、ローカルリンクでDNSのような操作を実行する機能を提供します。さらに、マルチキャストDNSは、DNSネームスペースの一部をローカルで使用できるように指定します。年会費を支払う必要はなく、委任を設定したり、これらの名前に応答するように従来のDNSサーバーを構成したりする必要もありません。
The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.
マルチキャストDNS名の主な利点は、（i）それらを設定するための管理や構成がほとんどまたはまったく必要ないこと、（ii）インフラストラクチャが存在しないときに機能すること、（iii）インフラストラクチャの障害時に機能することです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6762.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6762で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部で著作権を管理している人が、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................4
2. Conventions and Terminology Used in This Document ...............4
3. Multicast DNS Names .............................................5
4. Reverse Address Mapping .........................................7
5. Querying ........................................................8
6. Responding .....................................................13
7. Traffic Reduction ..............................................22
8. Probing and Announcing on Startup ..............................25
9. Conflict Resolution ............................................31
10. Resource Record TTL Values and Cache Coherency ................33
11. Source Address Check ..........................................38
12. Special Characteristics of Multicast DNS Domains ..............40
13. Enabling and Disabling Multicast DNS ..........................41
14. Considerations for Multiple Interfaces ........................42
15. Considerations for Multiple Responders on the Same Machine ....43
16. Multicast DNS Character Set ...................................45
17. Multicast DNS Message Size ....................................46
18. Multicast DNS Message Format ..................................47
19. Summary of Differences between Multicast DNS and Unicast DNS ..51
20. IPv6 Considerations ...........................................52
21. Security Considerations .......................................52
22. IANA Considerations ...........................................53
23. Acknowledgments ...............................................56
24. References ....................................................56
Appendix A. Design Rationale for Choice of UDP Port Number ........60
Appendix B. Design Rationale for Not Using Hashed Multicast
Addresses .............................................61
Appendix C. Design Rationale for Maximum Multicast DNS Name
Length ................................................62
Appendix D. Benefits of Multicast Responses .......................64
Appendix E. Design Rationale for Encoding Negative Responses ......65
Appendix F. Use of UTF-8 ..........................................66
Appendix G. Private DNS Namespaces ................................67
Appendix H. Deployment History ....................................67
Multicast DNS and its companion technology DNS-Based Service Discovery [RFC6763] were created to provide IP networking with the ease-of-use and autoconfiguration for which AppleTalk was well-known [RFC6760]. When reading this document, familiarity with the concepts of Zero Configuration Networking [Zeroconf] and automatic link-local addressing [RFC3927] [RFC4862] is helpful.
マルチキャストDNSとその関連テクノロジーであるDNSベースのサービスディスカバリ[RFC6763]は、AppleTalkがよく知られた[RFC6760]の使いやすさと自動構成をIPネットワーキングに提供するために作成されました。このドキュメントを読むときは、ゼロ構成ネットワーク[Zeroconf]および自動リンクローカルアドレス指定[RFC3927] [RFC4862]の概念に精通していると役立ちます。
Multicast DNS borrows heavily from the existing DNS protocol [RFC1034] [RFC1035] [RFC6195], using the existing DNS message structure, name syntax, and resource record types. This document specifies no new operation codes or response codes. This document describes how clients send DNS-like queries via IP multicast, and how a collection of hosts cooperate to collectively answer those queries in a useful manner.
マルチキャストDNSは、既存のDNSメッセージ構造、名前の構文、およびリソースレコードタイプを使用して、既存のDNSプロトコル[RFC1034] [RFC1035] [RFC6195]から大幅に借用します。このドキュメントでは、新しいオペレーションコードやレスポンスコードを指定していません。このドキュメントでは、クライアントがIPマルチキャストを介してDNSのようなクエリを送信する方法と、ホストのコレクションが協力してそれらのクエリに有用な方法で集合的に応答する方法について説明します。
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 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 「要件レベルを示すためのRFCで使用するキーワード」[RFC2119]で説明されているように解釈されます。
When this document uses the term "Multicast DNS", it should be taken to mean: "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response messages over IP Multicast to UDP port 5353". The design rationale for selecting UDP port 5353 is discussed in Appendix A.
このドキュメントで「マルチキャストDNS」という用語を使用する場合、「クライアントはIPマルチキャストを介してDNSのようなUDPクエリと応答メッセージをUDPポート5353に送信することにより、DNSのようなリソースレコードに対してDNSのようなクエリを実行する」という意味になります。 UDPポート5353を選択する設計の根拠については、付録Aで説明します。
This document uses the term "host name" in the strict sense to mean a fully qualified domain name that has an IPv4 or IPv6 address record. It does not use the term "host name" in the commonly used but incorrect sense to mean just the first DNS label of a host's fully qualified domain name.
このドキュメントでは、厳密な意味で「ホスト名」という用語を使用して、IPv4またはIPv6アドレスレコードを持つ完全修飾ドメイン名を意味します。一般的に使用されている「ホスト名」という用語は使用されていませんが、誤った意味では、ホストの完全修飾ドメイン名の最初のDNSラベルのみを意味しています。
A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP header, which is effectively a hop-count limit for the packet, to guard against routing loops. Each resource record also contains a TTL, which is the number of seconds for which the resource record may be cached. This document uses the term "IP TTL" to refer to the IP header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer to the resource record TTL (cache lifetime).
DNS（またはmDNS）パケットには、IPヘッダーにIP存続可能時間（TTL）が含まれています。これは、ルーティングループを防ぐためのパケットのホップカウント制限です。各リソースレコードには、リソースレコードをキャッシュできる秒数であるTTLも含まれています。このドキュメントでは、「IP TTL」という用語を使用してIPヘッダーTTL（ホップ制限）を示し、「RR TTL」または単に「TTL」という用語を使用してリソースレコードTTL（キャッシュの存続時間）を示します。
DNS-format messages contain a header, a Question Section, then Answer, Authority, and Additional Record Sections. The Answer, Authority, and Additional Record Sections all hold resource records in the same format. Where this document describes issues that apply equally to all three sections, it uses the term "Resource Record Sections" to refer collectively to these three sections.
DNS形式のメッセージには、ヘッダー、質問セクション、次に回答、権限、および追加レコードセクションが含まれます。 Answer、Authority、Additional Recordセクションはすべて、同じ形式のリソースレコードを保持します。このドキュメントでは、3つのセクションすべてに等しく当てはまる問題について説明しますが、「リソースレコードセクション」という用語を使用して、これら3つのセクションを総称します。
This document uses the terms "shared" and "unique" when referring to resource record sets [RFC1034]:
このドキュメントでは、リソースレコードセット[RFC1034]を指すときに「共有」および「一意」という用語を使用します。
A "shared" resource record set is one where several Multicast DNS responders may have records with the same name, rrtype, and rrclass, and several responders may respond to a particular query.
「共有」リソースレコードセットとは、複数のマルチキャストDNSレスポンダが同じ名前、rrtype、およびrrclassのレコードを持ち、複数のレスポンダが特定のクエリに応答する場合があるレコードセットです。
A "unique" resource record set is one where all the records with that name, rrtype, and rrclass are conceptually under the control or ownership of a single responder, and it is expected that at most one responder should respond to a query for that name, rrtype, and rrclass. Before claiming ownership of a unique resource record set, a responder MUST probe to verify that no other responder already claims ownership of that set, as described in Section 8.1, "Probing". (For fault-tolerance and other reasons, sometimes it is permissible to have more than one responder answering for a particular "unique" resource record set, but such cooperating responders MUST give answers containing identical rdata for these records. If they do not give answers containing identical rdata, then the probing step will reject the data as being inconsistent with what is already being advertised on the network for those names.)
「一意の」リソースレコードセットとは、その名前、rrtype、およびrrclassのすべてのレコードが、概念的には単一のレスポンダの制御または所有権の下にあり、最大で1人のレスポンダがその名前のクエリに応答することが期待されているリソースレコードセットです、rrtype、およびrrclass。一意のリソースレコードセットの所有権を要求する前に、レスポンダは、プローブして、他のレスポンダがそのセットの所有権をすでに要求していないことを確認する必要があります。 （フォールトトレランスやその他の理由により、特定の「一意の」リソースレコードセットに対して複数のレスポンダが応答することは許容される場合がありますが、そのような協調レスポンダは、これらのレコードに対して同一のrdataを含む応答を提供する必要があります。応答を提供しない場合同一のrdataが含まれている場合、プローブ手順では、これらの名前についてネットワーク上ですでにアドバタイズされているものと一致しないため、データが拒否されます。
Strictly speaking, the terms "shared" and "unique" apply to resource record sets, not to individual resource records. However, it is sometimes convenient to talk of "shared resource records" and "unique resource records". When used this way, the terms should be understood to mean a record that is a member of a "shared" or "unique" resource record set, respectively.
厳密に言うと、「共有」および「一意」という用語は、個々のリソースレコードではなく、リソースレコードセットに適用されます。ただし、「共有リソースレコード」と「一意のリソースレコード」について話すと便利な場合があります。この方法で使用する場合、これらの用語は、それぞれ「共有」または「一意」のリソースレコードセットのメンバーであるレコードを意味するものと理解してください。
A host that belongs to an organization or individual who has control over some portion of the DNS namespace can be assigned a globally unique name within that portion of the DNS namespace, such as, "cheshire.example.com.". For those of us who have this luxury, this works very well. However, the majority of home computer users do not have easy access to any portion of the global DNS namespace within which they have the authority to create names. This leaves the majority of home computers effectively anonymous for practical purposes.
DNS名前空間の一部を制御する組織または個人に属するホストには、「cheshire.example.com。」など、DNS名前空間のその部分内でグローバルに一意の名前を割り当てることができます。この贅沢さを持っている私たちにとって、これは非常にうまく機能します。ただし、大多数のホームコンピューターユーザーは、名前を作成する権限を持つグローバルDNS名前空間のどの部分にも簡単にアクセスできません。これにより、ほとんどの家庭用コンピュータは、実用的な目的のために事実上匿名になります。
To remedy this problem, this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local.". For example, a laptop computer may answer to the name "MyComputer.local.". Any computer user is granted the authority to name their computer this way, provided that the chosen host name is not already in use on that link. Having named their computer this way, the user has the authority to continue utilizing that name until such time as a name conflict occurs on the link that is not resolved in the user's favor. If this happens, the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link. These conflicts are expected to be relatively rare for people who choose reasonably imaginative names, but it is still important to have a mechanism in place to handle them when they happen.
この問題を解決するために、このドキュメントでは、すべてのコンピューターユーザーが自分のコンピューターに "single-dns-label.local。"という形式のリンクローカルマルチキャストDNSホスト名を与えることを選択できます。たとえば、ラップトップコンピュータが「MyComputer.local。」という名前に応答する場合があります。選択したホスト名がそのリンクでまだ使用されていない場合は、どのコンピューターユーザーにもこの方法でコンピューターに名前を付ける権限が付与されます。この方法でコンピューターに名前を付けたユーザーは、ユーザーの都合で解決されないリンクで名前の競合が発生するまで、その名前を引き続き使用する権限があります。これが発生した場合、コンピューター（またはその人間のユーザー）は名前の使用を中止する必要があり、そのリンクで使用するために新しい一意の名前を割り当てる必要があります（SHOULD）。これらの競合は、かなり想像力に富んだ名前を選択する人にとっては比較的まれであると予想されますが、それらが発生したときにそれらを処理するメカニズムを適切に設けることは依然として重要です。
This document specifies that the DNS top-level domain ".local." is a special domain with special semantics, namely that any fully qualified name ending in ".local." is link-local, and names within this domain are meaningful only on the link where they originate. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6 addresses in the FE80::/10 prefix, which are link-local and meaningful only on the link where they originate.
このドキュメントでは、DNSトップレベルドメイン「.local」を指定しています。特別なセマンティクスを持つ特別なドメインです。つまり、「。local」で終わる完全修飾名です。リンクローカルであり、このドメイン内の名前は、それらが発生するリンクでのみ意味があります。これは、169.254 / 16プレフィックスのIPv4アドレスまたはFE80 :: / 10プレフィックスのIPv6アドレスに似ています。これらはリンクローカルであり、発信元のリンクでのみ意味があります。
Any DNS query for a name ending with ".local." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6 equivalent FF02::FB). The design rationale for using a fixed multicast address instead of selecting from a range of multicast addresses using a hash function is discussed in Appendix B. Implementers MAY choose to look up such names concurrently via other mechanisms (e.g., Unicast DNS) and coalesce the results in some fashion. Implementers choosing to do this should be aware of the potential for user confusion when a given name can produce different results depending on external network conditions (such as, but not limited to, which name lookup mechanism responds faster).
「.local」で終わる名前のDNSクエリ。 mDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251（またはIPv6と同等のFF02 :: FB）に送信する必要があります。ハッシュ関数を使用してマルチキャストアドレスの範囲から選択するのではなく、固定マルチキャストアドレスを使用する設計の根拠については、付録Bで説明しています。いくつかの方法で。これを行うことを選択した実装者は、特定の名前が外部ネットワーク条件（これに限定されないが、どの名前検索メカニズムがより速く応答するかなど）に応じて異なる結果を生成する可能性がある場合、ユーザーの混乱の可能性に注意する必要があります。
It is unimportant whether a name ending with ".local." occurred because the user explicitly typed in a fully qualified domain name ending in ".local.", or because the user entered an unqualified domain name and the host software appended the suffix ".local." because that suffix appears in the user's search list. The ".local." suffix could appear in the search list because the user manually configured it, or because it was received via DHCP [RFC2132] or via any other mechanism for configuring the DNS search list. In this respect the ".local." suffix is treated no differently from any other search domain that might appear in the DNS search list.
名前が「.local」で終わるかどうかは重要ではありません。ユーザーが「.local。」で終わる完全修飾ドメイン名を明示的に入力したか、ユーザーが非修飾ドメイン名を入力し、ホストソフトウェアが接尾辞「.local。」を追加したために発生しましたそのサフィックスがユーザーの検索リストに表示されるためです。 「.local」サフィックスは、ユーザーが手動で構成したため、またはDHCP [RFC2132]またはDNS検索リストを構成するための他のメカニズムを介して受信されたため、検索リストに表示される可能性があります。この点で、「。local」。サフィックスは、DNS検索リストに表示される他の検索ドメインと同じように扱われます。
DNS queries for names that do not end with ".local." MAY be sent to the mDNS multicast address, if no other conventional DNS server is available. This can allow hosts on the same link to continue communicating using each other's globally unique DNS names during network outages that disrupt communication with the greater Internet. When resolving global names via local multicast, it is even more important to use DNS Security Extensions (DNSSEC) [RFC4033] or other security mechanisms to ensure that the response is trustworthy. Resolving global names via local multicast is a contentious issue, and this document does not discuss it further, instead concentrating on the issue of resolving local names using DNS messages sent to a multicast address.
「.local」で終わらない名前のDNSクエリ。他の従来のDNSサーバーが使用できない場合は、mDNSマルチキャストアドレスに送信できます。これにより、同じリンク上のホストは、大規模なインターネットとの通信を中断するネットワーク障害の間、お互いのグローバルに一意のDNS名を使用して通信を継続できます。ローカルマルチキャストを介してグローバル名を解決する場合、DNSセキュリティ拡張（DNSSEC）[RFC4033]またはその他のセキュリティメカニズムを使用して、応答が信頼できるものであることを確認することがさらに重要です。ローカルマルチキャストを介してグローバル名を解決することは論争の問題であり、このドキュメントではこれについてこれ以上説明せず、マルチキャストアドレスに送信されたDNSメッセージを使用してローカル名を解決する問題に集中します。
This document recommends a single flat namespace for dot-local host names, (i.e., the names of DNS "A" and "AAAA" records, which map names to IPv4 and IPv6 addresses), but other DNS record types (such as those used by DNS-Based Service Discovery [RFC6763]) may contain as many labels as appropriate for the desired usage, up to a maximum of 255 bytes, plus a terminating zero byte at the end. Name length issues are discussed further in Appendix C.
このドキュメントでは、ドットローカルホスト名（つまり、IPv4およびIPv6アドレスに名前をマップするDNS "A"および "AAAA"レコードの名前）に単一のフラットな名前空間を推奨していますが、他のDNSレコードタイプ（使用されているものなど） DNSベースのサービス検出[RFC6763]による）には、最大255バイトまでの希望する使用法に適切な数のラベルと、末尾に終了バイトが含まれる場合があります。名前の長さの問題については、付録Cでさらに説明します。
Enforcing uniqueness of host names is probably desirable in the common case, but this document does not mandate that. It is permissible for a collection of coordinated hosts to agree to maintain multiple DNS address records with the same name, possibly for load-balancing or fault-tolerance reasons. This document does not take a position on whether that is sensible. It is important that both modes of operation be supported. The Multicast DNS protocol allows hosts to verify and maintain unique names for resource records where that behavior is desired, and it also allows hosts to maintain multiple resource records with a single shared name where that behavior is desired. This consideration applies to all resource records, not just address records (host names). In summary: It is required that the protocol have the ability to detect and handle name conflicts, but it is not required that this ability be used for every record.
ホスト名の一意性を強制することは、一般的なケースではおそらく望ましいですが、このドキュメントではそれを義務付けていません。調整されたホストのコレクションが同じ名前の複数のDNSアドレスレコードを維持することに同意することは、おそらくロードバランシングまたはフォールトトレランスの理由で許容されます。このドキュメントは、それが賢明であるかどうかについての立場をとりません。両方の動作モードがサポートされていることが重要です。マルチキャストDNSプロトコルを使用すると、ホストは、その動作が必要なリソースレコードの一意の名前を確認および維持できます。また、ホストは、その動作が必要な単一の共有名を持つ複数のリソースレコードを維持できます。この考慮事項は、アドレスレコード（ホスト名）だけでなく、すべてのリソースレコードに適用されます。要約すると、プロトコルには名前の競合を検出して処理する機能が必要ですが、この機能をすべてのレコードに使用する必要はありません。
Like ".local.", the IPv4 and IPv6 reverse mapping domains are also defined to be link-local:
「.local。」と同様に、IPv4およびIPv6の逆マッピングドメインもリンクローカルとして定義されています。
Any DNS query for a name ending with "254.169.in-addr.arpa." MUST be sent to the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 multicast address FF02::FB. Since names under this domain correspond to IPv4 link-local addresses, it is logical that the local link is the best place to find information pertaining to those names.
「254.169.in-addr.arpa」で終わる名前のDNSクエリ。 mDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251またはmDNS IPv6マルチキャストアドレスFF02 :: FBに送信する必要があります。このドメインの名前はIPv4リンクローカルアドレスに対応しているため、これらの名前に関連する情報を見つけるには、ローカルリンクが最適な場所であることが論理的です。
Likewise, any DNS query for a name within the reverse mapping domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST be sent to the mDNS IPv6 link-local multicast address FF02::FB or the mDNS IPv4 link-local multicast address 224.0.0.251.
同様に、IPv6リンクローカルアドレスのリバースマッピングドメイン内の名前に対するDNSクエリ（ "8.efip6.arpa。"、 "9.efip6.arpa。"、 "aefip6.arpa。"、および " befip6.arpa。 "）は、mDNS IPv6リンクローカルマルチキャストアドレスFF02 :: FBまたはmDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251に送信する必要があります。
There are two kinds of Multicast DNS queries: one-shot queries of the kind made by legacy DNS resolvers, and continuous, ongoing Multicast DNS queries made by fully compliant Multicast DNS queriers, which support asynchronous operations including DNS-Based Service Discovery [RFC6763].
マルチキャストDNSクエリには2種類あります。レガシーDNSリゾルバーによって作成された種類のワンショットクエリと、完全準拠のマルチキャストDNSクエリアによって作成された継続的な継続的なマルチキャストDNSクエリで、DNSベースのサービスディスカバリ[RFC6763]を含む非同期操作をサポートします。 。
Except in the rare case of a Multicast DNS responder that is advertising only shared resource records and no unique records, a Multicast DNS responder MUST also implement a Multicast DNS querier so that it can first verify the uniqueness of those records before it begins answering queries for them.
共有リソースレコードのみをアドバタイズし、一意のレコードをアドバタイズしないまれなケースを除いて、マルチキャストDNSレスポンダは、マルチキャストDNSクエリアを実装して、クエリへの応答を開始する前にそれらのレコードの一意性を最初に確認できるようにする必要があります。それら。
The most basic kind of Multicast DNS client may simply send standard DNS queries blindly to 224.0.0.251:5353, without necessarily even being aware of what a multicast address is. This change can typically be implemented with just a few lines of code in an existing DNS resolver library. If a name being queried falls within one of the reserved Multicast DNS domains (see Sections 3 and 4), then, rather than using the configured Unicast DNS server address, the query is instead sent to 224.0.0.251:5353 (or its IPv6 equivalent [FF02::FB]:5353). Typically, the timeout would also be shortened to two or three seconds. It's possible to make a minimal Multicast DNS resolver with only these simple changes. These queries are typically done using a high-numbered ephemeral UDP source port, but regardless of whether they are sent from a dynamic port or from a fixed port, these queries MUST NOT be sent using UDP source port 5353, since using UDP source port 5353 signals the presence of a fully compliant Multicast DNS querier, as described below.
最も基本的な種類のマルチキャストDNSクライアントは、標準のDNSクエリを224.0.0.251:5353にブラインド送信するだけでよく、必ずしもマルチキャストアドレスが何であるかを意識する必要はありません。この変更は通常、既存のDNSリゾルバーライブラリの数行のコードで実装できます。照会される名前が予約済みのマルチキャストDNSドメイン（セクション3および4を参照）のいずれかに該当する場合、構成されたユニキャストDNSサーバーアドレスを使用する代わりに、クエリは代わりに224.0.0.251:5353（または同等のIPv6に送信されます） [FF02 :: FB]：5353）。通常、タイムアウトも2秒または3秒に短縮されます。これらの簡単な変更だけで、最小限のマルチキャストDNSリゾルバーを作成することができます。これらのクエリは通常、エフェメラルUDPソースポートを使用して行われますが、動的ポートから送信されるか、固定ポートから送信されるかに関係なく、これらのクエリはUDPソースポート5353を使用して送信しないでください。以下で説明するように、完全に準拠したマルチキャストDNSクエリアの存在を通知します。
A simple DNS resolver like this will typically just take the first response it receives. It will not listen for additional UDP responses, but in many instances this may not be a serious problem. If a user types "http://MyPrinter.local." into their web browser, and their simple DNS resolver just takes the first response it receives, and the user gets to see the status and configuration web page for their printer, then the protocol has met the user's needs in this case.
このような単純なDNSリゾルバーは、通常、最初に受け取った応答を受け取ります。追加のUDP応答をリッスンしませんが、多くの場合、これは深刻な問題ではない可能性があります。ユーザーが「http：//MyPrinter.local」と入力した場合。シンプルなDNSリゾルバーが最初の応答を受け取り、プリンターのステータスと構成のWebページを表示するだけで、プロトコルはユーザーのニーズを満たします。
While a basic DNS resolver like this may be adequate for simple host name lookup, it may not get ideal behavior in other cases. Additional refinements to create a fully compliant Multicast DNS querier are described below.
このような基本的なDNSリゾルバーは単純なホスト名のルックアップには十分かもしれませんが、他の場合には理想的な動作が得られない場合があります。完全に準拠したマルチキャストDNSクエリアを作成するための追加の改良点を以下に説明します。
In one-shot queries, the underlying assumption is that the transaction begins when the application issues a query, and ends when the first response is received. There is another type of query operation that is more asynchronous, in which having received one response is not necessarily an indication that there will be no more relevant responses, and the querying operation continues until no further responses are required. Determining when no further responses are required depends on the type of operation being performed. If the operation is looking up the IPv4 and IPv6 addresses of another host, then no further responses are required once a successful connection has been made to one of those IPv4 or IPv6 addresses. If the operation is browsing to present the user with a list of DNS-SD services found on the network [RFC6763], then no further responses are required once the user indicates this to the user-interface software, e.g., by closing the network browsing window that was displaying the list of discovered services.
ワンショットクエリの基本的な前提は、トランザクションは、アプリケーションがクエリを発行したときに始まり、最初の応答を受け取ったときに終了するというものです。より非同期のクエリ操作には別の種類があります。1つの応答を受け取ったからといって、必ずしも関連する応答がないことを示すものではなく、さらに応答が必要なくなるまでクエリ操作は続行されます。これ以上の応答が不要になるタイミングの決定は、実行されている操作のタイプによって異なります。操作が別のホストのIPv4およびIPv6アドレスをルックアップしている場合、それらのIPv4またはIPv6アドレスの1つへの接続が成功すると、それ以上の応答は必要ありません。操作がブラウジングであり、ネットワーク上で見つかったDNS-SDサービスのリストをユーザーに提示する場合[RFC6763]、ユーザーがこれをユーザーインターフェイスソフトウェアに指示すると、たとえばネットワークブラウジングを閉じることにより、これ以上の応答は必要ありません。検出されたサービスのリストを表示していたウィンドウ。
Imagine some hypothetical software that allows users to discover network printers. The user wishes to discover all printers on the local network, not only the printer that is quickest to respond. When the user is actively looking for a network printer to use, they open a network browsing window that displays the list of discovered printers. It would be convenient for the user if they could rely on this list of network printers to stay up to date as network printers come and go, rather than displaying out-of-date stale information, and requiring the user explicitly to click a "refresh" button any time they want to see accurate information (which, from the moment it is displayed, is itself already beginning to become out-of-date and stale). If we are to display a continuously updated live list like this, we need to be able to do it efficiently, without naive constant polling, which would be an unreasonable burden on the network. It is not expected that all users will be browsing to discover new printers all the time, but when a user is browsing to discover service instances for an extended period, we want to be able to support that operation efficiently.
ユーザーがネットワークプリンターを発見できる架空のソフトウェアを想像してみてください。ユーザーは、応答が最も速いプリンターだけでなく、ローカルネットワーク上のすべてのプリンターを検出したいと考えています。ユーザーは、使用するネットワークプリンターを積極的に探しているときに、検出されたプリンターの一覧を表示するネットワーク参照ウィンドウを開きます。古くなった古い情報を表示し、ユーザーに明示的に「更新」をクリックするように要求するのではなく、ネットワークプリンターが行き来するときにこのネットワークプリンターのリストを最新に保つことができれば、ユーザーにとって便利です。 "ボタンは、彼らが正確な情報を見たいときはいつでも（それが表示された瞬間から、それ自体がすでに古くなって古くなっています）。このように継続的に更新されるライブリストを表示する場合、単純な定数ポーリングなしで効率的に表示できる必要があります。これはネットワークに無理な負担をかけることになります。すべてのユーザーが常に新しいプリンターを発見するためにブラウジングすることは想定されていませんが、ユーザーがサービスインスタンスを発見するために長期間ブラウジングしている場合、その操作を効率的にサポートできるようにしたいと考えています。
Therefore, when retransmitting Multicast DNS queries to implement this kind of continuous monitoring, the interval between the first two queries MUST be at least one second, the intervals between successive queries MUST increase by at least a factor of two, and the querier MUST implement Known-Answer Suppression, as described below in Section 7.1. The Known-Answer Suppression mechanism tells responders which answers are already known to the querier, thereby allowing responders to avoid wasting network capacity with pointless repeated transmission of those answers. A querier retransmits its question because it wishes to receive answers it may have missed the first time, not because it wants additional duplicate copies of answers it already received. Failure to implement Known-Answer Suppression can result in unacceptable levels of network traffic. When the interval between queries reaches or exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60 minutes, and perform subsequent queries at a steady-state rate of one query per hour. To avoid accidental synchronization when, for some reason, multiple clients begin querying at exactly the same moment (e.g., because of some common external trigger event), a Multicast DNS querier SHOULD also delay the first query of the series by a randomly chosen amount in the range 20-120 ms.
したがって、この種の継続的な監視を実装するためにマルチキャストDNSクエリを再送信する場合、最初の2つのクエリ間の間隔は少なくとも1秒でなければならず、連続するクエリ間の間隔は少なくとも2倍でなければならず、クエリアは既知を実装する必要があります-Answer Suppression（セクション7.1で説明）。既知の応答抑制メカニズムは、クエリアがすでに知っている回答をレスポンダに通知します。これにより、レスポンダは、それらの回答の無意味な繰り返し送信によるネットワーク容量の浪費を回避できます。クエリアは、最初に見逃した可能性のある回答を受け取りたいので、質問を再送信します。すでに受け取った回答の重複コピーを追加したいのではありません。 Known-Answer Suppressionの実装に失敗すると、許容できないレベルのネットワークトラフィックが発生する可能性があります。クエリ間の間隔が60分以上になると、クエリアは間隔を最大60分に制限し、1時間あたり1つのクエリという定常状態のレートで後続のクエリを実行できます（MAY）。何らかの理由で（たとえば、いくつかの一般的な外部トリガーイベントのために）複数のクライアントがまったく同じタイミングでクエリを開始するときの偶発的な同期を回避するために、マルチキャストDNSクエリアは、ランダムに選択された量だけシリーズの最初のクエリを遅延させる必要があります（SHOULD）。範囲は20〜120ミリ秒です。
When a Multicast DNS querier receives an answer, the answer contains a TTL value that indicates for how many seconds this answer is valid. After this interval has passed, the answer will no longer be valid and SHOULD be deleted from the cache. Before the record expiry time is reached, a Multicast DNS querier that has local clients with an active interest in the state of that record (e.g., a network browsing window displaying a list of discovered services to the user) SHOULD reissue its query to determine whether the record is still valid.
マルチキャストDNSクエリアが回答を受信すると、回答には、この回答が有効な秒数を示すTTL値が含まれます。この間隔が経過すると、回答は無効になり、キャッシュから削除する必要があります（SHOULD）。レコードの有効期限に達する前に、そのレコードの状態にアクティブな関心を持つローカルクライアントを持つマルチキャストDNSクエリア（たとえば、発見されたサービスのリストをユーザーに表示するネットワークブラウジングウィンドウ）は、クエリを再発行して、レコードはまだ有効です。
To perform this cache maintenance, a Multicast DNS querier should plan to retransmit its query after at least 50% of the record lifetime has elapsed. This document recommends the following specific strategy.
このキャッシュメンテナンスを実行するには、マルチキャストDNSクエリアは、レコードの有効期間の少なくとも50％が経過した後にクエリを再送信するように計画する必要があります。このドキュメントでは、次の特定の戦略を推奨しています。
The querier should plan to issue a query at 80% of the record lifetime, and then if no answer is received, at 85%, 90%, and 95%. If an answer is received, then the remaining TTL is reset to the value given in the answer, and this process repeats for as long as the Multicast DNS querier has an ongoing interest in the record. If no answer is received after four queries, the record is deleted when it reaches 100% of its lifetime. A Multicast DNS querier MUST NOT perform this cache maintenance for records for which it has no local clients with an active interest. If the expiry of a particular record from the cache would result in no net effect to any client software running on the querier device, and no visible effect to the human user, then there is no reason for the Multicast DNS querier to waste network capacity checking whether the record remains valid.
クエリアは、レコードの有効期間の80％でクエリを発行し、回答が得られない場合は85％、90％、および95％でクエリを発行するように計画する必要があります。回答が受信されると、残りのTTLは回答で指定された値にリセットされ、マルチキャストDNSクエリアがレコードに継続的に関心を持っている限り、このプロセスが繰り返されます。 4つのクエリを実行しても応答が得られない場合、レコードは、有効期間の100％に達すると削除されます。マルチキャストDNSクエリアは、アクティブな関心を持つローカルクライアントがないレコードに対してこのキャッシュメンテナンスを実行してはなりません（MUST NOT）。キャッシュからの特定のレコードの期限切れにより、クエリアデバイスで実行されているクライアントソフトウェアに実質的な影響がなく、人間のユーザーに目に見える影響がない場合、マルチキャストDNSクエリアがネットワーク容量チェックを浪費する理由はありません。レコードが有効なままかどうか。
To avoid the case where multiple Multicast DNS queriers on a network all issue their queries simultaneously, a random variation of 2% of the record TTL should be added, so that queries are scheduled to be performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.
ネットワーク上の複数のマルチキャストDNSクエリアがすべて同時にクエリを発行するケースを回避するには、レコードTTLの2％のランダムな変動を追加して、クエリが80-82％、85-87％で実行されるようにスケジュールする必要があります。 、TTLの90〜92％、次に95〜97％。
An additional efficiency optimization SHOULD be performed when a Multicast DNS response is received containing a unique answer (as indicated by the cache-flush bit being set, described in Section 10.2, "Announcements to Flush Outdated Cache Entries"). In this case, there is no need for the querier to continue issuing a stream of queries with exponentially increasing intervals, since the receipt of a unique answer is a good indication that no other answers will be forthcoming. In this case, the Multicast DNS querier SHOULD plan to issue its next query for this record at 80-82% of the record's TTL, as described above.
一意の応答を含むマルチキャストDNS応答を受信したときに、追加の効率最適化を実行する必要があります（キャッシュフラッシュビットが設定されていることで示されます（10.2項「古いキャッシュエントリをフラッシュするためのアナウンス」で説明））。この場合、一意の回答の受信は他の回答がないことを示す良い指標であるため、クエリアが指数関数的に増加する間隔でクエリのストリームを発行し続ける必要はありません。この場合、マルチキャストDNSクエリアは、上記のように、レコードのTTLの80〜82％でこのレコードの次のクエリを発行する必要があります（SHOULD）。
A compliant Multicast DNS querier, which implements the rules specified in this document, MUST send its Multicast DNS queries from UDP source port 5353 (the well-known port assigned to mDNS), and MUST listen for Multicast DNS replies sent to UDP destination port 5353 at the mDNS link-local multicast address (224.0.0.251 and/or its IPv6 equivalent FF02::FB).
このドキュメントで指定されたルールを実装する準拠マルチキャストDNSクエリアは、UDP送信元ポート5353（mDNSに割り当てられた既知のポート）からマルチキャストDNSクエリを送信する必要があり、UDP宛先ポート5353に送信されるマルチキャストDNS応答をリッスンする必要がありますmDNSリンクローカルマルチキャストアドレス（224.0.0.251またはそのIPv6と同等のFF02 :: FB）。
Multicast DNS allows a querier to place multiple questions in the Question Section of a single Multicast DNS query message.
マルチキャストDNSにより、クエリアは単一のマルチキャストDNSクエリメッセージの質問セクションに複数の質問を配置できます。
The semantics of a Multicast DNS query message containing multiple questions is identical to a series of individual DNS query messages containing one question each. Combining multiple questions into a single message is purely an efficiency optimization and has no other semantic significance.
複数の質問を含むマルチキャストDNSクエリメッセージのセマンティクスは、それぞれが1つの質問を含む一連の個々のDNSクエリメッセージと同じです。複数の質問を1つのメッセージに結合することは、純粋に効率の最適化であり、他の意味上の意味はありません。
Sending Multicast DNS responses via multicast has the benefit that all the other hosts on the network get to see those responses, enabling them to keep their caches up to date and detect conflicting responses.
マルチキャスト経由でマルチキャストDNS応答を送信すると、ネットワーク上の他のすべてのホストがそれらの応答を確認できるようになるという利点があり、キャッシュを最新の状態に保ち、競合する応答を検出できるようになります。
However, there are situations where all the other hosts on the network don't need to see every response. Some examples are a laptop computer waking from sleep, the Ethernet cable being connected to a running machine, or a previously inactive interface being activated through a configuration change. At the instant of wake-up or link activation, the machine is a brand new participant on a new network. Its Multicast DNS cache for that interface is empty, and it has no knowledge of its peers on that link. It may have a significant number of questions that it wants answered right away, to discover information about its new surroundings and present that information to the user. As a new participant on the network, it has no idea whether the exact same questions may have been asked and answered just seconds ago. In this case, triggering a large sudden flood of multicast responses may impose an unreasonable burden on the network.
ただし、ネットワーク上の他のすべてのホストがすべての応答を確認する必要がない場合もあります。いくつかの例は、スリープから復帰したラップトップコンピュータ、実行中のマシンに接続されているイーサネットケーブル、または構成変更によってアクティブ化されていた以前は非アクティブだったインターフェイスです。ウェイクアップまたはリンクのアクティブ化の瞬間、マシンは新しいネットワークのまったく新しい参加者です。そのインターフェイスのマルチキャストDNSキャッシュは空であり、そのリンク上のピアの情報はありません。新しい環境に関する情報を発見し、その情報をユーザーに提示するために、すぐに回答を求められるかなりの数の質問があるかもしれません。ネットワークの新しい参加者として、まったく同じ質問が数秒前に行われ、回答された可能性があるかどうかはわかりません。この場合、マルチキャスト応答の突然の大量のフラッディングをトリガーすると、ネットワークに不当な負荷がかかる可能性があります。
To avoid large floods of potentially unnecessary responses in these cases, Multicast DNS defines the top bit in the class field of a DNS question as the unicast-response bit. When this bit is set in a question, it indicates that the querier is willing to accept unicast replies in response to this specific query, as well as the usual multicast responses. These questions requesting unicast responses are referred to as "QU" questions, to distinguish them from the more usual questions requesting multicast responses ("QM" questions). A Multicast DNS querier sending its initial batch of questions immediately on wake from sleep or interface activation SHOULD set the unicast-response bit in those questions.
これらのケースで潜在的に不要な応答の大量のフラッドを回避するために、マルチキャストDNSは、DNS質問のクラスフィールドのトップビットをユニキャスト応答ビットとして定義します。質問でこのビットが設定されている場合、クエリアは通常のマルチキャスト応答だけでなく、この特定のクエリに応答してユニキャスト応答を受け入れる用意があることを示しています。ユニキャスト応答を要求するこれらの質問は、マルチキャスト応答を要求する一般的な質問（「QM」質問）と区別するために、「QU」質問と呼ばれます。マルチキャストDNSクエリアは、スリープまたはインターフェイスのアクティブ化からウェイクした直後に最初の一連の質問を送信し、それらの質問にユニキャスト応答ビットを設定する必要があります（SHOULD）。
When a question is retransmitted (as described in Section 5.2), the unicast-response bit SHOULD NOT be set in subsequent retransmissions of that question. Subsequent retransmissions SHOULD be usual "QM" questions. After the first question has received its responses, the querier should have a large Known-Answer list (Section 7.1) so that subsequent queries should elicit few, if any, further responses. Reverting to multicast responses as soon as possible is important because of the benefits that multicast responses provide (see Appendix D). In addition, the unicast-response bit SHOULD be set only for questions that are active and ready to be sent the moment of wake from sleep or interface activation. New questions created by local clients afterwards should be treated as normal "QM" questions and SHOULD NOT have the unicast-response bit set on the first question of the series.
質問が再送信されると（セクション5.2で説明）、その質問の後続の再送信ではユニキャスト応答ビットが設定されるべきではない（SHOULD NOT）。後続の再送信は通常の「QM」質問である必要があります。最初の質問がその回答を受け取った後、クエリアは大きな既知の回答リスト（セクション7.1）を持っているはずです。マルチキャスト応答には利点があるため（付録Dを参照）、できるだけ早くマルチキャスト応答に戻すことが重要です。さらに、ユニキャスト応答ビットは、アクティブで、スリープまたはインターフェイスのアクティブ化からウェイクした瞬間に送信される準備ができている質問に対してのみ設定する必要があります（SHOULD）。その後ローカルクライアントによって作成された新しい質問は通常の「QM」質問として扱われる必要があり、シリーズの最初の質問にユニキャスト応答ビットを設定してはいけません（SHOULD NOT）。
When receiving a question with the unicast-response bit set, a responder SHOULD usually respond with a unicast packet directed back to the querier. However, if the responder has not multicast that record recently (within one quarter of its TTL), then the responder SHOULD instead multicast the response so as to keep all the peer caches up to date, and to permit passive conflict detection. In the case of answering a probe question (Section 8.1) with the unicast-response bit set, the responder should always generate the requested unicast response, but it may also send a multicast announcement if the time since the last multicast announcement of that record is more than a quarter of its TTL.
ユニキャスト応答ビットが設定された質問を受信した場合、レスポンダは通常、クエリアに送信されるユニキャストパケットで応答する必要があります（SHOULD）。ただし、レスポンダーがそのレコードを最近（そのTTLの4分の1以内に）マルチキャストしていない場合、レスポンダーは代わりに応答をマルチキャストして、すべてのピアキャッシュを最新の状態に保ち、パッシブ競合検出を許可する必要があります。ユニキャスト応答ビットが設定されたプローブの質問（セクション8.1）に応答する場合、レスポンダは常に要求されたユニキャスト応答を生成する必要がありますが、そのレコードの最後のマルチキャストアナウンス以降の時間がTTLの4分の1以上。
Unicast replies are subject to all the same packet generation rules as multicast replies, including the cache-flush bit (Section 10.2) and (except when defending a unique name against a probe from another host) randomized delays to reduce network collisions (Section 6).
ユニキャスト応答は、キャッシュフラッシュビット（セクション10.2）および（別のホストからのプローブに対して一意の名前を防御する場合を除く）ランダム化された遅延を含むマルチキャスト応答と同じすべてのパケット生成ルールの影響を受けます（セクション6）。 。
In specialized applications there may be rare situations where it makes sense for a Multicast DNS querier to send its query via unicast to a specific machine. When a Multicast DNS responder receives a query via direct unicast, it SHOULD respond as it would for "QU" questions, as described above in Section 5.4. Since it is possible for a unicast query to be received from a machine outside the local link, responders SHOULD check that the source address in the query packet matches the local subnet for that link (or, in the case of IPv6, the source address has an on-link prefix) and silently ignore the packet if not.
特殊なアプリケーションでは、マルチキャストDNSクエリアが特定のマシンにユニキャスト経由でクエリを送信することが理にかなっているまれな状況が存在する可能性があります。マルチキャストDNSレスポンダがダイレクトユニキャストを介してクエリを受信すると、セクション5.4で説明したように、「QU」質問の場合と同様に応答する必要があります（SHOULD）。ユニキャストクエリがローカルリンク外のマシンから受信される可能性があるため、レスポンダは、クエリパケットのソースアドレスがそのリンクのローカルサブネットと一致することを確認する必要があります（または、IPv6の場合、ソースアドレスはオンリンクプレフィックス）、そうでない場合は黙ってパケットを無視します。
There may be specialized situations, outside the scope of this document, where it is intended and desirable to create a responder that does answer queries originating outside the local link. Such a responder would need to ensure that these non-local queries are always answered via unicast back to the querier, since an answer sent via link-local multicast would not reach a querier outside the local link.
このドキュメントの範囲外で、ローカルリンクの外部から発信されたクエリに応答するレスポンダを作成することが意図され、望ましい特別な状況がある場合があります。リンクローカルマルチキャストを介して送信された応答はローカルリンク外のクエリアに到達しないため、このようなレスポンダは、これらの非ローカルクエリが常にクエリアにユニキャストで返されるようにする必要があります。
When a Multicast DNS responder constructs and sends a Multicast DNS response message, the Resource Record Sections of that message must contain only records for which that responder is explicitly authoritative. These answers may be generated because the record answers a question received in a Multicast DNS query message, or at certain other times that the responder determines than an unsolicited announcement is warranted. A Multicast DNS responder MUST NOT place records from its cache, which have been learned from other responders on the network, in the Resource Record Sections of outgoing response messages. Only an authoritative source for a given record is allowed to issue responses containing that record.
マルチキャストDNSレスポンダがマルチキャストDNS応答メッセージを作成して送信する場合、そのメッセージのリソースレコードセクションには、そのレスポンダが明示的に権限を持っているレコードのみを含める必要があります。これらの回答が生成されるのは、レコードがマルチキャストDNSクエリメッセージで受信した質問に回答した場合、または特定の時点で、レスポンダーが未承諾アナウンスが必要であると判断した場合です。マルチキャストDNSレスポンダは、ネットワーク上の他のレスポンダから学習したキャッシュからのレコードを、発信応答メッセージのリソースレコードセクションに配置してはなりません（MUST NOT）。特定のレコードの信頼できるソースのみが、そのレコードを含む応答を発行できます。
The determination of whether a given record answers a given question is made using the standard DNS rules: the record name must match the question name, the record rrtype must match the question qtype unless the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record rrclass must match the question qclass unless the qclass is "ANY" (255). As with Unicast DNS, generally only DNS class 1 ("Internet") is used, but should client software use classes other than 1, the matching rules described above MUST be used.
特定のレコードが特定の質問に回答するかどうかの決定は、標準のDNSルールを使用して行われます。レコード名は質問名と一致する必要があり、レコードのrrtypeは質問のqtypeと一致する必要があります。ただし、qtypeが「ANY」（255）であるか、rrtypeが"CNAME"（5）、およびレコードrrclassは、qclassが "ANY"（255）でない限り、質問qclassと一致する必要があります。ユニキャストDNSと同様に、通常はDNSクラス1（「インターネット」）のみが使用されますが、クライアントソフトウェアが1以外のクラスを使用する場合は、上記の一致ルールを使用する必要があります。
A Multicast DNS responder MUST only respond when it has a positive, non-null response to send, or it authoritatively knows that a particular record does not exist. For unique records, where the host has already established sole ownership of the name, it MUST return negative answers to queries for records that it knows not to exist. For example, a host with no IPv6 address, that has claimed sole ownership of the name "host.local." for all rrtypes, MUST respond to AAAA queries for "host.local." by sending a negative answer indicating that no AAAA records exist for that name. See Section 6.1, "Negative Responses". For shared records, which are owned by no single host, the nonexistence of a given record is ascertained by the failure of any machine to respond to the Multicast DNS query, not by any explicit negative response. For shared records, NXDOMAIN and other error responses MUST NOT be sent.
マルチキャストDNSレスポンダは、送信するnull以外の肯定的な応答がある場合、または特定のレコードが存在しないことを正式に知っている場合にのみ応答する必要があります。ホストが名前の唯一の所有権をすでに確立している一意のレコードの場合、存在しないことがわかっているレコードに対するクエリに対して否定的な応答を返す必要があります。たとえば、「host.local」という名前の唯一の所有権を主張しているIPv6アドレスのないホスト。すべてのrrtypeについて、「host.local」のAAAAクエリに応答する必要があります。その名前のAAAAレコードが存在しないことを示す否定応答を送信する。 6.1項「否定的な応答」を参照してください。単一のホストによって所有されていない共有レコードの場合、特定のレコードが存在しないことは、明示的な否定応答ではなく、マシンがマルチキャストDNSクエリに応答できなかったことによって確認されます。共有レコードの場合、NXDOMAINおよびその他のエラー応答を送信してはなりません（MUST NOT）。
Multicast DNS responses MUST NOT contain any questions in the Question Section. Any questions in the Question Section of a received Multicast DNS response MUST be silently ignored. Multicast DNS queriers receiving Multicast DNS responses do not care what question elicited the response; they care only that the information in the response is true and accurate.
マルチキャストDNS応答には、質問セクションに質問を含めることはできません。受信したマルチキャストDNS応答の質問セクションにある質問は、黙って無視する必要があります。マルチキャストDNS応答を受信するマルチキャストDNSクエリアは、どの質問が応答を引き出したかは関係ありません。彼らは、応答の情報が真実かつ正確であることのみを気にします。
A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared multiple access networks SHOULD have the capability of delaying its responses by up to 500 ms, as described below.
イーサネット上のマルチキャストDNSレスポンダ[IEEE.802.3]および同様の共有マルチアクセスネットワークは、以下で説明するように、最大500ミリ秒まで応答を遅延させる機能を持つ必要があります（SHOULD）。
If a large number of Multicast DNS responders were all to respond immediately to a particular query, a collision would be virtually guaranteed. By imposing a small random delay, the number of collisions is dramatically reduced. On a full-sized Ethernet using the maximum cable lengths allowed and the maximum number of repeaters allowed, an Ethernet frame is vulnerable to collisions during the transmission of its first 256 bits. On 10 Mb/s Ethernet, this equates to a vulnerable time window of 25.6 microseconds. On higher-speed variants of Ethernet, the vulnerable time window is shorter.
多数のマルチキャストDNSレスポンダがすべて特定のクエリに即座に応答する場合、衝突は事実上保証されます。小さなランダムな遅延を課すことにより、衝突の数は劇的に減少します。許可されている最大ケーブル長と許可されているリピータの最大数を使用するフルサイズのイーサネットでは、イーサネットフレームは最初の256ビットの送信中の衝突に対して脆弱です。 10 Mb / sイーサネットでは、これは25.6マイクロ秒の脆弱な時間枠に相当します。イーサネットのより高速なバリアントでは、脆弱な時間枠は短くなります。
In the case where a Multicast DNS responder has good reason to believe that it will be the only responder on the link that will send a response (i.e., because it is able to answer every question in the query message, and for all of those answer records it has previously verified that the name, rrtype, and rrclass are unique on the link), it SHOULD NOT impose any random delay before responding, and SHOULD normally generate its response within at most 10 ms. In particular, this applies to responding to probe queries with the unicast-response bit set. Since receiving a probe query gives a clear indication that some other responder is planning to start using this name in the very near future, answering such probe queries to defend a unique record is a high priority and needs to be done without delay. A probe query can be distinguished from a normal query by the fact that a probe query contains a proposed record in the Authority Section that answers the question in the Question Section (for more details, see Section 8.2, "Simultaneous Probe Tiebreaking").
マルチキャストDNSレスポンダが、応答を送信するリンク上の唯一のレスポンダであると信じる正当な理由がある場合（つまり、クエリメッセージのすべての質問に答えることができ、それらすべての答えに対して名前、rrtype、およびrrclassがリンク上で一意であることを以前に確認したレコード）、応答前にランダムな遅延を課すべきではなく、通常、最大10ミリ秒以内に応答を生成する必要があります（SHOULD）。特に、これは、ユニキャスト応答ビットが設定されたプローブクエリへの応答に適用されます。プローブクエリを受信すると、他のレスポンダが近い将来にこの名前の使用を開始する予定であることを明確に示しているため、一意のレコードを保護するためにそのようなプローブクエリに応答することは優先度が高く、遅延なく実行する必要があります。プローブクエリは、質問セクションの質問に回答する権限セクションに提案されたレコードが含まれているという事実によって、通常のクエリと区別できます（詳細については、セクション8.2「同時プローブタイブレイク」を参照してください）。
Responding without delay is appropriate for records like the address record for a particular host name, when the host name has been previously verified unique. Responding without delay is *not* appropriate for things like looking up PTR records used for DNS-Based Service Discovery [RFC6763], where a large number of responses may be anticipated.
ホスト名が以前に一意であることが確認されている場合、遅延なく応答することは、特定のホスト名のアドレスレコードなどのレコードに適しています。遅延なく応答することは、DNSベースのサービスディスカバリ[RFC6763]に使用されるPTRレコードの検索など、多数の応答が予想される場合には*適切ではありません*。
In any case where there may be multiple responses, such as queries where the answer is a member of a shared resource record set, each responder SHOULD delay its response by a random amount of time selected with uniform random distribution in the range 20-120 ms. The reason for requiring that the delay be at least 20 ms is to accommodate the situation where two or more query packets are sent back-to-back, because in that case we want a responder with answers to more than one of those queries to have the opportunity to aggregate all of its answers into a single response message.
回答が共有リソースレコードセットのメンバーであるクエリなど、複数の応答が存在する可能性がある場合は、各レスポンダは、20〜120 msの範囲の均一なランダム分布で選択されたランダムな時間だけ応答を遅延させる必要があります（SHOULD）。 。遅延を少なくとも20ミリ秒にする必要がある理由は、2つ以上のクエリパケットが連続して送信される状況に対応するためです。その場合、これらのクエリの複数に対する応答を持つレスポンダにすべての回答を1つの応答メッセージに集約する機会。
In the case where the query has the TC (truncated) bit set, indicating that subsequent Known-Answer packets will follow, responders SHOULD delay their responses by a random amount of time selected with uniform random distribution in the range 400-500 ms, to allow enough time for all the Known-Answer packets to arrive, as described in Section 7.2, "Multipacket Known-Answer Suppression".
クエリにTC（切り捨て）ビットセットがあり、後続の既知回答パケットが続くことを示す場合、レスポンダは、400から500ミリ秒の範囲の均一ランダム分布で選択されたランダムな時間だけ応答を遅延させる必要があります（SHOULD）。 7.2項「マルチパケットの既知の応答の抑制」で説明されているように、すべての既知の応答のパケットが到着するのに十分な時間を確保します。
The source UDP port in all Multicast DNS responses MUST be 5353 (the well-known port assigned to mDNS). Multicast DNS implementations MUST silently ignore any Multicast DNS responses they receive where the source UDP port is not 5353.
すべてのマルチキャストDNS応答のソースUDPポートは5353（mDNSに割り当てられた既知のポート）でなければなりません。マルチキャストDNS実装は、送信元UDPポートが5353でない場合に受信するマルチキャストDNS応答を黙って無視する必要があります。
The destination UDP port in all Multicast DNS responses MUST be 5353, and the destination address MUST be the mDNS IPv4 link-local multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except when generating a reply to a query that explicitly requested a unicast response:
すべてのマルチキャストDNS応答の宛先UDPポートは5353でなければならず、宛先アドレスは、mDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251またはそのIPv6と同等のFF02 :: FBでなければなりません（明示的に要求されたクエリへの応答を生成する場合を除く）ユニキャスト応答：
* via the unicast-response bit, * by virtue of being a legacy query (Section 6.7), or * by virtue of being a direct unicast query.
* *ユニキャスト応答ビットを介して、*レガシークエリであるため（セクション6.7）、または*直接ユニキャストクエリであるため。
Except for these three specific cases, responses MUST NOT be sent via unicast, because then the "Passive Observation of Failures" mechanisms described in Section 10.5 would not work correctly. Other
これらの3つの特定の場合を除いて、セクション10.5で説明されている「障害のパッシブ監視」メカニズムが正しく機能しないため、応答はユニキャスト経由で送信してはなりません（MUST NOT）。その他の
benefits of sending responses via multicast are discussed in Appendix D. A Multicast DNS querier MUST only accept unicast responses if they answer a recently sent query (e.g., sent within the last two seconds) that explicitly requested unicast responses. A Multicast DNS querier MUST silently ignore all other unicast responses.
マルチキャストを介して応答を送信する利点については、付録Dで説明します。マルチキャストDNSクエリアは、最近送信されたクエリ（最後の2秒以内に送信されたクエリなど）に明示的に要求してユニキャスト応答を要求した場合にのみ、ユニキャスト応答を受け入れる必要があります。マルチキャストDNSクエリアは、他のすべてのユニキャスト応答を黙って無視する必要があります。
To protect the network against excessive packet flooding due to software bugs or malicious attack, a Multicast DNS responder MUST NOT (except in the one special case of answering probe queries) multicast a record on a given interface until at least one second has elapsed since the last time that record was multicast on that particular interface. A legitimate querier on the network should have seen the previous transmission and cached it. A querier that did not receive and cache the previous transmission will retry its request and receive a subsequent response. In the special case of answering probe queries, because of the limited time before the probing host will make its decision about whether or not to use the name, a Multicast DNS responder MUST respond quickly. In this special case only, when responding via multicast to a probe, a Multicast DNS responder is only required to delay its transmission as necessary to ensure an interval of at least 250 ms since the last time the record was multicast on that interface.
ソフトウェアのバグや悪意のある攻撃による過度のパケットフラッディングからネットワークを保護するために、マルチキャストDNSレスポンダは（プローブクエリに応答する特別な場合を除いて）、指定されたインターフェイスで少なくとも1秒が経過するまでレコードをマルチキャストしてはなりません（MUST NOT）。そのレコードがその特定のインターフェースでマルチキャストされた最後の時間。ネットワーク上の正当なクエリアは、以前の送信を確認し、それをキャッシュする必要があります。前の送信を受信およびキャッシュしなかったクエリアは、その要求を再試行し、後続の応答を受信します。プローブクエリに応答する特殊なケースでは、プローブホストが名前を使用するかどうかを決定するまでの時間が限られているため、マルチキャストDNSレスポンダは迅速に応答する必要があります。この特別な場合のみ、マルチキャスト経由でプローブに応答する場合、マルチキャストDNSレスポンダは、そのレコードがそのインターフェースで最後にマルチキャストされてから少なくとも250ミリ秒の間隔を確保するために、必要に応じて送信を遅らせるだけで済みます。
In the early design of Multicast DNS it was assumed that explicit negative responses would never be needed. A host can assert the existence of the set of records that it claims to exist, and the union of all such sets on a link is the set of Multicast DNS records that exist on that link. Asserting the nonexistence of every record in the complement of that set -- i.e., all possible Multicast DNS records that could exist on this link but do not at this moment -- was felt to be impractical and unnecessary. The nonexistence of a record would be ascertained by a querier querying for it and failing to receive a response from any of the hosts currently attached to the link.
マルチキャストDNSの初期の設計では、明示的な否定応答が必要になることは決してないと想定されていました。ホストは、存在すると主張するレコードのセットの存在をアサートできます。リンク上のそのようなすべてのセットの結合は、そのリンク上に存在するマルチキャストDNSレコードのセットです。そのセットの補足のすべてのレコードの非存在（つまり、このリンクに存在する可能性があるが現時点では存在しない可能性のあるすべてのマルチキャストDNSレコード）をアサートすることは、非現実的で不要であると感じられました。レコードが存在しないことは、クエリアがそれを照会し、現在リンクに接続されているホストのいずれかから応答を受信できないことによって確認されます。
However, operational experience showed that explicit negative responses can sometimes be valuable. One such example is when a querier is querying for a AAAA record, and the host name in question has no associated IPv6 addresses. In this case, the responding host knows it currently has exclusive ownership of that name, and it knows that it currently does not have any IPv6 addresses, so an explicit negative response is preferable to the querier having to retransmit its query multiple times, and eventually give up with a timeout, before it can conclude that a given AAAA record does not exist.
ただし、運用上の経験から、明示的な否定的な応答が役立つ場合があることがわかっています。そのような例の1つは、クエリアがAAAAレコードを照会していて、問題のホスト名に関連付けられたIPv6アドレスがない場合です。この場合、応答するホストは、現在その名前の排他的所有権を持っていることを認識しており、現在IPv6アドレスを持たないことを認識しているため、クエリアがクエリを複数回再送信する必要があり、最終的には明示的な否定応答が望ましいです。特定のAAAAレコードが存在しないと結論付ける前に、タイムアウトをあきらめてください。
Any time a responder receives a query for a name for which it has verified exclusive ownership, for a type for which that name has no records, the responder MUST (except as allowed in (a) below) respond asserting the nonexistence of that record using a DNS NSEC record [RFC4034]. In the case of Multicast DNS the NSEC record is not being used for its usual DNSSEC [RFC4033] security properties, but simply as a way of expressing which records do or do not exist with a given name.
レスポンダーが排他的所有権を確認した名前のクエリを受信するたびに、その名前にレコードがないタイプの場合、レスポンダーは（以下の（a）で許可されている場合を除いて）、 DNS NSECレコード[RFC4034]。マルチキャストDNSの場合、NSECレコードは通常のDNSSEC [RFC4033]セキュリティプロパティには使用されませんが、単に、指定された名前でどのレコードが存在するか、存在しないかを表す方法として使用されます。
On receipt of a question for a particular name, rrtype, and rrclass, for which a responder does have one or more unique answers, the responder MAY also include an NSEC record in the Additional Record Section indicating the nonexistence of other rrtypes for that name and rrclass.
特定の名前、rrtype、およびrrclassに関する質問を受け取った場合、レスポンダは1つ以上の一意の回答を持っているため、レスポンダはその名前の他のrrtypeが存在しないことを示す追加レコードセクションにNSECレコードを含めることもできます（MAY）。 rrclass。
Implementers working with devices with sufficient memory and CPU resources MAY choose to implement code to handle the full generality of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits long. To facilitate use by devices with limited memory and CPU resources, Multicast DNS queriers are only REQUIRED to be able to parse a restricted form of the DNS NSEC record. All compliant Multicast DNS implementations MUST at least correctly generate and parse the restricted DNS NSEC record format described below:
十分なメモリとCPUリソースを備えたデバイスを使用する実装者は、最大65,536ビットのビットマップを含む、DNS NSECレコード[RFC4034]の完全な一般性を処理するコードを実装することを選択できます。メモリとCPUリソースが限られているデバイスによる使用を容易にするために、マルチキャストDNSクエリアは、制限された形式のDNS NSECレコードを解析できることのみが必要です。準拠するすべてのマルチキャストDNS実装は、以下に説明する制限付きDNS NSECレコード形式を少なくとも正しく生成および解析する必要があります。
o The 'Next Domain Name' field contains the record's own name. When used with name compression, this means that the 'Next Domain Name' field always takes exactly two bytes in the message.
o 「次のドメイン名」フィールドには、レコード自体の名前が含まれています。名前圧縮で使用する場合、これは、「次のドメイン名」フィールドがメッセージで常に正確に2バイトを取ることを意味します。
o The Type Bit Map block number is 0.
o タイプビットマップのブロック番号は0です。
o The Type Bit Map block length byte is a value in the range 1-32.
o タイプビットマップのブロック長バイトは、1-32の範囲の値です。
o The Type Bit Map data is 1-32 bytes, as indicated by length byte.
o タイプビットマップデータは、長さバイトで示されるように、1〜32バイトです。
Because this restricted form of the DNS NSEC record is limited to Type Bit Map block number zero, it cannot express the existence of rrtypes above 255. Consequently, if a Multicast DNS responder were to have records with rrtypes above 255, it MUST NOT generate these restricted-form NSEC records for those names, since to do so would imply that the name has no records with rrtypes above 255, which would be false. In such cases a Multicast DNS responder MUST either (a) emit no NSEC record for that name, or (b) emit a full NSEC record containing the appropriate Type Bit Map block(s) with the correct bits set for all the record types that exist. In practice this is not a significant limitation, since rrtypes above 255 are not currently in widespread use.
DNS NSECレコードのこの制限された形式はタイプビットマップブロック番号0に制限されているため、255を超えるrrtypeの存在を表すことはできません。そのため、マルチキャストDNSレスポンダが255を超えるrrtypeのレコードを持つ場合、これらを生成してはなりません（MUST NOT）これらの名前の制限付き形式のNSECレコード。これを行うと、名前にrrtypeが255を超えるレコードがないことを意味するため、falseになります。そのような場合、マルチキャストDNSレスポンダは、（a）その名前のNSECレコードを発行しないか、または（b）適切なタイプビットマップブロックを含む完全なNSECレコードを発行して、すべてのレコードタイプに正しいビットを設定する必要があります。存在します。 255を超えるrrtypeは現在広く使用されていないため、実際にはこれは大きな制限ではありません。
If a Multicast DNS implementation receives an NSEC record where the 'Next Domain Name' field is not the record's own name, then the implementation SHOULD ignore the 'Next Domain Name' field and process the remainder of the NSEC record as usual. In Multicast DNS the 'Next Domain Name' field is not currently used, but it could be used in a future version of this protocol, which is why a Multicast DNS implementation MUST NOT reject or ignore an NSEC record it receives just because it finds an unexpected value in the 'Next Domain Name' field.
マルチキャストDNS実装が「次のドメイン名」フィールドがレコード自体の名前ではないNSECレコードを受信した場合、実装は「次のドメイン名」フィールドを無視して、通常どおりにNSECレコードの残りを処理する必要があります。マルチキャストDNSでは、「次のドメイン名」フィールドは現在使用されていませんが、このプロトコルの将来のバージョンで使用される可能性があります。そのため、マルチキャストDNSの実装では、受信したNSECレコードを拒否または無視してはなりません。 [次のドメイン名]フィールドに予期しない値が含まれています。
If a Multicast DNS implementation receives an NSEC record containing more than one Type Bit Map, or where the Type Bit Map block number is not zero, or where the block length is not in the range 1-32, then the Multicast DNS implementation MAY silently ignore the entire NSEC record. A Multicast DNS implementation MUST NOT ignore an entire message just because that message contains one or more NSEC record(s) that the Multicast DNS implementation cannot parse. This provision is to allow future enhancements to the protocol to be introduced in a backwards-compatible way that does not break compatibility with older Multicast DNS implementations.
マルチキャストDNS実装が複数のタイプビットマップを含むNSECレコードを受信する場合、またはタイプビットマップのブロック番号がゼロでない場合、またはブロック長が1〜32の範囲にない場合、マルチキャストDNS実装はサイレントNSECレコード全体を無視します。マルチキャストDNS実装が解析できない1つまたは複数のNSECレコードがメッセージに含まれているという理由だけで、マルチキャストDNS実装はメッセージ全体を無視してはなりません（MUST NOT）。この規定により、プロトコルの将来の拡張機能を、下位の互換性のある方法で導入できるようになり、古いマルチキャストDNS実装との互換性が損なわれなくなります。
To help differentiate these synthesized NSEC records (generated programmatically on-the-fly) from conventional Unicast DNS NSEC records (which actually exist in a signed DNS zone), the synthesized Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type Bit Map, whereas conventional Unicast DNS NSEC records do have the NSEC bit set.
これらの合成されたNSECレコード（プログラムでオンザフライで生成）を従来のユニキャストDNS NSECレコード（実際には署名付きDNSゾーンに存在する）と区別するために、合成されたマルチキャストDNS NSECレコードは、タイプビットにNSECビットが設定されていてはなりません（MUST NOT）マップ。従来のユニキャストDNS NSECレコードにはNSECビットが設定されています。
The TTL of the NSEC record indicates the intended lifetime of the negative cache entry. In general, the TTL given for an NSEC record SHOULD be the same as the TTL that the record would have had, had it existed. For example, the TTL for address records in Multicast DNS is typically 120 seconds (see Section 10), so the negative cache lifetime for an address record that does not exist should also be 120 seconds.
NSECレコードのTTLは、ネガティブキャッシュエントリの予定寿命を示します。一般に、NSECレコードに指定されたTTLは、レコードが存在する場合、レコードが持っていたはずのTTLと同じである必要があります（SHOULD）。たとえば、マルチキャストDNSのアドレスレコードのTTLは通常120秒（セクション10を参照）であるため、存在しないアドレスレコードの負のキャッシュライフタイムも120秒にする必要があります。
A responder MUST only generate negative responses to queries for which it has legitimate ownership of the name, rrtype, and rrclass in question, and can legitimately assert that no record with that name, rrtype, and rrclass exists. A responder can assert that a specified rrtype does not exist for one of its names if it knows a priori that it has exclusive ownership of that name (e.g., names of reverse address mapping PTR records, which are derived from IP addresses, which should be unique on the local link) or if it previously claimed unique ownership of that name using probe queries for rrtype "ANY". (If it were to use probe queries for a specific rrtype, then it would only own the name for that rrtype, and could not assert that other rrtypes do not exist.) The design rationale for this mechanism for encoding negative responses is discussed further in Appendix E.
レスポンダは、問題の名前、rrtype、およびrrclassの正当な所有権を持ち、その名前、rrtype、およびrrclassのレコードが存在しないことを正当に主張できるクエリに対してのみ否定応答を生成する必要があります。レスポンダは、指定されたrrtypeがその名前の排他的所有権を持っていることをアプリオリに知っている場合（たとえば、IPアドレスから派生するリバースアドレスマッピングPTRレコードの名前）ローカルリンク上で一意）、または以前にrrtype "ANY"のプローブクエリを使用してその名前の一意の所有権を主張していた場合。 （特定のrrtypeに対してプローブクエリを使用する場合、それはそのrrtypeの名前のみを所有し、他のrrtypeが存在しないと断言することはできません。）否定応答をエンコードするためのこのメカニズムの設計根拠は、付録E.
When a Multicast DNS responder sends a Multicast DNS response message containing its own address records, it MUST include all addresses that are valid on the interface on which it is sending the message, and MUST NOT include addresses that are not valid on that interface (such as addresses that may be configured on the host's other interfaces). For example, if an interface has both an IPv6 link-local and an IPv6 routable address, both should be included in the response message so that queriers receive both and can make their own choice about which to use. This allows a querier that only has an IPv6 link-local address to connect to the link-local address, and a different querier that has an IPv6 routable address to connect to the IPv6 routable address instead.
マルチキャストDNSレスポンダが独自のアドレスレコードを含むマルチキャストDNS応答メッセージを送信する場合、メッセージを送信しているインターフェイスで有効なすべてのアドレスを含める必要があり、そのインターフェイスで無効なアドレス（ホストの他のインターフェースで構成できるアドレスとして）。たとえば、インターフェースにIPv6リンクローカルアドレスとIPv6ルーティング可能アドレスの両方がある場合、クエリアが両方を受信し、どちらを使用するかを独自に選択できるように、両方を応答メッセージに含める必要があります。これにより、IPv6リンクローカルアドレスのみを持つクエリアがリンクローカルアドレスに接続でき、代わりにIPv6ルーティング可能なアドレスを持つ別のクエリアがIPv6ルーティング可能なアドレスに接続できます。
When a Multicast DNS responder places an IPv4 or IPv6 address record (rrtype "A" or "AAAA") into a response message, it SHOULD also place any records of the other address type with the same name into the additional section, if there is space in the message. This is to provide fate sharing, so that all a device's addresses are delivered atomically in a single message, to reduce the risk that packet loss could cause a querier to receive only the IPv4 addresses and not the IPv6 addresses, or vice versa.
マルチキャストDNSレスポンダがIPv4またはIPv6アドレスレコード（rrtype "A"または "AAAA"）を応答メッセージに配置する場合、同じ名前を持つ他のアドレスタイプのレコードがあれば、それも追加セクションに配置する必要があります（SHOULD）。メッセージ内のスペース。これは運命の共有を提供し、すべてのデバイスのアドレスが単一のメッセージでアトミックに配信されるようにし、パケット損失によりクエリアがIPv4アドレスのみを受信し、IPv6アドレスを受信しない、またはその逆のリスクを軽減します。
In the event that a device has only IPv4 addresses but no IPv6 addresses, or vice versa, then the appropriate NSEC record SHOULD be placed into the additional section, so that queriers can know with certainty that the device has no addresses of that kind.
デバイスにIPv4アドレスのみがあり、IPv6アドレスがない場合、またはその逆の場合、適切なNSECレコードを追加セクションに配置する必要があります（SHOULD）。これにより、クエリアは、デバイスにその種類のアドレスがないことを確実に知ることができます。
Some Multicast DNS responders treat a physical interface with both IPv4 and IPv6 address as a single interface with two addresses. Other Multicast DNS responders may treat this case as logically two interfaces (one with one or more IPv4 addresses, and the other with one or more IPv6 addresses), but responders that operate this way MUST NOT put the corresponding automatic NSEC records in replies they send (i.e., a negative IPv4 assertion in their IPv6 responses, and a negative IPv6 assertion in their IPv4 responses) because this would cause incorrect operation in responders on the network that work the former way.
一部のマルチキャストDNSレスポンダは、IPv4アドレスとIPv6アドレスの両方を持つ物理インターフェイスを、2つのアドレスを持つ単一のインターフェイスとして扱います。他のマルチキャストDNSレスポンダは、このケースを論理的に2つのインターフェース（1つ以上のIPv4アドレスを持つインターフェイスと1つ以上のIPv6アドレスを持つインターフェイス）として扱う可能性がありますが、このように動作するレスポンダは、対応する自動NSECレコードを返信に含めてはなりません（MUST NOT） （つまり、IPv6応答でのIPv4アサーションの否定、およびIPv4応答でのIPv6アサーションの否定）これは、以前の方法で機能するネットワーク上のレスポンダーで正しくない動作を引き起こすためです。
Multicast DNS responders MUST correctly handle DNS query messages containing more than one question, by answering any or all of the questions to which they have answers. Unlike single-question queries, where responding without delay is allowed in appropriate cases, for query messages containing more than one question, all (non-defensive) answers SHOULD be randomly delayed in the range 20-120 ms, or 400-500 ms if the TC (truncated) bit is set. This is because when a query message contains more than one question, a Multicast DNS responder cannot generally be certain that other responders will not also be simultaneously generating answers to other questions in that query message. (Answers defending a name, in response to a probe for that name, are not subject to this delay rule and are still sent immediately.)
マルチキャストDNSレスポンダは、複数の質問を含むDNSクエリメッセージを、自分が回答する質問の一部またはすべてに回答することにより、正しく処理する必要があります。適切な場合に遅延なしでの応答が許可される単一質問クエリとは異なり、複数の質問を含むクエリメッセージの場合、すべての（非防御的）回答は20〜120ミリ秒、または400〜500ミリ秒の範囲でランダムに遅延する必要があります。 TC（切り捨て）ビットが設定されます。これは、クエリメッセージに複数の質問が含まれている場合、マルチキャストDNSレスポンダは通常、他のレスポンダがそのクエリメッセージ内の他の質問に対する回答を同時に生成しないことを確信できないためです。 （その名前のプローブに応答して名前を防御する回答は、この遅延ルールの対象ではなく、すぐに送信されます。）
When possible, a responder SHOULD, for the sake of network efficiency, aggregate as many responses as possible into a single Multicast DNS response message. For example, when a responder has several responses it plans to send, each delayed by a different interval, then earlier responses SHOULD be delayed by up to an additional 500 ms if that will permit them to be aggregated with other responses scheduled to go out a little later.
可能であれば、レスポンダは、ネットワーク効率のために、できるだけ多くの応答を単一のマルチキャストDNS応答メッセージに集約する必要があります（SHOULD）。たとえば、レスポンダーが送信する予定の複数の応答があり、それぞれが異なる間隔で遅延している場合、それより前の応答は、送信がスケジュールされている他の応答と集約される場合、最大500ミリ秒遅延する必要があります。少し後で。
When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its records that match the query. This is subtly different from how qtype "ANY" and qclass "ANY" work in Unicast DNS.
qtype "ANY"（255）またはqclass "ANY"（255）を使用してクエリに応答する場合、マルチキャストDNSレスポンダは、クエリに一致するレコードの* ALL *で応答する必要があります。これは、ユニキャストDNSでのqtype "ANY"およびqclass "ANY"の動作とは微妙に異なります。
A common misconception is that a Unicast DNS query for qtype "ANY" will elicit a response containing all matching records. This is incorrect. If there are any records that match the query, the response is required only to contain at least one of them, not necessarily all of them.
よくある誤解は、qtype "ANY"のユニキャストDNSクエリが、一致するすべてのレコードを含む応答を引き出すというものです。これは誤りです。クエリに一致するレコードがある場合、応答にはそれらのすべてではなく、少なくとも1つが含まれている必要があります。
This somewhat surprising behavior is commonly seen with caching (i.e., "recursive") name servers. If a caching server receives a qtype "ANY" query for which it has at least one valid answer, it is allowed to return only those matching answers it happens to have already in its cache, and it is not required to reconsult the authoritative name server to check if there are any more records that also match the qtype "ANY" query.
このやや意外な動作は、キャッシュ（つまり「再帰的」）ネームサーバーでよく見られます。キャッシングサーバーが有効な回答が少なくとも1つあるqtype "ANY"クエリを受信した場合、キャッシュにすでに存在する一致する回答のみを返すことが許可されており、権限のあるネームサーバーに再度問い合わせる必要はありません。 qtype "ANY"クエリにも一致するレコードが他にあるかどうかを確認します。
For example, one might imagine that a query for qtype "ANY" for name "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA) address records for that host. In reality, what happens is that it depends on the history of what queries have been previously received by intervening caching servers. If a caching server has no records for "host.example.com", then it will consult another server (usually the authoritative name server for the name in question), and, in that case, it will typically return all IPv4 and IPv6 address records. However, if some other host has recently done a query for qtype "A" for name "host.example.com", so that the caching server already has IPv4 address records for "host.example.com" in its cache but no IPv6 address records, then it will return only the IPv4 address records it already has cached, and no IPv6 address records.
たとえば、名前 "host.example.com"のqtype "ANY"のクエリで、そのホストのIPv4（A）とIPv6（AAAA）の両方のアドレスレコードが返されると想像してください。実際には、介在するキャッシングサーバーが以前に受信したクエリの履歴に依存します。キャッシングサーバーに "host.example.com"のレコードがない場合、キャッシングサーバーは別のサーバー（通常は問題の名前の権限のあるネームサーバー）に問い合わせ、その場合、通常はすべてのIPv4およびIPv6アドレスを返します記録。ただし、最近他のホストが名前 "host.example.com"のqtype "A"のクエリを実行したため、キャッシングサーバーはすでに "host.example.com"のIPv4アドレスレコードをキャッシュに持っているがIPv6は持っていない場合アドレスレコードの場合、すでにキャッシュしているIPv4アドレスレコードのみが返され、IPv6アドレスレコードは返されません。
Multicast DNS does not share this property that qtype "ANY" and qclass "ANY" queries return some undefined subset of the matching records. When responding to queries using qtype "ANY" (255) and/or qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its records that match the query.
マルチキャストDNSは、qtype "ANY"およびqclass "ANY"クエリが一致するレコードの未定義のサブセットを返すというこのプロパティを共有しません。 qtype "ANY"（255）またはqclass "ANY"（255）を使用してクエリに応答する場合、マルチキャストDNSレスポンダは、クエリに一致するレコードの* ALL *で応答する必要があります。
If a Multicast DNS responder ("A") observes some other Multicast DNS responder ("B") send a Multicast DNS response message containing a resource record with the same name, rrtype, and rrclass as one of A's resource records, but *different* rdata, then:
マルチキャストDNSレスポンダ（ "A"）が他のマルチキャストDNSレスポンダ（ "B"）を観察する場合、Aのリソースレコードの1つと同じ名前、rrtype、rrclassのリソースレコードを含むマルチキャストDNS応答メッセージを送信しますが、*異なる*次に、rdata：
o If A's resource record is intended to be a shared resource record, then this is no conflict, and no action is required.
o Aのリソースレコードが共有リソースレコードであることが意図されている場合、これは競合ではなく、アクションは必要ありません。
o If A's resource record is intended to be a member of a unique resource record set owned solely by that responder, then this is a conflict and MUST be handled as described in Section 9, "Conflict Resolution".
o Aのリソースレコードがそのレスポンダのみが所有する一意のリソースレコードセットのメンバーになることを意図している場合、これは競合であり、セクション9「競合解決」で説明されているように処理する必要があります。
If a Multicast DNS responder ("A") observes some other Multicast DNS responder ("B") send a Multicast DNS response message containing a resource record with the same name, rrtype, and rrclass as one of A's resource records, and *identical* rdata, then:
マルチキャストDNSレスポンダ（ "A"）が他のマルチキャストDNSレスポンダ（ "B"）を観察する場合、Aのリソースレコードの1つと同じ名前、rrtype、およびrrclassのリソースレコードを含むマルチキャストDNS応答メッセージを送信し、*同一*次に、rdata：
o If the TTL of B's resource record given in the message is at least half the true TTL from A's point of view, then no action is required.
o メッセージで指定されたBのリソースレコードのTTLがAの観点から見た真のTTLの半分以上である場合、アクションは不要です。
o If the TTL of B's resource record given in the message is less than half the true TTL from A's point of view, then A MUST mark its record to be announced via multicast. Queriers receiving the record from B would use the TTL given by B and, hence, may delete the record sooner than A expects. By sending its own multicast response correcting the TTL, A ensures that the record will be retained for the desired time.
o メッセージで指定されたBのリソースレコードのTTLがAの観点からの真のTTLの半分未満である場合、Aはそのレコードがマルチキャストで通知されるようにマークを付ける必要があります。 Bからレコードを受信するクエリアは、Bから提供されたTTLを使用するため、Aが予期するよりも早くレコードを削除する可能性があります。 Aは、TTLを修正する独自のマルチキャスト応答を送信することにより、レコードが必要な時間保持されるようにします。
These rules allow multiple Multicast DNS responders to offer the same data on the network (perhaps for fault-tolerance reasons) without conflicting with each other.
これらのルールにより、複数のマルチキャストDNSレスポンダが互いに競合することなく（おそらくフォールトトレランスの理由から）ネットワーク上で同じデータを提供できます。
If the source UDP port in a received Multicast DNS query is not port 5353, this indicates that the querier originating the query is a simple resolver such as described in Section 5.1, "One-Shot Multicast DNS Queries", which does not fully implement all of Multicast DNS. In this case, the Multicast DNS responder MUST send a UDP response directly back to the querier, via unicast, to the query packet's source IP address and port. This unicast response MUST be a conventional unicast response as would be generated by a conventional Unicast DNS server; for example, it MUST repeat the query ID and the question given in the query message. In addition, the cache-flush bit described in Section 10.2, "Announcements to Flush Outdated Cache Entries", MUST NOT be set in legacy unicast responses.
受信したマルチキャストDNSクエリのソースUDPポートがポート5353でない場合、これは、クエリを発信したクエリアが、5.1項「ワンショットマルチキャストDNSクエリ」で説明されているような単純なリゾルバであることを示します。マルチキャストDNS。この場合、マルチキャストDNSレスポンダは、UDP応答をクエリパケットの送信元IPアドレスとポートに、ユニキャスト経由でクエリアに直接送信する必要があります。このユニキャスト応答は、従来のユニキャストDNSサーバーによって生成されるような従来のユニキャスト応答でなければなりません。たとえば、クエリIDとクエリメッセージで指定された質問を繰り返す必要があります。さらに、10.2項「古いキャッシュエントリをフラッシュするためのアナウンス」で説明されているキャッシュフラッシュビットは、レガシーユニキャスト応答で設定してはいけません。
The resource record TTL given in a legacy unicast response SHOULD NOT be greater than ten seconds, even if the true TTL of the Multicast DNS resource record is higher. This is because Multicast DNS responders that fully participate in the protocol use the cache coherency mechanisms described in Section 10, "Resource Record TTL Values and Cache Coherency", to update and invalidate stale data. Were unicast responses sent to legacy resolvers to use the same high TTLs, these legacy resolvers, which do not implement these cache coherency mechanisms, could retain stale cached resource record data long after it is no longer valid.
従来のユニキャスト応答で提供されたリソースレコードTTLは、たとえマルチキャストDNSリソースレコードの真のTTLが高くても、10秒を超えてはなりません（SHOULD NOT）。これは、プロトコルに完全に参加しているマルチキャストDNSレスポンダが、セクション10「リソースレコードTTL値とキャッシュコヒーレンシ」で説明されているキャッシュコヒーレンシメカニズムを使用して、古いデータを更新および無効にするためです。同じ高TTLを使用するためにレガシーリゾルバーにユニキャスト応答が送信された場合、これらのレガシーリゾルバーは、これらのキャッシュコヒーレンシメカニズムを実装していないため、無効になった後も古くなったキャッシュリソースレコードデータを保持できます。
A variety of techniques are used to reduce the amount of traffic on the network.
ネットワーク上のトラフィック量を削減するために、さまざまな手法が使用されています。
When a Multicast DNS querier sends a query to which it already knows some answers, it populates the Answer Section of the DNS query message with those answers.
マルチキャストDNSクエリアが既にいくつかの回答を知っているクエリを送信すると、DNSクエリメッセージの回答セクションにそれらの回答が入力されます。
Generally, this applies only to Shared records, not Unique records, since if a Multicast DNS querier already has at least one Unique record in its cache then it should not be expecting further different answers to this question, since the Unique record(s) it already has comprise the complete answer, so it has no reason to be sending the query at all. In contrast, having some Shared records in its cache does not necessarily imply that a Multicast DNS querier will not receive further answers to this query, and it is in this case that it is beneficial to use the Known-Answer list to suppress repeated sending of redundant answers that the querier already knows.
通常、これは一意のレコードではなく共有レコードにのみ適用されます。マルチキャストDNSクエリアのキャッシュに少なくとも1つの一意のレコードがある場合、一意のレコードは一意のレコードであるため、この質問に対する別の異なる回答は期待できません。完全な回答がすでに含まれているため、クエリを送信する理由はまったくありません。対照的に、キャッシュにいくつかの共有レコードがあることは、マルチキャストDNSクエリアがこのクエリに対する追加の回答を受信しないことを必ずしも意味するわけではなく、この場合、既知の回答リストを使用して繰り返し送信されるのを抑制することが有益です。クエリアがすでに知っている冗長な回答。
A Multicast DNS responder MUST NOT answer a Multicast DNS query if the answer it would give is already included in the Answer Section with an RR TTL at least half the correct value. If the RR TTL of the answer as given in the Answer Section is less than half of the true RR TTL as known by the Multicast DNS responder, the responder MUST send an answer so as to update the querier's cache before the record becomes in danger of expiration.
マルチキャストDNSレスポンダは、適切な値の半分以上のRR TTLで回答セクションに既に含まれている場合、マルチキャストDNSクエリに回答してはなりません（MUST NOT）。回答セクションに記載されている回答のRR TTLがマルチキャストDNSレスポンダによって認識されている真のRR TTLの半分未満である場合、レスポンダは、レコードが危険になる前にクエリアのキャッシュを更新するように回答を送信する必要があります有効期限。
Because a Multicast DNS responder will respond if the remaining TTL given in the Known-Answer list is less than half the true TTL, it is superfluous for the querier to include such records in the Known-Answer list. Therefore, a Multicast DNS querier SHOULD NOT include records in the Known-Answer list whose remaining TTL is less than half of their original TTL. Doing so would simply consume space in the message without achieving the goal of suppressing responses and would, therefore, be a pointless waste of network capacity.
マルチキャストDNSレスポンダは、既知の回答のリストで指定された残りのTTLが真のTTLの半分未満である場合に応答するため、クエリアがそのようなレコードを既知の回答のリストに含めるのは不必要です。したがって、マルチキャストDNSクエリアには、残りのTTLが元のTTLの半分未満である既知の回答リストのレコードを含めるべきではありません（SHOULD NOT）。これを行うと、応答を抑制するという目標を達成せずにメッセージのスペースを消費するだけなので、ネットワーク容量を無駄に浪費することになります。
A Multicast DNS querier MUST NOT cache resource records observed in the Known-Answer Section of other Multicast DNS queries. The Answer Section of Multicast DNS queries is not authoritative. By placing information in the Answer Section of a Multicast DNS query, the querier is stating that it *believes* the information to be true. It is not asserting that the information *is* true. Some of those records may have come from other hosts that are no longer on the network. Propagating that stale information to other Multicast DNS queriers on the network would not be helpful.
マルチキャストDNSクエリアは、他のマルチキャストDNSクエリの既知の回答セクションで観察されたリソースレコードをキャッシュしてはなりません（MUST NOT）。マルチキャストDNSクエリの回答セクションには権限がありません。マルチキャストDNSクエリのAnswerセクションに情報を配置することにより、クエリアは、情報が真であると*信じる*と述べています。情報が*真実*であることを主張するものではありません。これらのレコードの一部は、ネットワーク上に存在しない他のホストからのものである可能性があります。古い情報をネットワーク上の他のマルチキャストDNSクエリアに伝播しても、役に立ちません。
Sometimes a Multicast DNS querier will already have too many answers to fit in the Known-Answer Section of its query packets. In this case, it should issue a Multicast DNS query containing a question and as many Known-Answer records as will fit. It MUST then set the TC (Truncated) bit in the header before sending the query. It MUST immediately follow the packet with another query packet containing no questions and as many more Known-Answer records as will fit. If there are still too many records remaining to fit in the packet, it again sets the TC bit and continues until all the Known-Answer records have been sent.
マルチキャストDNSクエリアの回答が多すぎて、クエリパケットの既知の回答セクションに収まらない場合があります。この場合、それは、質問と、できるだけ多くの既知の回答レコードを含むマルチキャストDNSクエリを発行する必要があります。次に、クエリを送信する前に、ヘッダーにTC（Truncated）ビットを設定する必要があります。パケットの直後に、質問を含まず、できるだけ多くの既知の回答レコードを含む別のクエリパケットが続く必要があります。パケットが収まらないほど多くのレコードが残っている場合は、TCビットを再度設定し、すべての既知の回答レコードが送信されるまで続行します。
A Multicast DNS responder seeing a Multicast DNS query with the TC bit set defers its response for a time period randomly selected in the interval 400-500 ms. This gives the Multicast DNS querier time to send additional Known-Answer packets before the responder responds. If the responder sees any of its answers listed in the Known-Answer lists of subsequent packets from the querying host, it MUST delete that answer from the list of answers it is planning to give (provided that no other host on the network has also issued a query for that record and is waiting to receive an answer).
TCビットが設定されたマルチキャストDNSクエリを受信したマルチキャストDNSレスポンダは、400〜500ミリ秒の間隔でランダムに選択された期間、その応答を延期します。これにより、応答側が応答する前に、マルチキャストDNSクエリアに追加の既知の応答パケットを送信する時間が与えられます。応答側は、クエリを実行しているホストからの後続のパケットの既知回答リストにリストされている回答を見つけた場合、その回答を、提供する予定の回答のリストから削除する必要があります（ネットワーク上の他のホストも発行していない場合）そのレコードのクエリであり、回答の受信を待機しています）。
If the responder receives additional Known-Answer packets with the TC bit set, it SHOULD extend the delay as necessary to ensure a pause of 400-500 ms after the last such packet before it sends its answer. This opens the potential risk that a continuous stream of Known-Answer packets could, theoretically, prevent a responder from answering indefinitely. In practice, answers are never actually delayed significantly, and should a situation arise where significant delays did happen, that would be a scenario where the network is so overloaded that it would be desirable to err on the side of caution. The consequence of delaying an answer may be that it takes a user longer than usual to discover all the services on the local network; in contrast, the consequence of incorrectly answering before all the Known-Answer packets have been received would be wasted capacity sending unnecessary answers on an already overloaded network. In this (rare) situation, sacrificing speed to preserve reliable network operation is the right trade-off.
レスポンダがTCビットが設定された追加の既知の応答パケットを受信する場合、応答を送信する前に、最後のそのようなパケットの後の400〜500 msの休止を確実にするために、必要に応じて遅延を拡張する必要があります。これにより、Known-Answerパケットの連続ストリームが、理論的にはレスポンダが無期限に応答するのを妨げる可能性のある潜在的なリスクが開かれます。実際には、回答が実際に大幅に遅延することは決してありません。また、大幅な遅延が発生した状況が発生した場合、ネットワークが過負荷になり、注意を怠るのが望ましいシナリオになります。回答が遅れると、ローカルネットワーク上のすべてのサービスを検出するのに通常よりも時間がかかる場合があります。対照的に、すべてのKnown-Answerパケットが受信される前に誤って応答すると、すでに過負荷のネットワーク上で不要な応答を送信する能力が無駄になります。この（まれな）状況では、信頼できるネットワーク操作を維持するために速度を犠牲にすることは適切なトレードオフです。
If a host is planning to transmit (or retransmit) a query, and it sees another host on the network send a query containing the same "QM" question, and the Known-Answer Section of that query does not contain any records that this host would not also put in its own Known-Answer Section, then this host SHOULD treat its own query as having been sent. When multiple queriers on the network are querying for the same resource records, there is no need for them to all be repeatedly asking the same question.
ホストがクエリを送信（または再送信）する予定で、ネットワーク上の別のホストが同じ "QM"質問を含むクエリを送信していることを確認し、そのクエリの既知の回答セクションにこのホストのレコードが含まれていない場合独自のKnown-Answerセクションも配置しない場合、このホストは独自のクエリを送信済みとして扱う必要があります（SHOULD）。ネットワーク上の複数のクエリアが同じリソースレコードをクエリしている場合、それらすべてが繰り返し同じ質問をする必要はありません。
If a host is planning to send an answer, and it sees another host on the network send a response message containing the same answer record, and the TTL in that record is not less than the TTL this host would have given, then this host SHOULD treat its own answer as having been sent, and not also send an identical answer itself. When multiple responders on the network have the same data, there is no need for all of them to respond.
ホストが回答を送信する予定であり、ネットワーク上の別のホストが同じ回答レコードを含む応答メッセージを送信していることを確認し、そのレコードのTTLがこのホストが提供するTTL未満でない場合、このホストはSHOULD自身の回答を送信済みとして扱い、同一の回答自体は送信しない。ネットワーク上の複数のレスポンダが同じデータを持っている場合、それらすべてが応答する必要はありません。
The opportunity for duplicate answer suppression occurs when a host has received a query, and is delaying its response for some pseudo-random interval up to 500 ms, as described elsewhere in this document, and then, before the host sends its response, it sees some other host on the network send a response message containing the same answer record.
重複した応答抑制の機会は、ホストがクエリを受信し、このドキュメントの別の場所で説明されているように、擬似ランダムな間隔で最大500ミリ秒応答を遅らせた後、ホストが応答を送信する前に、ネットワーク上の他のホストが、同じアンサーレコードを含む応答メッセージを送信します。
This feature is particularly useful when Multicast DNS Proxy Servers are in use, where there could be more than one proxy on the network giving Multicast DNS answers on behalf of some other host (e.g., because that other host is currently asleep and is not itself responding to queries).
この機能は、マルチキャストDNSプロキシサーバーが使用されている場合に特に役立ちます。ネットワーク上に複数のプロキシが存在し、他のホストに代わってマルチキャストDNS応答を提供する場合があります（たとえば、他のホストが現在スリープしていて、それ自体が応答していない場合など）。クエリに）。
Typically a Multicast DNS responder should have, at the very least, address records for all of its active interfaces. Creating and advertising an HINFO record on each interface as well can be useful to network administrators.
通常、マルチキャストDNSレスポンダには、少なくとも、すべてのアクティブなインターフェースのアドレスレコードが必要です。各インターフェイスでHINFOレコードを作成および通知することも、ネットワーク管理者にとって役立ちます。
Whenever a Multicast DNS responder starts up, wakes up from sleep, receives an indication of a network interface "Link Change" event, or has any other reason to believe that its network connectivity may have changed in some relevant way, it MUST perform the two startup steps below: Probing (Section 8.1) and Announcing (Section 8.3).
マルチキャストDNSレスポンダが起動したり、スリープから復帰したり、ネットワークインターフェースの「リンク変更」イベントの通知を受け取ったり、ネットワーク接続が何らかの関連する方法で変更された可能性があると信じる理由がある場合は常に、2つを実行する必要があります。以下の起動手順：プロービング（セクション8.1）およびアナウンス（セクション8.3）。
The first startup step is that, for all those resource records that a Multicast DNS responder desires to be unique on the local link, it MUST send a Multicast DNS query asking for those resource records, to see if any of them are already in use. The primary example of this is a host's address records, which map its unique host name to its unique IPv4 and/or IPv6 addresses. All probe queries SHOULD be done using the desired resource record name and class (usually class 1, "Internet"), and query type "ANY" (255), to elicit answers for all types of records with that name. This allows a single question to be used in place of several questions, which is more efficient on the network. It also allows a host to verify exclusive ownership of a name for all rrtypes, which is desirable in most cases. It would be confusing, for example, if one host owned the "A" record for "myhost.local.", but a different host owned the "AAAA" record for that name.
最初の起動手順は、マルチキャストDNSレスポンダがローカルリンク上で一意であることを望むすべてのリソースレコードについて、それらが既に使用されているかどうかを確認するために、それらのリソースレコードを要求するマルチキャストDNSクエリを送信する必要があります。この主な例は、ホストのアドレスレコードです。これは、一意のホスト名を一意のIPv4またはIPv6アドレスにマップします。すべてのプローブクエリは、目的のリソースレコード名とクラス（通常はクラス1、 "インターネット"）、およびクエリタイプ "ANY"（255）を使用して実行し、その名前のすべてのタイプのレコードの回答を引き出します。これにより、単一の質問を複数の質問の代わりに使用できるようになり、ネットワーク上でより効率的になります。また、ホストがすべてのrrtypeの名前の排他的所有権を検証できるようにします。これはほとんどの場合に望ましいことです。たとえば、あるホストが「myhost.local。」の「A」レコードを所有していて、別のホストがその名前の「AAAA」レコードを所有していた場合、混乱を招きます。
The ability to place more than one question in a Multicast DNS query is useful here, because it can allow a host to use a single message to probe for all of its resource records instead of needing a separate message for each. For example, a host can simultaneously probe for uniqueness of its "A" record and all its SRV records [RFC6763] in the same query message.
マルチキャストDNSクエリに複数の質問を配置する機能は、ホストが単一のメッセージを使用して、それぞれに個別のメッセージを必要とせずにすべてのリソースレコードをプローブできるため、ここで役立ちます。たとえば、ホストは、同じクエリメッセージ内の「A」レコードとそのすべてのSRVレコード[RFC6763]の一意性を同時にプローブできます。
When ready to send its Multicast DNS probe packet(s) the host should first wait for a short random delay time, uniformly distributed in the range 0-250 ms. This random delay is to guard against the case where several devices are powered on simultaneously, or several devices are connected to an Ethernet hub, which is then powered on, or some other external event happens that might cause a group of hosts to all send synchronized probes.
マルチキャストDNSプローブパケットを送信する準備ができたら、ホストは最初にランダムな短い遅延時間（0〜250 msの範囲で均一に分散される）を待つ必要があります。このランダムな遅延は、複数のデバイスの電源が同時にオンになった場合、または複数のデバイスがイーサネットハブに接続されてから電源がオンになった場合、またはホストのグループがすべて同期して送信する可能性がある他の外部イベントが発生した場合を防ぐためのものですプローブ。
250 ms after the first query, the host should send a second; then, 250 ms after that, a third. If, by 250 ms after the third probe, no conflicting Multicast DNS responses have been received, the host may move to the next step, announcing. (Note that probing is the one exception from the normal rule that there should be at least one second between repetitions of the same question, and the interval between subsequent repetitions should at least double.)
最初のクエリから250ミリ秒後、ホストは2番目のクエリを送信する必要があります。その後、250ミリ秒後、3分の1。 3番目のプローブから250 msまでに、競合するマルチキャストDNS応答が受信されなかった場合、ホストは次のステップに進み、通知する場合があります。 （プロービングは、同じ質問の繰り返しの間に少なくとも1秒は必要であり、後続の繰り返しの間隔は少なくとも2倍でなければならないという通常のルールからの1つの例外であることに注意してください。）
When sending probe queries, a host MUST NOT consult its cache for potential answers. Only conflicting Multicast DNS responses received "live" from the network are considered valid for the purposes of determining whether probing has succeeded or failed.
プローブクエリを送信するとき、ホストは潜在的な回答についてそのキャッシュを参照してはなりません（MUST NOT）。ネットワークから「ライブ」で受信された競合するマルチキャストDNS応答のみが、プローブが成功したか失敗したかを判断する目的で有効と見なされます。
In order to allow services to announce their presence without unreasonable delay, the time window for probing is intentionally set quite short. As a result of this, from the time the first probe packet is sent, another device on the network using that name has just 750 ms to respond to defend its name. On networks that are slow, or busy, or both, it is possible for round-trip latency to account for a few hundred milliseconds, and software delays in slow devices can add additional delay. Hence, it is important that when a device receives a probe query for a name that it is currently using, it SHOULD generate its response to defend that name immediately and send it as quickly as possible. The usual rules about random delays before responding, to avoid sudden bursts of simultaneous answers from different hosts, do not apply here since normally at most one host should ever respond to a given probe question. Even when a single DNS query message contains multiple probe questions, it would be unusual for that message to elicit a defensive response from more than one other host. Because of the mDNS multicast rate-limiting rules, the probes SHOULD be sent as "QU" questions with the unicast-response bit set, to allow a defending host to respond immediately via unicast, instead of potentially having to wait before replying via multicast.
サービスが不当な遅延なしにその存在を通知できるようにするために、プロービングの時間枠は意図的に非常に短く設定されています。この結果、最初のプローブパケットが送信されてから、その名前を使用しているネットワーク上の別のデバイスは、その名前を守るために応答するのにわずか750ミリ秒しかかかりません。低速またはビジー、あるいはその両方のネットワークでは、往復待ち時間が数百ミリ秒を占める可能性があり、低速デバイスでのソフトウェア遅延により、遅延がさらに追加される可能性があります。したがって、デバイスが現在使用している名前のプローブクエリを受信した場合、その名前を即座に保護し、できるだけ迅速に送信するための応答を生成する必要があります。応答前のランダムな遅延に関する通常のルールは、異なるホストからの同時応答の突然のバーストを回避するために、ここでは適用されません。通常、最大で1つのホストが特定のプローブの質問に応答する必要があるためです。 1つのDNSクエリメッセージに複数のプローブの質問が含まれている場合でも、そのメッセージが他の複数のホストから防御的な応答を引き出すことはまれです。 mDNSマルチキャストのレート制限ルールにより、ユニキャスト応答ビットが設定された「QU」質問としてプローブを送信して、マルチキャスト経由で応答する前に待機する必要がなく、ユニキャスト経由で即座に応答できるようにする必要があります（SHOULD）。
During probing, from the time the first probe packet is sent until 250 ms after the third probe, if any conflicting Multicast DNS response is received, then the probing host MUST defer to the existing host, and SHOULD choose new names for some or all of its resource records as appropriate. Apparently conflicting Multicast DNS responses received *before* the first probe packet is sent MUST be silently ignored (see discussion of stale probe packets in Section 8.2, "Simultaneous Probe Tiebreaking", below). In the case of a host probing using query type "ANY" as recommended above, any answer containing a record with that name, of any type, MUST be considered a conflicting response and handled accordingly.
プローブ中、最初のプローブパケットが送信されたときから3番目のプローブの250ミリ秒後まで、競合するマルチキャストDNS応答が受信された場合、プローブホストは既存のホストに従う必要があり、一部またはすべての新しい名前を選択する必要があります（SHOULD）必要に応じて、そのリソースレコード。最初のプローブパケットが送信される前に受信したマルチキャストDNS応答が明らかに競合しているようですが、黙って無視する必要があります（以下の8.2節「同時プローブタイブレーク」の古いプローブパケットの説明を参照）。上記で推奨されているクエリタイプ「ANY」を使用したホストプローブの場合、その名前のレコードを含むすべての回答は、あらゆるタイプの競合する応答と見なされ、それに応じて処理される必要があります。
If fifteen conflicts occur within any ten-second period, then the host MUST wait at least five seconds before each successive additional probe attempt. This is to help ensure that, in the event of software bugs or other unanticipated problems, errant hosts do not flood the network with a continuous stream of multicast traffic. For very simple devices, a valid way to comply with this requirement is to always wait five seconds after any failed probe attempt before trying again.
10秒以内に15件の競合が発生した場合、ホストは追加のプローブ試行が続く前に少なくとも5秒待機する必要があります。これは、ソフトウェアのバグやその他の予期しない問題が発生した場合に、誤ったホストがマルチキャストトラフィックの連続的なストリームでネットワークをフラッディングしないようにするためです。非常に単純なデバイスの場合、この要件に準拠する有効な方法は、プローブ試行が失敗した後常に5秒待ってから再試行することです。
If a responder knows by other means that its unique resource record set name, rrtype, and rrclass cannot already be in use by any other responder on the network, then it SHOULD skip the probing step for that resource record set. For example, when creating the reverse address mapping PTR records, the host can reasonably assume that no other host will be trying to create those same PTR records, since that would imply that the two hosts were trying to use the same IP address, and if that were the case, the two hosts would be suffering communication problems beyond the scope of what Multicast DNS is designed to solve. Similarly, if a responder is acting as a proxy, taking over from another Multicast DNS responder that has already verified the uniqueness of the record, then the proxy SHOULD NOT repeat the probing step for those records.
レスポンダが他の方法で、その一意のリソースレコードセット名、rrtype、およびrrclassがネットワーク上の他のレスポンダによってすでに使用されていないことを知っている場合、そのリソースレコードセットのプローブ手順をスキップする必要があります。たとえば、リバースアドレスマッピングPTRレコードを作成する場合、ホストは、他のホストが同じPTRレコードを作成しようとはしないと合理的に想定できます。これは、2つのホストが同じIPアドレスを使用しようとしていることを意味します。その場合、2つのホストは、マルチキャストDNSが解決するように設計されている範囲を超えて通信の問題に苦しむことになります。同様に、レスポンダがプロキシとして機能していて、レコードの一意性がすでに確認されている別のマルチキャストDNSレスポンダから引き継いでいる場合、プロキシはそれらのレコードのプローブ手順を繰り返さないでください（SHOULD NOT）。
The astute reader will observe that there is a race condition inherent in the previous description. If two hosts are probing for the same name simultaneously, neither will receive any response to the probe, and the hosts could incorrectly conclude that they may both proceed to use the name. To break this symmetry, each host populates the query message's Authority Section with the record or records with the rdata that it would be proposing to use, should its probing be successful. The Authority Section is being used here in a way analogous to the way it is used as the "Update Section" in a DNS Update message [RFC2136] [RFC3007].
鋭い読者は、前の説明に固有の競合状態があることに気づくでしょう。 2つのホストが同じ名前を同時にプローブしている場合、どちらもプローブに対する応答を受信せず、ホストは両方が名前の使用を続行する可能性があると誤って結論付ける可能性があります。この対称性を破るために、各ホストは、そのプローブが成功した場合に、使用を提案するrdataを含むレコードをクエリメッセージのAuthorityセクションに入力します。権限セクションは、DNS更新メッセージ[RFC2136] [RFC3007]の「更新セクション」として使用されているのと同様の方法で、ここで使用されています。
When a host is probing for a group of related records with the same name (e.g., the SRV and TXT record describing a DNS-SD service), only a single question need be placed in the Question Section, since query type "ANY" (255) is used, which will elicit answers for all records with that name. However, for tiebreaking to work correctly in all cases, the Authority Section must contain *all* the records and proposed rdata being probed for uniqueness.
ホストが同じ名前の関連レコードのグループ（たとえば、DNS-SDサービスを説明するSRVおよびTXTレコード）をプローブしている場合、クエリタイプ "ANY"（ 255）が使用され、その名前のすべてのレコードの回答が引き出されます。ただし、タイブレーキングがすべての場合に正しく機能するためには、権限セクションに*すべての*レコードと、一意性をプローブする提案されたrdataが含まれている必要があります。
When a host that is probing for a record sees another host issue a query for the same record, it consults the Authority Section of that query. If it finds any resource record(s) there which answers the query, then it compares the data of that (those) resource record(s) with its own tentative data. We consider first the simple case of a host probing for a single record, receiving a simultaneous probe from another host also probing for a single record. The two records are compared and the lexicographically later data wins. This means that if the host finds that its own data is lexicographically later, it simply ignores the other host's probe. If the host finds that its own data is lexicographically earlier, then it defers to the winning host by waiting one second, and then begins probing for this record again. The logic for waiting one second and then trying again is to guard against stale probe packets on the network (possibly even stale probe packets sent moments ago by this host itself, before some configuration change, which may be echoed back after a short delay by some Ethernet switches and some 802.11 base stations). If the winning simultaneous probe was from a real other host on the network, then after one second it will have completed its probing, and will answer subsequent probes. If the apparently winning simultaneous probe was in fact just an old stale packet on the network (maybe from the host itself), then when it retries its probing in one second, its probes will go unanswered, and it will successfully claim the name.
レコードをプローブしているホストは、別のホストが同じレコードに対するクエリを発行しているのを見ると、そのクエリの機関セクションを調べます。クエリに応答するリソースレコードが見つかった場合は、その（これらの）リソースレコードのデータを独自の仮データと比較します。まず、ホストが単一のレコードをプローブするという単純なケースを考えます。別のホストから同時プローブを受信し、単一のレコードもプローブする場合を考えます。 2つのレコードが比較され、辞書式順序で後のデータが優先されます。これは、ホストが自身のデータが辞書式に後であることがわかった場合、他のホストのプローブを単に無視することを意味します。ホストが自身のデータが辞書式順序で早いことを検出した場合、ホストは1秒待機して勝者のホストに延期し、その後、このレコードのプローブを再開します。 1秒待ってから再試行するロジックは、ネットワーク上の古いプローブパケット（このホスト自体によって少し前に送信された古いプローブパケットでさえ、構成変更の前に、場合によってはいくつかの短い遅延の後にエコーバックされる可能性があります）から保護することです。イーサネットスイッチと一部の802.11ベースステーション）。優勝した同時プローブがネットワーク上の他の実際のホストからのものだった場合、1秒後にプローブが完了し、後続のプローブに応答します。明らかに成功した同時プローブが、実際にはネットワーク上の古いホストパケットである場合（ホスト自体からのものである可能性があります）、1秒後にプローブを再試行すると、プローブは応答せず、名前を正常に要求します。
The determination of "lexicographically later" is performed by first comparing the record class (excluding the cache-flush bit described in Section 10.2), then the record type, then raw comparison of the binary content of the rdata without regard for meaning or structure. If the record classes differ, then the numerically greater class is considered "lexicographically later". Otherwise, if the record types differ, then the numerically greater type is considered "lexicographically later". If the rrtype and rrclass both match, then the rdata is compared.
「辞書順で後で」の決定は、最初にレコードクラス（セクション10.2で説明したキャッシュフラッシュビットを除く）を比較し、次にレコードタイプを比較してから、意味や構造に関係なくrdataのバイナリコンテンツをそのまま比較します。レコードクラスが異なる場合、数値的に大きいクラスは「辞書式に後で」考えられます。それ以外の場合、レコードタイプが異なると、数値的に大きいタイプが「辞書式に後で」考えられます。 rrtypeとrrclassの両方が一致する場合、rdataが比較されます。
In the case of resource records containing rdata that is subject to name compression [RFC1035], the names MUST be uncompressed before comparison. (The details of how a particular name is compressed is an artifact of how and where the record is written into the DNS message; it is not an intrinsic property of the resource record itself.)
名前の圧縮[RFC1035]の対象となるrdataを含むリソースレコードの場合、比較の前に名前を解凍する必要があります。 （特定の名前がどのように圧縮されるかの詳細は、レコードがDNSメッセージに書き込まれる方法と場所の成果物です。これは、リソースレコード自体の固有のプロパティではありません。）
The bytes of the raw uncompressed rdata are compared in turn, interpreting the bytes as eight-bit UNSIGNED values, until a byte is found whose value is greater than that of its counterpart (in which case, the rdata whose byte has the greater value is deemed lexicographically later) or one of the resource records runs out of rdata (in which case, the resource record which still has remaining data first is deemed lexicographically later). The following is an example of a conflict:
生の非圧縮rdataのバイトが順番に比較され、バイトが8ビットのUNSIGNED値として解釈され、対応する値より大きい値のバイトが見つかるまで（この場合、バイトのより大きい値を持つrdataは、辞書順で後であると見なされた場合）またはリソースレコードの1つがrdataを使い果たした場合（その場合、まだデータが残っているリソースレコードが辞書順で後であると見なされます）。以下は競合の例です。
MyPrinter.local. A 169.254.99.200 MyPrinter.local. A 169.254.200.50
MyPrinter.local。 169.254.99.200 MyPrinter.local。 A 169.254.200.50
In this case, 169.254.200.50 is lexicographically later (the third byte, with value 200, is greater than its counterpart with value 99), so it is deemed the winner.
この場合、169.254.200.50は辞書編集的に遅い（値200の3番目のバイトは値99の対応するバイトよりも大きい）ので、勝者と見なされます。
Note that it is vital that the bytes are interpreted as UNSIGNED values in the range 0-255, or the wrong outcome may result. In the example above, if the byte with value 200 had been incorrectly interpreted as a signed eight-bit value, then it would be interpreted as value -56, and the wrong address record would be deemed the winner.
バイトが0〜255の範囲のUNSIGNED値として解釈されることが重要であることに注意してください。そうしないと、誤った結果が生じる可能性があります。上記の例では、値200のバイトが符号付き8ビット値として誤って解釈された場合、値-56として解釈され、間違ったアドレスレコードが勝者と見なされます。
When a host is probing for a set of records with the same name, or a message is received containing multiple tiebreaker records answering a given probe question in the Question Section, the host's records and the tiebreaker records from the message are each sorted into order, and then compared pairwise, using the same comparison technique described above, until a difference is found.
ホストが同じ名前の一連のレコードをプローブしている場合、または質問セクションの特定のプローブの質問に回答する複数のタイブレーカーレコードを含むメッセージが受信されると、ホストのレコードとメッセージのタイブレーカーレコードがそれぞれ順番にソートされます。次に、違いが見つかるまで、上記と同じ比較手法を使用してペアで比較します。
The records are sorted using the same lexicographical order as described above, that is, if the record classes differ, the record with the lower class number comes first. If the classes are the same but the rrtypes differ, the record with the lower rrtype number comes first. If the class and rrtype match, then the rdata is compared bytewise until a difference is found. For example, in the common case of advertising DNS-SD services with a TXT record and an SRV record, the TXT record comes first (the rrtype value for TXT is 16) and the SRV record comes second (the rrtype value for SRV is 33).
レコードは、上記と同じ辞書式順序を使用してソートされます。つまり、レコードクラスが異なる場合は、クラス番号が小さいレコードが最初に来ます。クラスは同じでもrrtypeが異なる場合は、rrtype番号が小さいレコードが最初に来ます。クラスとrrtypeが一致する場合、違いが見つかるまでrdataがバイトごとに比較されます。たとえば、TXTレコードとSRVレコードでDNS-SDサービスをアドバタイズする一般的なケースでは、TXTレコードが最初に来て（TXTのrrtype値は16）、SRVレコードが2番目に来ます（SRVのrrtype値は33） ）。
When comparing the records, if the first records match perfectly, then the second records are compared, and so on. If either list of records runs out of records before any difference is found, then the list with records remaining is deemed to have won the tiebreak. If both lists run out of records at the same time without any difference being found, then this indicates that two devices are advertising identical sets of records, as is sometimes done for fault tolerance, and there is, in fact, no conflict.
レコードを比較するときに、最初のレコードが完全に一致する場合は、2番目のレコードが比較されます。差異が見つかる前にいずれかのレコードのリストがレコードを使い果たした場合、残りのレコードを含むリストはタイブレークに勝ったと見なされます。両方のリストで違いが見つからずに同時にレコードが不足した場合、これは、フォールトトレランスのために時々行われるように、2つのデバイスが同じレコードのセットをアドバタイズし、実際には競合がないことを示します。
The second startup step is that the Multicast DNS responder MUST send an unsolicited Multicast DNS response containing, in the Answer Section, all of its newly registered resource records (both shared records, and unique records that have completed the probing step). If there are too many resource records to fit in a single packet, multiple packets should be used.
2番目の起動手順は、マルチキャストDNSレスポンダが、新しく登録されたすべてのリソースレコード（共有レコードと調査手順を完了した一意のレコードの両方）を回答セクションに含む未承諾マルチキャストDNS応答を送信する必要があることです。リソースレコードが多すぎて1つのパケットに収まらない場合は、複数のパケットを使用する必要があります。
In the case of shared records (e.g., the PTR records used by DNS-Based Service Discovery [RFC6763]), the records are simply placed as is into the Answer Section of the DNS response.
共有レコード（DNSベースのサービスディスカバリ[RFC6763]で使用されるPTRレコードなど）の場合、レコードはそのままDNS応答の回答セクションに配置されます。
In the case of records that have been verified to be unique in the previous step, they are placed into the Answer Section of the DNS response with the most significant bit of the rrclass set to one. The most significant bit of the rrclass for a record in the Answer Section of a response message is the Multicast DNS cache-flush bit and is discussed in more detail below in Section 10.2, "Announcements to Flush Outdated Cache Entries".
前のステップで一意であることが確認されたレコードの場合、それらはrrclassの最上位ビットが1に設定されたDNS応答の回答セクションに配置されます。応答メッセージのAnswerセクションにあるレコードのrrclassの最も重要なビットは、マルチキャストDNSキャッシュフラッシュビットであり、10.2項「古いキャッシュエントリをフラッシュするためのアナウンス」で詳しく説明されています。
The Multicast DNS responder MUST send at least two unsolicited responses, one second apart. To provide increased robustness against packet loss, a responder MAY send up to eight unsolicited responses, provided that the interval between unsolicited responses increases by at least a factor of two with every response sent.
マルチキャストDNSレスポンダは、少なくとも2つの非送信請求応答を1秒間隔で送信する必要があります。パケット損失に対するロバスト性を高めるために、レスポンダは最大8つの非請求応答を送信できます（ただし、非送信応答の間隔が送信されるすべての応答で少なくとも2倍になる場合）。
A Multicast DNS responder MUST NOT send announcements in the absence of information that its network connectivity may have changed in some relevant way. In particular, a Multicast DNS responder MUST NOT send regular periodic announcements as a matter of course.
マルチキャストDNSレスポンダは、ネットワーク接続が関連する方法で変更された可能性があるという情報がない場合、アナウンスを送信してはなりません（MUST NOT）。特に、マルチキャストDNSレスポンダは、当然のことながら定期的に定期的なアナウンスを送信してはなりません。
Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record, the conflict MUST be resolved as described in Section 9, "Conflict Resolution".
マルチキャストDNSレスポンダが、競合するリソースレコードを含むマルチキャストDNS応答（要請されているかどうかにかかわらず）を受信する場合は常に、セクション9「競合解決」で説明されているように競合を解決する必要があります。
At any time, if the rdata of any of a host's Multicast DNS records changes, the host MUST repeat the Announcing step described above to update neighboring caches. For example, if any of a host's IP addresses change, it MUST re-announce those address records. The host does not need to repeat the Probing step because it has already established unique ownership of that name.
いつでも、ホストのマルチキャストDNSレコードのいずれかのrdataが変更された場合、ホストは上記のアナウンス手順を繰り返して、隣接するキャッシュを更新する必要があります。たとえば、ホストのIPアドレスのいずれかが変更された場合、それらのアドレスレコードを再通知する必要があります。ホストは、その名前の一意の所有権をすでに確立しているため、プローブ手順を繰り返す必要はありません。
In the case of shared records, a host MUST send a "goodbye" announcement with RR TTL zero (see Section 10.1, "Goodbye Packets") for the old rdata, to cause it to be deleted from peer caches, before announcing the new rdata. In the case of unique records, a host SHOULD omit the "goodbye" announcement, since the cache-flush bit on the newly announced records will cause old rdata to be flushed from peer caches anyway.
共有レコードの場合、ホストは新しいrdataをアナウンスする前に、古いrdataに対してRR TTLゼロ（10.1節「Goodbyeパケット」を参照）の「さようなら」アナウンスを送信して、ピアキャッシュから削除する必要があります。 。一意のレコードの場合、ホストは「さようなら」のアナウンスを省略する必要があります。これは、新しくアナウンスされたレコードのキャッシュフラッシュビットにより、古いrdataがピアキャッシュからフラッシュされるためです。
A host may update the contents of any of its records at any time, though a host SHOULD NOT update records more frequently than ten times per minute. Frequent rapid updates impose a burden on the network. If a host has information to disseminate which changes more frequently than ten times per minute, then it may be more appropriate to design a protocol for that specific purpose.
ホストは1分間に10回を超える頻度でレコードを更新するべきではありませんが、ホストはいつでもそのレコードの内容を更新できます。頻繁な迅速な更新はネットワークに負担をかけます。ホストが1分あたり10回よりも頻繁に変更を配布する情報を持っている場合は、その特定の目的のためのプロトコルを設計する方が適切な場合があります。
A conflict occurs when a Multicast DNS responder has a unique record for which it is currently authoritative, and it receives a Multicast DNS response message containing a record with the same name, rrtype and rrclass, but inconsistent rdata. What may be considered inconsistent is context sensitive, except that resource records with identical rdata are never considered inconsistent, even if they originate from different hosts. This is to permit use of proxies and other fault-tolerance mechanisms that may cause more than one responder to be capable of issuing identical answers on the network.
マルチキャストDNSレスポンダに現在権限のある一意のレコードがあり、同じ名前、rrtypeおよびrrclassのレコードを含むが、rdataが一貫していないマルチキャストDNS応答メッセージを受信すると、競合が発生します。一貫性がないと見なされる可能性があるのは、状況に依存します。ただし、同一のrdataを持つリソースレコードは、異なるホストからのものであっても、一貫性がないと見なされることはありません。これは、複数のレスポンダがネットワーク上で同一の回答を発行できるようにするプロキシやその他のフォールトトレランスメカニズムの使用を許可するためです。
A common example of a resource record type that is intended to be unique, not shared between hosts, is the address record that maps a host's name to its IP address. Should a host witness another host announce an address record with the same name but a different IP address, then that is considered inconsistent, and that address record is considered to be in conflict.
ホスト間で共有されない、一意であることが意図されているリソースレコードタイプの一般的な例は、ホストの名前をIPアドレスにマップするアドレスレコードです。ホストが別のホストに同じ名前でIPアドレスが異なるアドレスレコードをアナウンスした場合、それは不整合と見なされ、そのアドレスレコードは競合していると見なされます。
Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record in any of the Resource Record Sections, the Multicast DNS responder MUST immediately reset its conflicted unique record to probing state, and go through the startup steps described above in
マルチキャストDNSレスポンダが、リソースレコードセクションのいずれかに競合するリソースレコードを含むマルチキャストDNS応答（要請またはその他）を受信すると、マルチキャストDNSレスポンダは、競合する一意のレコードをただちにリセットしてプローブ状態にし、前述の起動手順を実行する必要があります。上記の
Section 8, "Probing and Announcing on Startup". The protocol used in the Probing phase will determine a winner and a loser, and the loser MUST cease using the name, and reconfigure.
セクション8、「起動時のプローブとアナウンス」。プロービングフェーズで使用されるプロトコルは勝者と敗者を決定し、敗者は名前の使用を中止し、再設定する必要があります。
It is very important that any host receiving a resource record that conflicts with one of its own MUST take action as described above. In the case of two hosts using the same host name, where one has been configured to require a unique host name and the other has not, the one that has not been configured to require a unique host name will not perceive any conflict, and will not take any action. By reverting to Probing state, the host that desires a unique host name will go through the necessary steps to ensure that a unique host name is obtained.
自身のいずれかと競合するリソースレコードを受信するホストは、上記のアクションを実行する必要があることが非常に重要です。同じホスト名を使用する2つのホストの場合、一方が一意のホスト名を要求するように構成され、もう一方がそうではない場合、一意のホスト名を要求するように構成されていないホストは競合を認識せず、何もしません。プロービング状態に戻すことにより、一意のホスト名が必要なホストは、一意のホスト名が取得されるようにするために必要な手順を実行します。
The recommended course of action after probing and failing is as follows:
プロービングおよび失敗後の推奨されるアクションコースは次のとおりです。
1. Programmatically change the resource record name in an attempt to find a new name that is unique. This could be done by adding some further identifying information (e.g., the model name of the hardware) if it is not already present in the name, or appending the digit "2" to the name, or incrementing a number at the end of the name if one is already present.
1. 一意の新しい名前を見つけようとして、プログラムでリソースレコード名を変更します。これは、名前にまだ存在しない場合、さらに識別情報（ハードウェアのモデル名など）を追加するか、名前に数字の「2」を追加するか、または末尾の数字を増やすことで実行できます。すでに存在する場合は名前。
2. Probe again, and repeat as necessary until a unique name is found.
2. 再度プローブし、一意の名前が見つかるまで必要に応じて繰り返します。
3. Once an available unique name has been determined, by probing without receiving any conflicting response, record this newly chosen name in persistent storage so that the device will use the same name the next time it is power-cycled.
3. 使用可能な一意の名前が決定したら、競合する応答を受信せずに調査することにより、この新しく選択した名前を永続ストレージに記録して、次回電源を入れ直したときにデバイスが同じ名前を使用するようにします。
4. Display a message to the user or operator informing them of the name change. For example:
4. 名前の変更を通知するメッセージをユーザーまたはオペレーターに表示します。例えば：
The name "Bob's Music" is in use by another music server on the network. Your music collection has been renamed to "Bob's Music (2)". If you want to change this name, use [describe appropriate menu item or preference dialog here].
「ボブの音楽」という名前は、ネットワーク上の別の音楽サーバーで使用されています。音楽コレクションの名前が「Bob's Music（2）」に変更されました。この名前を変更する場合は、[適切なメニュー項目または設定ダイアログをここに記述してください]を使用します。
The details of how the user or operator is informed of the new name depends on context. A desktop computer with a screen might put up a dialog box. A headless server in the closet may write a message to a log file, or use whatever mechanism (email, SNMP trap, etc.) it uses to inform the administrator of error conditions. On the other hand, a headless server in the closet may not inform the user at all -- if the user cares, they will notice the name has changed, and connect to the server in the usual way (e.g., via web browser) to configure a new name.
ユーザーまたはオペレーターに新しい名前を通知する方法の詳細は、コンテキストによって異なります。画面を備えたデスクトップコンピュータでは、ダイアログボックスが表示される場合があります。クローゼット内のヘッドレスサーバーは、ログファイルにメッセージを書き込むか、管理者にエラー状態を通知するために使用するメカニズム（電子メール、SNMPトラップなど）を使用します。一方、クローゼット内のヘッドレスサーバーはユーザーにまったく通知しない可能性があります。ユーザーが気にすると、名前が変更されたことに気付き、通常の方法（Webブラウザーなど）でサーバーに接続します。新しい名前を設定します。
5. After one minute of probing, if the Multicast DNS responder has been unable to find any unused name, it should log an error message to inform the user or operator of this fact. This situation should never occur in normal operation. The only situations that would cause this to happen would be either a deliberate denial-of-service attack, or some kind of very obscure hardware or software bug that acts like a deliberate denial-of-service attack.
5. 1分間プローブした後、マルチキャストDNSレスポンダが未使用の名前を見つけることができなかった場合、エラーメッセージをログに記録して、この事実をユーザーまたはオペレータに通知する必要があります。この状況は、通常の操作では発生しません。これを引き起こす唯一の状況は、故意のサービス拒否攻撃か、故意のサービス拒否攻撃のように振る舞うある種の非常にあいまいなハードウェアまたはソフトウェアのバグです。
These considerations apply to address records (i.e., host names) and to all resource records where uniqueness (or maintenance of some other defined constraint) is desired.
これらの考慮事項は、アドレスレコード（ホスト名など）、および一意性（または他の定義された制約の維持）が必要なすべてのリソースレコードに適用されます。
As a general rule, the recommended TTL value for Multicast DNS resource records with a host name as the resource record's name (e.g., A, AAAA, HINFO) or a host name contained within the resource record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120 seconds.
一般的な規則として、リソースレコードの名前としてホスト名を使用するマルチキャストDNSリソースレコードの推奨TTL値（A、AAAA、HINFOなど）またはリソースレコードのrdata内に含まれるホスト名（SRV、逆マッピングPTRなど）レコード）120秒にする必要があります。
The recommended TTL value for other Multicast DNS resource records is 75 minutes.
他のマルチキャストDNSリソースレコードの推奨TTL値は75分です。
A querier with an active outstanding query will issue a query message when one or more of the resource records in its cache are 80% of the way to expiry. If the TTL on those records is 75 minutes, this ongoing cache maintenance process yields a steady-state query rate of one query every 60 minutes.
アクティブな未解決のクエリを持つクエリアは、キャッシュ内の1つ以上のリソースレコードが有効期限切れの80％の時点でクエリメッセージを発行します。これらのレコードのTTLが75分である場合、この継続的なキャッシュメンテナンスプロセスにより、60分ごとに1つのクエリという定常状態のクエリレートが得られます。
Any distributed cache needs a cache coherency protocol. If Multicast DNS resource records follow the recommendation and have a TTL of 75 minutes, that means that stale data could persist in the system for a little over an hour. Making the default RR TTL significantly lower would reduce the lifetime of stale data, but would produce too much extra traffic on the network. Various techniques are available to minimize the impact of such stale data, outlined in the five subsections below.
分散キャッシュには、キャッシュコヒーレンシプロトコルが必要です。マルチキャストDNSリソースレコードが推奨に従い、TTLが75分の場合、古くなったデータがシステムに1時間強存続する可能性があります。デフォルトのRR TTLを大幅に低くすると、古くなったデータのライフタイムが短くなりますが、ネットワークで余計なトラフィックが発生しすぎます。このような古いデータの影響を最小限に抑えるために、以下の5つのサブセクションで概説するさまざまな手法を使用できます。
In the case where a host knows that certain resource record data is about to become invalid (for example, when the host is undergoing a clean shutdown), the host SHOULD send an unsolicited Multicast DNS response packet, giving the same resource record name, rrtype, rrclass, and rdata, but an RR TTL of zero. This has the effect of updating the TTL stored in neighboring hosts' cache entries to zero, causing that cache entry to be promptly deleted.
特定のリソースレコードデータが無効になることをホストが認識している場合（たとえば、ホストがクリーンシャットダウン中の場合）、ホストは非送信請求マルチキャストDNS応答パケットを送信して、同じリソースレコード名rrtypeを指定する必要があります（SHOULD）。 、rrclass、およびrdataですが、RR TTLはゼロです。これには、隣接するホストのキャッシュエントリに保存されているTTLをゼロに更新する効果があり、そのキャッシュエントリはすぐに削除されます。
Queriers receiving a Multicast DNS response with a TTL of zero SHOULD NOT immediately delete the record from the cache, but instead record a TTL of 1 and then delete the record one second later. In the case of multiple Multicast DNS responders on the network described in Section 6.6 above, if one of the responders shuts down and incorrectly sends goodbye packets for its records, it gives the other cooperating responders one second to send out their own response to "rescue" the records before they expire and are deleted.
TTLがゼロのマルチキャストDNS応答を受信するクエリアは、キャッシュからすぐにレコードを削除するのではなく（SHOULD NOT）、代わりに1のTTLを記録してから1秒後にレコードを削除します。上記のセクション6.6で説明したネットワーク上の複数のマルチキャストDNSレスポンダの場合、レスポンダの1つがシャットダウンし、そのレコードのサヨナラパケットを誤って送信すると、他の協調レスポンダに1秒ずつ応答して、「レスキュー」への応答を送信します"有効期限が切れて削除される前のレコード。
Whenever a host has a resource record with new data, or with what might potentially be new data (e.g., after rebooting, waking from sleep, connecting to a new network link, or changing IP address), the host needs to inform peers of that new data. In cases where the host has not been continuously connected and participating on the network link, it MUST first probe to re-verify uniqueness of its unique records, as described above in Section 8.1, "Probing".
ホストに新しいデータまたは新しいデータの可能性があるリソースレコードがある場合（たとえば、再起動、スリープからの復帰、新しいネットワークリンクへの接続、またはIPアドレスの変更後）は常に、ホストにピアにそのことを通知する必要があります。新しいデータ。 8.1節「プローブ」で説明したように、ホストが継続的に接続されておらず、ネットワークリンクに参加していない場合、最初にプローブしてその一意のレコードの一意性を再検証する必要があります。
Having completed the Probing step, if necessary, the host MUST then send a series of unsolicited announcements to update cache entries in its neighbor hosts. In these unsolicited announcements, if the record is one that has been verified unique, the host sets the most significant bit of the rrclass field of the resource record. This bit, the cache-flush bit, tells neighboring hosts that this is not a shared record type. Instead of merging this new record additively into the cache in addition to any previous records with the same name, rrtype, and rrclass, all old records with that name, rrtype, and rrclass that were received more than one second ago are declared invalid, and marked to expire from the cache in one second.
プロービングステップを完了した後、必要に応じて、ホストは一連の非請求アナウンスを送信して、隣接ホストのキャッシュエントリを更新する必要があります。これらの一方的なアナウンスでは、レコードが一意であることが確認されたものである場合、ホストはリソースレコードのrrclassフィールドの最上位ビットを設定します。このビット、キャッシュフラッシュビットは、これが共有レコードタイプではないことを隣接ホストに通知します。同じ名前、rrtype、およびrrclassの以前のレコードに加えて、この新しいレコードを追加でキャッシュにマージする代わりに、1秒以上前に受信されたその名前、rrtype、およびrrclassのすべての古いレコードは無効と宣言されます。キャッシュから1秒で期限切れになるようにマークされています。
The semantics of the cache-flush bit are as follows: normally when a resource record appears in a Resource Record Section of the DNS response it means, "This is an assertion that this information is true". When a resource record appears in a Resource Record Section of the DNS response with the cache-flush bit set, it means, "This is an assertion that this information is the truth and the whole truth, and anything you may have heard more than a second ago regarding records of this name/rrtype/rrclass is no longer true".
キャッシュフラッシュビットのセマンティクスは次のとおりです。通常、リソースレコードがDNS応答のリソースレコードセクションに表示される場合、「これはこの情報が真であることを表明しています」という意味です。キャッシュフラッシュビットが設定されたDNS応答のリソースレコードセクションにリソースレコードが表示される場合、これは「これは、この情報が真実であり、真実全体であるという主張であり、 2番目に前に、この名前/ rrtype / rrclassのレコードに関してはもはや真実ではありません。」
To accommodate the case where the set of records from one host constituting a single unique RRSet is too large to fit in a single packet, only cache records that are more than one second old are flushed. This allows the announcing host to generate a quick burst of packets back-to-back on the wire containing all the members of the RRSet. When receiving records with the cache-flush bit set, all records older than one second are marked to be deleted one second in the future. One second after the end of the little packet burst, any records not represented within that packet burst will then be expired from all peer caches.
1つの一意のRRSetを構成する1つのホストからのレコードのセットが大きすぎて1つのパケットに収まらない場合に対応するため、1秒以上経過したキャッシュレコードのみがフラッシュされます。これにより、アナウンスするホストは、RRSetのすべてのメンバーを含むワイヤ上で、パケットの高速バーストを連続して生成できます。キャッシュフラッシュビットが設定されたレコードを受信すると、1秒より古いすべてのレコードは、1秒後に削除されるようにマークされます。小さなパケットバーストが終了してから1秒後に、そのパケットバースト内に表されていないレコードはすべてのピアキャッシュから期限切れになります。
Any time a host sends a response packet containing some members of a unique RRSet, it MUST send the entire RRSet, preferably in a single packet, or if the entire RRSet will not fit in a single packet, in a quick burst of packets sent as close together as possible. The host MUST set the cache-flush bit on all members of the unique RRSet.
ホストは、一意のRRSetの一部のメンバーを含む応答パケットを送信するときは常に、RRSet全体を、できれば単一のパケットで送信する必要があります。または、RRSet全体が単一のパケットに収まらない場合は、できるだけ近づけてください。ホストは、一意のRRSetのすべてのメンバーにキャッシュフラッシュビットを設定する必要があります。
Another reason for waiting one second before deleting stale records from the cache is to accommodate bridged networks. For example, a host's address record announcement on a wireless interface may be bridged onto a wired Ethernet and may cause that same host's Ethernet address records to be flushed from peer caches. The one-second delay gives the host the chance to see its own announcement arrive on the wired Ethernet, and immediately re-announce its Ethernet interface's address records so that both sets remain valid and live in peer caches.
古いレコードをキャッシュから削除する前に1秒待機するもう1つの理由は、ブリッジネットワークに対応するためです。たとえば、ワイヤレスインターフェイス上のホストのアドレスレコードのアナウンスが有線イーサネットにブリッジされ、その同じホストのイーサネットアドレスレコードがピアキャッシュからフラッシュされる場合があります。 1秒の遅延により、ホストは自身のアナウンスが有線イーサネットに到着するのを確認し、イーサネットインターフェイスのアドレスレコードをすぐに再アナウンスして、両方のセットが有効でピアキャッシュに存在するようにすることができます。
These rules, about when to set the cache-flush bit and about sending the entire rrset, apply regardless of *why* the response message is being generated. They apply to startup announcements as described in Section 8.3, "Announcing", and to responses generated as a result of receiving query messages.
キャッシュフラッシュビットを設定するタイミングとrrset全体の送信に関するこれらのルールは、応答メッセージが生成される*理由*に関係なく適用されます。これらは、8.3項「アナウンス」で説明されている起動アナウンス、およびクエリメッセージの受信の結果として生成された応答に適用されます。
The cache-flush bit is only set in records in the Resource Record Sections of Multicast DNS responses sent to UDP port 5353.
cache-flushビットは、UDPポート5353に送信されるマルチキャストDNS応答のリソースレコードセクションのレコードでのみ設定されます。
The cache-flush bit MUST NOT be set in any resource records in a response message sent in legacy unicast responses to UDP ports other than 5353.
5353以外のUDPポートへのレガシーユニキャスト応答で送信された応答メッセージのリソースレコードで、キャッシュフラッシュビットを設定してはなりません（MUST NOT）。
The cache-flush bit MUST NOT be set in any resource records in the Known-Answer list of any query message.
キャッシュフラッシュビットは、クエリメッセージの既知の回答のリストにあるリソースレコードに設定しないでください。
The cache-flush bit MUST NOT ever be set in any shared resource record. To do so would cause all the other shared versions of this resource record with different rdata from different responders to be immediately deleted from all the caches on the network.
cache-flushビットは、共有リソースレコードで設定してはいけません。これを行うと、さまざまなレスポンダからのさまざまなrdataを持つこのリソースレコードの他のすべての共有バージョンが、ネットワーク上のすべてのキャッシュからすぐに削除されます。
The cache-flush bit does *not* apply to questions listed in the Question Section of a Multicast DNS message. The top bit of the rrclass field in questions is used for an entirely different purpose (see Section 5.4, "Questions Requesting Unicast Responses").
cache-flushビットは、マルチキャストDNSメッセージの質問セクションにリストされている質問には適用されません。質問のrrclassフィールドの最上位ビットは、まったく異なる目的で使用されます（5.4項「ユニキャスト応答を要求する質問」を参照）。
Note that the cache-flush bit is NOT part of the resource record class. The cache-flush bit is the most significant bit of the second 16-bit word of a resource record in a Resource Record Section of a Multicast DNS message (the field conventionally referred to as the rrclass field), and the actual resource record class is the least significant fifteen bits of this field. There is no Multicast DNS resource record class 0x8001. The value 0x8001 in the rrclass field of a resource record in a Multicast DNS response message indicates a resource record with class 1, with the cache-flush bit set. When receiving a resource record with the cache-flush bit set, implementations should take care to mask off that bit before storing the resource record in memory, or otherwise ensure that it is given the correct semantic interpretation.
cache-flushビットはリソースレコードクラスの一部ではないことに注意してください。キャッシュフラッシュビットは、マルチキャストDNSメッセージのリソースレコードセクションのリソースレコードの2番目の16ビットワードの最上位ビット（従来はrrclassフィールドと呼ばれていたフィールド）であり、実際のリソースレコードクラスはこのフィールドの最下位15ビット。マルチキャストDNSリソースレコードクラス0x8001はありません。マルチキャストDNS応答メッセージのリソースレコードのrrclassフィールドの値0x8001は、クラス1のリソースレコードを示し、キャッシュフラッシュビットが設定されています。キャッシュフラッシュビットが設定されたリソースレコードを受信する場合、実装では、リソースレコードをメモリに格納する前にそのビットをマスクするか、そうでない場合は正しいセマンティック解釈が確実に行われるようにする必要があります。
The reuse of the top bit of the rrclass field only applies to conventional resource record types that are subject to caching, not to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930], SIG0 [RFC2931], etc., that pertain only to a particular transport level message and not to any actual DNS data. Since pseudo-RRs should never go into the Multicast DNS cache, the concept of a cache-flush bit for these types is not applicable. In particular, the rrclass field of an OPT record encodes the sender's UDP payload size, and should be interpreted as a sixteen-bit length value in the range 0-65535, not a one-bit flag and a fifteen-bit length.
rrclassフィールドの最上位ビットの再利用は、キャッシュの対象となる従来のリソースレコードタイプにのみ適用され、OPT [RFC2671]、TSIG [RFC2845]、TKEY [RFC2930]、SIG0 [RFC2931]などの疑似RRには適用されません。、これは特定のトランスポートレベルメッセージにのみ関係し、実際のDNSデータには関係しません。疑似RRがマルチキャストDNSキャッシュに入らないようにする必要があるため、これらのタイプのキャッシュフラッシュビットの概念は適用されません。特に、OPTレコードのrrclassフィールドは送信者のUDPペイロードサイズをエンコードし、1ビットのフラグと15ビットの長さではなく、0〜65535の範囲の16ビットの長さの値として解釈されます。
If the hardware on a given host is able to indicate physical changes of connectivity, then when the hardware indicates such a change, the host should take this information into account in its Multicast DNS cache management strategy. For example, a host may choose to immediately flush all cache records received on a particular interface when that cable is disconnected. Alternatively, a host may choose to adjust the remaining TTL on all those records to a few seconds so that if the cable is not reconnected quickly, those records will expire from the cache.
特定のホストのハードウェアが接続の物理的な変化を示すことができる場合、ハードウェアがそのような変化を示すとき、ホストはマルチキャストDNSキャッシュ管理戦略でこの情報を考慮する必要があります。たとえば、ホストは、ケーブルが切断されたときに、特定のインターフェイスで受信したすべてのキャッシュレコードをすぐにフラッシュすることを選択できます。または、ホストはこれらのすべてのレコードの残りのTTLを数秒に調整することを選択できます。これにより、ケーブルがすぐに再接続されない場合、それらのレコードはキャッシュから期限切れになります。
Likewise, when a host reboots, wakes from sleep, or undergoes some other similar discontinuous state change, the cache management strategy should take that information into account.
同様に、ホストが再起動したり、スリープから復帰したり、その他の同様の不連続な状態変化を受けたりした場合、キャッシュ管理戦略ではその情報を考慮する必要があります。
Sometimes a cache record can be determined to be stale when a client attempts to use the rdata it contains, and the client finds that rdata to be incorrect.
キャッシュレコードに含まれているrdataをクライアントが使用しようとすると、キャッシュレコードが古くなっていると判断され、クライアントがそのrdataが正しくないことに気付く場合があります。
For example, the rdata in an address record can be determined to be incorrect if attempts to contact that host fail, either because (for an IPv4 address on a local subnet) ARP requests for that address go unanswered, because (for an IPv6 address with an on-link prefix) ND requests for that address go unanswered, or because (for an address on a remote network) a router returns an ICMP "Host Unreachable" error.
たとえば、（ローカルサブネットのIPv4アドレスの場合）そのアドレスへのARP要求が応答されなかったため（そのアドレスのIPv6アドレスの場合）、そのホストへの接続が失敗した場合、アドレスレコードのrdataが正しくないと判断できます。オンリンクプレフィックス）そのアドレスに対するND要求が応答しない、または（リモートネットワーク上のアドレスの場合）ルーターがICMP "Host Unreachable"エラーを返すため。
The rdata in an SRV record can be determined to be incorrect if attempts to communicate with the indicated service at the host and port number indicated are not successful.
SRVレコードのrdataは、示されたホストとのサービスおよび示されたポート番号との通信が失敗した場合に、誤っていると判断できます。
The rdata in a DNS-SD PTR record can be determined to be incorrect if attempts to look up the SRV record it references are not successful.
DNS-SD PTRレコード内のrdataは、それが参照するSRVレコードを検索しようとして失敗した場合に、誤っていると判断できます。
The software implementing the Multicast DNS resource record cache should provide a mechanism so that clients detecting stale rdata can inform the cache.
マルチキャストDNSリソースレコードキャッシュを実装するソフトウェアは、古いrdataを検出したクライアントがキャッシュに通知できるようにメカニズムを提供する必要があります。
When the cache receives this hint that it should reconfirm some record, it MUST issue two or more queries for the resource record in dispute. If no response is received within ten seconds, then, even though its TTL may indicate that it is not yet due to expire, that record SHOULD be promptly flushed from the cache.
キャッシュがこのレコードを再確認する必要があるというヒントを受け取った場合、論争中のリソースレコードに対して2つ以上のクエリを発行する必要があります。 10秒以内に応答が受信されない場合、TTLがまだ期限切れではないことを示している場合でも、そのレコードはキャッシュからすぐにフラッシュする必要があります（SHOULD）。
The end result of this is that if a printer suffers a sudden power failure or other abrupt disconnection from the network, its name may continue to appear in DNS-SD browser lists displayed on users' screens. Eventually, that entry will expire from the cache naturally, but if a user tries to access the printer before that happens, the failure to successfully contact the printer will trigger the more hasty demise of its cache entries. This is a sensible trade-off between good user experience and good network efficiency. If we were to insist that printers should disappear from the printer list within 30 seconds of becoming unavailable, for all failure modes, the only way to achieve this would be for the client to poll the printer at least every 30 seconds, or for the printer to announce its presence at least every 30 seconds, both of which would be an unreasonable burden on most networks.
その結果、プリンタで突然の電源障害やその他のネットワークからの突然の切断が発生した場合、その名前がユーザーの画面に表示されるDNS-SDブラウザリストに引き続き表示されることがあります。最終的に、そのエントリはキャッシュから期限切れになりますが、それが発生する前にユーザーがプリンターにアクセスしようとすると、プリンターへの接続に失敗すると、キャッシュエントリーがより早く終了します。これは、優れたユーザーエクスペリエンスと優れたネットワーク効率との間の賢明なトレードオフです。プリンターが使用不可になってから30秒以内にプリンターリストから削除するように要求した場合、すべての障害モードで、これを達成する唯一の方法は、クライアントが少なくとも30秒ごとにプリンターをポーリングするか、プリンター少なくとも30秒ごとにその存在をアナウンスします。どちらもほとんどのネットワークにとって不当な負担になります。
A host observes the multicast queries issued by the other hosts on the network. One of the major benefits of also sending responses using multicast is that it allows all hosts to see the responses (or lack thereof) to those queries.
ホストは、ネットワーク上の他のホストによって発行されたマルチキャストクエリを監視します。マルチキャストを使用して応答を送信することの主な利点の1つは、すべてのホストがそれらのクエリに対する応答（または応答がないこと）を確認できることです。
If a host sees queries, for which a record in its cache would be expected to be given as an answer in a multicast response, but no such answer is seen, then the host may take this as an indication that the record may no longer be valid.
ホストがクエリを確認した場合、そのキャッシュ内のレコードはマルチキャスト応答の回答として提供されると予想されますが、そのような回答が見られない場合、ホストはこれを、レコードがもはや存在しない可能性があることを示すものと見なします。有効。
After seeing two or more of these queries, and seeing no multicast response containing the expected answer within ten seconds, then even though its TTL may indicate that it is not yet due to expire, that record SHOULD be flushed from the cache. The host SHOULD NOT perform its own queries to reconfirm that the record is truly gone. If every host on a large network were to do this, it would cause a lot of unnecessary multicast traffic. If host A sends multicast queries that remain unanswered, then there is no reason to suppose that host B or any other host is likely to be any more successful.
これらのクエリを2つ以上確認し、10秒以内に予想される回答を含むマルチキャスト応答がないことを確認した後、TTLがまだ期限切れではないことを示している場合でも、そのレコードはキャッシュからフラッシュする必要があります（SHOULD）。ホストは、レコードが本当になくなったことを再確認するために独自のクエリを実行すべきではありません。大規模なネットワーク上のすべてのホストがこれを行うと、不要なマルチキャストトラフィックが大量に発生します。ホストAが応答のないマルチキャストクエリを送信する場合、ホストBまたは他のホストがこれ以上成功する可能性が高いと想定する理由はありません。
The previous section, "Cache Flush on Failure Indication", describes a situation where a user trying to print discovers that the printer is no longer available. By implementing the passive observation described here, when one user fails to contact the printer, all hosts on the network observe that failure and update their caches accordingly.
前のセクション「障害表示時のキャッシュフラッシュ」では、印刷しようとしたユーザーがプリンターが使用できなくなったことを発見した状況について説明しました。ここで説明するパッシブ監視を実装することにより、1人のユーザーがプリンターへの接続に失敗すると、ネットワーク上のすべてのホストがその障害を監視し、それに応じてキャッシュを更新します。
All Multicast DNS responses (including responses sent via unicast) SHOULD be sent with IP TTL set to 255. This is recommended to provide backwards-compatibility with older Multicast DNS queriers (implementing a draft version of this document, posted in February 2004) that check the IP TTL on reception to determine whether the packet originated on the local link. These older queriers discard all packets with TTLs other than 255.
すべてのマルチキャストDNS応答（ユニキャスト経由で送信される応答を含む）は、IP TTLを255に設定して送信する必要があります。これは、チェックする古いマルチキャストDNSクエリア（このドキュメントのドラフトバージョンを実装）との下位互換性を提供するために推奨されます。パケットがローカルリンクから発信されたかどうかを判断するための受信時のIP TTL。これらの古いクエリアは、255以外のTTLを持つすべてのパケットを破棄します。
A host sending Multicast DNS queries to a link-local destination address (including the 224.0.0.251 and FF02::FB link-local multicast addresses) MUST only accept responses to that query that originate from the local link, and silently discard any other response packets. Without this check, it could be possible for remote rogue hosts to send spoof answer packets (perhaps unicast to the victim host), which the receiving machine could misinterpret as having originated on the local link.
マルチキャストDNSクエリをリンクローカル宛先アドレス（224.0.0.251およびFF02 :: FBリンクローカルマルチキャストアドレスを含む）に送信するホストは、ローカルリンクから発信されたそのクエリへの応答のみを受け入れ、他の応答は通知せずに破棄する必要がありますパケット。このチェックがないと、リモートの不正なホストがスプーフィング応答パケット（おそらく被害ホストへのユニキャスト）を送信する可能性があり、受信マシンはローカルリンクから発信されたものであると誤って解釈する可能性があります。
The test for whether a response originated on the local link is done in two ways:
応答がローカルリンクで発生したかどうかのテストは、次の2つの方法で行われます。
* All responses received with a destination address in the IP header that is the mDNS IPv4 link-local multicast address 224.0.0.251 or the mDNS IPv6 link-local multicast address FF02::FB are necessarily deemed to have originated on the local link, regardless of source IP address. This is essential to allow devices to work correctly and reliably in unusual configurations, such as multiple logical IP subnets overlayed on a single link, or in cases of severe misconfiguration, where devices are physically connected to the same link, but are currently misconfigured with completely unrelated IP addresses and subnet masks.
* mDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251またはmDNS IPv6リンクローカルマルチキャストアドレスFF02 :: FBであるIPヘッダー内の宛先アドレスで受信されたすべての応答は、ローカルリンクで発信されたと見なされます。送信元IPアドレス。これは、単一のリンクにオーバーレイされた複数の論理IPサブネット、またはデバイスが同じリンクに物理的に接続されているが、現在完全に正しく構成されていない深刻な構成ミスの場合など、異常な構成でデバイスが正しく確実に機能するために不可欠です関連のないIPアドレスとサブネットマスク。
* For responses received with a unicast destination address in the IP header, the source IP address in the packet is checked to see if it is an address on a local subnet. An IPv4 source address is determined to be on a local subnet if, for (one of) the address(es) configured on the interface receiving the packet, (I & M) == (P & M), where I and M are the interface address and subnet mask respectively, P is the source IP address from the packet, '&' represents the bitwise logical 'and' operation, and '==' represents a bitwise equality test. An IPv6 source address is determined to be on the local link if, for any of the on-link IPv6 prefixes on the interface receiving the packet (learned via IPv6 router advertisements or otherwise configured on the host), the first 'n' bits of the IPv6 source address match the first 'n' bits of the prefix address, where 'n' is the length of the prefix being considered.
* IPヘッダーにユニキャスト宛先アドレスを指定して受信した応答の場合、パケットの送信元IPアドレスがチェックされ、ローカルサブネット上のアドレスであるかどうかが確認されます。 IPv4送信元アドレスは、パケットを受信するインターフェイスに構成された（1つまたは複数の）アドレスについて、（I＆M）==（P＆M）である場合、ローカルサブネット上にあると判断されます。それぞれインターフェイスアドレスとサブネットマスク、Pはパケットの送信元IPアドレス、「＆」はビット単位の論理「and」演算を表し、「==」はビット単位の等価テストを表します。 IPv6送信元アドレスは、パケットを受信するインターフェース上のリンク上のIPv6プレフィックス（IPv6ルーターアドバタイズメントによって学習されるか、ホスト上で構成されている）の最初の「n」ビットがローカルリンク上にあると判断されます。 IPv6送信元アドレスは、プレフィックスアドレスの最初の「n」ビットと一致します。「n」は、考慮されるプレフィックスの長さです。
Since queriers will ignore responses apparently originating outside the local subnet, a responder SHOULD avoid generating responses that it can reasonably predict will be ignored. This applies particularly in the case of overlayed subnets. If a responder receives a query addressed to the mDNS IPv4 link-local multicast address 224.0.0.251, from a source address not apparently on the same subnet as the responder (or, in the case of IPv6, from a source IPv6 address for which the responder does not have any address with the same prefix on that interface), then even if the query indicates that a unicast response is preferred (see Section 5.4, "Questions Requesting Unicast Responses"), the responder SHOULD elect to respond by multicast anyway, since it can reasonably predict that a unicast response with an apparently non-local source address will probably be ignored.
クエリアはローカルサブネットの外から発信されたように見える応答を無視するため、レスポンダは無視できると合理的に予測できる応答を生成しないようにする必要があります（SHOULD）。これは、オーバーレイされたサブネットの場合に特に当てはまります。レスポンダがmDNS IPv4リンクローカルマルチキャストアドレス224.0.0.251にアドレス指定されたクエリを、レスポンダと同じサブネット上にないソースアドレスから（またはIPv6の場合は、そのソースIPv6アドレスから）受信した場合レスポンダには、そのインターフェース上に同じプレフィックスを持つアドレスがありません）。次に、クエリがユニキャスト応答が優先されることを示している場合でも（セクション5.4「ユニキャスト応答を要求する質問」を参照）、レスポンダはとにかくマルチキャストで応答することを選択する必要があります。明らかに非ローカルな送信元アドレスを持つユニキャスト応答はおそらく無視されると合理的に予測できるためです。
Unlike conventional DNS names, names that end in ".local." have only local significance. The same is true of names within the IPv4 link-local reverse mapping domain "254.169.in-addr.arpa." and the IPv6 link-local reverse mapping domains "8.e.f.ip6.arpa.", "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
従来のDNS名とは異なり、「。local」で終わる名前。局所的な意味しかない。 IPv4リンクローカルリバースマッピングドメイン「254.169.in-addr.arpa」内の名前についても同様です。 IPv6リンクローカルリバースマッピングドメイン「8.e.f.ip6.arpa。」、「9.e.f.ip6.arpa。」、「a.e.f.ip6.arpa。」、「b.e.f.ip6.arpa。」。
These names function primarily as protocol identifiers, rather than as user-visible identifiers. Even though they may occasionally be visible to end users, that is not their primary purpose. As such, these names should be treated as opaque identifiers. In particular, the string "local" should not be translated or localized into different languages, much as the name "localhost" is not translated or localized into different languages.
これらの名前は、ユーザーに表示される識別子ではなく、主にプロトコル識別子として機能します。エンドユーザーにときどき表示される場合がありますが、それが主な目的ではありません。そのため、これらの名前は不透明な識別子として扱う必要があります。特に、「localhost」という名前は別の言語に翻訳またはローカライズされないため、文字列「local」は別の言語に翻訳またはローカライズされるべきではありません。
Conventional Unicast DNS seeks to provide a single unified namespace, where a given DNS query yields the same answer no matter where on the planet it is performed or to which recursive DNS server the query is sent. In contrast, each IP link has its own private ".local.", "254.169.in-addr.arpa." and IPv6 link-local reverse mapping namespaces, and the answer to any query for a name within those domains depends on where that query is asked. (This characteristic is not unique to Multicast DNS. Although the original concept of DNS was a single global namespace, in recent years, split views, firewalls, intranets, DNS geolocation, and the like have increasingly meant that the answer to a given DNS query has become dependent on the location of the querier.)
従来のユニキャストDNSは単一の統一された名前空間を提供しようとします。そこでは、与えられたDNSクエリは、それが実行される地球上のどこにいても、クエリが送信される再帰DNSサーバーに関係なく、同じ答えを返します。対照的に、各IPリンクには独自のプライベート「.local。」、「254.169.in-addr.arpa」があります。 IPv6リンクローカルリバースマッピング名前空間、およびそれらのドメイン内の名前に対するクエリへの回答は、そのクエリがどこで要求されるかによって異なります。 （この特性はマルチキャストDNSに固有のものではありません。DNSの元の概念は単一のグローバル名前空間でしたが、近年、分割ビュー、ファイアウォール、イントラネット、DNSジオロケーションなどにより、特定のDNSクエリに対する答えがクエリアの場所に依存するようになりました。）
The IPv4 name server address for a Multicast DNS domain is 224.0.0.251. The IPv6 name server address for a Multicast DNS domain is FF02::FB. These are multicast addresses; therefore, they identify not a single host but a collection of hosts, working in cooperation to maintain some reasonable facsimile of a competently managed DNS zone. Conceptually, a Multicast DNS domain is a single DNS zone; however, its server is implemented as a distributed process running on a cluster of loosely cooperating CPUs rather than as a single process running on a single CPU.
マルチキャストDNSドメインのIPv4ネームサーバーアドレスは224.0.0.251です。マルチキャストDNSドメインのIPv6ネームサーバーアドレスはFF02 :: FBです。これらはマルチキャストアドレスです。したがって、彼らは単一のホストではなくホストの集合を識別し、協力して、適切に管理されたDNSゾーンの合理的な複製を維持します。概念的には、マルチキャストDNSドメインは単一のDNSゾーンです。ただし、そのサーバーは、単一のCPUで実行される単一のプロセスとしてではなく、緩やかに連携するCPUのクラスターで実行される分散プロセスとして実装されます。
Multicast DNS domains are not delegated from their parent domain via use of NS (Name Server) records, and there is also no concept of delegation of subdomains within a Multicast DNS domain. Just because a particular host on the network may answer queries for a particular record type with the name "example.local." does not imply anything about whether that host will answer for the name "child.example.local.", or indeed for other record types with the name "example.local.".
マルチキャストDNSドメインは、NS（ネームサーバー）レコードを使用して親ドメインから委任されず、マルチキャストDNSドメイン内のサブドメインを委任する概念もありません。ネットワーク上の特定のホストが、「example.local」という名前の特定のレコードタイプに対するクエリに応答する可能性があるからです。そのホストが「child.example.local。」という名前で応答するのか、それとも「example.local。」という名前の他のレコードタイプで応答するのかについては何も意味しません。
There are no NS records anywhere in Multicast DNS domains. Instead, the Multicast DNS domains are reserved by IANA, and there is effectively an implicit delegation of all Multicast DNS domains to the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue of client software implementing the protocol rules specified in this document.
マルチキャストDNSドメインのどこにもNSレコードはありません。代わりに、マルチキャストDNSドメインはIANAによって予約されており、プロトコルを実装するクライアントソフトウェアによって、すべてのマルチキャストDNSドメインが224.0.0.251:5353および[FF02 :: FB]：5353マルチキャストグループに暗黙的に委任されます。このドキュメントで指定されているルール。
Multicast DNS zones have no SOA (Start of Authority) record. A conventional DNS zone's SOA record contains information such as the email address of the zone administrator and the monotonically increasing serial number of the last zone modification. There is no single human administrator for any given Multicast DNS zone, so there is no email address. Because the hosts managing any given Multicast DNS zone are only loosely coordinated, there is no readily available monotonically increasing serial number to determine whether or not the zone contents have changed. A host holding part of the shared zone could crash or be disconnected from the network at any time without informing the other hosts. There is no reliable way to provide a zone serial number that would, whenever such a crash or disconnection occurred, immediately change to indicate that the contents of the shared zone had changed.
マルチキャストDNSゾーンにはSOA（Start of Authority）レコードがありません。従来のDNSゾーンのSOAレコードには、ゾーン管理者の電子メールアドレスや、ゾーンの最後の変更の単調に増加するシリアル番号などの情報が含まれています。特定のマルチキャストDNSゾーンには人間の管理者が一人もいないため、電子メールアドレスはありません。特定のマルチキャストDNSゾーンを管理するホストは大まかに調整されているだけなので、ゾーンの内容が変更されたかどうかを判断するために単調に増加するシリアル番号をすぐに利用することはできません。共有ゾーンの一部を保持するホストは、他のホストに通知することなく、いつでもクラッシュしたり、ネットワークから切断されたりする可能性があります。ゾーンのシリアル番号を提供する確実な方法はありません。このようなクラッシュや切断が発生すると、すぐに変更され、共有ゾーンの内容が変更されたことを示します。
Zone transfers are not possible for any Multicast DNS zone.
マルチキャストDNSゾーンでは、ゾーン転送はできません。
The option to fail-over to Multicast DNS for names not ending in ".local." SHOULD be a user-configured option, and SHOULD be disabled by default because of the possible security issues related to unintended local resolution of apparently global names. Enabling Multicast DNS for names not ending in ".local." may be appropriate on a secure isolated network, or on some future network were machines exclusively use DNSSEC for all DNS queries, and have Multicast DNS responders capable of generating the appropriate cryptographic DNSSEC signatures, thereby guarding against spoofing.
末尾が「.local」でない名前のマルチキャストDNSにフェイルオーバーするオプション。明らかにグローバルな名前の意図しないローカル解決に関連する潜在的なセキュリティ問題のため、ユーザー設定オプションである必要があり、デフォルトで無効にする必要があります（SHOULD）。 「.local」で終わらない名前のマルチキャストDNSを有効にする安全な隔離されたネットワーク、または一部の将来のネットワークでは、マシンがすべてのDNSクエリにDNSSECのみを使用し、マルチキャストDNSレスポンダが適切な暗号化DNSSEC署名を生成できるため、なりすましを防ぐことができます。
The option to look up unqualified (relative) names by appending ".local." (or not) is controlled by whether ".local." appears (or not) in the client's DNS search list.
「.local」を追加することにより、非修飾（相対）名を検索するオプション。 （かどうか）は「.local」かどうかによって制御されますクライアントのDNS検索リストに表示されます（または表示されません）。
No special control is needed for enabling and disabling Multicast DNS for names explicitly ending with ".local." as entered by the user. The user doesn't need a way to disable Multicast DNS for names ending with ".local.", because if the user doesn't want to use Multicast DNS, they can achieve this by simply not using those names. If a user *does* enter a name ending in ".local.", then we can safely assume the user's intention was probably that it should work. Having user configuration options that can be (intentionally or unintentionally) set so that local names don't work is just one more way of frustrating the user's ability to perform the tasks they want, perpetuating the view that, "IP networking is too complicated to configure and too hard to use".
明示的に「.local」で終わる名前のマルチキャストDNSを有効または無効にするための特別な制御は必要ありません。ユーザーが入力したとおり。ユーザーが「.local。」で終わる名前のマルチキャストDNSを無効にする方法は必要ありません。ユーザーがマルチキャストDNSを使用したくない場合、それらの名前を使用しないことでこれを実現できるためです。ユーザーが「.local。」で終わる名前を入力する*場合*、ユーザーの意図はおそらく機能するはずであると安全に想定できます。ローカル名が機能しないように（意図的または意図せずに）設定できるユーザー構成オプションを用意することは、ユーザーが希望するタスクを実行する能力を挫折させるもう1つの方法であり、「IPネットワークは複雑すぎるため、構成し、使用するには難しすぎます。」
A host SHOULD defend its dot-local host name on all active interfaces on which it is answering Multicast DNS queries.
ホストは、マルチキャストDNSクエリに応答するすべてのアクティブなインターフェースで、そのドットローカルホスト名を防御する必要があります（SHOULD）。
In the event of a name conflict on *any* interface, a host should configure a new host name, if it wishes to maintain uniqueness of its host name.
*任意の*インターフェイスで名前の競合が発生した場合、ホスト名の一意性を維持したい場合、ホストは新しいホスト名を設定する必要があります。
A host may choose to use the same name (or set of names) for all of its address records on all interfaces, or it may choose to manage its Multicast DNS interfaces independently, potentially answering to a different name (or set of names) on different interfaces.
ホストは、すべてのインターフェースのすべてのアドレスレコードに同じ名前（または名前のセット）を使用するか、マルチキャストDNSインターフェースを個別に管理することを選択して、別の名前（または名前のセット）に応答する可能性があります異なるインターフェース。
Except in the case of proxying and other similar specialized uses, addresses in IPv4 or IPv6 address records in Multicast DNS responses MUST be valid for use on the interface on which the response is being sent.
プロキシおよびその他の同様の特殊な用途の場合を除いて、マルチキャストDNS応答のIPv4またはIPv6アドレスレコードのアドレスは、応答が送信されるインターフェイスでの使用に有効でなければなりません。
Just as the same link-local IP address may validly be in use simultaneously on different links by different hosts, the same link-local host name may validly be in use simultaneously on different links, and this is not an error. A multihomed host with connections to two different links may be able to communicate with two different hosts that are validly using the same name. While this kind of name duplication should be rare, it means that a host that wants to fully support this case needs network programming APIs that allow applications to specify on what interface to perform a link-local Multicast DNS query, and to discover on what interface a Multicast DNS response was received.
同じリンクローカルIPアドレスが異なるホストの異なるリンクで同時に有効に使用されているのと同じように、同じリンクローカルホスト名が異なるリンクで同時に有効に使用されている可能性がありますが、これはエラーではありません。 2つの異なるリンクへの接続を持つマルチホームホストは、同じ名前を有効に使用している2つの異なるホストと通信できる場合があります。この種の名前の重複はまれであるはずですが、このケースを完全にサポートする必要があるホストには、アプリケーションがリンクローカルマルチキャストDNSクエリを実行するインターフェイスを指定し、どのインターフェイスで検出できるようにするネットワークプログラミングAPIが必要であることを意味しますマルチキャストDNS応答が受信されました。
There is one other special precaution that multihomed hosts need to take. It's common with today's laptop computers to have an Ethernet connection and an 802.11 [IEEE.802.11] wireless connection active at the same time. What the software on the laptop computer can't easily tell is whether the wireless connection is in fact bridged onto the same network segment as its Ethernet connection. If the two networks are bridged together, then packets the host sends on one interface will arrive on the other interface a few milliseconds later, and care must be taken to ensure that this bridging does not cause problems: When the host announces its host name (i.e., its address records) on its wireless interface, those announcement records are sent with the cache-flush bit set, so when they arrive on the Ethernet segment, they will cause all the peers on the Ethernet to flush the host's Ethernet address records from their caches. The Multicast DNS protocol has a safeguard to protect against this situation: when records are received with the cache-flush bit set, other records are not deleted from peer caches immediately, but are marked for deletion in one second. When the host sees its own wireless address records arrive on its Ethernet interface, with the cache-flush bit set, this one-second grace period gives the host time to respond and re-announce its Ethernet address records, to reinstate those records in peer caches before they are deleted.
マルチホームホストが実行する必要がある、もう1つの特別な予防策があります。今日のラップトップコンピューターでは、イーサネット接続と802.11 [IEEE.802.11]ワイヤレス接続が同時にアクティブになるのが一般的です。ラップトップコンピュータのソフトウェアが簡単に判断できないのは、ワイヤレス接続が実際にイーサネット接続と同じネットワークセグメントにブリッジされているかどうかです。 2つのネットワークが一緒にブリッジされる場合、ホストが1つのインターフェースで送信するパケットは数ミリ秒後に他のインターフェースに到着し、このブリッジが問題を引き起こさないように注意する必要があります：ホストがホスト名（つまり、そのアドレスレコード）がワイヤレスインターフェースにある場合、これらのアナウンスレコードはキャッシュフラッシュビットが設定された状態で送信されるため、イーサネットセグメントに到着すると、イーサネット上のすべてのピアにホストのイーサネットアドレスレコードをフラッシュさせます。それらのキャッシュ。マルチキャストDNSプロトコルには、この状況から保護するための保護手段があります。キャッシュフラッシュビットを設定してレコードを受信すると、他のレコードはピアキャッシュからすぐに削除されず、1秒で削除対象としてマークされます。ホストが独自のワイヤレスアドレスレコードがイーサネットインターフェイスに到着し、キャッシュフラッシュビットが設定されていることを確認すると、この1秒の猶予期間により、ホストはイーサネットアドレスレコードに応答して再アナウンスし、それらのレコードをピアに復元することができます。削除される前のキャッシュ。
As described, this solves one problem, but creates another, because when those Ethernet announcement records arrive back on the wireless interface, the host would again respond defensively to reinstate its wireless records, and this process would continue forever, continuously flooding the network with traffic. The Multicast DNS protocol has a second safeguard, to solve this problem: the cache-flush bit does not apply to records received very recently, within the last second. This means that when the host sees its own Ethernet address records arrive on its wireless interface, with the cache-flush bit set, it knows there's no need to re-announce its wireless address records again because it already sent them less than a second ago, and this makes them immune from deletion from peer caches. (See Section 10.2.)
前述のように、これにより1つの問題は解決しますが、別の問題が発生します。これらのイーサネットアナウンスレコードがワイヤレスインターフェイスに戻ってくると、ホストは再び防御的に応答してワイヤレスレコードを元に戻し、このプロセスは永久に続き、ネットワークにトラフィックを常にあふれさせます。 。マルチキャストDNSプロトコルには、この問題を解決するための2番目の保護手段があります。キャッシュフラッシュビットは、最後の1秒以内に最近受信したレコードには適用されません。これは、キャッシュフラッシュビットが設定された独自のイーサネットアドレスレコードがワイヤレスインターフェイスに到着したことをホストが確認すると、ワイヤレスアドレスレコードを1秒以内に送信しているため、再度ワイヤレスアドレスレコードを再アナウンスする必要がないことがわかります。 、これにより、ピアキャッシュからの削除の影響を受けなくなります。 （セクション10.2を参照）
It is possible to have more than one Multicast DNS responder and/or querier implementation coexist on the same machine, but there are some known issues.
同じマシン上に複数のマルチキャストDNSレスポンダやクエリア実装を共存させることは可能ですが、いくつかの既知の問題があります。
In most operating systems, incoming *multicast* packets can be delivered to *all* open sockets bound to the right port number, provided that the clients take the appropriate steps to allow this. For this reason, all Multicast DNS implementations SHOULD use the SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as appropriate for the operating system in question) so they will all be able to bind to UDP port 5353 and receive incoming multicast packets addressed to that port. However, unlike multicast packets, incoming unicast UDP packets are typically delivered only to the first socket to bind to that port. This means that "QU" responses and other packets sent via unicast will be received only by the first Multicast DNS responder and/or querier on a system. This limitation can be partially mitigated if Multicast DNS implementations detect when they are not the first to bind to port 5353, and in that case they do not request "QU" responses. One way to detect if there is another Multicast DNS implementation already running is to attempt binding to port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that fails it indicates that some other socket is already bound to this port.
ほとんどのオペレーティングシステムでは、クライアントが適切な手順を実行できるようにすれば、着信*マルチキャスト*パケットを正しいポート番号にバインドされた*すべての*開いたソケットに配信できます。このため、すべてのマルチキャストDNS実装は、SO_REUSEPORTおよび/またはSO_REUSEADDRオプション（または問題のオペレーティングシステムに応じて同等）を使用して（SHOULD）、UDPポート5353にバインドし、そのポートにアドレス指定された着信マルチキャストパケットを受信できるようにします。ただし、マルチキャストパケットとは異なり、着信ユニキャストUDPパケットは通常、そのポートにバインドする最初のソケットにのみ配信されます。つまり、ユニキャストを介して送信された「QU」応答およびその他のパケットは、システム上の最初のマルチキャストDNSレスポンダまたはクエリア、あるいはその両方によってのみ受信されます。この制限は、マルチキャストDNS実装が最初にポート5353にバインドしない場合を検出し、その場合に「QU」応答を要求しない場合、部分的に軽減できます。別のマルチキャストDNS実装が既に実行されているかどうかを検出する1つの方法は、SO_REUSEPORTやSO_REUSEADDRを使用せずにポート5353へのバインドを試行することです。失敗した場合、他のソケットがすでにこのポートにバインドされていることを示します。
When a Multicast DNS querier issues a query with too many Known Answers to fit into a single packet, it divides the Known-Answer list into two or more packets. Multicast DNS responders associate the initial truncated query with its continuation packets by examining the source IP address in each packet. Since two independent Multicast DNS queriers running on the same machine will be sending packets with the same source IP address, from an outside perspective they appear to be a single entity. If both queriers happened to send the same multipacket query at the same time, with different Known-Answer lists, then they could each end up suppressing answers that the other needs.
マルチキャストDNSクエリアが1つのパケットに収まらないほど多くの既知の回答を含むクエリを発行すると、既知の回答のリストが2つ以上のパケットに分割されます。マルチキャストDNSレスポンダは、各パケットの送信元IPアドレスを調べることにより、最初の切り捨てられたクエリを継続パケットに関連付けます。同じマシンで実行されている2つの独立したマルチキャストDNSクエリアは同じ送信元IPアドレスでパケットを送信するため、外部から見ると、それらは単一のエンティティのように見えます。両方のクエリアが、異なる既知の回答リストを使用して、同じマルチパケットクエリを同時に送信した場合、それぞれが他の必要な回答を抑制してしまう可能性があります。
If different clients on a machine were each to have their own independent Multicast DNS implementation, they would lose certain efficiency benefits. Apart from the unnecessary code duplication, memory usage, and CPU load, the clients wouldn't get the benefit of a shared system-wide cache, and they would not be able to aggregate separate queries into single packets to reduce network traffic.
マシン上の異なるクライアントがそれぞれ独自の独立したマルチキャストDNS実装を持っている場合、特定の効率上の利点が失われます。不要なコードの重複、メモリ使用量、CPU負荷を除いて、クライアントはシステム全体の共有キャッシュのメリットを享受できず、個別のクエリを単一のパケットに集約してネットワークトラフィックを削減することができません。
Because of these issues, this document encourages implementers to design systems with a single Multicast DNS implementation that provides Multicast DNS services shared by all clients on that machine, much as most operating systems today have a single TCP implementation, which is shared between all clients on that machine. Due to engineering constraints, there may be situations where embedding a "user-level" Multicast DNS implementation in the client application software is the most expedient solution, and while this will usually work in practice, implementers should be aware of the issues outlined in this section.
これらの問題があるため、このドキュメントでは、今日のほとんどのオペレーティングシステムに単一のTCP実装があり、そのすべてのクライアント間で共有されるのと同じように、実装者は、そのマシン上のすべてのクライアントによって共有されるマルチキャストDNSサービスを提供する単一のマルチキャストDNS実装を使用してシステムを設計することを推奨しますそのマシン。エンジニアリング上の制約により、クライアントアプリケーションソフトウェアに「ユーザーレベル」のマルチキャストDNS実装を埋め込むことが最も適切な解決策である場合があります。これは通常実際に機能しますが、実装者はこれに概説されている問題に注意する必要があります。セクション。
Historically, Unicast DNS has been used with a very restricted set of characters. Indeed, conventional DNS is usually limited to just twenty-six letters, ten digits and the hyphen character, not even allowing spaces or other punctuation. Attempts to remedy this for Unicast DNS have been badly constrained by the perceived need to accommodate old buggy legacy DNS implementations. In reality, the DNS specification itself actually imposes no limits on what characters may be used in names, and good DNS implementations handle any arbitrary eight-bit data without trouble. "Clarifications to the DNS Specification" [RFC2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that DNS names may contain arbitrary eight-bit data. However, the old rules for ARPANET host names back in the 1980s required host names to be just letters, digits, and hyphens [RFC1034], and since the predominant use of DNS is to store host address records, many have assumed that the DNS protocol itself suffers from the same limitation. It might be accurate to say that there could be hypothetical bad implementations that do not handle eight-bit data correctly, but it would not be accurate to say that the protocol doesn't allow names containing eight-bit data.
これまで、ユニキャストDNSは非常に制限された文字セットで使用されてきました。実際、従来のDNSは、通常、26文字、10桁、およびハイフン文字に制限されており、スペースやその他の句読点も使用できません。これをユニキャストDNSで修正しようとする試みは、古いバグのあるレガシーDNS実装に対応する必要性が認識されているため、ひどく制約されていました。実際には、DNS仕様自体が実際に名前に使用できる文字に制限を課しておらず、優れたDNS実装は任意の8ビットデータを問題なく処理します。 「DNS仕様の明確化」[RFC2181]は、セクション11（「名前の構文」）で許容される文字セットの主題を直接説明し、DNS名に任意の8ビットデータが含まれる可能性があることを明示的に述べています。ただし、1980年代に遡るARPANETホスト名の古い規則では、ホスト名は文字、数字、ハイフンのみである必要があり[RFC1034]、DNSの主な用途はホストアドレスレコードを格納することであるため、DNSプロトコルはそれ自体にも同じ制限があります。 8ビットデータを正しく処理しない架空の悪い実装が存在する可能性があると言うことは正確かもしれませんが、プロトコルが8ビットデータを含む名前を許可しないと言うことは正確ではないでしょう。
Multicast DNS is a new protocol and doesn't (yet) have old buggy legacy implementations to constrain the design choices. Accordingly, it adopts the simple obvious elegant solution: all names in Multicast DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode" [RFC5198] text.
マルチキャストDNSは新しいプロトコルであり、設計の選択を制約するための古いバグのあるレガシー実装は（まだ）ありません。したがって、それは単純で明白なエレガントなソリューションを採用します：マルチキャストDNSのすべての名前は、事前に構成されたUTF-8 [RFC3629] "Net-Unicode" [RFC5198]テキストとしてエンコードする必要があります。
Some users of 16-bit Unicode have taken to stuffing a "zero-width nonbreaking space" character (U+FEFF) at the start of each UTF-16 file, as a hint to identify whether the data is big-endian or little-endian, and calling it a "Byte Order Mark" (BOM). Since there is only one possible byte order for UTF-8 data, a BOM is neither necessary nor permitted. Multicast DNS names MUST NOT contain a "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at the start or anywhere else in a Multicast DNS name MUST be interpreted as being an actual intended part of the name, representing (just as for any other legal unicode value) an actual literal instance of that character (in this case a zero-width non-breaking space character).
16ビットUnicodeの一部のユーザーは、データがビッグエンディアンかリトルエンディアンかを識別するためのヒントとして、各UTF-16ファイルの先頭に「ゼロ幅の非改行スペース」文字（U + FEFF）を詰め込むことに気を配っていますエンディアン、それを「バイトオーダーマーク」（BOM）と呼びます。 UTF-8データのバイトオーダーは1つしかないため、BOMは不要であり、許可されていません。マルチキャストDNS名に「バイトオーダーマーク」を含めることはできません。マルチキャストDNS名の先頭またはその他の場所にあるUnicode文字U + FEFFの出現は、名前の実際の意図された部分であると解釈され、（他の正当なUnicode値と同様に）その実際のリテラルインスタンスを表す必要があります。文字（この場合は、ゼロ幅の改行しないスペース文字）。
For names that are restricted to US-ASCII [RFC0020] letters, digits, and hyphens, the UTF-8 encoding is identical to the US-ASCII encoding, so this is entirely compatible with existing host names. For characters outside the US-ASCII range, UTF-8 encoding is used.
US-ASCII [RFC0020]の文字、数字、ハイフンに制限されている名前の場合、UTF-8エンコーディングはUS-ASCIIエンコーディングと同じであるため、既存のホスト名と完全に互換性があります。 US-ASCII範囲外の文字については、UTF-8エンコーディングが使用されます。
Multicast DNS implementations MUST NOT use any other encodings apart from precomposed UTF-8 (US-ASCII being considered a compatible subset of UTF-8). The reasons for selecting UTF-8 instead of Punycode [RFC3492] are discussed further in Appendix F.
マルチキャストDNSの実装では、事前に構成されたUTF-8（US-ASCIIはUTF-8の互換性のあるサブセットと見なされています）以外のエンコーディングを使用してはなりません（MUST NOT）。 Punycode [RFC3492]の代わりにUTF-8を選択する理由については、付録Fでさらに説明します。
The simple rules for case-insensitivity in Unicast DNS [RFC1034] [RFC1035] also apply in Multicast DNS; that is to say, in name comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a querier issues a query for an address record with the name "myprinter.local.", then a responder having an address record with the name "MyPrinter.local." should issue a response. No other automatic equivalences should be assumed. In particular, all UTF-8 multibyte characters (codes 0x80 and higher) are compared by simple binary comparison of the raw byte values. Accented characters are *not* defined to be automatically equivalent to their unaccented counterparts. Where automatic equivalences are desired, this may be achieved through the use of programmatically generated CNAME records. For example, if a responder has an address record for an accented name Y, and a querier issues a query for a name X, where X is the same as Y with all the accents removed, then the responder may issue a response containing two resource records: a CNAME record "X CNAME Y", asserting that the requested name X (unaccented) is an alias for the true (accented) name Y, followed by the address record for Y.
ユニキャストDNS [RFC1034] [RFC1035]の大文字と小文字を区別しない単純なルールは、マルチキャストDNSにも適用されます。つまり、名前の比較では、小文字の "a"〜 "z"（0x61〜0x7A）は、対応する大文字の "A"〜 "Z"（0x41〜0x5A）と一致します。したがって、クエリアが "myprinter.local。"という名前のアドレスレコードに対するクエリを発行すると、 "MyPrinter.local。"という名前のアドレスレコードを持つレスポンダが応答します。応答を発行する必要があります。他の自動等価は想定されるべきではありません。特に、すべてのUTF-8マルチバイト文字（コード0x80以上）は、生のバイト値の単純なバイナリ比較によって比較されます。アクセント記号付きの文字は、アクセント記号なしの対応する文字と自動的に同等であるとは*定義されていません*。自動等価が必要な場合は、プログラムで生成されたCNAMEレコードを使用してこれを実現できます。たとえば、レスポンダーにアクセント付きの名前Yのアドレスレコードがあり、クエリアが名前Xのクエリを発行した場合、XはYと同じで、すべてのアクセントが削除され、レスポンダーは2つのリソースを含む応答を発行できます。 records：CNAMEレコード "X CNAME Y"。要求された名前X（アクセント記号なし）が真の（アクセント記号付き）名前Yのエイリアスであり、その後にYのアドレスレコードが続くことを表明します。
The 1987 DNS specification [RFC1035] restricts DNS messages carried by UDP to no more than 512 bytes (not counting the IP or UDP headers). For UDP packets carried over the wide-area Internet in 1987, this was appropriate. For link-local multicast packets on today's networks, there is no reason to retain this restriction. Given that the packets are by definition link-local, there are no Path MTU issues to consider.
1987年のDNS仕様[RFC1035]は、UDPによって伝送されるDNSメッセージを512バイト以下に制限しています（IPまたはUDPヘッダーはカウントしません）。 1987年に広域インターネットで運ばれたUDPパケットの場合、これは適切でした。今日のネットワーク上のリンクローカルマルチキャストパケットの場合、この制限を維持する理由はありません。パケットが定義上リンクローカルであることを考えると、考慮すべきパスMTUの問題はありません。
Multicast DNS messages carried by UDP may be up to the IP MTU of the physical interface, less the space required for the IP header (20 bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
UDPによって運ばれるマルチキャストDNSメッセージは、物理インターフェースのIP MTUまでであり、IPヘッダー（IPv4の場合は20バイト、IPv6の場合は40バイト）およびUDPヘッダー（8バイト）に必要なスペースより少ない場合があります。
In the case of a single Multicast DNS resource record that is too large to fit in a single MTU-sized multicast response packet, a Multicast DNS responder SHOULD send the resource record alone, in a single IP datagram, using multiple IP fragments. Resource records this large SHOULD be avoided, except in the very rare cases where they really are the appropriate solution to the problem at hand. Implementers should be aware that many simple devices do not reassemble fragmented IP datagrams, so large resource records SHOULD NOT be used except in specialized cases where the implementer knows that all receivers implement reassembly, or where the large resource record contains optional data which is not essential for correct operation of the client.
単一のMTUサイズのマルチキャスト応答パケットに収まらない単一のマルチキャストDNSリソースレコードの場合、マルチキャストDNSレスポンダは、複数のIPフラグメントを使用して、単一のIPデータグラムでリソースレコードのみを送信する必要があります（SHOULD）。リソースレコードは、当面の問題に対する実際の適切な解決策である非常にまれなケースを除いて、この大きなレコードを避ける必要があります。実装者は、多くの単純なデバイスが断片化されたIPデータグラムを再構成しないことに注意してください。したがって、すべての受信者が再構成を実装することを実装者が知っている特別な場合、または大規模なリソースレコードに必須ではないオプションのデータが含まれている場合を除いて、大規模なリソースレコードは使用しないでください。クライアントの正しい操作のため。
A Multicast DNS packet larger than the interface MTU, which is sent using fragments, MUST NOT contain more than one resource record.
フラグメントを使用して送信されるインターフェイスMTUより大きいマルチキャストDNSパケットには、複数のリソースレコードを含めることはできません。
Even when fragmentation is used, a Multicast DNS packet, including IP and UDP headers, MUST NOT exceed 9000 bytes.
フラグメンテーションが使用されている場合でも、IPおよびUDPヘッダーを含むマルチキャストDNSパケットは、9000バイトを超えてはなりません。
Note that 9000 bytes is also the maximum payload size of an Ethernet "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo" packets are not widely used, so it is advantageous to keep packets under 1500 bytes whenever possible. Even on hosts that normally handle Ethernet "Jumbo" packets and IP fragment reassembly, it is becoming more common for these hosts to implement power-saving modes where the main CPU goes to sleep and hands off packet reception tasks to a more limited processor in the network interface hardware, which may not support Ethernet "Jumbo" packets or IP fragment reassembly.
9000バイトは、イーサネット「ジャンボ」パケットの最大ペイロードサイズでもあることに注意してください[ジャンボ]。ただし、実際にはイーサネットの「ジャンボ」パケットは広く使用されていないため、可能な場合は常に1500バイト未満のパケットを維持することをお勧めします。通常はイーサネット「ジャンボ」パケットとIPフラグメントの再構成を処理するホストでも、これらのホストがメインCPUがスリープ状態になり、パケット受信タスクをより限定されたプロセッサに渡す省電力モードを実装することが一般的になっています。イーサネット「ジャンボ」パケットまたはIPフラグメント再構成をサポートしない可能性があるネットワークインターフェイスハードウェア。
This section describes specific rules pertaining to the allowable values for the header fields of a Multicast DNS message, and other message format considerations.
このセクションでは、マルチキャストDNSメッセージのヘッダーフィールドの許容値に関連する特定のルール、およびその他のメッセージ形式の考慮事項について説明します。
Multicast DNS implementations SHOULD listen for unsolicited responses issued by hosts booting up (or waking up from sleep or otherwise joining the network). Since these unsolicited responses may contain a useful answer to a question for which the querier is currently awaiting an answer, Multicast DNS implementations SHOULD examine all received Multicast DNS response messages for useful answers, without regard to the contents of the ID field or the Question Section. In Multicast DNS, knowing which particular query message (if any) is responsible for eliciting a particular response message is less interesting than knowing whether the response message contains useful information.
マルチキャストDNS実装は、ホストの起動（またはスリープからの復帰、またはネットワークへの参加など）によって発行された非送信請求応答をリッスンする必要があります（SHOULD）。これらの非送信請求応答には、クエリアが現在応答を待っている質問に対する有用な回答が含まれている可能性があるため、マルチキャストDNS実装は、IDフィールドの内容や質問セクションに関係なく、受信したすべてのマルチキャストDNS応答メッセージで有用な回答を確認する必要があります（SHOULD）。 。マルチキャストDNSでは、特定のクエリメッセージ（存在する場合）が特定の応答メッセージの引き出しに関与していることを知ることは、応答メッセージに有用な情報が含まれているかどうかを知ることほど面白くありません。
Multicast DNS implementations MAY cache data from any or all Multicast DNS response messages they receive, for possible future use, provided of course that normal TTL aging is performed on these cached resource records.
マルチキャストDNS実装は、当然のことながら、これらのキャッシュされたリソースレコードで通常のTTLエージングが実行される限り、受信するマルチキャストDNS応答メッセージの一部またはすべてからデータをキャッシュできます（将来使用する場合があります）。
In multicast query messages, the Query Identifier SHOULD be set to zero on transmission.
マルチキャストクエリメッセージでは、送信時にクエリ識別子をゼロに設定する必要があります（SHOULD）。
In multicast responses, including unsolicited multicast responses, the Query Identifier MUST be set to zero on transmission, and MUST be ignored on reception.
非送信請求マルチキャスト応答を含むマルチキャスト応答では、クエリ識別子は送信時にゼロに設定する必要があり、受信時には無視する必要があります。
In legacy unicast response messages generated specifically in response to a particular (unicast or multicast) query, the Query Identifier MUST match the ID from the query message.
特定の（ユニキャストまたはマルチキャスト）クエリに応答して特別に生成されたレガシーユニキャスト応答メッセージでは、クエリ識別子はクエリメッセージのIDと一致する必要があります。
In query messages the QR bit MUST be zero. In response messages the QR bit MUST be one.
クエリメッセージでは、QRビットはゼロでなければなりません。応答メッセージでは、QRビットは1でなければなりません。
In both multicast query and multicast response messages, the OPCODE MUST be zero on transmission (only standard queries are currently supported over multicast). Multicast DNS messages received with an OPCODE other than zero MUST be silently ignored.
マルチキャストクエリメッセージとマルチキャストレスポンスメッセージの両方で、OPCODEは送信時にゼロでなければなりません（現在、マルチキャストでは標準クエリのみがサポートされています）。ゼロ以外のOPCODEで受信されたマルチキャストDNSメッセージは、黙って無視されなければなりません（MUST）。
In query messages, the Authoritative Answer bit MUST be zero on transmission, and MUST be ignored on reception.
クエリメッセージでは、Authoritative Answerビットは送信時にはゼロでなければならず、受信時には無視されなければなりません（MUST）。
In response messages for Multicast domains, the Authoritative Answer bit MUST be set to one (not setting this bit would imply there's some other place where "better" information may be found) and MUST be ignored on reception.
マルチキャストドメインの応答メッセージでは、Authoritative Answerビットを1に設定する必要があり（このビットを設定しないと、「より良い」情報が見つかる可能性がある他の場所があることを意味します）、受信時には無視する必要があります。
In query messages, if the TC bit is set, it means that additional Known-Answer records may be following shortly. A responder SHOULD record this fact, and wait for those additional Known-Answer records, before deciding whether to respond. If the TC bit is clear, it means that the querying host has no additional Known Answers.
クエリメッセージで、TCビットが設定されている場合、追加の既知の回答レコードが間もなく続く可能性があることを意味します。応答者は、この事実を記録し、応答するかどうかを決定する前に、それらの追加の既知回答レコードを待つ必要があります（SHOULD）。 TCビットがクリアされている場合は、クエリを実行しているホストに既知の回答がそれ以上ないことを意味します。
In multicast response messages, the TC bit MUST be zero on transmission, and MUST be ignored on reception.
マルチキャスト応答メッセージでは、TCビットは送信時にゼロでなければならず、受信時には無視されなければなりません（MUST）。
In legacy unicast response messages, the TC bit has the same meaning as in conventional Unicast DNS: it means that the response was too large to fit in a single packet, so the querier SHOULD reissue its query using TCP in order to receive the larger response.
レガシーユニキャスト応答メッセージでは、TCビットは従来のユニキャストDNSと同じ意味です。これは、応答が大きすぎて単一のパケットに収まらないことを意味します。そのため、クエリアは、より大きな応答を受信するために、TCPを使用してクエリを再発行する必要があります（SHOULD）。 。
In both multicast query and multicast response messages, the Recursion Desired bit SHOULD be zero on transmission, and MUST be ignored on reception.
マルチキャストクエリとマルチキャスト応答メッセージの両方で、再帰要求ビットは送信時にゼロである必要があり（SHOULD）、受信時に無視されなければなりません（MUST）。
In both multicast query and multicast response messages, the Recursion Available bit MUST be zero on transmission, and MUST be ignored on reception.
マルチキャストクエリメッセージとマルチキャスト応答メッセージの両方で、再帰利用可能ビットは送信時にゼロでなければならず、受信時には無視されなければなりません（MUST）。
In both query and response messages, the Zero bit MUST be zero on transmission, and MUST be ignored on reception.
クエリメッセージと応答メッセージの両方で、ゼロビットは送信時にゼロである必要があり、受信時には無視される必要があります。
In both multicast query and multicast response messages, the Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.
マルチキャストクエリメッセージとマルチキャスト応答メッセージの両方で、Authentic Dataビット[RFC2535]は送信時にゼロでなければならず、受信時には無視されなければなりません（MUST）。
In both multicast query and multicast response messages, the Checking Disabled bit [RFC2535] MUST be zero on transmission, and MUST be ignored on reception.
マルチキャストクエリとマルチキャスト応答メッセージの両方で、チェック無効ビット[RFC2535]は送信時にゼロでなければならず、受信時には無視されなければなりません（MUST）。
In both multicast query and multicast response messages, the Response Code MUST be zero on transmission. Multicast DNS messages received with non-zero Response Codes MUST be silently ignored.
マルチキャストクエリとマルチキャスト応答メッセージの両方で、応答コードは送信時にゼロでなければなりません。ゼロ以外の応答コードで受信されたマルチキャストDNSメッセージは、黙って無視されなければなりません（MUST）。
In the Question Section of a Multicast DNS query, the top bit of the qclass field is used to indicate that unicast responses are preferred for this particular question. (See Section 5.4.)
マルチキャストDNSクエリの質問セクションでは、qclassフィールドの最上位ビットを使用して、この特定の質問にユニキャスト応答が優先されることを示しています。 （5.4項を参照してください。）
In the Resource Record Sections of a Multicast DNS response, the top bit of the rrclass field is used to indicate that the record is a member of a unique RRSet, and the entire RRSet has been sent together (in the same packet, or in consecutive packets if there are too many records to fit in a single packet). (See Section 10.2.)
マルチキャストDNS応答のリソースレコードセクションでは、rrclassフィールドの最上位ビットを使用して、レコードが一意のRRSetのメンバーであり、RRSet全体が一緒に送信されました（同じパケットで、または連続して）レコードが多すぎて1つのパケットに収まらない場合）。 （セクション10.2を参照）
When generating Multicast DNS messages, implementations SHOULD use name compression wherever possible to compress the names of resource records, by replacing some or all of the resource record name with a compact two-byte reference to an appearance of that data somewhere earlier in the message [RFC1035].
マルチキャストDNSメッセージを生成するとき、実装は、リソースレコード名の一部またはすべてをメッセージ内のどこかにあるそのデータの外観へのコンパクトな2バイト参照に置き換えることにより、リソースレコードの名前を圧縮するために可能な限り名前圧縮を使用する必要があります[ RFC1035]。
This applies not only to Multicast DNS responses, but also to queries. When a query contains more than one question, successive questions in the same message often contain similar names, and consequently name compression SHOULD be used, to save bytes. In addition, queries may also contain Known Answers in the Answer Section, or probe tiebreaking data in the Authority Section, and these names SHOULD similarly be compressed for network efficiency.
これは、マルチキャストDNS応答だけでなく、クエリにも当てはまります。クエリに複数の質問が含まれている場合、同じメッセージ内の連続する質問には同様の名前が含まれていることが多いため、バイトを節約するために名前圧縮を使用する必要があります（SHOULD）。さらに、クエリにはAnswerセクションに既知の回答、Authorityセクションにプローブタイブレークデータが含まれる場合があり、これらの名前はネットワーク効率のために同様に圧縮する必要があります。
In addition to compressing the *names* of resource records, names that appear within the *rdata* of the following rrtypes SHOULD also be compressed in all Multicast DNS messages:
リソースレコードの*名前*を圧縮することに加えて、次のrrtypesの* rdata *内に現れる名前も、すべてのマルチキャストDNSメッセージで圧縮する必要があります。
NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
NS、CNAME、PTR、DNAME、SOA、MX、AFSDB、RT、KX、RP、PX、SRV、NSEC
Until future IETF Standards Action [RFC5226] specifying that names in the rdata of other types should be compressed, names that appear within the rdata of any type not listed above MUST NOT be compressed.
他のタイプのrdata内の名前を圧縮するように指定する将来のIETF標準アクション[RFC5226]まで、上記にリストされていないタイプのrdata内にある名前は圧縮してはなりません。
Implementations receiving Multicast DNS messages MUST correctly decode compressed names appearing in the Question Section, and compressed names of resource records appearing in other sections.
マルチキャストDNSメッセージを受信する実装は、質問セクションに表示される圧縮名と、他のセクションに表示されるリソースレコードの圧縮名を正しくデコードする必要があります。
In addition, implementations MUST correctly decode compressed names appearing within the *rdata* of the rrtypes listed above. Where possible, implementations SHOULD also correctly decode compressed names appearing within the *rdata* of other rrtypes known to the implementers at the time of implementation, because such forward-thinking planning helps facilitate the deployment of future implementations that may have reason to compress those rrtypes. It is possible that no future IETF Standards Action [RFC5226] will be created that mandates or permits the compression of rdata in new types, but having implementations designed such that they are capable of decompressing all known types helps keep future options open.
さらに、実装は、上記のrrtypeの* rdata *内にある圧縮名を正しくデコードする必要があります。可能な場合、実装は、実装時に実装者に知られている他のrrtypeの* rdata *内に現れる圧縮名も正しくデコードする必要があります。そのような前向きな計画は、それらのrrtypeを圧縮する理由があるかもしれない将来の実装の展開を容易にするためです。新しいタイプのrdataの圧縮を義務付けまたは許可する将来のIETF標準アクション[RFC5226]が作成されない可能性がありますが、既知のすべてのタイプを圧縮解除できるように設計された実装があると、将来のオプションを開いたままにできます。
One specific difference between Unicast DNS and Multicast DNS is that Unicast DNS does not allow name compression for the target host in an SRV record, because Unicast DNS implementations before the first SRV specification in 1996 [RFC2052] may not decode these compressed records properly. Since all Multicast DNS implementations were created after 1996, all Multicast DNS implementations are REQUIRED to decode compressed SRV records correctly.
ユニキャストDNSとマルチキャストDNSの特定の違いの1つは、1996年の最初のSRV仕様[RFC2052]より前のユニキャストDNSの実装では、これらの圧縮レコードが正しくデコードされない可能性があるため、ユニキャストDNSではSRVレコード内のターゲットホストの名前圧縮が許可されないことです。すべてのマルチキャストDNS実装は1996年以降に作成されたため、圧縮されたSRVレコードを正しくデコードするには、すべてのマルチキャストDNS実装が必要です。
In legacy unicast responses generated to answer legacy queries, name compression MUST NOT be performed on SRV records.
レガシークエリに応答するために生成されたレガシーユニキャスト応答では、SRVレコードに対して名前圧縮を実行してはなりません（MUST NOT）。
Multicast DNS shares, as much as possible, the familiar APIs, naming syntax, resource record types, etc., of Unicast DNS. There are, of course, necessary differences by virtue of it using multicast, and by virtue of it operating in a community of cooperating peers, rather than a precisely defined hierarchy controlled by a strict chain of formal delegations from the root. These differences are summarized below:
マルチキャストDNSは、ユニキャストDNSの使い慣れたAPI、ネーミング構文、リソースレコードタイプなどを可能な限り共有します。もちろん、ルートを使用した正式な委任の厳密なチェーンによって制御される正確に定義された階層ではなく、マルチキャストを使用することと、協力するピアのコミュニティで動作することにより、必要な違いがあります。これらの違いを以下にまとめます。
Multicast DNS... * uses multicast * uses UDP port 5353 instead of port 53 * operates in well-defined parts of the DNS namespace * has no SOA (Start of Authority) records * uses UTF-8, and only UTF-8, to encode resource record names * allows names up to 255 bytes plus a terminating zero byte * allows name compression in rdata for SRV and other record types * allows larger UDP packets * allows more than one question in a query message * defines consistent results for qtype "ANY" and qclass "ANY" queries * uses the Answer Section of a query to list Known Answers * uses the TC bit in a query to indicate additional Known Answers * uses the Authority Section of a query for probe tiebreaking * ignores the Query ID field (except for generating legacy responses) * doesn't require the question to be repeated in the response message * uses unsolicited responses to announce new records * uses NSEC records to signal nonexistence of records * defines a unicast-response bit in the rrclass of query questions * defines a cache-flush bit in the rrclass of response records * uses DNS RR TTL 0 to indicate that a record has been deleted * recommends AAAA records in the additional section when responding to rrtype "A" queries, and vice versa * monitors queries to perform Duplicate Question Suppression * monitors responses to perform Duplicate Answer Suppression... * ... and Ongoing Conflict Detection * ... and Opportunistic Caching
マルチキャストDNS ... *マルチキャストを使用*ポート53ではなくUDPポート5353を使用* DNS名前空間の明確に定義された部分で動作* SOA（Start of Authority）レコードがない* UTF-8を使用し、UTF-8のみを使用リソースレコード名をエンコードする* 255バイトまでの名前と終端のゼロバイトを許可する* SRVおよび他のレコードタイプのrdataで名前を圧縮できる*より大きなUDPパケットを許可する*クエリメッセージで複数の質問を許可する* qtypeの一貫した結果を定義する"ANY"およびqclass "ANY"クエリは*クエリの回答セクションを使用して既知の回答を一覧表示します*クエリのTCビットを使用して追加の既知の回答を示します*プローブタイブレークのためにクエリの権限セクションを使用します*クエリIDを無視しますフィールド（レガシー応答の生成を除く）*応答メッセージで質問を繰り返す必要はありません*未承諾の応答を使用して新しいレコードを通知します* NSECレコードを使用してレコードが存在しないことを通知します*のrrclassにユニキャスト応答ビットを定義しますクエリキューestions *応答レコードのrrclassにキャッシュフラッシュビットを定義します*レコードが削除されたことを示すためにDNS RR TTL 0を使用します* rrtype "A"クエリに応答するときに追加セクションでAAAAレコードを推奨し、逆も同様です*モニター重複質問抑制を実行するためのクエリ*重複回答抑制を実行するための応答を監視します... * ...および継続的な競合検出* ...および日和見キャッシュ
An IPv4-only host and an IPv6-only host behave as "ships that pass in the night". Even if they are on the same Ethernet, neither is aware of the other's traffic. For this reason, each physical link may have *two* unrelated ".local." zones, one for IPv4 and one for IPv6. Since for practical purposes, a group of IPv4-only hosts and a group of IPv6-only hosts on the same Ethernet act as if they were on two entirely separate Ethernet segments, it is unsurprising that their use of the ".local." zone should occur exactly as it would if they really were on two entirely separate Ethernet segments.
IPv4専用ホストとIPv6専用ホストは、「夜を過ごす船」として動作します。同じイーサネット上にあっても、どちらも相手のトラフィックを認識していません。このため、各物理リンクには* 2 *の無関係な「.local」が含まれる場合があります。 1つはIPv4用、もう1つはIPv6用です。実用上、同じイーサネット上のIPv4のみのホストのグループとIPv6のみのホストのグループは、2つのまったく別のイーサネットセグメント上にあるかのように動作するため、「。local」の使用は当然のことです。ゾーンは、2つの完全に別個のイーサネットセグメントに実際に存在する場合とまったく同じように発生する必要があります。
A dual-stack (v4/v6) host can participate in both ".local." zones, and should register its name(s) and perform its lookups both using IPv4 and IPv6. This enables it to reach, and be reached by, both IPv4-only and IPv6-only hosts. In effect, this acts like a multihomed host, with one connection to the logical "IPv4 Ethernet segment", and a connection to the logical "IPv6 Ethernet segment". When such a host generates NSEC records, if it is using the same host name for its IPv4 addresses and its IPv6 addresses on that network interface, its NSEC records should indicate that the host name has both A and AAAA records.
デュアルスタック（v4 / v6）ホストは、両方の「.local」に参加できます。ゾーン、およびその名前を登録し、IPv4とIPv6の両方を使用してルックアップを実行する必要があります。これにより、IPv4のみのホストとIPv6のみのホストの両方に到達し、到達できるようになります。実際、これは論理「IPv4イーサネットセグメント」への1つの接続と論理「IPv6イーサネットセグメント」への接続を備えたマルチホームホストのように機能します。そのようなホストがNSECレコードを生成するとき、そのネットワークインターフェイスでIPv4アドレスとIPv6アドレスに同じホスト名を使用している場合、そのNSECレコードは、ホスト名にAレコードとAAAAレコードの両方があることを示す必要があります。
The algorithm for detecting and resolving name conflicts is, by its very nature, an algorithm that assumes cooperating participants. Its purpose is to allow a group of hosts to arrive at a mutually disjoint set of host names and other DNS resource record names, in the absence of any central authority to coordinate this or mediate disputes. In the absence of any higher authority to resolve disputes, the only alternative is that the participants must work together cooperatively to arrive at a resolution.
名前の競合を検出して解決するアルゴリズムは、その性質上、協力する参加者を想定するアルゴリズムです。その目的は、ホストのグループが相互にばらばらのホスト名と他のDNSリソースレコード名のセットに到達できるようにすることです。紛争を解決するためのより高い権限がない場合、唯一の代替策は、参加者が協力して協力して解決に至る必要があることです。
In an environment where the participants are mutually antagonistic and unwilling to cooperate, other mechanisms are appropriate, like manually configured DNS.
参加者が互いに敵対的で協力を望まない環境では、手動で構成されたDNSなどの他のメカニズムが適切です。
In an environment where there is a group of cooperating participants, but clients cannot be sure that there are no antagonistic hosts on the same physical link, the cooperating participants need to use IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can distinguish Multicast DNS messages from trusted participants (which they process as usual) from Multicast DNS messages from untrusted participants (which they silently discard).
協力する参加者のグループが存在するが、クライアントが同じ物理リンクに敵対的なホストがないことを確認できない環境では、協力する参加者は、IPsec署名またはDNSSEC [RFC4033]署名を使用して、それらを区別できるようにする必要があります。信頼できる参加者からのマルチキャストDNSメッセージ（通常どおりに処理します）から、信頼できない参加者からのマルチキャストDNSメッセージ（黙って破棄します）。
If DNS queries for *global* DNS names are sent to the mDNS multicast address (during network outages which disrupt communication with the greater Internet) it is *especially* important to use DNSSEC, because the user may have the impression that he or she is communicating with some authentic host, when in fact he or she is really communicating with some local host that is merely masquerading as that name. This is less critical for names ending with ".local.", because the user should be aware that those names have only local significance and no global authority is implied.
*グローバル* DNS名のDNSクエリがmDNSマルチキャストアドレスに送信される場合（ネットワークの停止中に大規模なインターネットとの通信が中断される場合）、ユーザーは自分がそうであるという印象を持つ可能性があるため、DNSSECを使用することは特に重要です。実際に彼または彼女が実際にその名前を装ったローカルホストと実際に通信しているときに、本物のホストと通信している。 「.local。」で終わる名前の場合、これはそれほど重要ではありません。ユーザーはこれらの名前はローカルでのみ意味があり、グローバルな権限は含まれていないことに注意する必要があるためです。
Most computer users neglect to type the trailing dot at the end of a fully qualified domain name, making it a relative domain name (e.g., "www.example.com"). In the event of network outage, attempts to positively resolve the name as entered will fail, resulting in application of the search list, including ".local.", if present. A malicious host could masquerade as "www.example.com." by answering the resulting Multicast DNS query for "www.example.com.local.". To avoid this, a host MUST NOT append the search suffix ".local.", if present, to any relative (partially qualified) host name containing two or more labels. Appending ".local." to single-label relative host names is acceptable, since the user should have no expectation that a single-label host name will resolve as is. However, users who have both "example.com" and "local" in their search lists should be aware that if they type "www" into their web browser, it may not be immediately clear to them whether the page that appears is "www.example.com" or "www.local".
ほとんどのコンピューターユーザーは、完全修飾ドメイン名の末尾に末尾のドットを入力して、それを相対ドメイン名（「www.example.com」など）にすることを怠っています。ネットワーク障害が発生した場合、入力された名前を積極的に解決しようとすると失敗し、 "。local。"（存在する場合）を含む検索リストが適用されます。悪意のあるホストが「www.example.com」になりすます可能性があります。結果の「www.example.com.local。」のマルチキャストDNSクエリに回答します。これを回避するために、ホストは、検索接尾辞「.local。」が存在する場合、2つ以上のラベルを含む相対（部分修飾）ホスト名に追加してはなりません（MUST NOT）。 「.local。」を追加します単一ラベルの相対ホスト名への変換は許容されます。ユーザーは、単一ラベルのホスト名がそのまま解決されることを期待してはならないからです。ただし、検索リストに「example.com」と「local」の両方があるユーザーは、Webブラウザーに「www」と入力した場合、表示されるページが「www」であるかどうかがすぐにわかりにくい場合があることに注意してください。 .example.com」または「www.local」。
Multicast DNS uses UDP port 5353. On operating systems where only privileged processes are allowed to use ports below 1024, no such privilege is required to use port 5353.
マルチキャストDNSはUDPポート5353を使用します。特権プロセスのみが1024未満のポートの使用を許可されているオペレーティングシステムでは、ポート5353を使用するためにそのような特権は必要ありません。
IANA has allocated the UDP port 5353 for the Multicast DNS protocol described in this document [SN].
IANAは、このドキュメントで説明されているマルチキャストDNSプロトコル[SN]にUDPポート5353を割り当てています。
IANA has allocated the IPv4 link-local multicast address 224.0.0.251 for the use described in this document [MC4].
IANAは、このドキュメント[MC4]で説明されている使用のために、IPv4リンクローカルマルチキャストアドレス224.0.0.251を割り当てています。
IANA has allocated the IPv6 multicast address set FF0X::FB (where "X" indicates any hexadecimal digit from '1' to 'F') for the use described in this document [MC6]. Only address FF02::FB (link-local scope) is currently in use by deployed software, but it is possible that in the future implementers may experiment with Multicast DNS using larger-scoped addresses, such as FF05::FB (site-local scope) [RFC4291].
IANAは、このドキュメント[MC6]で説明されている使用のために、IPv6マルチキャストアドレスセットFF0X :: FB（「X」は「1」から「F」までの任意の16進数字を示します）を割り当てました。アドレスFF02 :: FB（リンクローカルスコープ）のみが現在展開されているソフトウェアで使用されていますが、将来的に実装者はFF05 :: FB（サイトローカルスコープ）[RFC4291]。
IANA has implemented the following DNS records:
IANAは次のDNSレコードを実装しています。
MDNS.MCAST.NET. IN A 224.0.0.251 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.
MDNS.MCAST.NET。 IN A 224.0.0.251 251.0.0.224.IN-ADDR.ARPA。 PTR MDNS.MCAST.NET。
Entries for the AAAA and corresponding PTR records have not been made as there is not yet an RFC providing direction for the management of the IP6.ARPA domain relating to the IPv6 multicast address space.
IPv6マルチキャストアドレススペースに関連するIP6.ARPAドメインの管理に関する指示を提供するRFCがないため、AAAAおよび対応するPTRレコードのエントリは作成されていません。
The reuse of the top bit of the rrclass field in the Question and Resource Record Sections means that Multicast DNS can only carry DNS records with classes in the range 0-32767. Classes in the range 32768 to 65535 are incompatible with Multicast DNS. IANA has noted this fact, and if IANA receives a request to allocate a DNS class value above 32767, IANA will make sure the requester is aware of this implication before proceeding. This does not mean that allocations of DNS class values above 32767 should be denied, only that they should not be allowed until the requester has indicated that they are aware of how this allocation will interact with Multicast DNS. However, to date, only three DNS classes have been assigned by IANA (1, 3, and 4), and only one (1, "Internet") is actually in widespread use, so this issue is likely to remain a purely theoretical one.
質問およびリソースレコードセクションのrrclassフィールドの最上位ビットを再利用するということは、マルチキャストDNSは0〜32767の範囲のクラスを持つDNSレコードのみを伝送できることを意味します。 32768〜65535の範囲のクラスは、マルチキャストDNSと互換性がありません。 IANAはこの事実を指摘しており、IANAが32767を超えるDNSクラス値を割り当てる要求を受け取った場合、IANAは続行する前に要求者がこの影響を認識していることを確認します。これは、32767を超えるDNSクラス値の割り当てを拒否する必要があることを意味するのではなく、要求者がこの割り当てがマルチキャストDNSとどのように相互作用するかを認識していることを示すまで、それらを許可しないようにする必要があります。ただし、これまでのところ、IANAによって割り当てられているDNSクラスは3つ（1、3、4）であり、実際に広く使用されているのは1つ（1、「インターネット」）のみであるため、この問題は純粋に理論上の問題のままであると考えられます。 。
IANA has recorded the list of domains below as being Special-Use Domain Names [RFC6761]:
IANAは、以下のドメインのリストを特殊用途ドメイン名[RFC6761]として記録しています。
.local. .254.169.in-addr.arpa. .8.e.f.ip6.arpa. .9.e.f.ip6.arpa. .a.e.f.ip6.arpa. .b.e.f.ip6.arpa.
。地元。 .254.169.in-addr.arpa。 .8.e.f.ip6.arpa。 .9.e.f.ip6.arpa。 .a.e.f.ip6.arpa。 .b.e.f.ip6.arpa。
The six domains listed above, and any names falling within those domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.", "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the following ways:
上記の6つのドメイン、およびそれらのドメインに含まれる名前（「MyPrinter.local。」、「34.12.254.169.in-addr.arpa。」、「Ink-Jet._pdl-datastream._tcp.local。」など） ）は、次の点で特別な[RFC6761]です。
1. Users may use these names as they would other DNS names, entering them anywhere that they would otherwise enter a conventional DNS name, or a dotted decimal IPv4 address, or a literal IPv6 address.
1. ユーザーは、他のDNS名と同じようにこれらの名前を使用し、従来のDNS名、またはドット10進IPv4アドレス、またはリテラルIPv6アドレスを入力する場所にそれらを入力できます。
Since there is no central authority responsible for assigning dot-local names, and all devices on the local network are equally entitled to claim any dot-local name, users SHOULD be aware of this and SHOULD exercise appropriate caution. In an untrusted or unfamiliar network environment, users SHOULD be aware that using a name like "www.local" may not actually connect them to the web site they expected, and could easily connect them to a different web page, or even a fake or spoof of their intended web site, designed to trick them into revealing confidential information. As always with networking, end-to-end cryptographic security can be a useful tool. For example, when connecting with ssh, the ssh host key verification process will inform the user if it detects that the identity of the entity they are communicating with has changed since the last time they connected to that name.
ドットローカル名の割り当てを担当する中央の権限はなく、ローカルネットワーク上のすべてのデバイスは、ドットローカル名を要求する権利が等しく与えられているため、ユーザーはこれに注意し、適切な注意を払う必要があります。信頼できない、またはなじみのないネットワーク環境では、ユーザーは、「www.local」のような名前を使用しても、実際には期待したWebサイトに接続できない場合があり、別のWebページに簡単に接続したり、偽物や意図したWebサイトのなりすまし。それらをだまして機密情報を漏らすように設計されています。いつものように、ネットワーキングと同様に、エンドツーエンドの暗号化セキュリティは便利なツールです。たとえば、sshを使用して接続する場合、sshホストキー検証プロセスは、ユーザーが通信しているエンティティのIDがその名前に最後に接続してから変更されていることを検出すると、ユーザーに通知します。
2. Application software may use these names as they would other similar DNS names, and is not required to recognize the names and treat them specially. Due to the relative ease of spoofing dot-local names, end-to-end cryptographic security remains important when communicating across a local network, just as it is when communicating across the global Internet.
2. アプリケーションソフトウェアは、他の同様のDNS名と同じようにこれらの名前を使用でき、名前を認識して特別に処理する必要はありません。ドットローカル名のスプーフィングは比較的容易であるため、ローカルネットワークを介して通信する場合も、グローバルインターネットを介して通信する場合と同様に、エンドツーエンドの暗号化セキュリティが重要です。
3. Name resolution APIs and libraries SHOULD recognize these names as special and SHOULD NOT send queries for these names to their configured (unicast) caching DNS server(s). This is to avoid unnecessary load on the root name servers and other name servers, caused by queries for which those name servers do not have useful non-negative answers to give, and will not ever have useful non-negative answers to give.
3. 名前解決APIとライブラリは、これらの名前を特別なものとして認識し（SHOULD）、これらの名前のクエリを構成済み（ユニキャスト）キャッシングDNSサーバーに送信しないでください（SHOULD NOT）。これは、ルートネームサーバーや他のネームサーバーに不必要な負荷がかかるのを防ぐためです。これらのネームサーバーが提供する有用な非否定的回答を持たず、有用な非否定的回答も提供されないクエリが原因です。
4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries they may receive (from misbehaving name resolver libraries). This is to avoid unnecessary load on the root name servers and other name servers.
4. キャッシングDNSサーバーは、これらの名前を特別なものとして認識すべきであり（SHOULD）、それらのNSレコードを検索しようとしないでください。そうでなければ、これらの名前を解決するために権威DNSサーバーにクエリを実行しないでください。代わりに、DNSサーバーのキャッシュは、（名前リゾルバーライブラリの誤動作から）受信する可能性があるすべてのクエリに対して、即時のNXDOMAIN応答を生成する必要があります（SHOULD）。これは、ルートネームサーバーや他のネームサーバーに不要な負荷がかかるのを避けるためです。
5. Authoritative DNS servers SHOULD NOT by default be configurable to answer queries for these names, and, like caching DNS servers, SHOULD generate immediate NXDOMAIN responses for all such queries they may receive. DNS server software MAY provide a configuration option to override this default, for testing purposes or other specialized uses.
5. 権限のあるDNSサーバーは、これらの名前のクエリに応答するようにデフォルトで設定可能であるべきではなく（SHOULD）、DNSサーバーのキャッシュと同様に、受信する可能性のあるすべてのクエリに対して即時のNXDOMAIN応答を生成する必要があります。 DNSサーバーソフトウェアは、テストやその他の特殊な用途のために、このデフォルトを上書きする構成オプションを提供する場合があります。
6. DNS server operators SHOULD NOT attempt to configure authoritative DNS servers to act as authoritative for any of these names. Configuring an authoritative DNS server to act as authoritative for any of these names may not, in many cases, yield the expected result. Since name resolver libraries and caching DNS servers SHOULD NOT send queries for those names (see 3 and 4 above), such queries SHOULD be suppressed before they even reach the authoritative DNS server in question, and consequently it will not even get an opportunity to answer them.
6. DNSサーバーオペレーターは、これらの名前のいずれかに対して信頼できるものとして機能するように、信頼できるDNSサーバーを構成することはできません。これらの名前のいずれかに対して信頼できるものとして機能するように信頼できるDNSサーバーを構成すると、多くの場合、期待される結果が得られないことがあります。名前リゾルバーライブラリとキャッシュDNSサーバーはこれらの名前のクエリを送信してはならないため（上記の3および4を参照）、そのようなクエリは、問題の権威あるDNSサーバーに到達する前に抑制すべきであり、その結果、回答する機会すら得られません。それら。
7. DNS Registrars MUST NOT allow any of these names to be registered in the normal way to any person or entity. These names are reserved protocol identifiers with special meaning and fall outside the set of names available for allocation by registrars. Attempting to allocate one of these names as if it were a normal domain name will probably not work as desired, for reasons 3, 4, and 6 above.
7. DNSレジストラは、これらの名前を通常の方法で個人またはエンティティに登録することを許可してはなりません。これらの名前は特別な意味を持つ予約済みのプロトコル識別子であり、レジストラによる割り当てに使用できる名前のセットの範囲外です。上記の3、4、6の理由により、これらの名前の1つを通常のドメイン名のように割り当てようとしても、おそらく期待どおりに機能しません。
The concepts described in this document have been explored, developed, and implemented with help from Ran Atkinson, Richard Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti, Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill Woodcock, and others. Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren Sekar for their significant contributions. Special thanks also to Kerry Lynn for converting the document to xml2rfc form in May 2010, and to Area Director Ralph Droms for shepherding the document through its final steps.
このドキュメントで説明されている概念は、Ran Atkinson、Richard Brown、Freek Dijkstra、Erik Guttman、Kyle McKay、Pasi Sarolahti、Pekka Savola、Robby Simpson、Mark Townsley、Paul Vixie、Bill Woodcockの助けを借りて調査、開発、実装されました。その他。 Bob Bradley、Josh Graessley、Scott Herscher、Rory McGuire、Roger Pantos、Kiren Sekarの多大な貢献に特に感謝します。 2010年5月にドキュメントをxml2rfc形式に変換してくれたKerry Lynnと、ドキュメントの最終ステップを実行してくれたエリアディレクターのRalph Dromsにも特に感謝します。
[MC4] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses/>.
[MC4] IANA、「IPv4 Multicast Address Space Registry」、<http://www.iana.org/assignments/multicast-addresses/>。
[MC6] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ ipv6-multicast-addresses/>.
[MC6] IANA、「IPv6マルチキャストアドレススペースレジストリ」、<http://www.iana.org/assignments/ ipv6-multicast-addresses />。
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC0020] Cerf、V。、「ネットワーク交換用のASCII形式」、RFC 20、1969年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、2005年3月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、2008年3月。
[RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6195, March 2011.
[RFC6195] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6195、2011年3月。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, February 2013.
[RFC6761] Cheshire、S。およびM. Krochmal、「特別用途ドメイン名」、RFC 6761、2013年2月。
[SN] IANA, "Service Name and Transport Protocol Port Number Registry", <http://www.iana.org/assignments/ service-names-port-numbers/>.
[SN] IANA、「Service Name and Transport Protocol Port Number Registry」、<http://www.iana.org/assignments/ service-names-port-numbers />。
[B4W] "Bonjour for Windows", <http://en.wikipedia.org/wiki/Bonjour_(software)>.
[B4W]「Bonjour for Windows」、<http://en.wikipedia.org/wiki/Bonjour_（software）>。
[BJ] Apple Bonjour Open Source Software, <http://developer.apple.com/bonjour/>.
[BJ] Apple Bonjourオープンソースソフトウェア、<http://developer.apple.com/bonjour/>。
[IEEE.802.3] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier Sense Multiple Access with Collision Detection (CMSA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008, <http://standards.ieee.org/getieee802/802.3.html>.
[IEEE.802.3]「情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート3：衝突検出（CMSA / CD）アクセス方法と物理層仕様のキャリアセンスマルチアクセス」、IEEE標準802.3-2008、2008年12月、<http://standards.ieee.org/getieee802/802.3.html>。
[IEEE.802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std 802.11-2007, June 2007, <http://standards.ieee.org/getieee802/802.11.html>.
[IEEE.802.11]「情報技術-システム間のテレコミュニケーションおよび情報交換-ローカルおよびメトロポリタンエリアネットワーク-特定の要件-パート11：ワイヤレスLAN媒体アクセス制御（MAC）および物理層（PHY）仕様」、IEEE Std 802.11-2007 、2007年6月、<http://standards.ieee.org/getieee802/802.11.html>。
[Jumbo] "Ethernet Jumbo Frames", November 2009, <http://www.ethernetalliance.org/library/whitepaper/ ethernet-jumbo-frames/>.
[ジャンボ]「イーサネットジャンボフレーム」、2009年11月、<http://www.ethernetalliance.org/library/whitepaper/ethernet-jumbo-frames/>。
[NIAS] Cheshire, S. "Discovering Named Instances of Abstract Services using DNS", Work in Progress, July 2001.
[NIAS]チェシャーS.「DNSを使用した抽象サービスの名前付きインスタンスの発見」、進行中の作業、2001年7月。
[NSD] "NsdManager | Android Developer", June 2012, <http://developer.android.com/reference/ android/net/nsd/NsdManager.html>.
[NSD]「NsdManager | Android Developer」、2012年6月、<http://developer.android.com/reference/ android / net / nsd / NsdManager.html>。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052] Gulbrandsen、A。およびP. Vixie、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2052、1996年10月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Ed。、Thomson、S.、Rekhter、Y.、and J. Bound、 "Dynamic Updates in the Domain Name System（DNS UPDATE）"、RFC 2136、April 1997。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、1997年7月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake 3rd、D。、「ドメインネームシステムセキュリティ拡張機能」、RFC 2535、1999年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の秘密鍵トランザクション認証（TSIG）」、RFC 2845、2000年5月。
[RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY RR)", RFC 2930, September 2000.
[RFC2930] Eastlake 3rd、D。、「DNSの秘密鍵の確立（TKEY RR）」、RFC 2930、2000年9月。
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000.
[RFC2931] Eastlake 3rd、D。、「DNS Request and Transaction Signatures（SIG（0）s）」、RFC 2931、2000年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492] Costello、A。、「Punycode：A Bootstring encoding for Unicode for Internationalized Domain Names in Applications（IDNA）」、RFC 3492、2003年3月。
[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リンクローカルアドレスの動的構成」、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月。
[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月。
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[RFC4795] Aboba、B.、Thaler、D。、およびL. Esibov、「Link-local Multicast Name Resolution（LLMNR）」、RFC 4795、2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R。、およびL. Zhang、「Understanding Apple's Back to My Mac（BTMM）Service」、RFC 6281、2011年6月。
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, February 2013.
[RFC6760] Cheshire、S。、およびM. Krochmal、「AppleTalk Name Binding Protocol（NBP）を置き換えるプロトコルの要件」、RFC 6760、2013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration Networking: The Definitive Guide", O'Reilly Media, Inc., ISBN 0-596-10100-7, December 2005.
[Zeroconf] Cheshire、S.およびD. Steinberg、「Zero Configuration Networking：The Definitive Guide」、O'Reilly Media、Inc.、ISBN 0-596-10100-7、2005年12月。
Arguments were made for and against using UDP port 53, the standard Unicast DNS port. Some of the arguments are given below. The arguments for using a different port were greater in number and more compelling, so that option was ultimately selected. The UDP port "5353" was selected for its mnemonic similarity to "53".
標準のユニキャストDNSポートであるUDPポート53の使用について賛否両論がありました。引数のいくつかを以下に示します。別のポートを使用することについての議論は数が多く、より説得力があったので、そのオプションが最終的に選択されました。 UDPポート「5353」は、「53」とのニーモニックな類似性のために選択されました。
Arguments for using UDP port 53:
UDPポート53を使用するための引数：
* This is "just DNS", so it should be the same port.
* これは「単なるDNS」なので、同じポートにする必要があります。
* There is less work to be done updating old resolver libraries to do simple Multicast DNS queries. Only the destination address need be changed. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251 to a configuration file.
* シンプルなマルチキャストDNSクエリを実行するために古いリゾルバライブラリを更新するために実行する必要のある作業が少なくなります。宛先アドレスのみを変更する必要があります。場合によっては、コードを変更せずに、アドレス224.0.0.251を構成ファイルに追加するだけでこれを実現できます。
Arguments for using a different port (UDP port 5353):
別のポート（UDPポート5353）を使用するための引数：
* This is not "just DNS". This is a DNS-like protocol, but different.
* これは「単なるDNS」ではありません。これはDNSのようなプロトコルですが、異なります。
* Changing resolver library code to use a different port number is not hard. In some cases, this can be achieved without any code changes, just by adding the address 224.0.0.251:5353 to a configuration file.
* 別のポート番号を使用するようにリゾルバーライブラリコードを変更することは難しくありません。場合によっては、コードを変更せずに、アドレス224.0.0.251:5353を構成ファイルに追加するだけでこれを実現できます。
* Using the same port number makes it hard to run a Multicast DNS responder and a conventional Unicast DNS server on the same machine. If a conventional Unicast DNS server wishes to implement Multicast DNS as well, it can still do that, by opening two sockets. Having two different port numbers allows this flexibility.
* 同じポート番号を使用すると、マルチキャストDNSレスポンダと従来のユニキャストDNSサーバーを同じマシンで実行することが難しくなります。従来のユニキャストDNSサーバーがマルチキャストDNSも実装したい場合でも、2つのソケットを開くことでそれを行うことができます。 2つの異なるポート番号を使用すると、この柔軟性が得られます。
* Some VPN software hijacks all outgoing traffic to port 53 and redirects it to a special DNS server set up to serve those VPN clients while they are connected to the corporate network. It is questionable whether this is the right thing to do, but it is common, and redirecting link-local multicast DNS packets to a remote server rarely produces any useful results. It does mean, for example, that a user of such VPN software becomes unable to access their local network printer sitting on their desk right next to their computer. Using a different UDP port helps avoid this particular problem.
* 一部のVPNソフトウェアは、すべての発信トラフィックをポート53に乗っ取り、企業ネットワークに接続されているVPNクライアントにサービスを提供するように設定された特別なDNSサーバーにリダイレクトします。これが正しいことかどうかは疑問ですが、一般的であり、リンクローカルマルチキャストDNSパケットをリモートサーバーにリダイレクトしても、有用な結果が得られることはほとんどありません。たとえば、そのようなVPNソフトウェアのユーザーが、自分のコンピューターのすぐ隣の机に座っているローカルネットワークプリンターにアクセスできなくなることを意味します。別のUDPポートを使用すると、この特定の問題を回避できます。
* On many operating systems, unprivileged software may not send or receive packets on low-numbered ports. This means that any software sending or receiving Multicast DNS packets on port 53 would have to run as "root", which is an undesirable security risk. Using a higher-numbered UDP port avoids this restriction.
* 多くのオペレーティングシステムでは、権限のないソフトウェアが小さい番号のポートでパケットを送受信できない場合があります。つまり、ポート53でマルチキャストDNSパケットを送受信するソフトウェアは、「ルート」として実行する必要があります。これは、望ましくないセキュリティリスクです。大きい番号のUDPポートを使用すると、この制限を回避できます。
Some discovery protocols use a range of multicast addresses, and determine the address to be used by a hash function of the name being sought. Queries are sent via multicast to the address as indicated by the hash function, and responses are returned to the querier via unicast. Particularly in IPv6, where multicast addresses are extremely plentiful, this approach is frequently advocated. For example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor Solicitation messages to the "solicited-node multicast address", which is computed as a function of the solicited IPv6 address.
一部の検出プロトコルは、一連のマルチキャストアドレスを使用し、検索する名前のハッシュ関数が使用するアドレスを決定します。クエリはハッシュ関数で示されるアドレスにマルチキャストで送信され、応答はユニキャストでクエリアに返されます。特にマルチキャストアドレスが非常に豊富なIPv6では、このアプローチが頻繁に推奨されます。たとえば、IPv6近隣探索[RFC4861]は、要請されたIPv6アドレスの関数として計算される「要請ノードマルチキャストアドレス」に近隣要請メッセージを送信します。
There are some disadvantages to using hashed multicast addresses like this in a service discovery protocol:
このようなハッシュされたマルチキャストアドレスをサービス検出プロトコルで使用することには、いくつかの欠点があります。
* When a host has a large number of records with different names, the host may have to join a large number of multicast groups. Each time a host joins or leaves a multicast group, this results in Internet Group Management Protocol (IGMP) or Multicast Listener Discovery (MLD) traffic on the network announcing this fact. Joining a large number of multicast groups can place undue burden on the Ethernet hardware, which typically supports a limited number of multicast addresses efficiently. When this number is exceeded, the Ethernet hardware may have to resort to receiving all multicasts and passing them up to the host networking code for filtering in software, thereby defeating much of the point of using a multicast address range in the first place. Finally, many IPv6 stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply fails with an error if a client attempts to exceed this limit. Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
* ホストに異なる名前の多数のレコードがある場合、ホストは多数のマルチキャストグループに参加する必要がある場合があります。ホストがマルチキャストグループに参加または脱退するたびに、ネットワーク上のインターネットグループ管理プロトコル（IGMP）またはマルチキャストリスナーディスカバリ（MLD）トラフィックが発生し、この事実が通知されます。多数のマルチキャストグループに参加すると、通常は限られた数のマルチキャストアドレスを効率的にサポートするイーサネットハードウェアに過度の負担がかかります。この数を超えると、イーサネットハードウェアはすべてのマルチキャストを受信し、ソフトウェアでフィルタリングするためにそれらをホストネットワークコードに渡す必要があるため、そもそもマルチキャストアドレス範囲を使用するポイントの多くを打ち負かす必要があります。最後に、多くのIPv6スタックには固定の制限IPV6_MAX_MEMBERSHIPSがあり、クライアントがこの制限を超えようとすると、コードは単にエラーで失敗します。 IPV6_MAX_MEMBERSHIPSの一般的な値は20または31です。
* Multiple questions cannot be placed in one packet if they don't all hash to the same multicast address.
* すべてが同じマルチキャストアドレスにハッシュしない場合、複数の質問を1つのパケットに入れることはできません。
* Duplicate Question Suppression doesn't work if queriers are not seeing each other's queries.
* クエリアが互いのクエリを表示していない場合、重複質問抑制は機能しません。
* Duplicate Answer Suppression doesn't work if responders are not seeing each other's responses.
* 応答者がお互いの応答を見ない場合、重複回答抑制は機能しません。
* Opportunistic Caching doesn't work.
* Opportunistic Cachingが機能しません。
* Ongoing Conflict Detection doesn't work.
* 継続的な競合検出が機能しません。
Multicast DNS names may be up to 255 bytes long (in the on-the-wire message format), not counting the terminating zero byte at the end.
マルチキャストDNS名の長さは最大255バイト（オンザワイヤーメッセージ形式）であり、最後の終端のゼロバイトはカウントされません。
"Domain Names - Implementation and Specification" [RFC1035] says:
「ドメイン名-実装と仕様」[RFC1035]はこう述べています：
Various objects and parameters in the DNS have size limits. They are listed below. Some could be easily changed, others are more fundamental.
DNSのさまざまなオブジェクトとパラメータにはサイズ制限があります。それらを以下に示します。簡単に変更できるものもあれば、より根本的なものもあります。
labels 63 octets or less
63オクテット以下のラベル
names 255 octets or less
255オクテット以下の名前
...
。。。
the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
ドメイン名の全長（つまり、ラベルオクテットとラベル長オクテット）は、255オクテット以下に制限されています。
This text does not state whether this 255-byte limit includes the terminating zero at the end of every name.
このテキストには、この255バイトの制限に、すべての名前の末尾に終了ゼロが含まれているかどうかは示されていません。
Several factors lead us to conclude that the 255-byte limit does *not* include the terminating zero:
いくつかの要因により、255バイトの制限には終端のゼロが*含まれない*と結論付けられます。
o It is common in software engineering to have size limits that are a power of two, or a multiple of a power of two, for efficiency. For example, an integer on a modern processor is typically 2, 4, or 8 bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor is it to most people a particularly noteworthy number. It is noteworthy to computer scientists for only one reason -- because it is exactly one *less* than a power of two. When a size limit is exactly one less than a power of two, that suggests strongly that the one extra byte is being reserved for some specific reason -- in this case reserved, perhaps, to leave room for a terminating zero at the end.
o ソフトウェアエンジニアリングでは、効率を上げるために、2の累乗、または2の累乗の倍数のサイズ制限があるのが一般的です。たとえば、最近のプロセッサの整数は通常2、4、または8バイトであり、3または5バイトではありません。 255という数値は2の累乗ではなく、ほとんどの人にとって特に注目に値する数値でもありません。これは、1つの理由だけでコンピュータサイエンティストにとって注目に値します。これは、2の累乗よりも1つ少ない*少ない*ためです。サイズ制限が2の累乗より1だけ小さい場合、特定の理由でこの1バイトが予約されていることを強く示唆しています。この場合は、最後に終端のゼロの余地を残すために予約されています。
o In the case of DNS label lengths, the stated limit is 63 bytes. As with the total name length, this limit is exactly one less than a power of two. This label length limit also excludes the label length byte at the start of every label. Including that extra byte, a 63-byte label takes 64 bytes of space in memory or in a DNS message.
o DNSラベル長の場合、制限は63バイトです。名前の長さの合計と同様に、この制限は2の累乗よりも1つ少なくなります。このラベルの長さの制限により、すべてのラベルの先頭にあるラベルの長さバイトも除外されます。その余分なバイトを含めて、63バイトのラベルは、メモリまたはDNSメッセージ内で64バイトのスペースを取ります。
o It is common in software engineering for the semantic "length" of an object to be one less than the number of bytes it takes to store that object. For example, in C, strlen("foo") is 3, but sizeof("foo") (which includes the terminating zero byte at the end) is 4.
o ソフトウェアエンジニアリングでは、オブジェクトのセマンティックな「長さ」が、そのオブジェクトを格納するのに必要なバイト数よりも1つ少ないことが一般的です。たとえば、Cでは、strlen（ "foo"）は3ですが、sizeof（ "foo"）（末尾に終了ゼロバイトを含む）は4です。
o The text describing the total length of a domain name mentions explicitly that label length and data octets are included, but does not mention the terminating zero at the end. The zero byte at the end of a domain name is not a label length. Indeed, the value zero is chosen as the terminating marker precisely because it is not a legal length byte value -- DNS prohibits empty labels. For example, a name like "bad..name." is not a valid domain name because it contains a zero-length label in the middle, which cannot be expressed in a DNS message, because software parsing the message would misinterpret a zero label-length byte as being a zero "end of name" marker instead.
o ドメイン名の全長を説明するテキストは、ラベル長とデータオクテットが含まれていることを明示的に述べていますが、最後の終端のゼロについては触れていません。ドメイン名の最後のゼロバイトは、ラベルの長さではありません。実際、ゼロという値は、正当な長さバイト値ではないため、終了マーカーとして正確に選択されます。DNSは空のラベルを禁止します。たとえば、「bad..name」のような名前。中央に長さ0のラベルが含まれ、DNSメッセージでは表現できないため、有効なドメイン名ではありません。これは、メッセージを解析するソフトウェアが、ラベルの長さ0のバイトを「名前の終わり」マーカー0と誤って解釈するためです。代わりに。
Finally, "Clarifications to the DNS Specification" [RFC2181] offers additional confirmation that, in the context of DNS specifications, the stated "length" of a domain name does not include the terminating zero byte at the end. That document refers to the root name, which is typically written as "." and is represented in a DNS message by a single lone zero byte (i.e., zero bytes of data plus a terminating zero), as the "zero length full name":
最後に、「DNS仕様の明確化」[RFC2181]は、DNS仕様のコンテキストでは、ドメイン名の「長さ」に末尾のゼロバイトが含まれていないという追加の確認を提供します。そのドキュメントは、通常「。」と書かれているルート名を参照しています。 DNSメッセージでは、単一の単一のゼロバイト（つまり、データのゼロバイトと終端のゼロ）で、「ゼロ長の完全な名前」として表されます。
The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".".
長さ0のフルネームは、DNSツリーのルートを表すものとして定義され、通常は「。」として記述および表示されます。
This wording supports the interpretation that, in a DNS context, when talking about lengths of names, the terminating zero byte at the end is not counted. If the root name (".") is considered to be zero length, then to be consistent, the length (for example) of "org" has to be 4 and the length of "ietf.org" has to be 9, as shown below:
この表現は、DNSコンテキストでは、名前の長さについて話すとき、末尾のゼロの終わりのバイトはカウントされないという解釈をサポートします。ルート名（ "。"）が長さゼロと見なされる場合、一貫性を保つために、たとえば、 "org"の長さは4でなければならず、 "ietf.org"の長さは9でなければなりません。下に示された：
------
| 0x00 | length = 0
------
------------------ ------
| 0x03 | o | r | g | | 0x00 | length = 4
------------------ ------
----------------------------------------- ------
| 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
----------------------------------------- ------
This means that the maximum length of a domain name, as represented in a Multicast DNS message, up to but not including the final terminating zero, must not exceed 255 bytes.
つまり、マルチキャストDNSメッセージで表されるドメイン名の最大長は、最後の終端のゼロを含まず、255バイトを超えてはなりません。
However, many Unicast DNS implementers have read these RFCs differently, and argue that the 255-byte limit does include the terminating zero, and that the "Clarifications to the DNS Specification" [RFC2181] statement that "." is the "zero length full name" was simply a mistake.
ただし、多くのユニキャストDNS実装者はこれらのRFCを異なる方法で読み、255バイトの制限には終端のゼロが含まれていること、および「DNS仕様への明確化」[RFC2181]ステートメントはそのことを主張しています。 「ゼロレングスのフルネーム」は単なる間違いでした。
Hence, implementers should be aware that other Unicast DNS implementations may limit the maximum domain name to 254 bytes plus a terminating zero, depending on how that implementer interpreted the DNS specifications.
したがって、実装者は、他のユニキャストDNS実装が最大DNS名を254バイトに加えて終了ゼロを制限する場合があることに注意してください。これは、その実装者がDNS仕様をどのように解釈したかによって異なります。
Compliant Multicast DNS implementations MUST support names up to 255 bytes plus a terminating zero, i.e., 256 bytes total.
準拠したマルチキャストDNS実装は、最大255バイトの名前と終端のゼロ、つまり合計256バイトまでの名前をサポートする必要があります。
Some people have argued that sending responses via multicast is inefficient on the network. In fact, using multicast responses can result in a net lowering of overall multicast traffic for a variety of reasons, and provides other benefits too:
一部の人々は、マルチキャストを介して応答を送信することはネットワーク上で非効率的であると主張しました。実際、マルチキャスト応答を使用すると、さまざまな理由で全体的なマルチキャストトラフィックが減少する可能性があり、他の利点も提供されます。
* Opportunistic Caching. One multicast response can update the caches on all machines on the network. If another machine later wants to issue the same query, and it already has the answer in its cache, it may not need to even transmit that multicast query on the network at all.
* 日和見キャッシュ。 1つのマルチキャスト応答で、ネットワーク上のすべてのマシンのキャッシュを更新できます。別のマシンが後で同じクエリを発行する必要があり、そのキャッシュにすでに回答がある場合、ネットワーク上でそのマルチキャストクエリを送信する必要すらありません。
* Duplicate Query Suppression. When more than one machine has the same ongoing long-lived query running, every machine does not have to transmit its own independent query. When one machine transmits a query, all the other hosts see the answers, so they can suppress their own queries.
* 重複クエリの抑制。複数のマシンで実行中の同じ長期クエリが実行されている場合、すべてのマシンが独自の独立したクエリを送信する必要はありません。 1台のマシンがクエリを送信すると、他のすべてのホストが回答を表示するため、独自のクエリを抑制できます。
* Passive Observation Of Failures (POOF). When a host sees a multicast query, but does not see the corresponding multicast response, it can use this information to promptly delete stale data from its cache. To achieve the same level of user-interface quality and responsiveness without multicast responses would require lower cache lifetimes and more frequent network polling, resulting in a higher packet rate.
* 障害のパッシブ監視（POOF）。ホストがマルチキャストクエリを確認しても、対応するマルチキャスト応答を確認できない場合、この情報を使用して、古いデータをキャッシュから即座に削除できます。マルチキャスト応答なしで同じレベルのユーザーインターフェイス品質と応答性を実現するには、キャッシュの有効期間を短くし、ネットワークポーリングを頻繁に行う必要があるため、パケットレートが高くなります。
* Passive Conflict Detection. Just because a name has been previously verified to be unique does not guarantee it will continue to be so indefinitely. By allowing all Multicast DNS responders to constantly monitor their peers' responses, conflicts arising out of network topology changes can be promptly detected and resolved. If responses were not sent via multicast, some other conflict detection mechanism would be needed, imposing its own additional burden on the network.
*パッシブ競合検出。名前が一意であることが以前に確認されているからといって、名前が無期限に続くことは保証されません。すべてのマルチキャストDNSレスポンダがピアの応答を常に監視できるようにすることで、ネットワークトポロジの変更に起因する競合を迅速に検出して解決できます。応答がマルチキャストを介して送信されなかった場合、他の競合検出メカニズムが必要になり、ネットワークに独自の追加の負担を課します。
* Use on devices with constrained memory resources: When using delayed responses to reduce network collisions, responders need to maintain a list recording to whom each answer should be sent. The option of multicast responses allows responders with limited storage, which cannot store an arbitrarily long list of response addresses, to choose to fail-over to a single multicast response in place of multiple unicast responses, when appropriate.
* メモリリソースが制限されているデバイスでの使用：遅延応答を使用してネットワークの衝突を減らす場合、レスポンダは各回答の送信先となる記録をリストに保持する必要があります。マルチキャスト応答のオプションにより、応答アドレスの任意の長いリストを格納できない限られたストレージを持つレスポンダーは、適切な場合、複数のユニキャスト応答の代わりに単一のマルチキャスト応答にフェイルオーバーすることを選択できます。
* Overlayed Subnets. In the case of overlayed subnets, multicast responses allow a receiver to know with certainty that a response originated on the local link, even when its source address may apparently suggest otherwise.
* オーバーレイされたサブネット。オーバーレイされたサブネットの場合、マルチキャスト応答により、受信者は、ソースアドレスが明らかに別のことを示唆している場合でも、ローカルリンクで応答が発生したことを確実に知ることができます。
* Robustness in the face of misconfiguration: Link-local multicast transcends virtually every conceivable network misconfiguration. Even if you have a collection of devices where every device's IP address, subnet mask, default gateway, and DNS server address are all wrong, packets sent by any of those devices addressed to a link-local multicast destination address will still be delivered to all peers on the local link. This can be extremely helpful when diagnosing and rectifying network problems, since it facilitates a direct communication channel between client and server that works without reliance on ARP, IP routing tables, etc. Being able to discover what IP address a device has (or thinks it has) is frequently a very valuable first step in diagnosing why it is unable to communicate on the local network.
* 設定ミスに直面した場合の堅牢性：リンクローカルマルチキャストは、考えられるすべてのネットワーク設定ミスを超越します。すべてのデバイスのIPアドレス、サブネットマスク、デフォルトゲートウェイ、およびDNSサーバーアドレスがすべて間違っているデバイスのコレクションがある場合でも、リンクローカルマルチキャスト宛先アドレスにアドレス指定されたこれらのデバイスのいずれかによって送信されたパケットは、すべてに配信されますローカルリンク上のピア。これは、ARP、IPルーティングテーブルなどに依存せずに機能するクライアントとサーバー間の直接通信チャネルを容易にするため、ネットワークの問題を診断および修正するときに非常に役立ちます。デバイスが持っているIPアドレスを発見できる（または考えている） has）は、ローカルネットワーク上で通信できない理由を診断するための非常に貴重な最初のステップであることがよくあります。
Alternative methods of asserting nonexistence were considered, such as using an NXDOMAIN response, or emitting a resource record with zero-length rdata.
NXDOMAIN応答を使用したり、長さがゼロのrdataでリソースレコードを発行したりするなど、存在しないことを表明する別の方法が検討されました。
Using an NXDOMAIN response does not work well with Multicast DNS. A Unicast DNS NXDOMAIN response applies to the entire message, but for efficiency Multicast DNS allows (and encourages) multiple responses in a single message. If the error code in the header were NXDOMAIN, it would not be clear to which name(s) that error code applied.
NXDOMAIN応答の使用は、マルチキャストDNSではうまく機能しません。ユニキャストDNS NXDOMAIN応答はメッセージ全体に適用されますが、効率を上げるために、マルチキャストDNSは単一のメッセージで複数の応答を許可（および推奨）します。ヘッダーのエラーコードがNXDOMAINの場合、そのエラーコードがどの名前に適用されたかは明確ではありません。
Asserting nonexistence by emitting a resource record with zero-length rdata would mean that there would be no way to differentiate between a record that doesn't exist, and a record that does exist, with zero- length rdata. By analogy, most file systems today allow empty files, so a file that exists with zero bytes of data is not considered equivalent to a filename that does not exist.
長さ0のrdataを持つリソースレコードを発行して存在しないことを表明すると、存在しないレコードと長さ0のrdataを持つ存在するレコードを区別する方法がなくなります。類推により、今日のほとんどのファイルシステムでは空のファイルが許可されているため、データが0バイトのファイルは、存在しないファイル名と同等とは見なされません。
A benefit of asserting nonexistence through NSEC records instead of through NXDOMAIN responses is that NSEC records can be added to the Additional Section of a DNS response to offer additional information beyond what the querier explicitly requested. For example, in response to an SRV query, a responder should include A record(s) giving its IPv4 addresses in the Additional Section, and an NSEC record indicating which other types it does or does not have for this name. If the responder is running on a host that does not support IPv6 (or does support IPv6 but currently has no IPv6 address on that interface) then this NSEC record in the Additional Section will indicate this absence of AAAA records. In effect, the responder is saying, "Here's my SRV record, and here are my IPv4 addresses, and no, I don't have any IPv6 addresses, so don't waste your time asking". Without this information in the Additional Section, it would take the querier an additional round-trip to perform an additional query to ascertain that the target host has no AAAA records. (Arguably Unicast DNS could also benefit from this ability to express nonexistence in the Additional Section, but that is outside the scope of this document.)
NXDOMAIN応答ではなくNSECレコードを通じて非存在をアサートする利点は、NSECレコードをDNS応答の追加セクションに追加して、クエリアが明示的に要求したものを超える追加情報を提供できることです。たとえば、SRVクエリへの応答として、レスポンダはIPv4アドレスを提供するAレコードを追加セクションに含め、NSECレコードはこの名前に対して他のどのタイプを持っているか持っていないかを示します。レスポンダがIPv6をサポートしていない（またはIPv6をサポートしているが、現在そのインターフェイスにIPv6アドレスがない）ホストで実行されている場合、追加セクションのこのNSECレコードは、AAAAレコードがないことを示します。実際、レスポンダーは「これが私のSRVレコードで、ここが私のIPv4アドレスです。いいえ、私はIPv6アドレスを持っていないので、時間を無駄にしないでください」と言っています。追加セクションにこの情報がないと、クエリアは追加のラウンドトリップを実行して追加のクエリを実行し、ターゲットホストにAAAAレコードがないことを確認します。 （間違いなく、ユニキャストDNSは、追加セクションで非存在を表現するこの機能の恩恵を受けることができますが、それはこのドキュメントの範囲外です。）
After many years of debate, as a result of the perceived need to accommodate certain DNS implementations that apparently couldn't handle any character that's not a letter, digit, or hyphen (and apparently never would be updated to remedy this limitation), the Unicast DNS community settled on an extremely baroque encoding called "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding solution, but it is complicated, hard to understand, and hard to implement, using sophisticated techniques including insertion unsort coding, generalized variable-length integers, and bias adaptation. The resulting encoding is remarkably compact given the constraints, but it's still not as good as simple straightforward UTF-8, and it's hard even to predict whether a given input string will encode to a Punycode string that fits within DNS's 63-byte limit, except by simply trying the encoding and seeing whether it fits. Indeed, the encoded size depends not only on the input characters, but on the order they appear, so the same set of characters may or may not encode to a legal Punycode string that fits within DNS's 63-byte limit, depending on the order the characters appear. This is extremely hard to present in a user interface that explains to users why one name is allowed, but another name containing the exact same characters is not. Neither Punycode nor any other of the "ASCII-Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used in Multicast DNS messages. Any text being represented internally in some other representation must be converted to canonical precomposed UTF-8 before being placed in any Multicast DNS message.
長年の議論の末、明らかに文字、数字、ハイフン以外の文字を処理できない特定のDNS実装に対応する必要があると認識された結果（そしてこの制限を修正するために更新されることはないようです）、ユニキャストDNSコミュニティは、「Punycode」[RFC3492]と呼ばれる非常にバロックなエンコーディングに落ち着きました。 Punycodeは非常に独創的なエンコーディングソリューションですが、挿入ソートなしコーディング、一般化された可変長整数、バイアス適応などの高度な技術を使用して、複雑で理解しにくく、実装するのが困難です。結果として得られるエンコーディングは、制約を考えると非常にコンパクトですが、それでも単純な単純なUTF-8ほど良くなく、特定の入力文字列がDNSの63バイトの制限内に収まるPunycode文字列にエンコードされるかどうかを予測することさえも困難です。単にエンコーディングを試して、それが適合するかどうかを確認するだけです。実際、エンコードされたサイズは入力文字だけでなく、それらが表示される順序にも依存するため、同じ文字セットが、DNSの63バイトの制限内に収まる有効なPunycode文字列にエンコードされる場合とエンコードされない場合があります。文字が表示されます。ある名前が許可されている理由をユーザーに説明するユーザーインターフェイスでこれを提示するのは非常に困難ですが、まったく同じ文字を含む別の名前は許可されていません。ユニキャストDNSのために提案されたPunycodeやその他の「ASCII互換エンコーディング」[RFC5890]は、マルチキャストDNSメッセージで使用できません。他の表現で内部的に表現されているテキストは、マルチキャストDNSメッセージに配置する前に、正規の事前合成UTF-8に変換する必要があります。
Appendix G. Private DNS Namespaces
付録G.プライベートDNS名前空間
The special treatment of names ending in ".local." has been implemented in Macintosh computers since the days of Mac OS 9, and continues today in Mac OS X and iOS. There are also implementations for Microsoft Windows [B4W], Linux, and other platforms.
「.local」で終わる名前の特別な扱い。 Mac OS 9の時代からMacintoshコンピュータに実装されており、今日でもMac OS XとiOSで使用されています。 Microsoft Windows [B4W]、Linux、およびその他のプラットフォームの実装もあります。
Some network operators setting up private internal networks ("intranets") have used unregistered top-level domains, and some may have used the ".local" top-level domain. Using ".local" as a private top-level domain conflicts with Multicast DNS and may cause problems for users. Clients can be configured to send both Multicast and Unicast DNS queries in parallel for these names, and this does allow names to be looked up both ways, but this results in additional network traffic and additional delays in name resolution, as well as potentially creating user confusion when it is not clear whether any given result was received via link-local multicast from a peer on the same link, or from the configured unicast name server. Because of this, we recommend against using ".local" as a private Unicast DNS top-level domain. We do not recommend use of unregistered top-level domains at all, but should network operators decide to do this, the following top-level domains have been used on private internal networks without the problems caused by trying to reuse ".local." for this purpose:
プライベート内部ネットワーク（「イントラネット」）を設定する一部のネットワークオペレーターは、未登録のトップレベルドメインを使用している場合もあれば、「。local」トップレベルドメインを使用している場合もあります。 「.local」をプライベートトップレベルドメインとして使用すると、マルチキャストDNSと競合し、ユーザーに問題が発生する可能性があります。クライアントは、これらの名前に対してマルチキャストDNSクエリとユニキャストDNSクエリの両方を並行して送信するように構成できます。これにより、名前を両方の方法で検索できるようになりますが、これにより、ネットワークトラフィックが増加し、名前解決の遅延が増えるだけでなく、ユーザーが作成される可能性があります特定の結果が同じローカル上のピアからリンクローカルマルチキャストを介して受信されたか、構成されたユニキャストネームサーバーから受信されたかが明確でない場合の混乱。このため、プライベートユニキャストDNSトップレベルドメインとして「.local」を使用しないことをお勧めします。未登録のトップレベルドメインを使用することはお勧めしませんが、ネットワークオペレーターがこれを決定した場合、次のトップレベルドメインがプライベート内部ネットワークで使用され、「。local」の再利用による問題は発生していません。この目的のために：
.intranet. .internal. .private. .corp. .home. .lan.
。イントラネット。 。内部。 。民間。 .corp。 .home。 .lan。
Appendix H. Deployment History
付録H.展開履歴
In July 1997, in an email to the net-thinkers@thumper.vmeng.com mailing list, Stuart Cheshire first proposed the idea of running the AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of this and related IETF discussions, the IETF Zeroconf working group was chartered September 1999. After various working group discussions and other informal IETF discussions, several Internet-Drafts were written that were loosely related to the general themes of DNS and multicast, but did not address the service discovery aspect of NBP.
1997年7月、net-thinkers @ thumper.vmeng.comメーリングリストへの電子メールで、Stuart Cheshireは最初にIPを介してAppleTalk Name Binding Protocol [RFC6760]を実行するというアイデアを提案しました。これと関連するIETFディスカッションの結果、IETF Zeroconfワーキンググループは1999年9月にチャーターされました。さまざまなワーキンググループディスカッションと他の非公式のIETFディスカッションの後、DNSとマルチキャストの一般的なテーマに緩やかに関連するいくつかのインターネットドラフトが書かれました。しかし、NBPのサービス検出の側面については触れていません。
In April 2000, Stuart Cheshire registered IPv4 multicast address 224.0.0.251 with IANA [MC4] and began writing code to test and develop the idea of performing NBP-like service discovery using Multicast DNS, which was documented in a group of three Internet-Drafts:
2000年4月、スチュアートチェシャーは、IPv4マルチキャストアドレス224.0.0.251をIANA [MC4]に登録し、マルチキャストDNSを使用してNBPのようなサービスディスカバリを実行するアイデアをテストおよび開発するコードの記述を開始しました。 ：
o "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk Name Binding Protocol, because many in the IETF community had little first-hand experience using AppleTalk, and confusion in the IETF community about what AppleTalk NBP did was causing confusion about what would be required in an IP-based replacement.
o 「AppleTalkネームバインディングプロトコル（NBP）を置き換えるプロトコルの要件」[RFC6760]は、AppleTalkネームバインディングプロトコルを説明する概要です。これは、IETFコミュニティの多くはAppleTalkを使用した直接の経験がほとんどなく、IETFコミュニティで混乱しているためです。 AppleTalk NBPが何をしたかについて、IPベースの交換に何が必要かについて混乱が生じていました。
o "Discovering Named Instances of Abstract Services using DNS" [NIAS] proposed a way to perform NBP-like service discovery using DNS-compatible names and record types.
o 「DNSを使用した抽象サービスの名前付きインスタンスの検出」[NIAS]は、DNS互換の名前とレコードタイプを使用して、NBPのようなサービス検出を実行する方法を提案しました。
o "Multicast DNS" (this document) specifies a way to transport those DNS-compatible queries and responses using IP multicast, for zero-configuration environments where no conventional Unicast DNS server was available.
o 「マルチキャストDNS」（このドキュメント）は、従来のユニキャストDNSサーバーが利用できなかったゼロ構成環境で、IPマルチキャストを使用してそれらのDNS互換のクエリと応答を転送する方法を指定します。
In 2001, an update to Mac OS 9 added resolver library support for host name lookup using Multicast DNS. If the user typed a name such as "MyPrinter.local." into any piece of networking software that used the standard Mac OS 9 name lookup APIs, then those name lookup APIs would recognize the name as a dot-local name and query for it by sending simple one-shot Multicast DNS queries to 224.0.0.251:5353. This enabled the user to, for example, enter the name "MyPrinter.local." into their web browser in order to view a printer's status and configuration web page, or enter the name "MyPrinter.local." into the printer setup utility to create a print queue for printing documents on that printer.
2001年、Mac OS 9へのアップデートにより、マルチキャストDNSを使用したホスト名ルックアップのリゾルバーライブラリサポートが追加されました。ユーザーが「MyPrinter.local」などの名前を入力した場合標準のMac OS 9の名前検索APIを使用するネットワークソフトウェアに挿入すると、これらの名前検索APIは名前をドットローカル名として認識し、単純なワンショットマルチキャストDNSクエリを224.0.0.251に送信することでクエリします。 5353。これにより、ユーザーは、たとえば「MyPrinter.local」という名前を入力できます。プリンタのステータスと設定のWebページを表示するためにWebブラウザに入力するか、「MyPrinter.local」という名前を入力します。プリンタセットアップユーティリティを使用して、そのプリンタでドキュメントを印刷するための印刷キューを作成します。
Multicast DNS responder software, with full service discovery, first began shipping to end users in volume with the launch of Mac OS X 10.2 "Jaguar" in August 2002, and network printer makers (who had historically supported AppleTalk in their network printers and were receptive to IP-based technologies that could offer them similar ease-of-use) started adopting Multicast DNS shortly thereafter.
マルチキャストDNSレスポンダーソフトウェアは、完全なサービスディスカバリを備え、2002年8月にMac OS X 10.2 "Jaguar"を発表し、ネットワークプリンターメーカー（これまでネットワークプリンターでAppleTalkをサポートし、受け入れていた）によって、最初に大量にエンドユーザーに出荷されました。同様の使いやすさを提供できるIPベースのテクノロジーへの変更）は、その後まもなくマルチキャストDNSの採用を開始しました。
In September 2002, Apple released the source code for the mDNSResponder daemon as Open Source under Apple's standard Apple Public Source License (APSL).
2002年9月、アップルはmDNSResponderデーモンのソースコードを、アップルの標準アップルパブリックソースライセンス（APSL）に基づくオープンソースとしてリリースしました。
Multicast DNS responder software became available for Microsoft Windows users in June 2004 with the launch of Apple's "Rendezvous for Windows" (now "Bonjour for Windows"), both in executable form (a downloadable installer for end users) and as Open Source (one of the supported platforms within Apple's body of cross-platform code in the publicly accessible mDNSResponder CVS source code repository) [BJ].
マルチキャストDNSレスポンダーソフトウェアは、2004年6月にAppleの「Rendezvous for Windows」（現在は「Bonjour for Windows」）の発売とともにMicrosoft Windowsユーザーが利用できるようになりました。公にアクセス可能なmDNSResponder CVSソースコードリポジトリのアップルのクロスプラットフォームコードの本体内でサポートされているプラットフォームの一部）[BJ]。
In August 2006, Apple re-licensed the cross-platform mDNSResponder source code under the Apache License, Version 2.0.
2006年8月、アップルはクロスプラットフォームのmDNSResponderソースコードをApacheライセンスバージョン2.0に基づいて再ライセンスしました。
In addition to desktop and laptop computers running Mac OS X and Microsoft Windows, Multicast DNS is now implemented in a wide range of hardware devices, such as Apple's "AirPort" wireless base stations, iPhone and iPad, and in home gateways from other vendors, network printers, network cameras, TiVo DVRs, etc.
Mac OS XおよびMicrosoft Windowsを実行しているデスクトップおよびラップトップコンピュータに加えて、マルチキャストDNSはAppleの「AirPort」ワイヤレスベースステーション、iPhoneおよびiPadなどの幅広いハードウェアデバイス、および他のベンダーのホームゲートウェイに実装されています。ネットワークプリンター、ネットワークカメラ、TiVo DVRなど
The Open Source community has produced many independent implementations of Multicast DNS, some in C like Apple's mDNSResponder daemon, and others in a variety of different languages including Java, Python, Perl, and C#/Mono.
オープンソースコミュニティは、AppleのmDNSResponderデーモンのようにCにあるものや、Java、Python、Perl、C＃/ Monoを含むさまざまな異なる言語のマルチキャストDNSの多くの独立した実装を生み出しています。
In January 2007, the IETF published the Informational RFC "Link-Local Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially similar to Multicast DNS, but incompatible in some small but important ways. In particular, the LLMNR design explicitly excluded support for service discovery, which made it an unsuitable candidate for a protocol to replace AppleTalk NBP [RFC6760].
2007年1月、IETFは情報RFC「リンクローカルマルチキャスト名前解決（LLMNR）」[RFC4795]を公開しました。これは、マルチキャストDNSと実質的に類似していますが、いくつかの小さな重要な点で互換性がありません。特に、LLMNR設計はサービス検出のサポートを明示的に除外したため、AppleTalk NBP [RFC6760]を置き換えるプロトコルの候補としては不適切でした。
While the original focus of Multicast DNS and DNS-Based Service Discovery was for zero-configuration environments without a conventional Unicast DNS server, DNS-Based Service Discovery also works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007] to create service discovery records and standard DNS queries to query for them. Apple's Back to My Mac service, launched with Mac OS X 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over Unicast DNS [RFC6281].
マルチキャストDNSとDNSベースのサービスディスカバリの本来の焦点は、従来のユニキャストDNSサーバーのないゼロ構成環境でしたが、DNSベースのサービスディスカバリは、ユニキャストDNSサーバーを使用して機能し、DNSアップデート[RFC2136] [RFC3007]を使用してサービスを作成しますそれらを照会するための検出レコードと標準DNSクエリ。 AppleのBack to My Macサービスは、2007年10月にMac OS X 10.5 "Leopard"でリリースされ、ユニキャストDNS [RFC6281]を介したDNSベースのサービスディスカバリを使用しています。
In June 2012, Google's Android operating system added native support for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
2012年6月、GoogleのAndroidオペレーティングシステムは、Android 4.1「Jelly Bean」（APIレベル16）[NSD]のandroid.net.nsd.NsdManagerクラスでDNS-SDおよびマルチキャストDNSのネイティブサポートを追加しました。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 3207
EMail: cheshire@apple.com
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA
Phone: +1 408 974 4368
EMail: marc@apple.com