On Tue, Mar 28, 2023 at 10:01 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > On Wed, Mar 15, 2023 at 08:48:29AM -0400, Shumon Huque wrote: > > > 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. > > Adding EDNS0 signals here is much too complex. The DO bit is > sufficient. A validating resolver that supports the proposed > specification can infer NXDOMAIN from the form of the NSEC RR. > If it does not support the proposed specification, then the presented > DoE proof is NODATA, and that must be sent. So just always send NODATA > (NOERROR) when the DO bit is set in the query. > > The clients that see the restored NXDOMAIN will be the stub resolvers > that don't do validation, and sit behind a local validating forwarder. > The issue is that there are a lot of security, diagnostic, and traffic characterization tools that examine the RCODE field and want that to be accurate even for DO=1 queries -- not just a converted RCODE by a NXNAME recognizing resolver, but in the response from the authorities too. In theory those could be enhanced to recognize NXNAME, but I think there is a lot of pessimism that would happen anytime soon, since many of them are generally not developed by DNS experts, and older deployed code generally hangs around forever. I recently spoke to the vendor of one such tool, and suggested that they need to look deeper in the packet to get the info out of the NSEC bitmap, but they seemed pessimistic that they could do that at wire speed with high volume DNS traffic. Maybe this problem is too complex to solve, but let's at least talk through the details first before disbanding it. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
