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

[Mark Andrews <[e-mail]>]

> On 15 Feb 2024, at 03:03, Paul Wouters <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]