On Fri, Oct 4, 2024 at 10:21 AM Vladimír Čunát <vladimir.cunat=2Bietf= 40nic...@dmarc.ietf.org> wrote:
> On 04/10/2024 05.20, John Levine wrote: > > Editorially, I would move the stuff about approaches not taken to an appendix > to > avoid confusing people. That includes the second and last paragraphs of > section 2. > > Yes, please. > Yes, I agree too. We will do that. (I wanted to mention these alternative approaches as they have actually been deployed in the field, and it would be good for people examining old packet traces to have a reference for what they are seeing. Putting this in an appendix is a good approach.) Hence, in the penultimate paragraph in section 2, the sentence that starts "No > special handling" should say that resolvers MUST implement the response code > restoration in 4.1 unless the client sends the EDNS0 Compact Answers OK > option. > > You can't restore the RCODE by default. This topic is repeating. Such > answers must not pass DNSSEC validation, as I understand it (for those that > don't implement this draft). Backwards compatibility unfortunately > complicates all this. > Yes, apart from backwards compatibility, we know there are some resolver implementers that don't want to add complexity just to restore the response code for these implementations. Personally, I think that they probably should, because this scheme is already so deployed widely, but ... I agree that query minimization can be inefficient with compact answers (if > the query goes deeper than the existing names), but software wanting to > avoid this case will just have to react to NXNAME in addition to RCODE. > Yes. Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
