Only for Compact Answers, otherwise downstream validators may treat the response as unvalidatable because the rcode doesn't match the DNSSEC proof. So, I actually see this is unbreaking things.
I think it's worth taking a step back though and asking a larger question: if we are restoring the NXDOMAIN signal with the NXNAME pseudo type in the NSEC record of NODATA responses, why do we also need to restore NXDOMAIN into the RCODE field? The answer to that I think is that a number of folks have argued to me that there are tons of security, analytics, and traffic characterization tools in existence today that look at the RCODE field for this purpose, and they are presently already broken because of this. We could ask them to modify their implementations to infer NXDOMAIN from the NXNAME pseudo-type, but who knows how long that will take (if ever). Shumon. On Wed, Mar 15, 2023 at 10:04 AM John Levine <jo...@taugh.com> wrote: > Wait, so if my cache does this and I change nothing, it silently turns > NXDOMAIN into NOERROR? That is badly broken. > > > > > Sent from my Galaxy > > -------- Original message -------- > From: Shumon Huque <shu...@gmail.com> > Date: 3/15/23 07:48 (GMT-05:00) > To: Ralf Weber <d...@fl1ger.de> > Cc: John R Levine <jo...@taugh.com>, dnsop@ietf.org, pe...@desec.io > Subject: Re: [DNSOP] Updated: Compact Denial of Existence > >> >> > Precisely, but it can still work if the signal is used in a hop by hop > fashion. > > So, if a resolver sends EDNS CompactAnswersOK signal to an authority > server, which returns a NODATA+NXNAME proof + RCODE=3 response, then the > resolver would have to intelligently manage that answer in its cache. To > downstream DO=1 queriers that also set CompactAnswersOK, it could return > that answer as is. To those that don't, it would have to reset the RCODE to > NOERROR. This imposes more complexity on the resolver implementation of > course, but I don't see any reason why it wouldn't work - and it would be > optional anyway. Clients that want to see the NXDOMAIN signal in the RCODE > might push their resolver service to implement it. > > Shumon. > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
