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

[Paul Wouters <[e-mail]>]

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?

Paul