[secdir] Re: Secdir early review of draft-ietf-dnsop-compact-denial-of-existence-04

[Brian Weis <[e-mail]>]

Hi Shumon,

Thanks … your replies to the questions make sense to me.

Brian

> On Jul 30, 2024, at 7:13 PM, Shumon Huque <[e-mail]> wrote:
> 
> On Tue, Jul 30, 2024 at 7:51 PM Brian Weis via Datatracker <[e-mail] <mailto:[e-mail]>> wrote:
>> Reviewer: Brian Weis
>> Review result: Has Nits
> 
> Thank you for your review Brian.
>  
> [... Good summary deleted for brevity ...]
>  
>> Security Considerations also mentions that some security tools rely
>> on particular return codes to detect non-existent domain names, and
>> their current method may be impacted by this change. This is
>> unfortunate, but I suspect that there was no clean way to accommodate
>> those semantics in this design. It is noted that if security tools
>> support this new method that they will be relying on signed data
>> rather than the unsigned header to obtain the same information.
> 
> Yes, that is correct.
>  
>> Also, the document describes an optional header flag which a resolver
>> that returns a different status. This seems to be intended to aid
>> security tools, but perhaps if they’ve updated their tool to send
>> a new header flag they would also be able to update it to accept
>> the main method described in this document.  Is theres another
>> practical reason for this optional feature? Or are the semantics
>> of a resolver understanding both the old and new main methods just
>> complicated and this makes it easier for them?
> 
> The NXDOMAIN response code restoration methods are optional,
> because we expect that not all resolver implementers will want to
> make accommodations for this method (although some do plan to).
> Impacted security tools could indeed be updated to recognize the
> NXNAME signal, but there is some skepticism that this will happen
> quickly because of inertia, unwillingness to do deeper packet
> inspection, or because they are often written by folks without detailed
> familiarity with the DNS protocol. The rcode restoration capability will
> help them, and their users may decide to use resolvers that implement
> this feature. In other words, the spec is providing the capability, and
> we'll let customer demand help sort out where it might get deployed.
>  
>> I’m a little confused by this statement in Section 4 (Response Code
>> Restoration): “For non-existent names, implementations should try
>> wherever possible, to preserve the response code value of 3 (NXDOMAIN).
>> This is generally possible for non-DNSSEC enabled queries,
>> namely those which do not set the DNSSEC_OK EDNS flag (DO bit).” I
>> believe this is describing a case where the response does not include
>> DNSSEC. Based on the name of the document that it was concerned
>> only with a DNSSEC response, so it’s not clear to me why this
>> suggestion needs to be made.
> 
> Yes, your observation is correct. However, there was strong consensus
> in the working group that this document explicitly state that non DNSSEC
> enabled queries for non-existent names return the expected NXDOMAIN
> response code (there are implementations of this protocol in the field for
> example that return NODATA today for non-DNSSEC responses too).
> 
>> One general suggestion is that it might be helpful for the RFC Editor
>> if there was an explicit note somewhere warning them that Section 6.2
>> contains an (RFC TBD) self-reference that they’ll need to resolve.
> 
> If we wanted to get rid of the self-reference we could also only state the
> name of the protocol and omit the RFC#.
> 
> Shumon.
>