This is mostly a question for developers: I've noticed that test suite for
Unbound contains scenarios with DSA signatures in a different format than
specified by RFC 2536 (http://tools.ietf.org/html/rfc2536#section-3).
The DNSSEC DSA signature should be alywas 41 bytes long. But if I take a look
for instance at testdata/val_nsec3_nods.rpl line 97, I can see the following
record:
This signature is 46 bytes long. And it is sucessfully validated by Unbound.
Obviously, it's the DSA signature encoded as the X.509 Dss-Sig-Value
(https://tools.ietf.org/html/rfc2459#section-7.2.2).
Is there a reason why does Unbound you accept these signatures?
This is mostly a question for developers: I've noticed that test
suite for Unbound contains scenarios with DSA signatures in a
different format than specified by RFC 2536
(http://tools.ietf.org/html/rfc2536#section-3).
The DNSSEC DSA signature should be alywas 41 bytes long. But if I
take a look for instance at testdata/val_nsec3_nods.rpl line 97, I
can see the following record:
This signature is 46 bytes long. And it is sucessfully validated by
Unbound. Obviously, it's the DSA signature encoded as the X.509
Dss-Sig-Value (https://tools.ietf.org/html/rfc2459#section-7.2.2).
Is there a reason why does Unbound you accept these signatures?
These signatures are produced by (an old?) signer. Unbound is
compatible with its quirks. DSA is almost not deployed at all for
DNSSEC, and the signer may already have been fixed for a long time.
Unbound is compatible to remove false-positives from validation
failures as much as possible.