On Sun, Mar 12, 2023 at 6:03 AM Vladimír Čunát <vladimir.cu...@nic.cz> wrote:
> On 06/03/2023 03.35, Shumon Huque wrote: > > I suspect that unilaterally putting NXDOMAIN into the rcode field will > break a lot of validator code. They are likely to use the rcode to advise > them on what type of proof to look for in the message body, and they won't > find a traditional NXDOMAIN proof. > > My understanding of RFCs is that NXDOMAIN or NOERROR are a mandatory part > of what needs to be proven by the records inside. If the proof doesn't > match the RCODE, surely validators should SERVFAIL. I don't think you can > salvage this by a simple new EDNS option; it's the signed records where you > need to prove the result you want. > The NXDOMAIN or NOERROR "state" definitely has to be proven by the signed records inside the message. I haven't found anywhere in the spec that says that this state has to match the RCODE value though (I skimmed RFC 4035 and 5155 a couple of days ago). Let me know if it's there and I didn't spot it. Those specs solely talk about how to determine various responses from signed records without reference to RCODE (RCODE is mentioned only in connection with setting SERVFAIL for responses that fail to or cannot be validated, and parenthetically in the example message contents in the appendix). It may be an implicit assumption that they should match the RCODE, but I think there is room for a debate. As I mentioned previously, the RCODE is unauthenticated, and so at most it should only be used as a hint as to what proof exists in the message body. And it is certainly not required to validate such proofs. For example, RFC9102 (TLS DNSSEC Chain Extension) delivers a chain of signed RRsets without any response code, and validators are expected to verify them and determine the appropriate state (e.g. Answer vs NXDOMAIN vs NODATA vs unsigned delegation along the path). In any case, my assumption remains that unconditionally changing the RCODE for compact answer nxdomains will break many existing validators. I'm assuming from your response that that's the case with Knot. I was waiting to see if other implementers would confirm the behavior in their implementations. But in the meantime, I've done some very quick empirical tests (with a hacked up DNS authoritative server that returns NXDOMAIN for all signed responses) and the results are interesting: BIND and 8.8.8.8 SERVFAIL on everything that doesn't contain a real NXDOMAIN proof; Unbound appears to authenticate NODATA responses fine, and sets AD=1 and resets RCODE=NOERROR to downstream queries, but SERVFAILS on other non NXDOMAIN proofs; and Cloudflare/1.1.1.1 appears to authenticate all responses fine and sets AD=1, but returns the lied about RCODE intact to downstream queriers. So, I think the only way we could safely do RCODE replacement for signed responses is by the use of an EDNS signal. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
