Thanks for pointing out the mistake. I will revise it in next version.

The opening paragraph of 4.3 should be removed and how a recursive DNS responds 
to a DDC request option should be added in 4.2. 
As recent research has found new attack that by pointing the glue address to 
public recursive DNS which does not follow standard specification well(like 
ignore RD bit), can significantly amplify attack traffic.




zuop...@cnnic.cn
 
From: Dick Franks
Date: 2024-01-22 02:16
To: zuop...@cnnic.cn
CC: dnsop
Subject: Re: [DNSOP] Fw: New Version Notification for 
draft-zuo-dnsop-delegation-confirmation-00.txt
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
 
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to