On Wed, 14 Feb 2024, Roy Arends wrote:
1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), but no
statement about how to mitigate the effects when these are not used. What ought
someone to do when this is not done?
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?
And if using TLS, then one wouldn't need a COOKIE anymore to prove genuineness.
However, there is little value in the response. The actual value for error-reporting is to the authoritative server that may have an issue.
When cookies are not set, or are not used, there is language that states the following:
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.
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.
I hope this is sufficient.
I'm not the person this was written for, but now I an actually confused
what the purpose of the DNS COOKIES is.
Paul
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
