On Tue, 2 Jan 2024 at 07:34, zuop...@cnnic.cn <zuop...@cnnic.cn> wrote:
>8
> This draft suggests a lightweight and backward-compatible mechanism to
> mitigate the risk of these attacks.
>
> Any comments are welcome!
>
The proposal contains internal inconsistencies and contradictions
which need to be addressed:
4.2. Responding to a request
DDC request option should be responded by a DDC-aware authoritative
server. For a DDC-not-aware server, the presence of a DDC request
option is ignored and the server responds as if no DDC request option
had been included in the request.
4.3. Processing Responses
If the client(usually a Recursive server) is expecting the response
to contain a DDC respond option and it is missing, the response MUST
be discarded.
The client has no way of knowing in advance if the server is DDC-aware.
Considering 4.2, merely sending a DDC request does not create any
reliable expectation that there will be a corresponding DDC response.
Regarding the processing of the DNS delegation respond option by a
recursive server, there are 4 possibilities:
(1) The client is expecting the response to contain a DDC respond
option and it is missing. In this case, the client processes
the response as normal and does not implement DNS delegation
confirmation.
This contradicts the MUST in the opening paragraph of 4.3
--rwf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
