The RRL code also sends BADCOOKIE if there isn’t a server cookie instead of setting TC=1.
> On 15 Feb 2024, at 10:27, Mark Andrews <ma...@isc.org> wrote: > > > >> On 15 Feb 2024, at 03:03, Paul Wouters <p...@nohats.ca> 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@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
