如何解决 RFC 之间的冲突？
How to resolve a conflict between RFCs?
RFC 4034 规定如下：
A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.
* 强调我的
RFC 6762 规定如下：
All compliant Multicast DNS implementations MUST at least correctly generate and parse the restricted DNS NSEC record format described below:
- 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.
这似乎是一个冲突。一个 RFC 指出不应使用名称压缩，另一个建议兼容的实现必须能够生成和解析具有名称压缩的记录。
鉴于 mDNS 旨在与现有 DNS 解析器一起正常工作，我作为程序员应该如何实现生成和解析 NSEC 记录的方法？
我是否应该使用名称压缩？
虽然 mDNS 大量借鉴了 DNS，但它们不是同一种协议。它们之间有许多显着差异，NSEC 记录的使用就是其中之一。由于 DNSSEC 在 mDNS 上下文中没有意义（mDNS 没有授权），mDNS 将 NSEC 记录类型用于自己的用途。这是为了替换 DNS NXDOMAIN 功能，像这样（来自 RFC 6762 第 6.1 节）：
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.
DNS NSEC 记录不能使用名称压缩的原因是它们必须只有一个定义明确的二进制表示形式，可以进行加密签名。允许压缩意味着同一内容有几种不同的正确线格式表示，这在尝试验证签名时会是一个问题，因为在生成签名时无法确定使用了哪种表示。
mDNS 不签署任何东西，因此该限制不适用，因此可以在 NSEC 记录中免费使用名称压缩。
所以是的，存在冲突。但这不是同一协议的两个 RFC 之间的冲突，而是两个不同协议之间的冲突。 RFC 6762 中的第 19 节列出了 DNS 和 mDNS 之间的主要区别，确实有一些重要的区别。期望对两种协议使用完全相同的代码对我来说似乎不现实。
RFC 4034 规定如下：
A sender MUST NOT use DNS name compression on the Next Domain Name field when transmitting an NSEC RR.
* 强调我的
RFC 6762 规定如下：
All compliant Multicast DNS implementations MUST at least correctly generate and parse the restricted DNS NSEC record format described below:
- 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.
这似乎是一个冲突。一个 RFC 指出不应使用名称压缩，另一个建议兼容的实现必须能够生成和解析具有名称压缩的记录。
鉴于 mDNS 旨在与现有 DNS 解析器一起正常工作，我作为程序员应该如何实现生成和解析 NSEC 记录的方法？
我是否应该使用名称压缩？
虽然 mDNS 大量借鉴了 DNS，但它们不是同一种协议。它们之间有许多显着差异，NSEC 记录的使用就是其中之一。由于 DNSSEC 在 mDNS 上下文中没有意义（mDNS 没有授权），mDNS 将 NSEC 记录类型用于自己的用途。这是为了替换 DNS NXDOMAIN 功能，像这样（来自 RFC 6762 第 6.1 节）：
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.
DNS NSEC 记录不能使用名称压缩的原因是它们必须只有一个定义明确的二进制表示形式，可以进行加密签名。允许压缩意味着同一内容有几种不同的正确线格式表示，这在尝试验证签名时会是一个问题，因为在生成签名时无法确定使用了哪种表示。
mDNS 不签署任何东西，因此该限制不适用，因此可以在 NSEC 记录中免费使用名称压缩。
所以是的，存在冲突。但这不是同一协议的两个 RFC 之间的冲突，而是两个不同协议之间的冲突。 RFC 6762 中的第 19 节列出了 DNS 和 mDNS 之间的主要区别，确实有一些重要的区别。期望对两种协议使用完全相同的代码对我来说似乎不现实。