RFC 4592, "The Role of Wildcards in the Domain Name System", July 2006

4.7. NSEC RRSet at a Wildcard Domain Name
Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
Synthesis of these records will only occur when the query exactly
matches the record. Synthesized NSEC RRs will not be harmful as they
will never be used in negative caching or to generate a negative
response [RFC2308].

It should say:

4.7. NSEC RRSet at a Wildcard Domain Name
Wildcard domain names in DNSSEC signed zones will have an NSEC RRSet.
NSEC RRSets must not be synthesized from this wildcard NSEC.

Notes:

Synthesizing these records would destroy the semantics of the NSEC chain and could be very harmful if implementations would cache them and use them for "Aggressive Use of DNSSEC-Validated Cache" (RFC 8198).

RFC 4592, "The Role of Wildcards in the Domain Name System", July 2006

(1) [improper/misleading wording]
In the explanations to the Example in Section 2.2.1, RFC 4592
(near the top of page 9) says:
| The following responses would not be synthesized from any of the
| wildcards in the zone:
This wording is improper/misleading.
Perhaps, the RFC should better say:
| The following queries would not cause RRs to be synthesized for the
| answer from any of the wildcards in the zone:
(2) [typo]
The last paragraph of Section 2.2.2, on page 10, says:
As RFC 1034 also defines "an authoritative name error indicating that
| the name does not exist" in section 4.3.1, so this apparently is not
the intent of the original definition, justifying the need for an
updated definition in the next section.
"As ..., so ..." is redundant.
Thus, the RFC should say instead:
As RFC 1034 also defines "an authoritative name error indicating that
| the name does not exist" in section 4.3.1, this apparently is not the
intent of the original definition, justifying the need for an updated
definition in the next section.
(3) [typo]
In Section 3.3.1, the 4th paragraph, on page 12, says:
A source of synthesis does not guarantee having a RRSet to use for
synthesis. The source of synthesis could be an empty non-terminal.
It should say:
| A source of synthesis does not guarantee having an RRSet to use for
synthesis. The source of synthesis could be an empty non-terminal.
(4) [typo]
In Section 3.3.3, the last paragraph on page 13 says:
This is essentially the same text in part 'a' covering the processing
of CNAME RRSets.
It should say:
| This is essentially the same text as in part 'a' covering the
processing of CNAME RRSets.
(5) [incomplete change in example?]
In Section 4.4, the second-to-last paragraph on page 16 says:
The DNAME specification is not clear on whether DNAME records in a
cache are used to rewrite queries. In some interpretations, the
rewrite occurs; in others, it does not. Allowing for the occurrence
of rewriting, queries for "sub.a.b.example. A" may be rewritten as
| "sub.foo.bar.tld. A" by the former caching server and may be
| rewritten as "sub.a.foo.bar.tld. A" by the latter. Coherency is
lost, and an operational nightmare ensues.
"tld." does never appear in the preceding text; apparently it has
been replaced there by "example.net."
Therefore, the RFC should say instead:
The DNAME specification is not clear on whether DNAME records in a
cache are used to rewrite queries. In some interpretations, the
rewrite occurs; in others, it does not. Allowing for the occurrence
of rewriting, queries for "sub.a.b.example. A" may be rewritten as
| "sub.foo.bar.example.net. A" by the former caching server and may be
| rewritten as "sub.a.foo.bar.example.net. A" by the latter. Coherency
is lost, and an operational nightmare ensues.