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

[Shumon Huque <[e-mail]>]

On Tue, Jul 30, 2024 at 7:51 PM Brian Weis via Datatracker <[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.