> On 15 Feb 2024, at 03:03, Paul Wouters <paul@xxxxxxxxx> wrote: > > On Wed, 14 Feb 2024, Roy Arends wrote: > >>>> 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. > > So it is not the benefit of the client/resolver, but the benefit of the > monitoring agent getting some more confidence the report is not spoofed. > Maybe make that more explicit in the text? > >>> 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? > > Which earlier transaction? If "er.otherdomain.example" is > used for receiving only failure reports? I guess NS queries for > "otherdomain.example" could trigger those. I am not sure what the current > practise of DNS COOKIES is. Do responders only request it when they see > their answer would be bigger than the question, or will they always > ask for it? Can it be enabled per-domain, so you enable it "always" > only for the error reporting zone? > > I can also see the case where resolvers might not want to invest in TCP > connections for error reporting, and might decide to not report errors at > all in such cases. So I am not sure the DNS COOKIES and/or TC strategy is > the right one, unless it would only trigger after receiving repetitive > reports. But if the reports are repetitive, no need to tell clients to > come back with TCP, since you presumable already know the error they > are wanting to report. I feel I am missing some guidance here. > > Perhaps this can be further explored in an Operational Considerations > section? You can respond with BADCOOKIE if there isn’t a server cookie. Still much cheaper than TCP. named’s 'require-server-cookie yes;’ does this. All nameservers that implement DNSCOOKIE should handle this as part of their recursive query handling. ``` % dig +showbadcookie +qr soa . ; <<>> DiG 9.19.20-dev <<>> +showbadcookie +qr soa . ;; global options: +cmd ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48594 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a396 ;; QUESTION SECTION: ;. IN SOA ;; QUERY SIZE: 40 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: BADCOOKIE, id: 48594 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a3960100000065cd4b21b108c8b316f0d5cc (good) ;; QUESTION SECTION: ;. IN SOA ;; Query time: 2 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Feb 15 10:22:09 AEDT 2024 ;; MSG SIZE rcvd: 56 ;; BADCOOKIE, retrying. ;; Sending: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47057 ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a3960100000065cd4b21b108c8b316f0d5cc ;; QUESTION SECTION: ;. IN SOA ;; QUERY SIZE: 56 ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47057 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 287badf367f9a3960100000065cd4b21b108c8b316f0d5cc (good) ;; QUESTION SECTION: ;. IN SOA ;; ANSWER SECTION: . 426 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2024021302 1800 900 604800 86400 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) (UDP) ;; WHEN: Thu Feb 15 10:22:09 AEDT 2024 ;; MSG SIZE rcvd: 131 % ``` > Paul > > _______________________________________________ > DNSOP mailing list > DNSOP@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
