Re: [Tsv-art] [DNSOP] [Last-Call] Tsvart telechat review of draft-ietf-dnsop-dns-error-reporting-07

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 <marka@isc.org> wrote:
> 
> 
> 
>> On 15 Feb 2024, at 03:03, Paul Wouters <paul@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: marka@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: marka@isc.org