I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Has Nits.

This document adds a “Compact Denial of Existence in DNSSEC” method
to a couple of existing “denial of existence” methods using DNSSEC
(i.e., NSEC and NSEC3).  Denial of Existence means “proving that a
DNS name or record type does not exist”. It does this by returning
a dynamically signed DNS response with this information.  A new RR
type (NXNAME) is defined in the document, which is returned by a
server with the “denial of existence” declaration.  This method is
said to be smaller in size and requires less cryptographic computing
than the previous methods, including when those methods dynamically
sign updates.

With the caveat that I am not very familiar with DNS protocols,
this document seems to have generally considered the security
ramifications of the method. The risks of on-line signing of DNS
records are covered. Additionally, the document states that this
method “prevents adversaries from enumerating the entire contents
of DNS zones by walking NSEC chains”.

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.
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?

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.

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.