NXT
Click on the red underlined text to get to the source
... DS) [RFC3658] introduction of new semantics for the NXT RR
that are incompatible with the semantics in [RFC2535 ...
... Delegation Signer (DS) introduces new semantics for the NXT RR that
are incompatible with the semantics in RFC 2535(-> 4035prop | 4034prop | 4033prop) ...
... semantics in RFC 2535(-> 4035prop | 4034prop | 4033prop). In RFC 2535(-> 4035prop | 4034prop | 4033prop), NXT
records were only required to be returned as part of a non-existence
proof. With DS ...
... NXT and
SIG(NXT). RFC 2535(-> 4035prop | 4034prop | 4033prop) didn't specify how a resolver was to interpret a
response with RCODE ...
... RCODE=0, AA=0, and both an NS and an NXT in the
authority section. Some widely deployed 2535-aware resolvers
...
... authority section. Some widely deployed 2535-aware resolvers
interpret any answer with an NXT as a proof of non-existence of the
requested record. This results in unsecure delegations being
...
... 2535(-> 4035prop | 4034prop | 4033prop)-aware)
resolvers need to be kept from seeing unsecure referrals that include
NXT records in the authority section. The simplest way to do that is
to change the type codes for SIG ...
... authority section. The simplest way to do that is
to change the type codes for SIG, KEY, and NXT.
The obvious drawback to this is that new resolvers will not be able
...
...
The observed problem with unsecure referrals could be addressed by
changing only the NXT type code or another subset of the type codes
that includes NXT ...
... NXT type code or another subset of the type codes
that includes NXT. This has the virtue of apparent simplicity, but
it risks introducing new problems or not going far enough. It's
quite possible that more incompatibilities exist between DS ...
... RFC2065] and,
due to under specification in those documents, interpret any answer
with an NXT as a non-existence proof. So long as that is the case,
zone owners will have a strong incentive to not sign any zones that
contain unsecure delegations ...
...
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above, largely
because the behavior of resolvers that receive unknown type codes is
...
... SIG, and NSEC (Next SECure) will replace NXT. These new types
completely replace the old types, except that SIG(0) [RFC2931 ...
... syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535(-> 4035prop | 4034prop | 4033prop) and RFC 3658(-> 4035prop | 4034prop | 4033prop) except for
...
... validate RRSIGs.
If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
special treatment. As an example, if a SIG ...
... to give error messages when loading zones containing SIG or NXT
records (KEY records may be included for SIG(0) or TKEY ...