RFC 4034声明如下：
发送NSEC RR时，发件人绝不能在“下一个域名”字段上使用DNS名称压缩。
*强调我的
RFC 6762声明如下：
所有兼容的多播DNS实施必须至少正确生成和解析下面描述的受限DNS NSEC记录格式：
- ＆＃39;下一个域名＆＃39;字段包含记录的名称。与名称压缩一起使用时，这意味着＆＃39;下一个域名＆＃39;字段总是在消息中占用两个字节。
这似乎是一种冲突。一个RFC表示不应该使用名称压缩，另一个表明兼容的实现必须能够生成和解析具有名称压缩的记录。
鉴于mDNS旨在与现有DNS解析器一起正常工作，我作为程序员应该如何实现生成和解析NSEC记录的方法？
我是否应该使用名称压缩？
答案 0 :(得分：1)
虽然mDNS大量借用DNS，但它们并不是相同的协议。它们之间存在许多显着差异，NSEC记录的使用就是其中之一。由于DNSSEC在mDNS上下文中没有意义（mDNS没有委托），因此mDNS将NSEC记录类型用于自己的使用。这是替换DNS NXDOMAIN功能，如此（来自RFC 6762第6.1节）：
每当响应者收到对其具有的名称的查询时 已验证的独占所有权，对于该名称没有的类型 记录，响应者必须（除了下面（a）中允许的）响应
使用DNS NSEC记录声明该记录不存在 [RFC4034]。在多播DNS的情况下，NSEC记录不存在 用于其通常的DNSSEC [RFC4033]安全属性，但只是为了 作为表达哪些记录在给定的情况下存在或不存在的一种方式 名。
DNS NSEC记录不能使用名称压缩的原因是它们必须具有一个可以加密签名的明确定义的二进制表示。允许压缩意味着存在相同内容的几种不同的正确线格表示，这在尝试验证签名时会成为问题，因为在生成签名时无法确定使用了哪种表示。
mDNS不签名，因此限制不适用，因此可以在NSEC记录中自由使用名称压缩。
是的，存在冲突。但是对于相同的协议，它不是两个RFC之间的冲突，而是两个不同协议之间的冲突。 RFC 6762中的第19节列出了DNS和mDNS之间的主要区别，并且确实存在一些重要的差异。期望对两种协议使用完全相同的代码对我来说似乎不太现实。