头痛呀头疼，解决完一个BUG又出来一个
后续冲突（Subsequent Conflict）
测试工具等待十秒钟，然后发出与设备使用的主机名冲突的mDNS响应。
当设备重新发出对该主机名的探测时，测试工具再次发送其冲突响应，并验证设备是否选择了新的主机名并再次探测/宣布。如果设备选择新的主机名而未首先探测其原始名称，则会发出警告。对设备正在使用的服务名称（SRV记录）重复此过程。（如果操作员禁用SRV探测/通告，则禁用。）
有关详细信息，请参阅“RFC6762 9。冲突解决”。
6.回应
当多播 DNS 响应者构造并发送多播 DNS响应消息，该消息的资源记录部分必须仅包含明确响应者的记录权威性。这些答案的产生可能是因为记录回答在多播 DNS 查询消息中收到的问题，或响应者确定的某些其他时间而不是未经请求的公告是有保证的。多播 DNS 响应者不得放置来自其缓存的记录，这些记录是从其他响应者那里学到的在网络上，在传出响应的资源记录部分消息。
只允许给定记录的权威来源发布包含该记录的响应。确定给定记录是否回答给定问题使用标准 DNS 规则创建：记录名称必须与问题名称，记录 rrtype 必须与问题 qtype 匹配，除非qtype 是“ANY”（255）或 rrtype 是“CNAME”（5），并且记录rrclass 必须匹配问题 qclass 除非 qclass 是“任何”（255）。与单播 DNS 一样，通常只有 DNS 1 类（“Internet”）被使用，但如果客户端软件使用 1 以外的类，则必须使用上述匹配规则。
多播 DNS 响应器必须仅在它具有肯定的、要发送的非空响应，或者它权威地知道一个特定记录不存在。对于唯一记录，主机所在的位置已经建立了名称的唯一所有权，它必须返回对它知道不存在的记录查询的否定回答。
例如，一个没有 IPv6 地址的主机，声称唯一名称“host.local”的所有权。对于所有 rrtypes，必须响应AAAA 查询“host.local”。通过发送否定答复表示该名称不存在 AAAA 记录。见章节6.1，“负面反应”。对于不属于任何人的共享记录单个主机，给定记录的不存在由任何机器无法响应多播 DNS 查询，而不是通过任何明确的否定回应。对于共享记录，NXDOMAIN 和不得发送其他错误响应。
多播 DNS 响应不得包含任何问题问题部分。问题部分中的任何问题收到的多播 DNS 响应必须被静默忽略。组播接收多播 DNS 响应的 DNS 查询器不关心什么 问题引起了反应；他们只关心信息在响应中是真实准确的。以太网上的多播 DNS 响应器 [IEEE.802.3] 和类似共享多路访问网络应该有延迟它的能力响应最多 500 毫秒，如下所述。如果大量的Multicast DNS响应者全部响应立即针对特定查询，实际上会发生碰撞保证。
通过施加一个小的随机延迟，碰撞大大减少。在全尺寸以太网上使用允许的最大电缆长度和最大中继器数量允许时，以太网帧在传输过程中容易发生冲突其前 256 位的传输。在 10 Mb/s 以太网上，这相当于 25.6 微秒的易受攻击时间窗口。在更高的以太网的速度变体，易受攻击的时间窗口更短。
在多播 DNS 响应者有充分理由的情况下相信它将是发送链接的唯一响应者一个响应（即，因为它能够回答查询消息，以及它之前拥有的所有这些答复记录验证名称、rrtype 和 rrclass 在链接上是唯一的），它不应该在响应之前施加任何随机延迟，并且应该通常最多在 10 毫秒内产生响应。
尤其，这适用于使用单播响应来响应探测查询位设置。由于收到探测查询给出了一个明确的指示其他一些响应者正计划开始使用这个名字在不久的将来，回答此类调查查询以捍卫独特的记录是一个高度优先事项，需要立即完成。探测查询可以通过以下事实与普通查询区分开来：探测查询包含授权部分中的建议记录回答问题部分中的问题（有关更多详细信息，请参阅第 8.2 节，“同时探针打破平局”）。
立即回复适用于地址等记录记录一个特定的主机名，当主机名已经以前验证过的唯一。毫不拖延地回应是不是适用于查找用于基于 DNS 的 PTR 记录之类的事情服务发现 [RFC6763]，其中可能有大量响应预期的。
在任何可能有多个响应的情况下，例如查询其中答案是共享资源记录集的成员，每个响应者应该将其响应延迟一个随机时间选择在 20-120 毫秒范围内均匀随机分布。要求延迟至少为 20 ms 的原因是为了适应发送两个或多个查询包的情况背靠背，因为在那种情况下我们想要一个有答案的响应者不止一个这样的查询有机会将其所有答案聚合到单个响应消息中。
在查询设置了 TC（截断）位的情况下，指示随后的已知答案数据包将跟随，响应者应该随机延迟他们的响应时间在 400-500 毫秒范围内选择均匀随机分布，以为所有已知答案数据包留出足够的时间到达，因为在第 7.2 节“多数据包已知答案抑制”中有描述。
所有多播 DNS 响应中的源 UDP 端口必须是 5353（分配给 mDNS 的知名端口）。多播 DNS 实现必须默默地忽略他们收到的任何多播 DNS 响应源 UDP 端口不是 5353。所有多播 DNS 响应中的目标 UDP 端口必须是 5353，目标地址必须是 mDNS IPv4 链路本地多播地址 224.0.0.251 或其等效的 IPv6 FF02::FB，除了当生成对明确请求的查询的回复时
单播响应： 通过单播响应位，由于是遗留查询（第 6.7 节），或者 由于是直接单播查询。
除这三种特定情况外，不得通过以下方式发送响应单播，因为那时“失败的被动观察”第 10.5 节中描述的机制将无法正常工作。
其他附录中讨论了通过多播发送响应的好处D
附录 D. 多播响应的好处
有些人认为通过多播发送响应是在网络上效率低下。事实上，使用多播响应可以导致各种整体多播流量的净降低原因，并提供其他好处：
- 机会缓存。一个多播响应可以更新缓存在网络上的所有机器上。如果以后换一台机器想要发出相同的查询，并且它已经有了答案缓存，它甚至可能不需要在完全没有网络。
- 重复查询抑制。当不止一台机器有同样持续的长期查询运行，每台机器都没有传输自己的独立查询。当一台机器传输查询，所有其他主机都会看到答案，因此他们可以抑制 他们自己的查询。
- 被动观察失败 (POOF)。当主人看到一个多播查询，但是没有看到对应的多播响应，它可以使用此信息及时删除陈旧数据从它的缓存中。实现相同级别的用户界面没有多播响应的质量和响应能力将需要更短的缓存寿命和更频繁的网络轮询， 导致更高的数据包速率。
- 被动冲突检测。只因为一个名字已经以前验证为唯一的并不能保证它会无限期地继续下去。通过允许所有多播 DNS响应者不断监视他们的同龄人的反应，冲突可以及时检测到网络拓扑变化引起的变化并解决了。如果响应不是通过多播发送的，则其他一些将需要冲突检测机制，强加自己的 网络的额外负担。
- 在内存资源受限的设备上使用：使用时延迟响应以减少网络冲突，响应者需要维护一个列表记录每个答案应该发送给谁。这多播响应选项允许响应者具有有限的存储，不能存储任意长的响应列表地址，选择故障转移到单个多播响应 在适当的时候放置多个单播响应。
- 重叠子网。在重叠子网的情况下，多播响应允许接收者确定地知道响应起源于本地链路，即使其源地址可能 显然另有建议。
- 面对错误配置的稳健性：链路本地多播超越几乎所有可以想象的网络错误配置。即使您有一组设备，其中每个设备的 IP地址、子网掩码、默认网关和 DNS 服务器地址是都错了，这些设备中的任何一个发送的数据包都发送给了链路本地多播目标地址仍将传送到本地链路上的所有对等点。这在以下情况下非常有用诊断和纠正网络问题，因为它有助于客户端和服务器之间的直接通信通道有效不依赖 ARP、IP 路由表等。能够发现设备拥有（或认为拥有）的 IP 地址是什么通常是诊断其原因的非常有价值的第一步无法在本地网络上通信。
多播 DNS 查询器必须只接受单播响应，如果他们回答最近发送的查询（例如，在过去的两个秒）明确请求单播响应。组播DNS 查询器必须默默地忽略所有其他单播响应。
为了保护网络免受由于软件错误或恶意攻击，多播 DNS 响应者不得（回答探测查询的一种特殊情况除外）多播给定界面上的记录，直到至少一秒钟过去自上次该记录在该特定设备上多播以来界面。网络上的合法查询者应该已经看到以前的传输并缓存它。
未收到的查询器并缓存先前的传输将重试其请求并且收到后续回复。在回答的特殊情况下探测查询，因为探测主机之前的时间有限将决定是否使用该名称，多播 DNS 响应者必须快速响应。
在这种特殊情况下仅当通过多播响应探测时，多播 DNS响应者只需要在必要时延迟其传输确保自上次记录以来至少间隔 250 毫秒在该接口上进行多播。
6.1.负面回应
在多播 DNS 的早期设计中，假定显式永远不需要负面回应。主机可以断言 它声称存在的记录集的存在，以及链接上所有此类集合的并集是多播 DNS 记录的集合存在于该链接上。
断言每条记录都不存在在该集合的补充中——即所有可能的多播 DNS此链接上可能存在但目前不存在的记录 --被认为是不切实际和不必要的。一个的不存在记录将由查询器查询并失败来确定从当前连接到的任何主机接收响应关联。
然而，运营经验表明，明确的消极回应有时很有价值。一个这样的例子是当一个查询器正在查询 AAAA 记录，以及有问题的主机名没有关联的 IPv6 地址。在这种情况下，响应主机知道它目前拥有该名称的专有所有权，并且它知道它目前没有任何 IPv6 地址，所以一个明确的否定响应比查询器必须重新传输更可取 它多次查询，并最终放弃超时，在它可以断定给定的 AAAA 记录不存在之前。 每当响应者收到对其具有的名称的查询时已验证的专有所有权，对于该名称没有的类型记录，响应者必须（除了下面（a）中允许的）响应使用 DNS NSEC 记录断言该记录不存在[RFC4034]。在多播 DNS 的情况下，NSEC 记录不用于其通常的 DNSSEC [RFC4033] 安全属性，但只是作为表达给定记录存在或不存在的一种方式姓名。
在收到有关特定名称、rrtype 和 rrclass 的问题时，对于响应者确实有一个或多个唯一答案的问题，响应者还可以在附加记录中包含一个 NSEC 记录指示该名称不存在其他 rrtypes 的部分和类。
使用具有足够内存和 CPU 的设备的实施者资源可以选择实现代码来处理全部通用性DNS NSEC 记录 [RFC4034]，包括高达 65,536 位的位图长的。方便内存和 CPU 有限的设备使用资源，多播 DNS 查询器只需要能够解析 DNS NSEC 记录的受限形式。全部符合多播 DNS 实现必须至少正确地生成和解析如下所述的受限 DNS NSEC 记录格式：
- “下一个域名”字段包含记录自己的名称。当与名称压缩一起使用时，这意味着 ‘NextDomain Name’ 字段总是恰好占用两个字节信息。
- 类型位图块号为 0。
- 类型位图块长度字节是 1-32 范围内的值。
- 类型位图数据为 1-32 字节，如长度所示字节。
因为这种受限形式的 DNS NSEC 记录仅限于Type Bit Map 块号为零，不能表示存在rrtypes 高于 255。因此，如果多播 DNS 响应者是要拥有 rrtypes 高于 255 的记录，它绝不能生成这些这些名字的限制形式的 NSEC 记录，因为这样做会暗示该名称没有 rrtypes 超过 255 的记录，这会是假的。在这种情况下，多播 DNS 响应者必须
(a) 不发出该名称的 NSEC 记录，或 (b) 发出完整的 NSEC 记录包含具有正确的适当类型位图块为所有存在的记录类型设置的位。实际上这是不是一个重要的限制，因为 255 以上的 rrtypes 不是目前广泛使用。
如果多播 DNS 实现收到 NSEC 记录，其中’Next Domain Name’字段不是记录自己的名字，则实施应该忽略“下一个域名”字段和过程NSEC 记录的其余部分照常进行。
在多播 DNS 中“下一个域名”字段当前未使用，但可以使用在此协议的未来版本中，这就是多播 DNS 的原因实现不得拒绝或忽略它收到的 NSEC 记录只是因为它在“下一个域名”中发现了一个意想不到的值场地。
如果一个多播 DNS 实现收到一个 NSEC 记录包含超过一个类型位图，或者类型位图块号是不为零，或者块长度不在 1-32 范围内，则多播 DNS 实现可以默默地忽略整个 NSEC记录。多播 DNS 实现绝不能忽略整个消息只是因为该消息包含一个或多个 NSEC 记录多播 DNS 实现无法解析。
本规定是为了允许在未来对协议进行增强不破坏与旧版本兼容性的向后兼容方式多播 DNS 实现。
为了帮助区分这些合成的 NSEC 记录（生成以编程方式即时）来自传统的单播 DNS NSEC记录（实际上存在于已签名的 DNS 区域中）、合成的多播 DNS NSEC 记录不得在类型中设置 NSEC 位位图，而传统的单播 DNS NSEC 记录确实具有NSEC 位设置。
NSEC 记录的 TTL 表示预期的生命周期负缓存条目。一般来说，NSEC 记录的 TTL应该与记录本应具有的 TTL 相同，如果有的话存在。例如，多播 DNS 中地址记录的 TTL通常为 120 秒（参见第 10 节），因此负缓存不存在的地址记录的生命周期也应为 120秒。
响应者必须只对以下查询生成否定响应它拥有名称、rrtype 和 rrclass 的合法所有权问题，并可以合法地断言没有该名称的记录，rrtype 和 rrclass 存在。响应者可以断言指定的如果它先验地知道 rrtype 其名称之一不存在它拥有该名称的专有所有权（例如，反向名称地址映射 PTR 记录，源自 IP 地址，这在本地链接上应该是唯一的）或者如果它之前声明过使用 rrtype“ANY”的探测查询对该名称的唯一所有权。（如果它对特定的 rrtype 使用探测查询，那么它会只拥有该 rrtype 的名称，不能断言其他rrtypes 不存在。）
这种负编码机制的设计原理响应在附录 E 中进一步讨论。
6.2.回应地址查询
当多播 DNS 响应者发送多播 DNS 响应消息时包含自己的地址记录，它必须包含所有地址在发送消息的接口上有效，并且不得包含在该接口上无效的地址（例如可能在主机的其他地址上配置的地址接口）。
例如，如果一个接口同时具有 IPv6 链路 -local 和 IPv6 可路由地址，两者都应包含在响应消息，以便查询者收到两者并可以自己制作选择使用哪个。这允许查询器只有一个IPv6链路本地地址连接到链路本地地址，以及具有 IPv6 可路由地址的不同查询器连接到IPv6 可路由地址。
当多播 DNS 响应程序放置 IPv4 或 IPv6 地址记录时（rrtype“A”或“AAAA”）到响应消息中，它还应该放置具有相同名称的其他地址类型的任何记录附加部分，如果消息中有空格。
这是为了提供命运共享，使所有设备的地址都被传递 原子地在一条消息中，以减少丢包的风险可能导致查询器只接收 IPv4 地址而不是IPv6 地址，反之亦然。
如果设备只有 IPv4 地址而没有 IPv6地址，反之亦然，那么适当的 NSEC 记录应该是放入附加部分，以便查询者可以知道确定该设备没有那种地址。
一些多播 DNS 响应器将物理接口与两者一起处理IPv4 和 IPv6 地址作为具有两个地址的单个接口。其他多播 DNS 响应者可能会将这种情况视为逻辑上的两种情况接口（一个具有一个或多个 IPv4 地址，另一个具有一个或多个 IPv6 地址），但以这种方式运行的响应者不得将相应的自动 NSEC 记录放入回复中发送（即在他们的 IPv6 响应中否定 IPv4 断言，以及在他们的 IPv4 响应中否定 IPv6 断言），因为这会导致网络上响应器的不正确操作以前的方式。
6.3.响应多问题查询
多播 DNS 响应者必须正确处理 DNS 查询消息包含多个问题，通过回答任何或所有问题他们有答案的问题。不同于单一问题
查询，在适当的情况下允许立即响应案例，对于包含多个问题的查询消息，所有（非防御性）答案应该在范围内随机延迟20-120 毫秒，如果设置了 TC（截断）位，则为 400-500 毫秒。这是因为当查询消息包含多个问题时，多播 DNS 响应者通常不能确定其他响应者也不会同时生成答案该查询消息中的其他问题。 （捍卫名字的答案，在响应对该名称的探测，不受此延迟规则的约束 并且仍然立即发送。）
6.4.响应聚合
在可能的情况下，为了网络的缘故，响应者应该效率，将尽可能多的响应聚合到一个多播 DNS 响应消息。例如，当响应者有它计划发送几个响应，每个响应都被不同的延迟间隔，则较早的响应应延迟最多额外 500 毫秒，如果这将允许它们与其他回复计划稍后发布。
6.5.通配符查询（qtype“ANY”和 qclass“ANY”）
使用 qtype “ANY” (255) 和/或 qclass 响应查询时"ANY" (255)，一个多播 DNS 响应者必须用它的 ALL 响应与查询匹配的记录。这与qtype “ANY” 和 qclass “ANY” 在单播 DNS 中工作。
一个常见的误解是 qtype“ANY”的单播 DNS 查询将引发包含所有匹配记录的响应。这是不正确。如果有匹配查询的记录，则response 只需要包含至少其中一项即可，不需要必须全部。
这种有点令人惊讶的行为在缓存中很常见（即“递归”）名称服务器。如果缓存服务器收到qtype “ANY” 至少有一个有效答案的查询，它是允许只返回恰好有的匹配答案已经在它的缓存中，并且不需要重新咨询权威名称服务器检查是否有更多的记录也匹配 qtype“ANY”查询。
例如，人们可能会想象查询 qtype “ANY” for name“host.example.com”将同时返回 IPv4 (A) 和 IPv6 (AAAA)该主机的地址记录。实际上，发生的事情是取决于之前收到的查询的历史记录通过干预缓存服务器。如果缓存服务器没有记录对于“host.example.com”，然后它将咨询另一台服务器（通常相关名称的权威名称服务器），并且，在那在这种情况下，它通常会返回所有 IPv4 和 IPv6 地址记录。
但是，如果其他主机最近查询了 qtype“A”对于名称“host.example.com”，这样缓存服务器已经有其缓存中“host.example.com”的 IPv4 地址记录，但没有 IPv6地址记录，那么它将只返回记录它的 IPv4 地址已经有缓存，并且没有 IPv6 地址记录。
多播 DNS 不共享 qtype “ANY” 和qclass “ANY” 查询返回一些未定义的匹配子集记录。使用 qtype “ANY” (255) 和/或响应查询时qclass “ANY” (255)，多播 DNS 响应者必须响应 ALL其匹配查询的记录。
6.6.协作多播 DNS 响应程序
如果多播 DNS 响应者（“A”）观察到其他一些多播 DNS响应者（“B”）发送多播 DNS 响应消息，其中包含具有与 A 之一相同的名称、rrtype 和 rrclass 的资源记录资源记录，但不同 rdata，则：
- 如果 A 的资源记录打算成为共享资源记录，那么这就没有冲突，不需要任何操作。
- 如果 A 的资源记录是一个唯一的成员由该响应者独有的资源记录集，那么这是冲突，必须按照第 9 节中的描述进行处理，“解决冲突”。如果多播 DNS 响应者（“A”）观察到其他一些多播 DNS响应者（“B”）发送多播 DNS 响应消息，其中包含具有与 A 之一相同的名称、rrtype 和 rrclass 的资源记录资源记录和相同 rdata，然后：
- 如果消息中给出的 B 的资源记录的 TTL 是从 A 的角度来看，至少是真实 TTL 的一半，然后不采取任何行动是必须的。
- 如果消息中给出的B的资源记录的TTL小于从 A 的角度来看，比真实 TTL 的一半还多，那么 A 必须标记其记录将通过多播公布。查询器接收来自 B 的记录将使用 B 给出的 TTL，因此可能比 A 预期的更早删除记录。通过发送自己的多播响应纠正 TTL，A 确保记录将保留所需的时间。
这些规则允许多个多播 DNS 响应者提供相同的网络上的数据（可能出于容错原因）相互冲突。
6.7.传统单播响应
如果收到的多播 DNS 查询中的源 UDP 端口不是端口5353，这表示发起查询的查询器是简单的解析器，如第 5.1 节“一次性多播”中所述DNS 查询”，它没有完全实现所有多播 DNS。在这种情况下，多播 DNS 响应者必须发送 UDP 响应 直接返回查询器，通过单播，到查询数据包的源 IP 地址和端口。
这个单播响应必须是传统的单播响应将由传统的单播DNS服务器；例如，它必须重复查询 ID 和查询消息中给出的问题。
此外，缓存刷新第 10.2 节“刷新过时缓存的公告”中描述的位条目”，不得在传统单播响应中设置。遗留单播响应中给出的资源记录 TTL 不应该大于十秒，即使多播的真实 TTLDNS 资源记录较高。
这是因为多播 DNS完全参与协议的响应者使用缓存第 10 节“资源记录 TTL”中描述的一致性机制Values and Cache Coherency”，以更新陈旧数据并使其失效。
是否将单播响应发送到遗留解析器以使用相同的高TTL，这些遗留解析器，不实现这些缓存一致性机制，可以保留陈旧的缓存资源记录数据很久之后它就不再有效了。
