dnspython icon indicating copy to clipboard operation
dnspython copied to clipboard
verified publisher icon rthalley

Initial changes to prepare for SIG(0)

Open jschlyter opened this issue 8 months ago • 1 comments

  • Add shared RRSIGBase for code shared between RRSIG and SIG
  • Modify RRSIG to use RRSIGBase
  • Add KEY RR
  • Add SIG RR

jschlyter avatar Jun 15 '25 09:06 jschlyter

I think all of this looks reasonable, but it's missing the differences between KEY and DNSKEY - KEY allows symbolic constants to be be used for the protocol and flags fields (https://www.rfc-editor.org/rfc/rfc2535#section-7.1), while DNSKEY (and dnspython's parser) does not.

bwelling avatar Jun 16 '25 16:06 bwelling

Trying to pick up this work after some time…

I think all of this looks reasonable, but it's missing the differences between KEY and DNSKEY - KEY allows symbolic constants to be be used for the protocol and flags fields (https://www.rfc-editor.org/rfc/rfc2535#section-7.1), while DNSKEY (and dnspython's parser) does not.

Does something like this work for you @bwelling ?

jschlyter avatar Sep 14 '25 16:09 jschlyter

Looking at RFC 2535 for a minute, I also noticed this text from section 7.1:

Note that if the type flags field has the NOKEY value, nothing
appears after the algorithm octet.

I believe the current code will fail if there are no base64 encoded chunks to concatenate. I don't know if this is worth addressing, although it might be needed if tests that depend on it are copied from elsewhere.

bwelling avatar Sep 15 '25 21:09 bwelling

Looking at RFC 2535 for a minute, I also noticed this text from section 7.1:

Note that if the type flags field has the NOKEY value, nothing
appears after the algorithm octet.

I believe the current code will fail if there are no base64 encoded chunks to concatenate. I don't know if this is worth addressing, although it might be needed if tests that depend on it are copied from elsewhere.

416f72688d368f89c9817374f015df032f074dc9 should do it?

jschlyter avatar Sep 16 '25 06:09 jschlyter

Looking at RFC 2535 for a minute, I also noticed this text from section 7.1:

Note that if the type flags field has the NOKEY value, nothing
appears after the algorithm octet.

I believe the current code will fail if there are no base64 encoded chunks to concatenate. I don't know if this is worth addressing, although it might be needed if tests that depend on it are copied from elsewhere.

416f726 should do it?

Maybe? I'm not sure if the RFC is saying that the flags must equal NOKEY or must contain both bits that comprise NOKEY.

bwelling avatar Sep 16 '25 06:09 bwelling

Maybe? I'm not sure if the RFC is saying that the flags must equal NOKEY or must contain both bits that comprise NOKEY.

I'll ask Donald.

jschlyter avatar Sep 16 '25 06:09 jschlyter

Refactored after more Tokenizer helpers and some feedback from Donald Eastlake 3rd.

jschlyter avatar Sep 20 '25 16:09 jschlyter

I'm fine with this, though it would be nice to fix the type errors. I think # pyright: ignore at the points it is unhappy about, similar to those nearby, would do it.

rthalley avatar Sep 24 '25 17:09 rthalley

Oh, and if what I said about pyright wasn't clear enough, or you'd just rather I do it, let me know and I'll merge and fix it.

rthalley avatar Sep 24 '25 17:09 rthalley

I'm fine with this, though it would be nice to fix the type errors. I think # pyright: ignore at the points it is unhappy about, similar to those nearby, would do it.

@rthalley Should be fine now. Perhaps including pyright in dev dependency would make sense? #1227

jschlyter avatar Sep 24 '25 20:09 jschlyter