The proposed standard for DNS cookies specifies that the server cookie is to be computed as follows:
The Server Cookie SHOULD consist of or include a 64-bit or larger pseudo-random function of the request source IP address, the request Client Cookie, and a secret quantity known only to the server.
The reasoning provided for the inclusion of the client cookie is as follows:
However, NAT devices sometimes also map ports. This can cause multiple DNS requests and responses from multiple internal hosts to be mapped to a smaller number of external IP addresses, such as one address. Thus there could be many clients behind a NAT box that appear to come from the same source IP address to a server outside that NAT box. If one of these were an attacker (think Zombie or Botnet), that behind-NAT attacker could get the Server Cookie for some server for the outgoing IP address by just making some random request to that server. It could then include that Server Cookie in the COOKIE OPT of requests to the server with the forged local IP address of some other host and/or client behind the NAT box. (Attacker possession of this Server Cookie will not help in forging responses to cause cache poisoning as such responses are protected by the required Client Cookie.)
To fix this potential defect, it is necessary to distinguish different clients behind a NAT box from the point of view of the server. It is for this reason that the Server Cookie is specified as a pseudo-random function of both the request source IP address and the Client Cookie. From this inclusion of the Client Cookie in the calculation of the Server Cookie, it follows that a stable Client Cookie, for any particular server, is needed. If, for example, the request ID was included in the calculation of the Client Cookie, it would normally change with each request to a particular server. This would mean that each request would have to be sent twice: first to learn the new Server Cookie based on this new Client Cookie based on the new ID and then again using this new Client Cookie to actually get an answer. Thus the input to the Client Cookie computation must be limited to the server IP address and one or more things that change slowly such as the client secret.
What is the attack that this is supposed to protect against? And how does it achieve said protection?
The three attacks mentioned in the document are:
- DNS Amplification Attacks
- DNS Server Denial-of-Service
- Cache Poisoning and Answer Forgery Attacks
But as far as I can tell the inclusion of client cookie in the server cookie calculation cannot be addressing any of those.
DNS amplification attacks where attacker and victim are behind the same NAT will still be possible. When the attacker has received the server cookie, he can simply start spoofing the IP of the victim while using client cookie and server cookie exchanged with the server previously. Because client and victim are behind the same NAT, the change in client IP address will be invisible to the server. Thus the client cookie still maps to the same server cookie, and the attack will succeed.
In the case of DNS Server DoS, the aim of the cookies is just to ensure that the server will know the correct IP address of whoever is performing the attack. When attacker is behind a NAT, the server will see the IP address of that NAT regardless of what spoofing the attacker performs behind the NAT. And the cookies don't change that.
In the case of forged replies, the protection is provided by the client cookie of the victim which remains unknown to the attacker. So regardless of how the server cookie is computed, this attack would fail. Moreover forged replies are by definition not generated by the server thus there will be no validation of the server cookie anyway.
So if the inclusion of client cookie in server cookie computation isn't done for one of those three reasons, then what is the purpose of it?