SIG
Click on the red underlined text to get to the source
... DS RR in the form of an NXT and
SIG(NXT). RFC 2535(-> 4035prop | 4034prop | 4033prop) didn't specify how a resolver was to interpret a
...
... NXT records in the authority section. The simplest way to do that is
to change the type codes for SIG, KEY, and NXT.
...
... earlier semantics. Legacy resolvers may also be confused by seeing
records they recognize (SIG and KEY) while being unable to find NXTs.
Although it may seem unnecessary to fix that which is not obviously
broken, it's far cleaner to change all of the type codes at once.
...
...
This document changes the type codes of SIG, KEY, and NXT. This
approach is the cleanest and safest of those discussed above, largely
...
... Resource Record SIGnature) will replace
SIG, and NSEC (Next SECure) will replace NXT. These new types
...
... NSEC (Next SECure) will replace NXT. These new types
completely replace the old types, except that SIG(0) [RFC2931] and
TKEY ...
... TKEY [RFC2930] will continue to use SIG and KEY.
The new types will have exactly the same syntax and semantics ...
... The new types will have exactly the same syntax and semantics as
specified for SIG, KEY, and NXT in RFC 2535(-> 4035prop | 4034prop | 4033prop) and RFC 3658(-> 4035prop | 4034prop | 4033prop) ...
... validate SIGs or use KEYs to validate RRSIGs.
If SIG, KEY, or NXT RRs are included in a zone, they MUST NOT receive
...
... NXT RRs are included in a zone, they MUST NOT receive
special treatment. As an example, if a SIG is included in a signed
zone, there MUST be an RRSIG for it. Authoritative servers may wish
...
... RRSIG for it. Authoritative servers may wish
to give error messages when loading zones containing SIG or NXT
records (KEY records may be included for SIG ...
... transaction security mechanisms
(SIG(0) and TKEY) to use different sets of algorithms, the existing
...