RFC 4034和RFC 6762似乎相互矛盾。如何解決RFC之間的衝突？
RFC 4034規定如下：
發件人MUST發送NSEC RR當對下一個域名字段不使用DNS名稱的壓縮。
*重點煤礦
RFC 6762條規定如下：
所有兼容多播DNS實現至少必須正確生成和分析下面描述的限制DNS NSEC記錄格式：
- 「下一個域名」字段包含記錄的名稱。與名稱壓縮一起使用時，這意味着「下一個域名」字段始終佔用消息中的兩個字節。
這似乎是一個衝突。一個RFC表示不應該使用名稱壓縮，另一個RFC建議兼容實現必須能夠使用名稱壓縮來生成和解析記錄。
鑑於mDNS旨在與現有的DNS解析器正常工作，我作爲程序員應如何實現用於生成和解析NSEC記錄的方法？
我應該使用名稱壓縮嗎？
雖然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之間的主要區別，並且確實有一些重要的區別。我期望爲兩種協議使用完全相同的代碼似乎並不現實。