Sorry, I don't follow. The whole point of the conditional behavior based on the EDNS signal, is to allow RCODE replacement without causing SERVFAIL. Perhaps I have not clearly described the details, and I also should write it up more precisely. I'll also wait for your write-up.
Shumon. On Wed, Mar 15, 2023 at 10:49 AM John Levine <[email protected]> wrote: > Now it sounds like NXDOMAIN turns into SERVFAIL. When I have a decent > keyboard I'll suggest a way this might not break unmodified downstream > clients. > > > > Sent from my Galaxy > > > -------- Original message -------- > From: Shumon Huque <[email protected]> > Date: 3/15/23 09:18 (GMT-05:00) > To: John Levine <[email protected]> > Cc: [email protected] > Subject: Re: [DNSOP] Updated: Compact Denial of Existence > > 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 <[email protected]> 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 <[email protected]> >> Date: 3/15/23 07:48 (GMT-05:00) >> To: Ralf Weber <[email protected]> >> Cc: John R Levine <[email protected]>, [email protected], [email protected] >> 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 [email protected] https://www.ietf.org/mailman/listinfo/dnsop
