Hi Shumon, Thanks … your replies to the questions make sense to me.
Brian > On Jul 30, 2024, at 7:13 PM, Shumon Huque <shu...@gmail.com> wrote: > > On Tue, Jul 30, 2024 at 7:51 PM Brian Weis via Datatracker <nore...@ietf.org > <mailto:nore...@ietf.org>> wrote: >> Reviewer: Brian Weis >> Review result: Has Nits > > Thank you for your review Brian. > > [... Good summary deleted for brevity ...] > >> Security Considerations also mentions that some security tools rely >> on particular return codes to detect non-existent domain names, and >> their current method may be impacted by this change. This is >> unfortunate, but I suspect that there was no clean way to accommodate >> those semantics in this design. It is noted that if security tools >> support this new method that they will be relying on signed data >> rather than the unsigned header to obtain the same information. > > Yes, that is correct. > >> Also, the document describes an optional header flag which a resolver >> that returns a different status. This seems to be intended to aid >> security tools, but perhaps if they’ve updated their tool to send >> a new header flag they would also be able to update it to accept >> the main method described in this document. Is theres another >> practical reason for this optional feature? Or are the semantics >> of a resolver understanding both the old and new main methods just >> complicated and this makes it easier for them? > > The NXDOMAIN response code restoration methods are optional, > because we expect that not all resolver implementers will want to > make accommodations for this method (although some do plan to). > Impacted security tools could indeed be updated to recognize the > NXNAME signal, but there is some skepticism that this will happen > quickly because of inertia, unwillingness to do deeper packet > inspection, or because they are often written by folks without detailed > familiarity with the DNS protocol. The rcode restoration capability will > help them, and their users may decide to use resolvers that implement > this feature. In other words, the spec is providing the capability, and > we'll let customer demand help sort out where it might get deployed. > >> I’m a little confused by this statement in Section 4 (Response Code >> Restoration): “For non-existent names, implementations should try >> wherever possible, to preserve the response code value of 3 (NXDOMAIN). >> This is generally possible for non-DNSSEC enabled queries, >> namely those which do not set the DNSSEC_OK EDNS flag (DO bit).” I >> believe this is describing a case where the response does not include >> DNSSEC. Based on the name of the document that it was concerned >> only with a DNSSEC response, so it’s not clear to me why this >> suggestion needs to be made. > > Yes, your observation is correct. However, there was strong consensus > in the working group that this document explicitly state that non DNSSEC > enabled queries for non-existent names return the expected NXDOMAIN > response code (there are implementations of this protocol in the field for > example that return NODATA today for non-DNSSEC responses too). > >> One general suggestion is that it might be helpful for the RFC Editor >> if there was an explicit note somewhere warning them that Section 6.2 >> contains an (RFC TBD) self-reference that they’ll need to resolve. > > If we wanted to get rid of the self-reference we could also only state the > name of the protocol and omit the RFC#. > > Shumon. >
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
