> On 14 Feb 2024, at 03:31, Paul Wouters <paul@xxxxxxxxx> wrote: > > On Wed, 14 Feb 2024, Roy Arends wrote: > >>> 1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no >>> statement about how to mitigate the effects when these are not used. What ought >>> someone to do when this is not done? >> >> It is recommended that the client (the resolver) sets the DNS COOKIE. The benefit of using cookies is for the client. It is to make sure that the response is genuine. > > Does it? Not for an on-path attacker that sees the COOKIE in the clear. > So what attack does this really counter? Ah, no, apologies, it doesn’t. (I’ll blame this on my DNSSEC muscle memory). I should know better. I’ll try again: There is text in the document that specifies what the monitoring agent should do if cookies are not used: Section 6.3: The monitoring agent SHOULD respond to queries received over UDP that have no DNS COOKIE set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query over TCP. > And if using TLS, then one wouldn't need a COOKIE anymore to prove genuineness. > >> However, there is little value in the response. The actual value for error-reporting is to the authoritative server that may have an issue. >> >> When cookies are not set, or are not used, there is language that states the following: >> >> The monitoring agent SHOULD respond to queries received over UDP that have no DNS COOKIE set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query over TCP. > > This sounds more like an attempt for a mechanism for the monitoring agent > to determine that the incoming report is not send from a spoofed address, > but it wouldn't work like that. Setting the TC would work, provided the > client comes back. Or if the monitoring agent would demand a COOKIE > before answering (even if the answer is not the actual data the resolver > wants anyway). If the monitoring agent requests a COOKIE, it would force > the resolver to resend with the COOKIE, proving it is not just a spoofed > packet. But that would always result in double the load to the > monitoring agent. A cookie may be set due to an earlier transaction, no? Roy -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
