You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The zone contains TXT and NS records and currently records of same name, type and class are ordered using sorted() in sign_rrset().
But that seems to be an issue as the ordering is wrong.
RFC 4034 6.3 says:
For the purposes of DNS security, RRs with the same owner name,
class, and type are sorted by treating the RDATA portion of the
canonical form of each RR as a left-justified unsigned octet sequence
in which the absence of an octet sorts before a zero octet.
which does not seem to always be the case using sorted() and instead the canonial for of the entire record has to be used for the sorting to get the signature generated correctly.
I did a quick test by re-using code from _canonical_order() to order by rData and the issue seems to be fixed and the records could be validated then.
The text was updated successfully, but these errors were encountered:
I just discovered in issue with signing zones.
The zone contains TXT and NS records and currently records of same name, type and class are ordered using sorted() in sign_rrset().
But that seems to be an issue as the ordering is wrong.
RFC 4034 6.3 says:
For the purposes of DNS security, RRs with the same owner name,
class, and type are sorted by treating the RDATA portion of the
canonical form of each RR as a left-justified unsigned octet sequence
in which the absence of an octet sorts before a zero octet.
which does not seem to always be the case using sorted() and instead the canonial for of the entire record has to be used for the sorting to get the signature generated correctly.
I did a quick test by re-using code from _canonical_order() to order by rData and the issue seems to be fixed and the records could be validated then.
The text was updated successfully, but these errors were encountered: